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 10:26:16 +0100
User-agent: mu4e 1.4.1; emacs 28.0.50

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.

> https://github.com/vivier/m68k-testfloat
> https://github.com/vivier/m68k-softfloat

Ahh I see you have sys_float functions to compare to TestFloat. 

> I also used the gcc and libc testsuite to detect problems but this was a
> very slow process...
>
> I have also ported RISU to m68k, but I didn't add FPU test in it (does
> it support FPU test?).

There is no reason why it couldn't. The FPU support would basically be
ensuring the appropriate registers are saved out of the context. I did
similar when we expanded the aarch64 RISU to support SVE. In fact
looking at the code:

    for (i = 0; i < 8; i++) {
        if (m->fpregs.f_fpregs[i][0] != a->fpregs.f_fpregs[i][0] ||
            m->fpregs.f_fpregs[i][1] != a->fpregs.f_fpregs[i][1] ||
            m->fpregs.f_fpregs[i][2] != a->fpregs.f_fpregs[i][2]) {
            return 0;
        }
    }

it seems the fpregs are included and tested so it should be good.

That said RISU's random instruction approach means most floating point
numbers very quickly become tend to NaNs which is part of the reason I
wrote the float_convs/float_madds tests which try to be more systematic
in exercising the range of float types (normals, denormals, min and max
etc). Maybe we could improve risugen's seeding of floating point values
to better exercise FP ops rather than just dumping random stuff there.

>
> Thanks,
> Laurent


-- 
Alex Bennée



reply via email to

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