Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch
Subject: Re: Bandwidth and RISC vs. CISC
Message-ID: <39049@bbn.COM>
Date: 24 Apr 89 18:46:11 GMT
References: <38853@bbn.COM> <423@bnr-fos.UUCP> <17417@cup.portal.com> <38971@bbn.COM> <100524@sun.Eng.Sun.COM>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 45

In article <100524@sun.Eng.Sun.COM> dgh%dgh@Sun.COM (David Hough) writes:
>In article <38971@bbn.COM>, slackey@bbn.com (Stan Lackey) writes:
>> 
>> I have a real problem with anything that includes IEEE floating point
>> AND calls itself a RISC.  IEEE FP violates every rule of RISC; it has
>> features that compilers will never use (rounding modes), features that
>> are rarely needed that slow things down (denormalized operands), and
>> features that make things complex that nobody needs (round-to-even).
>> (emotional stuff deleted)
>Not all code is compiled.
I agree - I was just quoting the RISC guys.
>Interval arithmetic is
>efficient to implement with the directed rounding modes required by IEEE
>arithmetic, but you can't write the implementation in standard C or...
>Such rounding is no more expensive than biased rounding
>on a system that is required to provide directed rounding modes as well.  
>It's not the bottleneck on any hardware IEEE implementation of which I'm aware.

Having to detect EXACTLY .5 is a bottleneck in terms of transistor
count, design time, and diagnostics.  The extra execution time may not
affect overall cycle time, but the RISC guys say that any added
hardware increases cycle time (they usually use it in the context of
instruction decode).

>I have heard that adder carry propagate time and multiplier array size 
>are the key constraints with a floating-point chip; hardware experts
>will correct me if I'm wrong.  
These are probably the largest single elements in most implementations.
But, as the hardware guys will tell you, it's the exceptions that get you.
Note: It's prealigning a denormalized operand before a multiplication
that REALLY hurts.

>Memory bandwidth tends to be the key constraint
>on overall system performance unless floating-point division and sqrt
>dominate.
Absolutely true, but not very relevant.

>David Hough

Lots of valid uses of IEEE features listed.  I didn't mean that IEEE
was bad or useless, it's just that it was architected when CISC was
the trend, and it shows.  Especially after my own efforts in an IEEE
implementation, I am glad to see from this posting and others that at
least a few users can make use of the features.  I think the RISC
implementers should have a RISC-style floating point standard, though.