Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch
Subject: Re: Questions on SparcStation 1 performance
Message-ID: <39808@bbn.COM>
Date: 11 May 89 14:07:33 GMT
References: <6008@brunix.UUCP> <13024@haddock.ima.isc.com>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 29

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