Hi,
On torstai 30 toukokuu 2013, Thomas Huth wrote:
> Does it make a difference when you set USE_LONG_DOUBLE to 1 in
> src/cpu/newcpu.h of the Hatari sources?
No, result is exactly the same as with it set to 0.
- Eero
PS. that option gives quite a lot of warnings, so I'm not sure
wheth
Hi,
Am Sun, 26 May 2013 20:23:22 +0300
schrieb Eero Tamminen :
> 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:
Laurent Vivier writes:
> If I remember correctly, last time I checked, Aranym was using internally
> only 64bit floating point type (like coldfire).
Your information is outdated. The mpfr implementation fully supports
extended precision.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG
Laurent Vivier dixit:
> If I remember correctly, last time I checked, Aranym was using internally only
> 64bit floating point type (like coldfire).
If it were, we didn’t have this problem.
No, ARAnyM (when running on i386 or amd64, at least) is using 80 bits,
although the mpfr routines probably
Tuomas Vainikka writes:
> Is there a difference between 040 FPU and the 68881 in how many bits of
> excess precision things get calculated?
No.
> IIRC there was a difference between 040 and 68881 in gcc with how
> -fexcess-precision was handled...
The only difference between 68881/2 and 68040+
Le 26/05/2013 19:44, Thorsten Glaser a écrit :
Eero Tamminen dixit:
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
Nice ;)
I.e. it seems that W
On 05/26/2013 04:26 PM, 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 ;-)
Is there a difference between 040 FPU and the 68881 in how many bits of
excess precision things get calculated?
IIRC th
Eero Tamminen dixit:
>> > 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
Nice ;)
>I.e. it seems that WinUAE FPU emulation is also lacking FPUCW
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.0E+00
> >> test#2 fail: 1.00040E+16
> >> chang
Laurent Vivier dixit:
> Le 26/05/2013 16:23, Thorsten Glaser a écrit :
>> Laurent Vivier dixit:
>>
>>> For the "etc" ;-) , in Qemu, I have:
>> Hm, I thought qemu did not emulate an MMU?
> You're right.
>
> I cheat : I use Qemu in linux-user mode, it means I use m68k user binaries on
> an x86_64 ke
Le 26/05/2013 16:23, Thorsten Glaser a écrit :
Laurent Vivier dixit:
For the "etc" ;-) , in Qemu, I have:
Hm, I thought qemu did not emulate an MMU?
You're right.
I cheat : I use Qemu in linux-user mode, it means I use m68k user
binaries on an x86_64 kernel within a linux container.
Regar
Laurent Vivier dixit:
> For the "etc" ;-) , in Qemu, I have:
Hm, I thought qemu did not emulate an MMU?
bye,
//mirabilos
--
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there
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.0E+00
test#2 fail: 1.00040E+16
changing FPU control word from to 0080 => 0080
test#1 good: 1.
Laurent Vivier dixit:
> BTW, the result on a real CPU (68040) is :
68881 even ;-)
> test#1 fail: 1.0E+00
> test#2 fail: 1.00040E+16
> changing FPU control word from to 0080 => 0080
> test#1 good: 1.00022E+00
> test#2 good: 1.00
Le 26/05/2013 00:19, Thorsten Glaser a écrit :
Here’s the result of running it on the latest ARAnyM, which
did get MPFR-based FPU emulation bugfixes, but apparently
still ignores any FPUCW changes (or, at least the ones relating
to precision):
root@ara3:~ # ./a.out
test#1 fail: 1.000
Mark Dickinson dixit:
>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
I think that’s what we’re seeing here.
Python 3.3.1 (default, May 10 2013, 02:52:57)
[G
Thorsten Glaser writes:
> root@ara3:~ # ./a.out
> test#1 fail: 1.0E+00
> test#2 fail: 1.00040E+16
> changing FPU control word from to 0080 => 0080
> test#1 fail: 1.0E+00
> test#2 fail: 1.00040E+16
What is the exact sequence
mirabilos dixit:
>mirabilos added the comment:
>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.)
Here’s the Python testcase made into a sta
18 matches
Mail list logo
