Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-ses!hpcuhb!hpindda!kmont
From: kmont@hpindda.HP.COM (Kevin Montgomery)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Why The Move To RISC Architectures?  ('386 vs. RISC)
Message-ID: <40970054@hpindda.HP.COM>
Date: 21 Mar 90 02:43:15 GMT
References: <28011@cup.portal.com>
Organization: Bill and Dave's
Lines: 54


> Also, since the 80386 has a more complex instruction set and does
> more work in a given instruction than does a typical RISC chip,
> does comparing MIPS figures between RISC and non-RISC
> architectures really tell you anything of worth?

nopers...   "MIPS are meaningless"

> 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.

First, I'd refer you to comp.arch, where this is talked about endlessly.
The advantage is that the simpler a design is, the more it can be optimized.

A couple of profs at Berkeley (Patterson and Sequin) looked at the usage of 
the instructions of a few machines and found that 10% of the instructions
were being used 90% of the time.  Even though some snazzy, neato, high-level
instructions existed (who can forget the VAX polynomial instruction?), the
code spit out by the compiler never made use of them (to say nothing of the
fact that alot of these functions were in microcode!).  So, you had 95% of 
the code in the world suffering to get their stuff done because the design 
of the processor was convoluted by having functions that only a few people
used.  So, these guys at UCB (along with some great folks at Stanford) said,
"Gee (no GTE), maybe we should only have the instructions we need and optimize
the hardware/stacks in a big way" (UCB)  and "Gee (same joke), maybe we should 
get the compiler writers and hardware guys to talk together" (Stanford).  So, 
UCB cut out the deadwood and optimized the hardware, and Stanford cut out the
deadwood, got the compiler writers and hardware guys talking, used a larger
set of general registers, left Stanford and begat MIPS  (okay, a little 
simplistic, but hey, it's MY posting).  Other companies were looking at the
technology at the time and picked either one of the camps (Sun->UCB, HP&MIPS
->Stan).

So, in general, you want to only have the instructions you're going to use
and you want these as fast as can be.  Unused instructions are deadwood that
prevents you from optimizing the remaining instructions.  Also, by making
the designs less complicated, clock speeds can go through the roof.  So, you
get these screaming little processors that need more and more memory to keep
them fed.  Also, since you have the chip space and life is simpler, you
can do other nice things like pipelining.  Also, don't forget- since it's
simpler, you can crank out a design in half the time it used to take.

Will it hold up?  Dunno.  Personally, I think that multiprocessor designs may
be the undoing of RISC-based systems, unless someone can build a good, cheap,
fast dual-ported memory.  Remember, the faster the CPU goes, the more the 
memory bottleneck grows.  And having more processors increases the contention
for memory.  We'll see how it shakes out, but for now, the customer wins big.

						kevin