Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lamaster
From: lamaster@ames.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: When is RISC not RISC?
Message-ID: <21606@ames.arc.nasa.gov>
Date: 9 Feb 89 19:02:26 GMT
References: <747@atanasoff.cs.iastate.edu> <6310013@hpcupt1.HP.COM>
Organization: NASA - Ames Research Center
Lines: 55

In article <6310013@hpcupt1.HP.COM> bla@hpcupt1.HP.COM (Brad Ahlf) writes:
>>> Sigh, RISC doesn't mean a small number of instructions. RISC means..
>
>Instead of RISC, how about RCC:
>
>Reduced Complexity Computers

****************************************

How about FIFC?

Fixed Instruction Format Computer


"To avoid these [described previously] problems two criteria were used in
the design of the VAX-11 instruction format: 1) all instructions should
have the "natural" number of operands, and (2) all operands should have the
same generality in specification.  These criteria led to a highly variable
instruction format.  ..."   - W. D. Strecker, "VAX 11/780" (reprinted in
Sieworiek, Bell, and Newell).


Now, as history has shown, it was exactly that highly variable format, with
a variable number of operands, and addressing mode encoding requiring separate
decoding, which has made such instruction sets hard to pipeline, and thus 
harder to build high performance machines with.  (And thus the cause of more 
problems than those solved.)  The secret to success for all the
RISC machines that I know of, from the CDC 6600 on, has been the choice of
simple, fixed, easy to decode instruction formats.

As has been pointed out repeatedly on this group, the NUMBER of instructions
is really a second order determinant of performance.  (On the other hand,
including a lot of special hardware for functions which are never exercised
certainly is a first order determinant.)

So, while we are proposing, I propose turning Strecker's phrase around:
the opposite of "highly variable" is "fixed", and it also happens to be one
of the few common denominators of all "RISC" machines.

*************************************************

As an aside, I note, as previously, that the VAX was very successful at
meeting another mid-70's problem however: keeping object code size small.

I notice that, recently, some results from the GNU compiler on some RISC's
has been a challenge to the object code size of VAX code.  Obviously, GNU
is doing something interesting there.  Does anyone know why the code from
the GNU C compiler appears to be significantly more compact than other
compilers on the RISC machines?

-- 
  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117