Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ncrlnk!emdeng!hrich
From: hrich@emdeng.Dayton.NCR.COM (George.H.Harry.Rich)
Newsgroups: comp.arch
Subject: Re: Why The Move To RISC Architectures?  ('386 vs. RISC)
Message-ID: <289@emdeng.Dayton.NCR.COM>
Date: 21 Mar 90 13:46:27 GMT
References: <28012@cup.portal.com>
Reply-To: hrich@emdeng.UUCP (George.H.Harry.Rich)
Organization: NCR, E&M Dayton
Lines: 48

.In article <28012@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
.>architectures really tell you anything of worth?
...
.>
.>Finally, why is everyone so excited about RISC?  Why the move to
.>simplicity in microprocessor instruction sets?  You would think
.>that the trend would be just the opposite - toward more and more
.>complex instruction sets - in order to increase the execution
.>speed of very high-level instructions by putting them in silicon
.>and in order to make implementation of high-level language
.>constructs easier.
.>
>Thanks,
>Will              (sun!portal!cup.portal.com!Will)
> 

I want to first state that I'm not an expert on RISC architecture, but the
experts seem not to have replied, or given oversimplified explanations, so
I'll make an attempt.  My area is software, not hardware, so I hope those
who are knowledable will be quick to correct me if I'm wrong.

First of all, what you save on a complex instruction versus several simple
ones is the fetch and decode time.  If the processor has good prefetch and
caching what you are generally talking about is decode time.  However,
a really simple instruction set takes less time to decode, so it is conceivable
that you could have a net savings without taking other factors into account.

However, the real point is that you pay the penalty for the complex decode
even for very simple instructions where you don't get a benefit for your
increase in decoding time.  While compilers may take advantage of complex
instructions for such things as stack frame management,  most complex
instructions seem to be designed for the convenience of assembler programmers
rather than compiler code generation, and the bulk of the code generated by
compilers involves relatively simple instructions.  Even where instructions
are designed for compiler code generation, the designers miss fairly often,
and the instruction sits there in silicon, unused by the compiler writers.

It might even be true that a complex instruction set designed ideally for
compiler code generation might beat RISC.  However, ideal designers are
very rare.  There are always some design flaws in a complex system.  A
RISC design has the benefit of targeting toward a simple thing done well,
and removes from the designer the burden of knowing some of the more
arcane details of compiler writing.  It is not really surprising that it
is a good approach in practice.

Regards,

	Harry Rich