Path: utzoo!attcan!uunet!husc6!bloom-beacon!bu-cs!purdue!decwrl!labrea!agate!helios.ee.lbl.gov!lll-tis!oodis01!uplherc!esunix!bpendlet
From: bpendlet@esunix.UUCP (Bob Pendleton)
Newsgroups: comp.arch
Subject: Re: Architecture Wars, again; survey
Message-ID: <1077@esunix.UUCP>
Date: 11 Nov 88 15:32:33 GMT
References: <7926@winchester.mips.COM>
Organization: Evans & Sutherland, Salt Lake City, Utah
Lines: 31

From article <7926@winchester.mips.COM>, by mash@mips.COM (John Mashey):
> In article <9725@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes:
> 
>>On this second note, I wonder how long it will be before everyone realizes
>>that a CISC = RISC + ROM program?
> 
> Not all of us agree with that statement..... :-)

I've just finished reading "mips R2000 RISC Architecture" by Gerry
Kane. The instruction set looks very much like vertical microcode. You
could even imagine building a machine that packed 2 to 4 R2000
instructions into a 64 to 128 bit instruction word, calling it
horizontal microcode, and executing each instruction in a subcycle of
the main processor.

But, hey, doesn't the instruction cache let you fetch multiple words
from main memory? And isn't being able to execute 1 instruction/cycle
more flexible than always having 4 instructions to execute?

What I'm trying to say is that even though RISC machines look a lot
like microcode engines your average microcode engine is nowhere near
as flexible as a RISC, RISC+ROM != Microcode engine+ROM. So for a
general purpose processor I'd have to say that CISC < RISC+ROM. For
special purpose processors microcode running on problem specific
microengines still wins.

				Bob P.
-- 
              Bob Pendleton, speaking only for myself.
UUCP Address:  decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet

		Reality is what you make of it.