🚀 go-pugleaf

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.