Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!ucbvax!hplabs!hpda!hpcuhc!hpspcoi!kluksdah
From: kluksdah@hpspcoi.HP.COM (Keith Kluksdahl)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Why The Move To RISC Architectures?  ('386 vs. RISC)
Message-ID: <1640082@hpspcoi.HP.COM>
Date: 21 Mar 90 17:29:18 GMT
References: <28011@cup.portal.com>
Organization: HP PCG, Sunnyvale CA
Lines: 30


All this does not mention microcode, which is the real reason that
RISC processors can achieve greater throughput.  Each time one of
the complex instructions is fetched, it requires many microcode
instructions to execute.  Fancy instructions such as multiply
require quite a number of microcode instructions.  And each
microcode instruction requires a clock cycle.  The simplier
instructions require a penalty or several microcode instructions,
and clock cycles, to execute.

Most of the instructions executed in a computer are loads,
stores, and branches, which are relatively simple to perform.
RISC systems perform these instructions in one clock cycle (with
some exceptions, of course), instead of the multiple clock cycles
required by CISC processors.

By adding things like barrel shifters, many other instructions
can also execute in one clock cycle.  The result is a fairly
rich instruction set, which isn't really reduced.

Writing code for RISC machines is much like writing microcode.
And it can be more difficult than writing CISC code.  But the
performance seems to make it worthwhile.  Time will tell.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
| These views are my own, but I may   |  Keith Kluksdahl   |
| be re-programmed tomorrow........   |  HP Bedford Falls  |
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Tested tough in Alaska.    |<---------- So Long ---------->|