🚀 go-pugleaf

In article <470@batcomputer.tn.cornell.edu> braner@batcomputer.UUCP (braner) writes:
>[]
>
>Thanks to Sandra Loosemore for posting the interesting benchmarks.
>Here are results of the Savage benchmark for Megamax C on the Atari ST
>(8 MHz 68000):
>					time	error
>
>	Single precision:		146	4.3E+01
>	Double precision:		496	8.5E-07
>	Double precision, with 32081:	119	2.2E-08
>
>The Megamax math library (written in C, using sloppy algorithms) is even
>slower than the (in)SANE numeric package on the Apple Macintosh, as
>exemplified by Aztec C (353 seconds).  In comparision, Absoft FORTRAN
>on the Amiga did it in 77 seconds (could someone post the Absoft time
>on the ST?), Alcyon C v4.14 (libm) clocked in at 73 seconds, and HP BASIC
>(also on an 8 MHz 68000) managed 45 seconds.  (Any data for Mark Williams C?)
>

This is a response to Moshe Braner's posting. My brother Mike Bunnell wrote
the floating point math library for the Megamax C compiler about a year ago.
He also wrote the C compiler (by the way). He wrote the floating point routines
in 2 days because Megamax was anxious to get the compiler out the door. They
were supposed to replace the routines along time ago. It looks like they will
do so this month.

The reason for this posting is I have some benchmark results that I think you
will find interesting.

The results for the Savage Benchmark for a 68020 (16.67 MHZ)
with a 68881 (12.5 MHZ) (compiler PCC):

                        time (in seconds)       error
    Double precision:   0.63                    1.177341e-09

The results for the Savage Benchmark for a 68010 (12.5 MHZ)
with a 68881 (12.5 MHZ) (Megamax C):

                        time (in seconds)       error
    Double precision:   1.25                    1.177341e-09


Note that in the case of the 68010 the floating point processor was hooked
up as a peripheral just as it would be on a 68000. Also the 68010 computer
is a muli-tasking machine so the floating point processor was accessed through
a trap routine. With a single tasking system (like the ST) there would be
less overhead because the processor could be accessed in-line.

The 68020 was, of course, co-processing with its 68881.

It seems to me that adding a 68881 card to the ROM port on the ST would give
you a reasonable number crunching machine.  You would not even need the
added expense of a 68020. According to the schematics there is no read/write
line going to the ROM port.  If that is true you would have to sneak that line
from the DMA (hard disk) port.

With such a system you would blow away an 8086+8087 computer.

Mitch Bunnell