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 13:23, Finn Thain a écrit :
I think the correct fix would be a bootloader that disables the SCC
irq sources. But a kernel patch would help until bootloaders are
fixed. Finn
It could be hard to do this : booloaders use MacOS ROM traps to access
hardware and I don't think it is p
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
Finn Thain dixit:
>I think the correct fix would be a bootloader that disables the SCC irq
>sources. But a kernel patch would help until bootloaders are fixed.
Can asm code to do that be put into early kernel (asm) part?
IIRC head.S or somesuch.
Just a Devil’s Advocate’s thought,
//mirabilos
--
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
Hi!
I'm glad to announce that Elgar will relocate next Saturday to its new hosting
site at Physics Department of FU Berlin.
John Paul Adrian Glaubitz will pick up Elgar in Rostock and take it to Berlin,
so he'll be the first contact for on-site remote hands. ;-)
I will shutdown the buildd on E
Please send any patch you want I test (including Kconfig one)
Laurent Vivier a écrit :
>Le 26/05/2013 02:30, Finn Thain a écrit :
>> On Sat, 25 May 2013, Laurent Vivier wrote:
>>
>>> Le 25/05/2013 10:04, Finn Thain a ?crit :
>>>
If you enable EARLY_CONSOLE, don't generate any Zilog SCC inte
On Sun, 26 May 2013, Laurent Vivier wrote:
> Le 26/05/2013 02:30, Finn Thain a ecrit :
>
> This works if I disable "EARLY_PRINTK". To do that I need to patch
> Kconfig :
>
> --- a/arch/m68k/Kconfig.debug
> +++ b/arch/m68k/Kconfig.debug
> @@ -11,7 +11,7 @@ config BOOTPARAM_STRING
> depe
Le 26/05/2013 02:30, Finn Thain a écrit :
On Sat, 25 May 2013, Laurent Vivier wrote:
Le 25/05/2013 10:04, Finn Thain a ?crit :
If you enable EARLY_CONSOLE, don't generate any Zilog SCC interrupts
before the pmac_zilog driver gets opened (i.e. before getty starts on
ttyS0). The early boot asm
On Sat, May 25, 2013 at 9:47 PM, Ingo Jürgensmann
wrote:
>>> arch/m68k/configs/mac_defconfig --+
>>> CONFIG_MAC_PARTITION : y y y y y . y y y y y .
>> Shouldn't MAC_PARTITION be enabled for the mac configuration?
>
> Yeah, I wondered about that for Amiga as well,
22 matches
Mail list logo
