🚀 go-pugleaf

In article <13024@haddock.ima.isc.com> suitti@haddock.ima.isc.com (Stephen Uitti) writes:
>In article <6008@brunix.UUCP> jps@cs.brown.edu (John Shewchuk) writes:
>>What is going on here?  Intuitively, an integer multiply followed by
>>an integer divide should be faster than a convert int to float,
>>floating multiply, and convert float to int but this does not seem to
>>be the case.

>On the other hand, if SPARC doesn't have the integer divide in hardware, but
>does have hardware floating point, and has to call a routine for the integer
>stuff, i'm surprised that its only 5 times slower.

I believe the first SPARC had the microprocessor (incl. integer
processing) in a 20K gate gate array, and Weitek for FP.  Integer
divide had no hardware help (unlike multiply), so was probably like 3
or 4 cycles per bit.

The Weitek FP chips I think they used also didn't have FP divide, but
some hardware to support a reciprocal-divide algorithm.  The FP
multiplier would be involved in the loop.

Each iteration would do like 6 or 8 bits, but with the multiply would
take 5 or 6 cycles (for single precision).  So, given this, and that
integer divide generates 32 bits while FP does 24, FP divide looks
around 5 times faster than integer.

Note: The Weitek's only take a few cycles to do format conversions.

Could someone who knows clear up the "I think"'s and the "probably"'s?
Thanks.  -Stan