Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!oliveb!sun!fatcity!khb
From: khb@fatcity.Sun.COM (Keith Bierman Sun Tactical Engineering)
Newsgroups: comp.arch
Subject: Re: Bandwidth and RISC vs. CISC
Message-ID: <102028@sun.Eng.Sun.COM>
Date: 1 May 89 03:05:42 GMT
References: <38853@bbn.COM> <423@bnr-fos.UUCP> <17417@cup.portal.com> <39049@bbn.COM> <100891@sun.Eng.Sun.COM>
Sender: news@sun.Eng.Sun.COM
Reply-To: khb@sun.UUCP (Keith Bierman Sun Tactical Engineering)
Organization: Sun Microsystems, Mountain View
Lines: 21

In article <100891@sun.Eng.Sun.COM> dgh%dgh@Sun.COM (David Hough) writes:

>
>This event is rare enough that it needn't be as fast as a normal
>multiplication, so it's OK to slow down somewhat by holding the CPU,
>but not so rare that you want to punt to software.  By throwing enough
>hardware at the problem you can make it as fast as the normal case.
>I don't advocate that but that's my understanding of what the Cydra-5 did.  

Well, the details are probably the only things of value for the
Cydrome investors to fence (I mean sell :>) so we won't go into the
details. The Cydra 5 was constructed to that fp mults could be _issued_
EVERY cycle, and took a precise number of instructions to complete.
There was not enough real estate (it was only a 17 board ECL numeric
engine) to do the same for divide.... this was something of a
performance bottleneck (divide may be rare, but when it happens, it
happens often! :>)
Keith H. Bierman      |*My thoughts are my own. Only my work belongs to Sun*
It's Not My Fault     |	Marketing Technical Specialist 
I Voted for Bill &    |   Languages and Performance Tools. 
Opus            (* strange as it may seem, I do more engineering now     *)