Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site unc.unc.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!mcnc!unc!rentsch
From: rentsch@unc.UUCP (Tim Rentsch)
Newsgroups: net.arch
Subject: Re: RISC question
Message-ID: <1073@unc.unc.UUCP>
Date: Mon, 3-Mar-86 20:20:26 EST
Article-I.D.: unc.1073
Posted: Mon Mar  3 20:20:26 1986
Date-Received: Wed, 5-Mar-86 06:42:37 EST
References: <1181@ecsvax.UUCP> <411@ccivax.UUCP> <375@ektools.UUCP> <738@ihwpt.UUCP>
Reply-To: rentsch@unc.UUCP (Tim Rentsch)
Distribution: net
Organization: CS Dept, U. of N. Carolina, Chapel Hill
Lines: 58
Summary: 

In article <738@ihwpt.UUCP> knudsen@ihwpt.UUCP (mike knudsen) writes:
>> Since a RISC machine doesn't have the fancy microcoded instructions of
>> a CISC machine, it takes more instructions to do the same job.  Even
>> though a RISC instruction typically requires fewer bits than a CISC
>> instruction, a program for a RISC machine is generally said to be
>> larger than the equivalent program for a CISC machine.  With today's
>> low memory prices, this is not a terrible thing.
>> 
>> I was always taught that 80%-95% of the bus usage of a processor was
>> for instruction fetches.  Therefore if a RISC machine takes more bytes
>> of instructions to run a program than a CISC machine would, the RISC
>> processor will eat up MORE bus cycles, leaving fewer for displays, DMA
>> , and co-processors.
>
>I agree with you.  Modern CISC processors are microcoded
>(nanocoded?) and fetch one CISC instruction from system RAM,
>then proceed to fetch many nano-instrs from internal ROM
>to perform it.  Meanwhile, the bus is free.
>RISC machines essentially run "nano code" out of YOUR main
>RAM over YOUR bus.  So yes, you seem right to me.
>	mike k
>Or are we both missing something?


The proper term is microcode.  Nanocode actually exists in some
machines (although what the term means varies).  The Nanodata QM-1
(no, I am not making this up) is the most well known example.

Also, you are missing something.  In the first place, the numbers
are wrong: instruction fetches use only about half of the bandwidth
used by a program, not 80-95%.  (As I recall this percentage was
given for the recent Clipper chip, a RISC chip, as 55%.)

For another thing, you assume that the amount of bandwidth so
consumed is significant.  I will grant that RISC programs are
bigger.  Let's be generous and say they are twice as big (usual
numbers are less than 2).  Assuming 50% of pre-RISC program
bandwidth came from instruction fetches, this is an increase of
program bandwidth requirements of 50% (((2*50% + 1*50%) / 100%) - 100%). 
But programs do *not* use up all of the memory bandwidth available.
I don't have any actual numbers handy, but suppose they use 1/3 of
the total bandwidth available (pre-RISC).  After RISCing, they use
1/2.  In other words, "extra" memory bandwidth has decreased by only
25%.  I for one would trade the memory cycles for a faster
processor, since it is then easy to reduce the need for the
"extra-processor" memory cycles -- just buy more RAM.

Finally, instruction bandwidth does not necessarily translate into
bus bandwidth, because of memory caches.  If the cache hit rate is
very high, almost no bus bandwidth will be consumed by the longer
instruction fetches.  Granted, a larger cache will be required to
achieve the same hit rate for the now-larger instructions, but
instuctions generally have higher cache hit rates than data so
that a modest increase in cache size should suffice.  (In any case,
caches scale up nicely and easily, so if you need more cache, just
add it.)  The Clipper, somewhat RISCish, has two caches, one for
instructions and one for data, so that instruction bandwidth does
not interfere with data bandwidth.