Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!apple!sun-barr!newstop!sun!joe!petolino
From: petolino@joe.Sun.COM (Joe Petolino)
Newsgroups: comp.arch
Subject: Re: More RISC vs. CISC wars
Message-ID: <114814@sun.Eng.Sun.COM>
Date: 11 Jul 89 20:49:46 GMT
References: <2190@oakhill.UUCP> <13980@lanl.gov> <42550@bbn.COM>
Sender: news@sun.Eng.Sun.COM
Reply-To: petolino@sun.UUCP (Joe Petolino)
Organization: Sun Microsystems, Mountain View
Lines: 30

>>>But, RISC machines are easier to pipeline

>I don't see how this can be true, other than possibly in the scoreboarding
>logic.  If it has it.  

One of the most fundamental principles of the RISC philosophy (if there is one)
is to *not* include anything in the architecture specification if it will
make a pipelined implementation difficult.  Examples of this are numerous:
delayed branches, lack of interlocks in various cases, etc.  What these have
in common is that they relax the requirement for the processor to follow a
strictly sequential model of execution in cases where it would slow down
and/or complicate a pipelined implementation.

>>>I don't
>>>know of any CISC machines with 'hardwired' instruction sets.  Micro-
>>>coding slows the machine down.

>>I can think of a couple of old ones.  The first pdp11, the 11/20, was
>>hardwired.  (This accounts for some of the little irregularities in the
>>11 instruction set, in fact, like the way INC isn't quite the same as
>>ADD #1...)  And I seem to recall that the 360/75 was mostly hardwired,
>>for speed.

No need to go back that far.  None of the Amdahl 470-series machines (V6, V7,
V8) had microcode per se.  They couldn't find RAMs fast enough (yes,
mainframes often use RAM, not ROM, for microcode, since it's faster). 
Instead, something that looked very much like microcode was transformed into
PLA equations and implemented in gate arrays.

-Joe