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.
