Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!ico!vail!rcd
From: rcd@ico.isc.com (Dick Dunn)
Newsgroups: comp.arch
Subject: Re: ERISC???
Summary: the point was "Is it RISC?" not "Is it good?"
Message-ID: <1989Oct19.044615.7973@ico.isc.com>
Date: 19 Oct 89 04:46:15 GMT
References: <16190@vail.ICO.ISC.COM> <2393@gmu90x.UUCP> <1087@m3.mfci.UUCP> <1228@crdos1.crd.ge.COM>
Organization: Interactive Systems Corporation
Lines: 32

davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) 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.

OK.  This points out something which Colwell (in the uncited parent to
Davidsen's article) also alluded to--the goal is not to produce a RISC; the
goal is to produce a fast machine.  RISC is a means to that end.  But we do
have to beware goal substitution.

>   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.
> I am not offended by a chip with 1024 instructions, if it averages 1.1
> cycles/op...

Nor am I, but that wasn't the point.  The America processor, if you believe
the _EE_Times_ article that started this (a notable "if"!), has substan-
tially more instructions than, say, an 80386.  It may be fast, but that's
not a reduced instruction set.  If they've made a new fast computer, let's
call it a new fast computer and not slap the "RISC" label on it just
because RISC is in vogue.

In fact, it is interesting to examine the question Colwell mentioned--
namely, did the America work abandon the RISC approach?  There's a lot to
kick around there, but it's going to require that we stop talking as if
RISC==fast.  (Of course, if we're going to examine whether America con-
stitutes an abandonment of the RISC approach, we'll need more info on
America, including real price and performance data.)
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...No DOS.  UNIX.