Path: utzoo!mnetor!uunet!mfci!root
From: root@mfci.UUCP (SuperUser)
Newsgroups: comp.arch
Subject: Re: RISC  a short answer??
Message-ID: <381@m3.mfci.UUCP>
Date: 3 May 88 01:28:03 GMT
References: <1036@nusdhub.UUCP> <21149@pyramid.pyramid.com> <307@mucmot.UUCP>
Reply-To: mfci!colwell@uunet.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 46

In article <307@mucmot.UUCP> ron@mucmot.UUCP (Ron Voss) writes:
=From article <21149@pyramid.pyramid.com=, by csg@pyramid.pyramid.com (Carl S. Gutekunst):
== In article <1036@nusdhub.UUCP= rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
===Can someone give me [short answer style] a description of what "RISC" means.
== 
== My favorite answer is this:
== 
== 	RISC (Reduced Instruction Set Computer) is a design philosophy that
== 	trades off decreased complexity in hardware for increased complexity
== 	in software. The instruction set is specifically chosen to provide a
== 	set of primitives that are most usable by compilers. Then these few
== 	instructions are made to run as fast as possible. The compilers are
== 	given the responsibility of building the primitives into the higher-
== 	level constructs used by the language.
== 
== By implication, the compilers becomes as much a part of the design as the CPU
== itself.
== 
== <csg=
=It's not that I disagree with Carl, it's just that I think he's left out
=what for me is the most central issue:  Dedicating more of the finite
=chip real estate to circuits whose chief function is to provide increased
=processor speed.  The most significant consequence is that there is no
=room left to implement more complex instructions.  The theory (proven?)
=is that there is a net increase in performance, since processors spend
=most of their time at relatively simple operations, like load, store,
=add.  More complex (now missing) instructions, like "toggle bit n of byte m"
=may end up running slower in emulation, but the increased speed of simple
=instructions more than makes up for it. <rnv=

But let's not get too provincial.  What lessons there are to learn
from RISC apply to more than just one-chip processors, and it isn't
obvious how to extend your "finite chip real estate" metric to
board-level machine design.  And watch out for something else.  A
processor running a general UNIX/university job mix is going to look
a lot different than a scientific computer, which spends a lot more
of its time doing fairly complex operations (floating point ops).
The key is to 1) keep what you absolutely need; 2) include things you
can prove will help performance; 3) move whatever you can to
compile-time.  And no matter what you design, by all means call it a
RISC (mega-smiley here).

Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090