Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site amdahl.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!houxm!mhuxt!mhuxr!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!sun!amdahl!mat
From: mat@amdahl.UUCP (Mike Taylor)
Newsgroups: net.micro.68k,net.arch
Subject: Re: RISC
Message-ID: <1590@amdahl.UUCP>
Date: Fri, 31-May-85 12:05:33 EDT
Article-I.D.: amdahl.1590
Posted: Fri May 31 12:05:33 1985
Date-Received: Sun, 2-Jun-85 04:29:16 EDT
References: <639@vax2.fluke.UUCP> <2743@nsc.UUCP> <576@terak.UUCP>
Organization: Amdahl Corp, Sunnyvale CA
Lines: 50
Xref: watmath net.micro.68k:850 net.arch:1294

> 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.
> 
> But doesn't that sound like your everyday, garden variety microcoded
> non-RISC cpu?
> -- 
> Doug Pardee -- Terak Corp. -- !{ihnp4,seismo,decvax}!noao!terak!doug
>                ^^^^^--- soon to be CalComp

Fetching one instruction per cycle is pretty much necessary to execute
one instruction per cycle.  Whether this is a bug or a feature is a
good question.  The difference between fetching a microword every cycle
and fetching an instruction is that the microcoded machine has a fixed
microsequence in ROM while the instructions come from RAM.  Since they
come from RAM, they can be optimized by the compiler for the particular
job being done. Clearly you pay for this by diverting fetches from
microstore to RAM.  Some RISC implementations try to get this cost back by
using the microstore's chip space for registers and/or instruction queues,
reducing total fetch traffic.

How can you tell a machine is not a RISC ?  Proposal...

If it is possible to replace some instructions with sequences of other
instructions with only small performance penalties (or gains, a la VAX)
then those instructions probably have no business in the instruction
set.  Their presence is probably slowing down the whole system.  Take
them out.  Redesign to use the space you got back by removing them.

Repeat the above cycle until no more instructions can be removed or
the cycle doesn't improve performance.  You now have a RISC.

Arguments ?
-- 
Mike Taylor                        ...!{ihnp4,hplabs,amd,sun}!amdahl!mat

[ This may not reflect my opinion, let alone anyone else's.  ]