Hi,
On sunnuntai 26 toukokuu 2013, Laurent Vivier wrote:
> Le 26/05/2013 15:16, Thorsten Glaser a écrit :
> > Laurent Vivier dixit:
> >> BTW, the result on a real CPU (68040) is :
> > 68881 even ;-)
> >
> >> test#1 fail: 1.00000000000000000E+00
> >> test#2 fail: 1.00000000000000040E+16
> >> changing FPU control word from 00000000 to 00000080 => 00000080
> >> test#1 good: 1.00000000000000022E+00
> >> test#2 good: 1.00000000000000020E+16
>
> > Thanks, that’s what I was guessing. I get similar results on i386.
> >
> > Now as additional data point, UAE/WinUAE/etc. would be interesting.
I built the test with fpu_control.h header from eglibc, using
Sparemint GCC 2.9.5 (with 2010 binutils) and MiNTlib. When it's
run on Hatari, either oldUAE or WinUAE CPU core, the result is:
------------------------------------
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
------------------------------------
I.e. it seems that WinUAE FPU emulation is also lacking FPUCW change
handling (for precision).
(Hatari's WinUAE CPU core code was synched with upstream last year.)
> For the "etc" ;-) , in Qemu, I have:
>
> test#1 fail: 1.00000000000000000E+00
> test#2 fail: 1.00000000000000040E+16
> changing FPU control word from 00000000 to 00000080 => 00000080
> test#1 good: 1.00000000000000022E+00
> test#2 good: 1.00000000000000020E+16
- Eero
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201305262023.22239....@helsinkinet.fi
