Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!cmcl2!yale!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.arch
Subject: Re: When is RISC not RISC?
Message-ID: <634@m3.mfci.UUCP>
Date: 31 Jan 89 13:52:06 GMT
References: <170@microsoft.UUCP> <4008@hubcap.UUCP> <747@atanasoff.cs.iastate.edu>
Sender: colwell@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 49

In article <747@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu (John Hascall) writes:
>
>  In response to someone proposing adding instructions to a RISC
>  machine, I wrote:
> 
>>>  Here it is again, adding instructions to a RISC machine... won't
>>>  be long before we have a RISC machine with more instructions
>>>  than a VAX.... :-)
>
>  And was "corrected" by someone* thusly:
>   
>> And again...
>> Sigh, RISC doesn't mean a small number of instructions.  RISC means....
>
>   REDUCED Instruction Set Computer (i.e., a reduced number of instructions)

No, that's what the *acronym* stands for.  That acronym was not invented by
the folks who started the RISC effort (IBM), it came from Berkeley.  Which
doesn't by itself make it invalid (no, I really mean that :-)) but it does
cast doubt on appeals to authority in this case.  And early on, it fit the
concept a lot better than it does now.

I gave a talk at MIT a couple of months ago arguing, I hope successfully,
that our VLIW embodies almost all of the major RISC concepts.  The one 
thing it does not have is "few" instructions, 2**1024 is a big number.
But, as Brian said, the intrinsic complexity of an instruction isn't the
source of evil, it's the cost of implementing it vs. the performance
cost of not having it vs. the compiler cost of each.  We implement that
large number of instructions by having many functional units, each with
its own fully decoded instruction residing in its own ICache slice, so
what you may have thought would be the large runtime cost of decoding an
instruction word that big is actually negligible.

Besides, "reduced" can be taken to mean "reduced in number" or "reduced
in complexity".  I think it's high time to leave the obsolete notion of
numbers of instructions as a measure of "RISCness" and move to the more
appropriate "function/implementation level".  If you move a lot of 
functionality into runtime hardware you are following in the tradition
of CISC machines.  If you are maximizing performance by moving as much
as you can into compile time, thus minimizing the machine's cycle time,
you are probably building a RISC.

The days of counting instructions and drawing some 
legitimate conclusion are long gone.

Bob Colwell               ..!uunet!mfci!colwell
Multiflow Computer     or colwell@multiflow.com
175 N. Main St.
Branford, CT 06405     203-488-6090