Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.arch
Subject: Re: RISC processors
Message-ID: <4640@utzoo.UUCP>
Date: Thu, 15-Nov-84 17:39:54 EST
Article-I.D.: utzoo.4640
Posted: Thu Nov 15 17:39:54 1984
Date-Received: Thu, 15-Nov-84 17:39:54 EST
References: <641@watdcsu.UUCP>, <267@idi.UUCP>
Organization: U of Toronto Zoology
Lines: 28

> RISC machines may not be as good as they look at first
> glance.  The Berkeley implementations, in particular, gain
> nearly all of their performance by using register windows.
> The simplicity of the instruction set may in fact slow these
> chips down, although it certainly makes them easier to
> implement.

Don't knock implementation ease.  No way could the Berkeley people have
built a chip with all those registers unless the control section was
very simple.  There is also the telling observation that many existing
CISC machines are notorious for being faster if you "hand code" the
complex sequences rather than relying on the all-singing-all-dancing
fancy instructions.  For example, C function calls are faster on an
11/70 than on a VAX, even though it's one instruction on the VAX and
about a dozen on the 70.

Another way to look at it is that the RISC machine is a machine with
unusually "clean" microcode that is executed directly out of main
memory, and generated directly by compilers.  Assuming that the
cleanliness and the memory fetches aren't a major problem, clearly
it is faster to write your own microcode for a specific job than to
rely on the CPU designer's ROM microcode.

"If the big performance win is register windows, then the rest of the
CPU should be made as simple as possible, i.e. a RISC."
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry