Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site metheus.UUCP
Path: utzoo!linus!philabs!seismo!harpo!floyd!vax135!cornell!uw-beaver!tektronix!ogcvax!metheus!howard
From: howard@metheus.UUCP (Howard A. Landman)
Newsgroups: net.arch
Subject: Re: Risc Over-blown - (nf)
Message-ID: <192@metheus.UUCP>
Date: Thu, 15-Dec-83 18:55:12 EST
Article-I.D.: metheus.192
Posted: Thu Dec 15 18:55:12 1983
Date-Received: Sat, 17-Dec-83 07:44:05 EST
References: <579@inmet.UUCP>
Organization: Metheus, Portland Oregon
Lines: 80

In response to inmet!bhyde (ben hyde):

	I thought the problem was to consume all those transistors that the
	VLSI people have to burn.  ... wouldn't a complex processor with a
	compact rich format be a reasonable place to spend the chip area?

	... lots of things to spend transistors on, memory mapping caches,
	instruction stream caches, decoded instruction caches, stack caches,
	microcode, registers, capablity addressing, memory, memory, memory.

	If the number of transistors was very very large, so the incremental
	cost of the next thousand transistors was very low it would seem that
	one would always spend them on increased complexity, reliablity, etc.

	... given that the cost difference was only a small factor would you
	by [sic] a RISC or a VAX?

Consider the Hewlett-Packard "wonder chip".  It has nearly half a million
transistors and is implemented in a 1-micron (!) techology that inherently
is 4+ times faster and 16+ times denser than the 4-micron technology that
RISC I and RISC II were implemented in.  I will not speak of the enormous
expense of its development.  And yet ... it is not faster than the RISC
chips for executing HLL programs.

Consider the 432.  Consider its multi-year $50,000,000 development effort.
Consider its performance.  Consider the 17 man-months needed to develop the
RISC I chip (maybe double that to account for the architectural studies),
which would have cost a company less than .005 as much, took less than .1
as long, and resulted in a better-performing chip.  Consider what could have
been done by the RISC designers if THEY had been given $50,000,000 and 5 years
in which to finish their design and turn it into a commercial product.  Or
$10,000,000 and 1 year.  Or $5,000,000 and 6 months.

Now think about these things very carefully and ask yourself why your
conclusions are wrong.  It may take several months for you to fully discard
the wrong assumptions that led you to them.

When RISC I was being designed, we asked some very simple questions.  Q: What
do we want to do with computers? A: Execute HLL programs. Q: What's a good
current architecture for doing this? A: VAX 11/780 seems quite reasonable.
Q: What limits the performance of the VAX? A: Memory bandwidth. Q: What is
using up most of the VAX's memory bandwidth? A: It turns out that procedure
calls and returns account for almost half of the memory traffic. Q: How could
something faster than a VAX be built? A: Build hardware support for calls and
returns, cutting memory accesses in half.

etc.  What I am trying to say is that you have to carefully look at the issues
and spend chip real estate on things that will improve the price/performance
of the entire system.  For example, the importance of code density is related
to the cost of memory and the extent to which instruction fetching memory
accesses limit performance.  So it may be VERY important, or it may be
unimportant, depending on architecture and RAM chip prices.

Complex instruction sets and complex architectures require complex control.
All commercial microprocessors ever produced use 50-75% of the chip for
control.  RISC I used 6-8% for control.  For a given chip size, this implies
that a RISCy architecture would get to use 2 to 4 times as many transistors
for all the wonderful performance-enhancing additions you mentioned above
than would a complex architecture.  Not to mention that the designers would
be spending less time on implementing the basic architecture and more time
on how to make it run fast.  So the question is, would you rather spend
silicon on adding more instructions to your instruction set, or on speeding
up the execution of the instructions you have?  EVERY analysis that we did
in the RISC design indicated that the former was pretty much useless and the
latter was highly desirable, once the instruction set passes the point where
it is adequate to support HLLs and operating systems.  Many people still feel
otherwise and design systems accordingly.

I do not mean to say that the RISC chips are the last word in microprocessor
architecture.  But I believe that any effort to do something better should be
asking itself some important questions: Q: What do we want to do with this
chip? A: Execute HLL programs. Q: What's a good current architecture for doing
this? A: RISC seems quite reasonable.  Q: What limits the performance of the
RISC? A: (?) Q: How can we solve this and go faster still? A: (?!)

As is usual for this field, there are many theses and/or dollars awaiting
those who answer these questions correctly.

	Howard A. Landman (just another RISC I designer)
	ogcvax!metheus!howard