m68k FPU precision issue #62262
Comments
|
Hi, splitting off bpo-18061 by request of pitrou: FPU precision issue: MC68881 FPU, similar to Intel 80387, uses 80-bit precision internally. We do not want to change it to 64-bit because it’s not supported in all environments. Can probably be reproduced on i386 (with disabled SSE); fixing this in general would allow keeping the FPUCW on i387 unchanged too. See bpo-18061 for details. |
mirabilos
mannequin
added
the
interpreter-core
Does this also apply to changing the precision temporarily? Because HAVE_PY_SET_53BIT_PRECISION To me it sounds that you'd basically have to provide these macros |
Yes, that’s precisely what’s not working on the most widespread emulator, at the very least. (I have working code for that, in three(!) variants, but it just ignores those requests to change precision.) I think FPU is the one thing current m68k emulators do the worst… the responses I got from the mailing list back then said so, anyway. |
|
I forgot to comment on this:
Actually dtoa.c (which is used on i387) explicitly requires to change Looking at the test results, it seems to me that a couple of tests Not sure about the lgamma etc. failures though, perhaps that's |
|
mirabilos dixit:
Here’s the Python testcase made into a standalone test: -----BEGIN cutting here may damage your screen surface----- #include <stdio.h>
#include <stdlib.h>
#include <math.h>
#ifndef __MirBSD__
#include <fpu_control.h>
#endif
void runtests(void);
void
runtests(void)
{
volatile double x, y, z;
/* 1./(1-2**-53) -> 1+2**-52 (correct), 1.0 (double rounding) */
x = 0.99999999999999989; /* 1-2**-53 */
y = 1./x;
printf("test#1 %s: %.17E\n", (y == 1.) ? "fail" : "good", y);
/* 1e16+2.99999 -> 1e16+2. (correct), 1e16+4. (double rounding) */
x = 1e16;
y = 2.99999;
z = x + y;
printf("test#2 %s: %.17E\n", z == 1e16+4. ? "fail" : "good", z);
}
int
main(void) {
#ifdef _FPU_SETCW
fpu_control_t cwold, cwnew, cwgot;
#endif
runtests();
#if (defined(__i386__) || defined(__m68k__)) && defined(_FPU_SETCW)
_FPU_GETCW(cwold);
#ifdef __i386__
cwnew = 0x127f;
#else
cwnew = _FPU_RC_NEAREST | _FPU_DOUBLE;
#endif
_FPU_SETCW(cwnew);
_FPU_GETCW(cwgot);
printf("changing FPU control word from %08X to %08X => %08X\n",
cwold, cwnew, cwgot);
runtests();
#endif
return (0);
}
-----END cutting here may damage your screen surfaceHere’s the result of running it on the latest ARAnyM, which root@ara3:~ # ./a.out bye,
|
|
Stefan Krah dixit:
Right. By fixing the “older” code, i386 is not required to change The problem with changing the FPUCW on i387 is that it changes And on m68k we simply cannot afford to change the FPUCW because
Ah okay.
If I can get self-contained test cases (preferably in C because Or you can ask on debian-68k@lists.debian.org for testers. I guess a python2.6 runnable testcase would be okay, even for bye,
|
That's not a problem for dtoa.c, at least: dtoa.c avoids any use of subnormals in intermediate calculations. It's not really too much of a problem for Python in general, either. Windows typically operates in this mode. |
|
It's also an option not to use dtoa.c: Python still has fallback code that uses the OS double <-> char* conversions for the case where the configuration step can't figure out how to change the FPU control word. In that case compilation should still succeed, and the resulting Python would show: >>> import sys
>>> sys.float_repr_style
'legacy'If there are tests failing with the 'legacy' mode, that may just indicate buggy tests that haven't been properly marked as depending on the short float repr. (E.g., by decorating with "@unittest.skipUnless(getattr(sys, 'float_repr_style', '') == 'short'"), or poorly-designed tests that could be rewritten. |
|
Thorsten Glaser <tg@mirbsd.de> writes:
What is the exact sequence of fpu insns? Andreas. |
|
Mark Dickinson dixit:
I think that’s what we’re seeing here. Python 3.3.1 (default, May 10 2013, 02:52:57)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.float_repr_style
'legacy'Andreas Schwab dixit:
That’s all gcc-generated code and a system header… In main (after commenting out the second getcw and printf): #APP And the subroutine: runtests: bye,
|
|
Laurent Vivier dixit:
68881 even ;-)
Thanks, that’s what I was guessing. I get similar results on i386. Now as additional data point, UAE/WinUAE/etc. would be interesting. Even so, I’d be very reluctant to add this code to Python to make bye,
|
|
Laurent Vivier dixit:
Hm, I thought qemu did not emulate an MMU? bye,
|
|
Eero Tamminen dixit:
Nice ;)
OK, thanks. I’d just say let’s say changing FPU precision is not bye,
|
|
Can we somehow merge this issue with bpo-20904? |
|
This should be fixed now. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: