Path: utzoo!attcan!uunet!hsi!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.arch
Subject: Re: Why The Move To RISC Architectures?  ('386 vs. RISC)
Message-ID: <1268@m3.mfci.UUCP>
Date: 22 Mar 90 14:52:26 GMT
References: <28012@cup.portal.com> <1990Mar20.175843.2612@utzoo.uucp> <5303@scolex.sco.COM>
Sender: colwell@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 60

In article <5303@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes:
>
>In article <1990Mar20.175843.2612@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>The fact is, trying to bundle
>>zillions of instructions onto the chip usually makes them slower, and
>>compilers find it very difficult to effectively exploit all the bizarre
>>silliness that CISC designers throw in.  
>
>...you have a couple of options:  you can
>make a small amount of instructions *really* fast (through the brute force
>method of just throwing silicon at it), or you can make a large amount of
>instructions (which might be fast, or might not; since you now have less
>silicon, they will probably be slower).

[a moment please while I find my soapbox...oh here it is...]  And once
again I claim that the NUMBER OF INSTRUCTIONS is very nearly meaningless
as a measure of RISCyness.  It isn't the number of instructions that makes
a VAX hard to speed up, it's their architecturally-required semantic content.
Ok, so indirectly you have a point, in that an architecture as complicated
as that probably needs microcode for its implementation.  But that's not
what you said.  Do you want to hear my arguments for why our VLIW with
2**1024 possible instructions is nevertheless a RISC?

>After you've done all that, btw, you can throw in pipelining if you don't
>already have it, multiple functional units, scoreboarding (either full or
>the simpler one most people use), etc.  Meanwhile, the CISC chip is still
>trying to make the POLY instruction execute in something less than 100
>cycles...

And those 100 cycles might well be considerably faster than the equivalent
RISC code sequence (including the icache misses the RISC will incur in
executing it).  But RISC probably still wins.  Why?  Because those RISC
operations can be overlapped with other useful ops, and while the CISC is
running its POLY, nothing else can usefully proceed.  The pipelining,
multiple FUs, and scoreboarding can be done on RISCs or CISCs (and has
been) so it doesn't seem especially relevant here.

>>About a decade ago, it started
>>to become clear that executing simple instructions very quickly works
>>much better.
>
>Well, I'd say more than that, about 25 years.  Seymour Cray and the CDC
>Cyber 6600, a truly wonderful machine with less than 74 instructions, a
>load-store architecture, and three-operand instructions.  Just beautiful.

An amazing machine.  But unless we know more about how it shared 
responsibility for performance with its compiler, I refuse to call
it a RISC.  From what I've read, it was designed so that the hardware
would extract whatever parallelism it could use, and all the compiler
did was convert the high level source into sequential machine ops.
Close, but not much different in principle from what drives the CISC
design philosophy.  (Oh yes, there was one.  The CISC design philosophy
was to "make the compiler writer's job easier"; yes, it probably failed
at that, too, but that's one of the reasons for all those complicated
instruction sets in the first place.)

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