Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.arch
Subject: Re: CISC Silent Spring
Message-ID: <1229@m3.mfci.UUCP>
Date: 9 Feb 90 14:48:26 GMT
References: <3300098@m.cs.uiuc.edu> <771@sce.carleton.ca> <35456@mips.mips.COM> <25cb6b65.702c@polyslo.CalPoly.EDU> <7826@pt.cs.cmu.edu> <3562@odin.SGI.COM> <35647@mips.mips.COM> <38462@apple.Apple.COM>
Sender: colwell@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 47

In article <38462@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes:
>>In article <35647@mips.mips.COM> mash@mips.COM (John Mashey) writes:
>>Some of the issues are:
>>2) AS everybody gets more aggressive, the pipelines and other critical paths
>>get more complex, as more aggressive = more things in parallel.
>>CISCs may well take longer to design (or not), but the key issue is what
>>happens in the critical paths on the chip.  From past history (i.e., things
>>like 360/91), you can make any architecture go faster, but if not designed
>>for smooth pipelining, the complexity can get very high.
>
>Bingo! I believe you've said something I believe strongly, and the
>crux is the "designed for smooth piplelining" phrase. I feel that this
>is really the major distinguishing feature between "RISC" & "CISC".
>This is far more important than the silly RISC/CISC
>#of-regs/addressing modes arguments. A "CISC" which is designed for
>pipelining should keep up with a "RISC". The tricks used to make
>"RISC"s go faster then work for "CISC"s as well.
>Most of the otherwise fundamental problems of "CISC"s (exception handling)
>go away (to the same extent they go away in "RISC"s anyway)

But this is only true if you are setting out to design a CISC starting
from a clean slate.  It's not clear to me why anyone would do that, 
unless they had goals other than performance uppermost in their minds
(and I believe there are some.)  If your task is to implement the VAX,
say, with "smooth pipelining", and you want to keep up with a machine
designed to be a RISC-like compiler target, then I believe you're doomed 
to failure.  (See Doug Clark's description of his travails in implementing
the VAX-8600 in ASPLOS-II.  I actually felt sorry for him, it reads like
an Edgar Allan Poe horror story.)  There are just too many 
architecturally-required strands of spaghetti for you to end up with
a clean design.

And if you're starting from scratch to design a CISC, and you try
to implement this concept of "smooth pipelining" (which could stand
a more rigorous definition, by the way), and you try to yank exception
handling into software, and you make the frequent ops go fast, and
you minimize the side-effects of ops, then what have you got left
that qualifies your design as a CISC?  Maybe you've left yourself
some really complicated instrs for some special purposes.  If so,
good luck working those into your exceptions-handling and pipelining
schemes.  I don't believe you can do that in anything like the same
amount of time a similar RISC design would need.

Bob Colwell               ..!uunet!mfci!colwell
Multiflow Computer     or colwell@multiflow.com
31 Business Park Dr.
Branford, CT 06405     203-488-6090