Hi, Am Sun, 26 May 2013 20:23:22 +0300 schrieb Eero Tamminen <o...@helsinkinet.fi>:
> 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.) Does it make a difference when you set USE_LONG_DOUBLE to 1 in src/cpu/newcpu.h of the Hatari sources? Thomas -- 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/20130530125528.07d7e189@think43
