Re: [hatari-devel] Bug in FPU code

[Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>]

Thomas, thank you very much for the patch! This fixes 68030/68882 on my system.
Now i think the FPU should be fully functional on all little endian systems using long double with size >= 10 bytes.

Regards,

Andreas

Am 07.03.2012 um 01:22 schrieb Thomas Huth:

> Am Tue, 6 Mar 2012 21:19:47 +0100
> schrieb Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>:
> 
>> I did more research on the FPU code today, trying to fix 68030/68882.
>> I found the problem: it's one or both of the functions "to_pack" and
>> "from_pack". Replacing them with the fixed to_exten and from_exten
>> makes the FPU pass the test (obviously the test does not do any
>> calculations with the values, just copying them forth and back
>> to/from the FPU register). This is of course no valid patch, as it
>> will break handling of packed format values (break the broken
>> handling ...).
>> 
>> Maybe someone can tell what's wrong with these functions? They look a
>> little "strange" to me, but for now i can't make any diagnosis, as i
>> do not yet understand the packed decimal format of the 68882.
> 
> You can find a description of the packed decimal format in the manual
> of the 68881 for example :
>   http://www.datasheetcatalog.org/datasheet/motorola/MC68881.pdf
> The from_pack and to_pack functions might look a little bit strange,
> but I think they are basically ok.
> 
> I played around with these functions by calling them directly with some
> test values, and I think I've found two bugs:
> 
> to_pack uses sscanf(str, "%le", &d) ... according to my man page of
> scanf, the format string for "long double" (which we use as fptype in
> our CPU) should rather be "%Le" instead of "%le".
> 
> Same for from_pack: sprintf(str, "%.16e", src) should rather use
> "%.16Le" instead of "%.16e".
> 
> With these two modifications, I was able to use these two functions to
> convert a test value from one format to the other and back.
> 
> Thomas
> 
>