Re: [hatari-devel] Bug in FPU code

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/