Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!mit-eddie!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch
Subject: Re: Bandwidth and RISC vs. CISC
Message-ID: <38971@bbn.COM>
Date: 21 Apr 89 17:28:36 GMT
References: <38853@bbn.COM> <423@bnr-fos.UUCP> <17417@cup.portal.com>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 45

In article <17417@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes:
>>of data latency.  The basic premise of RISC is to not telll the CPU anything
>>until the last moment. This strikes me as a funny way of optimizing throughput.
>
>This strikes me as a funny way of interpreting RISC!!! :-)  There are
>several "basic premises" of RISC, and as far as I know, none of them is "to
>not tell the CPU anything until the last moment."  Conversely, as far as I

Stuff like vector instructions, the VAX character string instructions,
VAX CALL/RET, the 680x0 MOVEM, etc.  give the CPU a real strong hint
as to what near-future memory accesses will be.  As memory access times 
become even longer [relative to cycle time], this becomes more important.
And will begin to widen the performance gap, if implemented properly.
RISC architectures don't have the ability to communicate this class 
of information, and if it is added, they won't be RISC's anymore (unless 
Marketing SAYS they are, I guess...)

>>To execute your 1.0 FLOP, the typical RISC will do about 1.5 memory access
>>intructions, 1.5 address adjusting instructions, say 0.5 instructions for
>>boundary condition checking and 0.5 jump instructions. This adds up to 5
>>instructions to do 1 FLOP,. Many CISC machines can do a FLOP with only 2
>>instructions.
>
>Who cares about instructions?

If each instruction consumes one cycle to issue I sure do!
(BTW, the Alliant takes one cycle to do MULF (a2)+,fp0; don't tell me
it's impossible.)

>look at existing implementations.  And don't confuse on-chip resources with
>real complexity (the kind that makes it hard) like the editor of UNIX
><somethingorother> did in his comments on the i860.  He claimed it is the
>CISCiest processor yet!

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).
I'd really like to see someone stand up and say, "Boy, the IEEE
round-to-even is much more accurate than DEC's round .5 up.  I have an
application right here that proves it."  Or, "Gradual underflow is
much better.  I have an application that can be run in single precision
that would need to be run double precision without it."
:-) Stan