Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!iuvax!pur-ee!hankd
From: hankd@pur-ee.UUCP (Hank Dietz)
Newsgroups: comp.arch
Subject: Re: Architecture Wars, again; survey
Summary: jhgjyhgj
Message-ID: <9774@pur-ee.UUCP>
Date: 14 Nov 88 14:48:24 GMT
References: <7926@winchester.mips.COM> <1077@esunix.UUCP>
Organization: Purdue University Engineering Computer Network
Lines: 20

In article <1077@esunix.UUCP>, bpendlet@esunix.UUCP (Bob Pendleton) writes:
...
> 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.

Fair enough, but who said anything about "average" things?  My point was
simply that creating a RISC design geared specifically to the task of
interpreting an instruction set leads rather naturally to the design of a
microcode engine.  I was not claiming that you take a SPARC (or any other
existing RISC design out there) and add ROM and you have exactly got some
particular CISC.  If you didn't like my "CISC = RISC + ROM" claim, here's
another nasty:  it is also true that "CISC = VLIW + ROM."  Of course, the
same disclaimers apply....

						-hankd