[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linux 3.10-2-m68k FPU support



Andreas Schwab dixit:

>None of the trigonometric or logarithmic insns are implemented (grep for

OK, decide on whether this should let it be disabled or not.


Ingo J�rgensmann dixit:

>Hmmm... if Aranym is the problematic part in this story, then Aranym

No, it’s not, that’s a totally different story. I was wondering whether
the FPU emulation code worked _better_ than ARAnyM (see below), in
which case we might want to use that instead.


Geert Uytterhoeven dixit:

>Furthermore, for people running Debian on their FPU-less machines before,
>the new kernel image is definitely a regression, so it warrants re-enabling
>FPU emulation to fix this.

Not an argument ;-)

>Indeed. The emulation may be incomplete, but for most people it's useable,
>and definitely better than nothing.

OK, I’ll take your word for it.

>Nevertheless, FPU emulation in ARAnyM is something different. ARAnyM
>is an emulator that emulates a full 68040, incl. FPU. So as far as the Linux

Yes, except it doesn’t emulate the FPU fully.

>kernel is concerned, no in-kernel FPU emulation is involved.

Right.


Andreas Schwab dixit:

>Thorsten Glaser <tg@mirbsd.de> writes:
>
>> On the other hand, I cannot help but wonder how well it compares
>> to whatever ARAnyM passes as FPU. I know ARAnyM doesn’t handle the
>> 80/64bit precision switch at all
>
>It doesn't?

In my tests, it didn’t, and I later got a mail from someone saying
that it indeed doesn’t do that.

And yes, testing still shows it to fail:

(sid-m68k-sbuild)tg@ara5:/tmp$ gcc -O2 x.c && ./a.out
test#1 fail: 1.00000000000000000E+00
test#2 fail: 1.00000000000000040E+16
changing FPU control word from 00000000 to 00000080 => 00000080
test#1 fail: 1.00000000000000000E+00
test#2 fail: 1.00000000000000040E+16

That with the attached test file I reported to Python upstream.

MirBSD/i386 always runs with 64-bit precision…

tg@blau:~ $ mgcc -O2 x.c && ./a.out
x.c:0: note: someone does not honour COPTS correctly, passed 0 times
test#1 good: 1.00000000000000022E+00
test#2 good: 1.00000000000000020E+16

… and Linux/i386 is able to change to it:

tg@frozenfish:~ $ gcc -O2 x.c && ./a.out
test#1 fail: 1.00000000000000000E+00
test#2 fail: 1.00000000000000040E+16
changing FPU control word from 0000037F to 0000127F => 0000127F
test#1 good: 1.00000000000000022E+00
test#2 good: 1.00000000000000020E+16

In Python, we decided to just use the fallback code for systems
whose FPU cannot be switched to 64-bit precision, as the current
ARAnyM code is relatively widespread, and the other code, which
relies on 64(53)-bit precision, has catastrophic failure modes
if the switch doesn’t work, whereas the older code, while not as
“good”, will just always work.

bye,
//mirabilos
-- 
<diogenese> Beware of ritual lest you forget the meaning behind it.
<igli> yeah but it means if you really care about something, don't
    ritualise it, or you will lose it. don't fetishise it, don't
    obsess. or you'll forget why you love it in the first place.
#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);
}

Reply to: