qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 3/6] target-m68k: use floatx80 internally


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH v5 3/6] target-m68k: use floatx80 internally
Date: Wed, 21 Jun 2017 18:45:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0

Le 21/06/2017 à 18:37, Richard Henderson a écrit :
> On 06/21/2017 09:18 AM, Philippe Mathieu-Daudé wrote:
>>> +typedef CPU_LDoubleU FPReg;
>>
>> What an awful name... Anyway checking on "qemu/bswap.h" it seems there
>> is some endianess issue with it if your host is little-endian.
> 
> There is no endian-ness issue because we do not attempt to read that
> structure from memory as a whole.  Instead, Laurent uses two big-endian
> loads (with appropriate address arithmetic) and stores the result into
> this host structure in host-endian order.  Further, the host routines
> use the structure members by name and do not assume any particular
> relationship between them.
> 
>> Do you have a way to run Berkeley TestFloat?
> 
> As noted in Laurent's cover message, floatx80 isn't quite right -- that
> is the x86 data type, and the proper m68k data type is slightly different.
> 
> I would expect the results from using floatx80 to be Just Good Enough to
> produce a working m68k user-land.  It will produce correct results for
> normal numbers in arithmetic such as 1.0 + 10.0.  But I would expect
> many of the edge conditions that TestFloat would attempt (especially
> de-normals and un-normals) would fail.
> 

Thank you Richard.

Yes, with floatx80, we can run m68k user-land. I'm going to post the
missing instructions.

I've also ported TestFloat and SoftFloat to m68k to check the result,
it's not perfect but in a good shape.

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

I can compare result from my reference hardware (a real Quadra 800) and
qemu-m68k chroot.

But I plan to replace the floatx80 by a floatx96 in a near future...

Thanks,
Laurent





reply via email to

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