Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site tardis.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!tardis!lucius
From: lucius@tardis.UUCP (Lucius Chiaraviglio)
Newsgroups: net.arch
Subject: Re: Re: RISC
Message-ID: <10083@tardis.UUCP>
Date: Thu, 30-May-85 01:16:48 EDT
Article-I.D.: tardis.10083
Posted: Thu May 30 01:16:48 1985
Date-Received: Fri, 31-May-85 05:56:48 EDT
Distribution: net
Organization: Harvard University, Cruft Lab (TARDIS)
Lines: 60

_
> RISC is an interesting concept, but I have a major reservation.  Perhaps
> someone can explain to me how on earth you're going to feed instructions
> to a RISC machine fast enough?
> 
> 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.

	How about giving the processor an instruction and operand queue in
addition to a cache and give both the processor-to-cache and cache-to-memory
paths a width that is some multiple of the length of a normal data word.  The
idea is to do memory access in parallel (even more than it already is -- this
means parallel not only at the bit level but at the word level as well; I
believe this is not a foreign idea -- if I remember correctly the VAX has a
cache-to-memory data path of this type) so as to make up for the slow serial
speed of these operations.

> 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.

	Why can't you fit as much logic into the cache of a RISC machine as
into the cache of a standard CPU?  The rest of the CPU would still be RISC; I
thought part of the idea of some RISC projects was to save hardware space for
things like this.  Of course, some RISC projects also have the idea of making
the compiler and/or the operating system take care of managing the cache.

> 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?

	Yes, but with simpler and faster hardware, and no fixed microcode
(unless you take the step of putting these routines in ROM, which could be
useful for some applications).  Some CPUs have writable control store than be
loaded without having to reboot the system but with a RISC software (the
compiler, for one thing) is more responsible for taking care of this, so you
can arrange to have even more flexibility and less hassle with context
switches (for the non-assembly programmer that is -- at the low level the
hardware and the software are doing a great amount of work (the new hardware
that RISC machines put in the space they save on conventional hardware is for
this kind of thing) to make it easy for the upper levels, and thus to make the
whole system generally run more smoothly).  So in other words you still get
the advantages of your "everyday, garden variety microcoded non-RISC cpu"
(except that you have to spend more money on lots of fast memory, including
the cache, but memory is getting cheap enough these days to make it worth the
additional expense by improving performance), but lack some of the
disadvantages.

-- 
	-- Lucius Chiaraviglio
	{ seismo!tardis!lucius | lucius@tardis.ARPA | lucius@tardis.UUCP }