Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site hammer.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!orca!hammer!steveg
From: steveg@hammer.UUCP (Steve Glaser)
Newsgroups: net.micro.68k,net.arch
Subject: Re: RISC
Message-ID: <1303@hammer.UUCP>
Date: Tue, 4-Jun-85 20:51:09 EDT
Article-I.D.: hammer.1303
Posted: Tue Jun  4 20:51:09 1985
Date-Received: Thu, 6-Jun-85 08:39:50 EDT
References: <639@vax2.fluke.UUCP> <2743@nsc.UUCP> <576@terak.UUCP> <1590@amdahl.UUCP>
Reply-To: steveg@hammer.UUCP (Steve Glaser)
Organization: Tektronix, Wilsonville OR
Lines: 46
Xref: watmath net.micro.68k:871 net.arch:1322
Summary: 

In article <1590@amdahl.UUCP> mat@amdahl.UUCP (Mike Taylor) writes:
>> All of the popular 8 and 16 bit microprocessors are speed limited by
>> instruction fetch, not by instruction complexity.  I will entertain the
>> objection that the 6502, with its critical shortage of on-chip
>> registers, is also limited by operand accesses.  The usual RISC machine
>> has lots of registers, so operand accesses shouldn't be a problem.
>> And nobody says that a non-RISC cpu can't have lots of registers.
>> 
>> The knee-jerk answer is "cache".  But that's only an answer if one
>> refuses to allow non-RISC cpus to use cache; they can fit more logic
>> into any given cache than can RISC cpus, thereby having a better "hit
>> ratio" than RISC.
>> 
>> Of course, one could design a RISC machine with a super-high-speed ROM
>> or cache in which one could store the commonly used functions like
>> multiplication and division, and then one would only have to fetch a
>> subroutine call from the (slow) instruction stream.
>> 

The basic tenants of RISC are that you throw out the useless bagage
that's in there "cause somebody wanted it and microcode was cheap" and
get back to a reaconable minimal set (do chuck out an instruction;
measure performance; if better or same, repeat).  With the real estate
gained, you then start putting reasonable sized caches and/or prefetch
queues on chip instead of useless instructions.

Some folks have decided that RISC means that you eliminate the
microcode and directly decode the operations.  This is too narrow of a
view.  It doesn't matter how you implement what's left, as long as you
only implement what is really needed.

As for caches, one issue that hasn't been mentioned is the use of block
mode transfers for fast cache filling.  There are ram chips out there
that can access "nearby" ram cells significantly faster that random
ones (so called page mode, nibble mode, or static column rams).  These
were mainly developed for the raster display markets (so you don't
waste all your memory bandwith refreshing the screen and you get a
chance to make updates to it), but are useful in other areas as well.
Since caches blocks are typically a power of 2 in size and start on
nice boundaries, it's pretty easy to map these into the notion of
"nearby" supported by a ram chip.  The only problem you have with this
kind of architecture is (1) you need a new bus protocol, and (2) ECC
gets harder cause you need to do it faster (anybody for a pipelined ECC
chip that can keep up with 50nsec ram cycles?).

	Steve Glaser