Re: [PATCH 1/2] softfloat: m68k: infinity is a valid encoding

[Laurent Vivier]

Le 28/04/2020 à 19:17, KONRAD Frederic a écrit :
> The MC68881 say about infinities (3.2.4):
> 
> "*For the extended precision format, the most significant bit of the
> mantissa (the integer bit) is a don't care."
> 
> https://www.nxp.com/docs/en/reference-manual/MC68881UM.pdf

As we use 68040 I refer to:

https://www.nxp.com/files-static/archives/doc/ref_manual/M68000PRM.pdf

> 
> The m68k extended format is implemented with the floatx80 and
> floatx80_invalid_encoding currently treats 0x7fff00000000000000000000 as
> an invalid encoding.  This patch fixes floatx80_invalid_encoding so it
> accepts that the most significant bit of the mantissa can be 0.
> 
> This bug can be revealed with the following code which pushes extended
> infinity on the stack as a double and then reloads it as a double.  It
> should normally be converted and read back as infinity and is currently
> read back as nan:
> 
>         .global _start
>         .text
> _start:
>         lea val, %a0
>         lea fp, %fp
>         fmovex (%a0), %fp0
>         fmoved %fp0, %fp@(-8)
>         fmoved %fp@(-8), %fp0
> end:
>         bra end
> 
> .align 0x4
> val:
>         .fill 1, 4, 0x7fff0000
>         .fill 1, 4, 0x00000000
>         .fill 1, 4, 0x00000000
> .align 0x4
>         .fill 0x100, 1, 0
> fp:
> 
> -------------
> 
> (gdb) tar rem :1234
> Remote debugging using :1234
> _start () at main.S:5
> 5              lea val, %a0
> (gdb) display $fp0
> 1: $fp0 = nan(0xffffffffffffffff)
> (gdb) si
> 6             lea fp, %fp
> 1: $fp0 = nan(0xffffffffffffffff)
> (gdb) si
> _start () at main.S:7
> 7              fmovex (%a0), %fp0
> 1: $fp0 = nan(0xffffffffffffffff)
> (gdb) si
> 8             fmoved %fp0, %fp@(-8)
> 1: $fp0 = inf
> (gdb) si
> 9             fmoved %fp@(-8), %fp0
> 1: $fp0 = inf
> (gdb) si
> end () at main.S:12
> 12          bra end
> 1: $fp0 = nan(0xfffffffffffff800)
> (gdb) x/1xg $fp-8
> 0x40000120 <val+260>:   0x7fffffffffffffff
> 
> Signed-off-by: KONRAD Frederic <address@hidden>
> ---
>  include/fpu/softfloat.h | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/fpu/softfloat.h b/include/fpu/softfloat.h
> index ecb8ba0..dc80298 100644
> --- a/include/fpu/softfloat.h
> +++ b/include/fpu/softfloat.h
> @@ -688,7 +688,12 @@ static inline int floatx80_is_any_nan(floatx80 a)
>  
> *----------------------------------------------------------------------------*/
>  static inline bool floatx80_invalid_encoding(floatx80 a)
>  {
> +#if defined(TARGET_M68K)
> +    return (a.low & (1ULL << 63)) == 0 && (((a.high & 0x7FFF) != 0)
> +                                           && (a.high != 0x7FFF));
> +#else
>      return (a.low & (1ULL << 63)) == 0 && (a.high & 0x7FFF) != 0;
> +#endif
>  }
>  
>  #define floatx80_zero make_floatx80(0x0000, 0x0000000000000000LL)
> 

This is denormalized numbers and should generate an exception.

I tried something like that in the past:

https://patchew.org/QEMU/address@hidden/address@hidden/

Pierre tried recently:
https://patchew.org/QEMU/address@hidden/

See "1.6.2 Denormalized Numbers" in M68000 FAMILY PROGRAMMER’S REFERENCE
MANUAL.

"Since the extended-precision data format has an explicit integer bit, a
number can be formatted with a nonzero exponent, less than the maximum
value, and a zero integer bit. The IEEE 754 standard does not define a
zero integer bit. Such a number is an unnormalized number. Hardware does
not directly support denormalized and unnormalized numbers, but
implicitly supports them by trapping them as unimplemented data types,
allowing efficient conversion in software."

But m68k FPU exceptions are not currently implemented in QEMU.

Thanks,
Laurent