On 17/2/25 13:50, Peter Maydell wrote:
Because floatx80 has an explicit integer bit, this permits some
odd encodings where the integer bit is not set correctly for the
floating point value type. In In Intel terminology the
categories are:
exp == 0, int = 0, mantissa == 0 : zeroes
exp == 0, int = 0, mantissa != 0 : denormals
exp == 0, int = 1 : pseudo-denormals
0 < exp < 0x7fff, int = 0 : unnormals
0 < exp < 0x7fff, int = 1 : normals
exp == 0x7fff, int = 0, mantissa == 0 : pseudo-infinities
exp == 0x7fff, int = 1, mantissa == 0 : infinities
exp == 0x7fff, int = 0, mantissa != 0 : pseudo-NaNs
exp == 0x7fff, int = 1, mantissa == 0 : NaNs
The usual IEEE cases of zero, denormal, normal, inf and NaN are always valid.
x87 permits as input also pseudo-denormals.
m68k permits all those and also pseudo-infinities, pseudo-NaNs and unnormals.
Currently we have an ifdef in floatx80_invalid_encoding() to select
the x86 vs m68k behaviour. Add new floatx80_behaviour flags to
select whether pseudo-NaN and unnormal are valid, and use these
(plus the existing pseudo_inf_valid flag) to decide whether these
encodings are invalid at runtime.
We leave pseudo-denormals as always-valid, since both x86 and m68k
accept them.
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
---
include/fpu/softfloat-types.h | 14 +++++++
include/fpu/softfloat.h | 70 ++++++++++++++++++-----------------
fpu/softfloat.c | 2 +-
target/i386/tcg/fpu_helper.c | 24 ++++++------
target/m68k/cpu.c | 28 +++++++++++++-
5 files changed, 92 insertions(+), 46 deletions(-)
Again, passing float_status argument to floatx80_invalid_encoding
in a preliminary patch:
3 files changed, 77 insertions(+), 33 deletions(-)
