[issue18062] m68k FPU precision issue

[mirabilos]

mirabilos added the comment:

Stefan Krah dixit:

>> fixing this in general would allow keeping the FPUCW on i387 unchanged too.
>
>Actually dtoa.c (which is used on i387) explicitly requires to change
>the control word.

Right. By fixing the “older” code, i386 is not required to change
the FPUCW any more and can use it too.

The problem with changing the FPUCW on i387 is that it changes
from 64/15 bit mantissa/exponent to 53/15 bit which is still
not the 53/11 bit of IEEE double, so you *still* get double-
rounding issues (with denormal numbers only, I guess) because
the internal precision is still higher.

And on m68k we simply cannot afford to change the FPUCW because
that will cause runtime failures on some implementations.

>Looking at the test results, it seems to me that a couple of tests
>could be skipped if PY_NO_SHORT_FLOAT_REPR is defined, i.e.the
>failures are fully expected.

Ah okay.

>Not sure about the lgamma etc. failures though, perhaps that's
>an emulator bug.

If I can get self-contained test cases (preferably in C because
that makes it easier for others to test), I can ask people who
run real bare-metal Atari or Amiga to test them.

Or you can ask on debian-68k at lists.debian.org for testers.

I guess a python2.6 runnable testcase would be okay, even for
those running an a bit older “base system”. (I admit mine is
not really up to date either, just the build chroots, because
of the post-release unfreeze upload peak and related transitions.)

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
	-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18062>
_______________________________________