When FPCR.AH is 1, the behaviour of some instructions changes:
* AdvSIMD BFCVT, BFCVTN, BFCVTN2, BFMLALB, BFMLALT
* SVE BFCVT, BFCVTNT, BFMLALB, BFMLALT, BFMLSLB, BFMLSLT
* SME BFCVT, BFCVTN, BFMLAL, BFMLSL (these are all in SME2 which
QEMU does not yet implement)
* FRECPE, FRECPS, FRECPX, FRSQRTE, FRSQRTS
The behaviour change is:
* the instructions do not update the FPSR cumulative exception flags
* trapped floating point exceptions are disabled (a no-op for QEMU,
which doesn't implement FPCR.{IDE,IXE,UFE,OFE,DZE,IOE})
* rounding is always round-to-nearest-even regardless of FPCR.RMode
* denormalized inputs and outputs are always flushed to zero, as if
FPCR.{FZ,FIZ} is {1,1}
* FPCR.FZ16 is still honoured for half-precision inputs
(See the Arm ARM DDI0487L.a section A1.5.9.)
We can provide all these behaviours with another pair of float_status fields
which we use only for these insns, when FPCR.AH is 1. These float_status
fields will always have:
* flush_to_zero and flush_inputs_to_zero set for the non-F16 field
* rounding mode set to round-to-nearest-even
and so the only FPCR fields they need to honour are DN and FZ16.
In this commit we only define the new fp_status fields and give them
the required behaviour when FPSR is updated. In subsequent commits
we will arrange to use this new fp_status field for the instructions
that should be affected by FPCR.AH in this way.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
I'm not super enthusiastic about the ah_fp_status naming, which sort
of suggests it's always to be used when AH=1, rather than "for this
specific group of insns when AH=1". But I couldn't think of a better
name that was still reasonably short...
---