qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Bennée
Subject: Re: [PATCH 1/2] softfloat: m68k: infinity is a valid encoding
Date: Wed, 29 Apr 2020 21:51:05 +0100
User-agent: mu4e 1.4.1; emacs 28.0.50

Laurent Vivier <address@hidden> writes:

> Le 29/04/2020 à 11:26, Alex Bennée a écrit :
>> 
>> Laurent Vivier <address@hidden> writes:
>> 
>>> Le 28/04/2020 à 20:43, Alex Bennée a écrit :
>>>>
>>>> KONRAD Frederic <address@hidden> writes:
>>>>
>>>>> 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:
>>>>
>>>> Do you have any real HW on which you could record some .ref files for
>>>> the various multiarch float tests we have (float_convs/float_madds)?
>>>> Does this different of invalid encoding show up when you add them?
>>>
>>> On my side, in the past when I started to implement m68k FPU, I used
>>> TestFloat and SoftFloat I have ported to m68k and I compare the result
>>> in QEMU and in a Quadra 800.
>> 
>> Surely TestFloat and SoftFloat is all emulation though?
>> 
>> Anyway if you have a Quadra 800 running Linux could you generate some
>> .ref files for the float_convs and float_madds test cases. The binaries
>> are static so you should just be able to copy them and run.
>> 
>>
>
> Here are the files I have generated on Q800.

So running those with:

  run-float_convs: QEMU_OPTS += -cpu m68040
  run-float_madds: QEMU_OPTS += -cpu m68040

We see the m68k float needs a fair bit of work from the get go:

      Reference                                            qemu-m68k -cou m68040

  ### Rounding to nearest                                               ### 
Rounding to nearest
                                                                >       from 
single: f32(-nan:0xffbfffff)
                                                                >         to 
double: f64(-nan:0x00fff7ffffe0000000) (OK)
                                                                >          to 
int32: 2147483647 (OK)
                                                                >          to 
int64: 9223372034707292159 (OK)
                                                                >         to 
uint32: 2147483647 (OK)
                                                                >         to 
uint64: 9223372034707292159 (OK)
  from single: f32(-nan:0xffffffff)                             from single: 
f32(-nan:0xffffffff)
    to double: f64(-nan:0x00ffffffffe0000000) (OK)                to double: 
f64(-nan:0x00ffffffffe0000000) (OK)
     to int32: 2147483392 (INVALID)                           |    to int32: 
2147483647 (OK)
     to int64: 9223370939490631424 (INVALID)                  |    to int64: 
9223372034707292159 (OK)
    to uint32: 2147483392 (INVALID)                           |   to uint32: 
2147483647 (OK)
    to uint64: 9223370939490631424 (INVALID)                  |   to uint64: 
9223372034707292159 (OK)
  from single: f32(-nan:0xffffffff)                           | from single: 
f32(nan:0x7fffffff)
    to double: f64(-nan:0x00ffffffffe0000000) (OK)            |   to double: 
f64(nan:0x007fffffffe0000000) (OK)
     to int32: 2147483392 (INVALID)                           |    to int32: 
2147483647 (OK)
     to int64: 9223370939490631424 (INVALID)                  |    to int64: 
9223372034707292159 (OK)
    to uint32: 2147483392 (INVALID)                           |   to uint32: 
2147483647 (OK)
    to uint64: 9223370939490631424 (INVALID)                  |   to uint64: 
9223372034707292159 (OK)
  from single: f32(-inf:0xff800000)                           <
    to double: f64(-inf:0x00fff0000000000000) (OK)            <
     to int32: -2147483648 (INVALID)                          <
     to int64: 1 (INVALID)                                    <
    to uint32: -2147483648 (INVALID)                          <
    to uint64: -9223372034707292160 (INVALID)                 <
  from single: f32(-0x1.fffffe00000000000000p+127:0xff7fffff)   from single: 
f32(-0x1.fffffe00000000000000p+127:0xff7fffff)
    to double: f64(-0x1.fffffe00000000000000p+127:0x00c7efffffe   to double: 
f64(-0x1.fffffe00000000000000p+127:0x00c7efffffe
     to int32: -2147483648 (INVALID)                          |    to int32: 
-2147483648 (OK)
     to int64: 1 (INVALID)                                    |    to int64: 1 
(OK)
    to uint32: -2147483648 (INVALID)                          |   to uint32: 
-2147483648 (OK)
    to uint64: -9223372034707292160 (INVALID)                 |   to uint64: 
-9223372034707292160 (OK)

snipped a bunch more.

-- 
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]