Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!athena.mit.edu!elwin
From: elwin@athena.mit.edu (Lee W Campbell)
Newsgroups: comp.arch
Subject: Re: ERISC???
Message-ID: <15251@bloom-beacon.MIT.EDU>
Date: 20 Oct 89 13:43:54 GMT
References: <16190@vail.ICO.ISC.COM> <2393@gmu90x.UUCP> <1087@m3.mfci.UUCP> <1228@crdos1.crd.ge.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: elwin@athena.mit.edu (Lee W Campbell)
Organization: Massachusetts Institute of Technology
Lines: 80

In article <???>, davidsen@crdos1.UUCP (bill davidsen) writes:

>  From what I've read and heard, the reason for developing RISC was
>*not* as an end in itself, but for speed. By reducing the cycles per
>instruction more instructions per send would be executed. Only to do
>that the instruction set was made smaller. Enter RISC.
>
>  I am a true believer in reducing the cycles per instruction, but I see
>no virtue in having fewer instructions for any reason other than speed.
>   ...

Hear, hear! When I was taking courses in CPU architecture (about 2 years
ago), the RISC philosophy was described thus:

  1. Look at the CPU schematic and find the longest propagation delay.
     (i.e. what signal needs to trickle through the largest number of
     gates during 1 clock cycle).
  2. Determine what instruction(s) that path is associated with.
     Are they essential, or frequently used instructions? If not,
     eliminate them!
  3. Speed up CPU clock as fast as new (reduced) architecture can
     handle.
  4. repeat the above 3 steps until you can't speed up architecture
     any more.

Another motivation was that the machine that executed the microcode
could go like hell, and if you could sell that to users with good
compilers, it might make them happy.

In doing this, some general principles were uncovered:

(a) Instructions which must fetch from main memory and then use the ALU
cause more delay than instructions which fetch from registers and then
use the ALU. Therefore, eliminate a lot of fancy indirect-auto-this-
and-that addressing modes. Instead, use a "load/store" architecture
where all references to main memory are either register loads or
register stores, and all ALU instructions use register operands.

(b) Lots of registers are good! But not too many, because you need to save
then when you change tasks.

(c) 1 cycle per instruction is good, because it reduces the amount of
"hidden registers" that need to be saved on interrupts, and makes it
easier to restart an instruction, etc.

(d) etc. Please feel free to insert your own favorite RISC principles.

My only point is to emphasize what bill davidsen wrote: that the only
purpose of RISC is SPEED. RISC is not some unifying philosphy, it is
a collection of ad hoc techniques to make computation faster.

Back when I was taking my course, we didn't even talk about multiple large
onboard caches with wide (128 bits or more) busses to the instruction
decoder, ALU, and register file. But obviously they are very useful and
very effective in the Intel 860, 960CA, and 486 chips.

One of the lessons of the 860 and 960CA is that it is possible to go
considerably faster than 1 instruction per clock cycle.

A major lesson from the 486 is that a big cache with a fat bus reduces
the delay caused by fancy indirect-auto-this-and-that instructions, so
you don't have to eliminate them, so you can get RISC-like performance
with complex instructions! Since I believe the definition of RISC is a
performance based definition, I consider the 486 to be as RISC machine
executing a CISC instruction set!

(A note: I believe it will always take less silicon area to build a
 "traditional" RISC load/store machine than to build an equivalent
 performance RISC/CISC machine. So I am not forcasting the death of
 SPARC or other load/store RISCS. But I don't believe they will
 wipe out major popular instruction sets such as 80386, 68030, VAX,
 IBM 370, etc. You'll just pay a little more for a CPU to execute
 those instruction sets).

My, my, I do get windy in my old age...
						- Lee

      .===.       \|/			-	   This Space		-
     { Max }      AKA     Lee		-	 Unintentionally	-
   H-headphones   /|\     Campbell	-	   Left Blank		-