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