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

[Fred Konrad <konrad@adacore.com>]

Missed this one sorry.

Le 6/12/20 à 10:31 AM, Laurent Vivier a écrit :
> 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
>>
>> 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:
>>

[...]

> 
> According to "M68000 FAMILY PROGRAMMER’S REFERENCE MANUAL" the explicit
> integer bit is "Don't care" for signed infinite (a.high == 0x7FFF) (this
> is the case this patch manages).
> 
> But wit a zero exponent and a non zero mantissa, it's a denormal number,
> and a signed zero has also a zero explicit integer bit but a zero
> mantissa. (both cases are already managed in the existing code).
> 
> with a non zero exponent less than the maximum value it's an unnormal
> number.
> 
> The denormal and unnormal numbers must be managed during the load
> operation in the m68k TCG emulation to generate directly the FP_UNIMP
> exception.

Is this already handled in the TCG code?

Thanks,
Fred

> 
> So I think, in the end, we don't have invalid number at softfloat level
> and floatx80_invalid_encoding() should always return "false" for
> TARGET_M68K.
> 
> Thanks,
> Laurent
>