Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site terak.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!hao!noao!terak!doug
From: doug@terak.UUCP (Doug Pardee)
Newsgroups: net.micro.68k,net.arch
Subject: Re: RISC
Message-ID: <591@terak.UUCP>
Date: Mon, 3-Jun-85 16:39:43 EDT
Article-I.D.: terak.591
Posted: Mon Jun  3 16:39:43 1985
Date-Received: Thu, 6-Jun-85 02:37:19 EDT
References: <639@vax2.fluke.UUCP> <2743@nsc.UUCP> <576@terak.UUCP> <611@lll-crg.ARPA>
Organization: Terak Corporation, Scottsdale, AZ, USA
Lines: 48
Xref: watmath net.micro.68k:862 net.arch:1313

Responses to early comments on my question about how a RISC cpu can
fetch instructions fast enough to keep up with non-RISC cpus:

> The knee jerk answer to the instruction fetch bandwidth problem, cache,
> is a valid answer.  The argument that one can give as much cache to a
> complicated instruction set engine and therby get as much performance is
> not valid.  The performance reduction for the complicated instruction set
> comes from the time spent running microcode decode and execute instructions.

I'd believe this except that it ain't so.  The performance reduction on
current non-RISC single-chip cpus comes from instruction fetch.  For
example, the NS32016 can do your basic RISC-type operations in 3 or 4
clock cycles, but it takes 5 clock cycles to fetch the next instruction.
RISC-type instructions on the 32016 therefore take 5 clock cycles each.
And the 32016 is "burdened" by non-RISC "microcode decode and execute
instructions."

> One way to help with this problem is to use fairly wide memory accesses
> (at least for instruction fetches).  Thus, in one memory cycle, many
> instructions may be fetched simultaniously.  Of course this is done for
> non-RISC machines as well, but a non-RISC machine will become
> execution-bound sooner.

The NS32032 and MC68020 both fetch 32 bits of instruction data at one
time.  Both have "zillions" of pins on the package in order to pull that
off; I can't imagine building a RISC chip with 128-bit wide instruction
fetch, requiring over 250 pins on the package.

And if we're not talking single-chip architectures, we're going to have
a devil of a time making rational comparisons.  After all, IBM has used
a non-RISC architecture for some time and it goes pretty fast :-)

I'll believe that a non-RISC machine will become execution-bound sooner,
but this just another way of saying that the RISC machine is much more
limited by instruction fetch than the non-RISC machine is.

> Also, since the RISC instruction set is simpler, the op-codes require fewer
> bits, so a memory fetch will get more RISC instructions in one cycle
> than it would non-RISC instructions.

I thought this too, until I looked into some RISC machines.  They use
32-bit instruction words, twice as wide as the equivalent instructions
in, say, the 680xx and 320xx cpus.

Still looking for the answer...
-- 
Doug Pardee -- Terak Corp. -- !{ihnp4,seismo,decvax}!noao!terak!doug
               ^^^^^--- soon to be CalComp