🚀 go-pugleaf

In article <2583@tank.uchicago.edu> phd_ivo@gsbacd.uchicago.edu writes:
>floating point performance of the Motorola 68882. Is there help on the horizon?
>A plug-in compatible chip along the Weitek 80387 replacements that can speed up
>flp? And why is the 68882 so slow when compared with other chips that do
>essentially the same mathematical operations?

The 68881/2 are not really any worse performance-wise than their main
competition, the 80x87 family. Both families are very slow.  A substantial
contributor to this is that both families of chips convert all input to
an 80-bit format internally before use, and convert back to 32 or 64-bit
formats afterward. Maybe someone from Motorola can say how the cycles are
spent, but the 68882 takes about 40 cycles to do a floating-point add,
compared with about 5 cycles on the MC88000 and 2 cycles on the MIPS
R2010/3010. (No flames, please, these numbers are from memory and may 
be off a bit.)  Maybe the co-processor for the 68040 will improve on 
this situation.

On the bright side, both the Intel and Motorola chips make it easy
to implement a robust IEEE-compliant floating-point system, since just
about everything is done by the hardware.  If the compiler is smart about
keeping intermediate results on the co-processor's internal stack, then
the extra accuracy can be helpful.  The worst problem is that it is 
nearly impossible to figure out how much of your calculation got done
in extended precision on-chip before being truncated back to 32 bits 
or 64 bits for storage in main memory.

----------------------   John D. McCalpin   ------------------------
Dept of Oceanography & Supercomputer Computations Research Institute
mccalpin@masig1.ocean.fsu.edu		mccalpin@nu.cs.fsu.edu
--------------------------------------------------------------------