I could run this on my physical A1200 / 68060 compiling via VBCC for
AmigaOS if you are interested in further info.
( FWIW: I'd really expect that 68882 68040 and 68060 will agree on all
encondings, and also could be interesting to double check against WinUAE or
FS-UAE)
On Sat, Jul 24, 2021 at 6:06 AM Finn Thain <fth...@linux-m68k.org> wrote:
> On Fri, 23 Jul 2021, Stan Johnson wrote:
>
> > On 7/22/21 5:57 PM, Brad Boyer wrote:
> > > On Thu, Jul 22, 2021 at 07:32:49PM +1000, Finn Thain wrote:
> > >>> $ cat /proc/cpuinfo
> > >>> CPU: 68030
> > >>> MMU: 68030
> > >>> FPU: 68882
> > >>
> > >> I wonder if that hardware should be expected to give the same result
> as
> > >> 68040 hardware (?) Both QEMU and Aranym emulate the latter:
> > >>
> > >> CPU: 68040
> > >> MMU: 68040
> > >> FPU: 68040
> > >
> > > The m68k PRM does document some minor differences between the
> 68881/68882
> > > and the built-in FPU in the 68040 (other than the obvious unimplemented
> > > instructions in the 68040), but I don't think any of it would rise to
> > > this level. They're almost entirely compatible. My first guess would be
> > > an emulation bug. This is the sort of thing that would likely be easy
> to
> > > get wrong.
> > >
> > > My apologies for not having any of my 68040 systems available for a
> test
> > > on the real hardware. I'm not even sure if any of them still work.
> > >
> > > Brad Boyer
> > > f...@allandria.com
> > >
> >
> > Attached are three results of running bug-float80.c on m68k hardware:
> >
> > 1) 68040, Centris 650, Debian SID, gcc 9.2.1
>
> It appears that your Motorola 68040 result agrees with your Motorola 68882
> result, as Brad predicted.
>
> > 2) 68040, Centris 650, NetBSD 9.1, gcc 7.5.0
> > 3) 68030, Mac SE/30, NetBSD 9.1, gcc 7.5.0
> >
>
> The NetBSD test results are in agreement, but they differ from Linux. I
> wonder why?
>
> > The bug-float80.c program doesn't compile in its current form in A/UX;
> > not only does stdint.h not exist there, but both Aople's C compiler and
> > an early gcc (2.7.2) repported syntax errors.
> >
>
> The program can probably be ported to System V Release 2 without too much
> pain. You'll have to drop stdint.h. You may need to include limits.h. And
> you may need to build it with "gcc -D__m68k__ bug-float80.c".
>
> Debian/m68k 3 "woody" has gcc 2.95.4, and it fails like this:
>
> sh-2.05a# cc -D__m68k__ bug-float80.c
> bug-float80.c: In function `main':
> bug-float80.c:45: hexadecimal floating constant has no exponent
> bug-float80.c:45: missing white space after number `0x0.deadbee'
> bug-float80.c:45: parse error before `cafefeedp'
>
> So I think you'll want to start with a patch like this:
>
> --- a/bug-float80.c 2021-07-22 19:08:30.000000000 +1000
> +++ b/bug-float80.c 2021-07-24 23:40:27.000000000 +1000
> @@ -13,9 +13,10 @@
> ***********************************************************************/
>
> #include <float.h>
> -#include <stdint.h>
> #include <stdio.h>
> #include <stdlib.h>
> +#include <string.h>
> +#include <limits.h>
>
> #if defined(__m68k__)
> typedef long double __float80;
> @@ -28,7 +29,7 @@
> {
> __float80 x;
> int k, big_endian;
> - union { long double v; uint16_t i[6]; uint32_t j[3]; } u;
> + union { long double v; unsigned short i[6]; unsigned long j[3]; } u;
>
> u.v = 0x1p0;
> big_endian = (u.i[4] == 0);
> @@ -42,7 +43,7 @@
> PRINTF("LDBL_MIN = %0.16La = %0.19Lg\n", (long double)LDBL_MIN,
> (long double)LDBL_MIN);
> PRINTF("\n");
>
> - x = 0x0.deadbeefcafefeedp-16381L;
> + memcpy(&x, "\x00\x01\x00\x00\xDE\xAD\xBE\xEF\xCA\xFE\xFE\xED",
> sizeof(x));
> u.v = x;
> k = -16381;
>
>
> BTW, limits.h in A/UX 3.0.1 has this:
>
> #if !defined(DBL_MIN)
> /* Minimum normalised double */
> #ifndef __STDC__
> # define DBL_MIN (2.2250738585072018e-308)
> #else
> # define DBL_MIN (2.2250738585072014e-308)
> #endif
> #endif
>
> However, the LDBL_* definitions seem to be independent of other macros.
>
>
--
Antonio Vargas Gonzalez | winden ^ capsule ^ rgba ^ network ^ batman.group |
+windenntw <https://plus.google.com/117143451409201100384/about> |
winden...@gmail.com
