Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.6.2.17 $; site uiucdcs.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!bcase
From: bcase@uiucdcs.UUCP
Newsgroups: net.arch
Subject: Re: RISC processors
Message-ID: <27800034@uiucdcs.UUCP>
Date: Wed, 21-Nov-84 17:02:00 EST
Article-I.D.: uiucdcs.27800034
Posted: Wed Nov 21 17:02:00 1984
Date-Received: Sun, 25-Nov-84 03:29:35 EST
References: <641@watdcsu.UUCP>
Lines: 77
Nf-ID: #R:watdcsu:-64100:uiucdcs:27800034:000:4158
Nf-From: uiucdcs!bcase    Nov 21 16:02:00 1984

[bug lunch]

The Ridge-32 is a RISCy machine.  It does not have lots of registers,
but rather has a very simple instruction set.  It can do 8 MIPS if
everything is in registers.

The RISC I has 78 registers, the RISC II has 138.

The Pyramid machine is not a RISC machine even though it does have
the register windows.  It is microcoded and does pay a penalty,
but in the interest of getting the machine out fast, it was a big
win for Pyramid to use microcode.

There are some RISC designs in the pipelines of some companies:  HP
has a project called SPECTRUM which is to be the basis of "all"
future big HP computers (I may have that phrased a little incorrectly).
It "should" already be out, but you know big companies.  Inmos has
been spouting off about the Transputer, a single-chip RISC machine,
but we haven't seen too many of those either.  DEC is experimenting
with RISC.  SUN is experimenting with RISC.  Weitek (spelling?)
(the makers of floating point chip sets) is experimenting with RISC.
In short, anyone who has any sense and does not fear the idea of
being incompatible with past designs (at the instruction set level),
is toying with RISC designs.  There are some start-ups whose sole
goal in life is to exploit the benefits of the RISC concepts (not
all of which are to be found in papers and especially not in BYTE),
and there are some companies trying to form with the same goal in
mind.

What are the main RISC concepts and why are they so important?
Main concepts:  efficient storage hierarchy and minimal instruction
interpretation overhead.  The importance of an efficient storage
hierarchy should be obvious, but not so obvious is the fact that the
register set of the machine is really just the fastest part of the
hierarchy.  The storage hierarchy is MUCH more important than the
number of instructions executed to implement a given function (within
reason of course).  The importance of minimal instruction interpretation
overhead has far reaching implications, including not wasting time,
not wasting silicon, making it easier for a compiler to decide
which instructions, or sequence of instructions, to use, making it
easier to pipeline the machine, etc.

Another important property of RISC machines (here machine means the
hardware together with the compiler) is that they tend (given good
compilers) to REUSE results and data rather than RECOMPUTE or REFETCH
results and data.  As an example, take some VAX instruction which
computes the address of some stack-local variable:

    OPCODE    4(sp),x,y

If this instruction is in a loop, then the computation of 4+sp will
be done on EACH iteration of the loop!  This is clearly wasted effort.
A good RISC compiler will factor out this computation and place the
address in a register (thus, we begin to see the need for lots of
registers).  Now you say, "but the VAX compiler could do this also!"
Sure, but then what becomes of the sp+offset addressing mode?  It is
surely not nearly as important now, and all the control needed to
implement it is less utilized, or perhaps little utilized (there will
still be some other places where register+offset will be useful),
and if it were eliminated, the whole machine may become faster by
virtue of a shorter cycle time.  But now, we need to get instructions
to the CPU at shorter intervals, thus again reinforcing the need for
an efficient storage hierarchy.  If enough iterations of this
measuring/simplifying algorithm are carried out, a RISC design is the
result.

The issue is certainly more compilcated than my discussion would lead
one to believe (one problem is handling interrupts and other pipeline
inconsistencies), but I think I have shed some light on the subject.
There has been considerable work done in this area, and even though
much more needs to be done, the ideas are mature enough that some are
venturing into the commercial market.  RISC machines promise to give
us high performance designs in less time and space (and maybe money)
than conventional machines.  Plus, by using the RISC philosophies,
machines can be designed for special purposes in cases where an attempt
to do so wouldn't have been made before.