Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!seismo!rlgvax!cvl!umcp-cs!mark
From: mark@umcp-cs.UUCP
Newsgroups: net.arch
Subject: Re: "another RISC" machine
Message-ID: <7101@umcp-cs.UUCP>
Date: Sun, 20-May-84 00:05:27 EDT
Article-I.D.: umcp-cs.7101
Posted: Sun May 20 00:05:27 1984
Date-Received: Mon, 21-May-84 03:42:09 EDT
References: <332@decwrl.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 68


	...Thus we might say that the Pyramid machine is NOT a RISC machine
	because it has moderate amounts of microcode rather than saying
	that it is a RISC machine because it has register windows.
	Likewise, the Ridge machine would not be a RISC machine because
	it also has a moderate amount of microcode.  (Yes, we know that
	the marketing departments at Pyramid and Ridge have already
	asserted that their machines are RISC machines.)...

Thanks for the clarification, Forest.  

Assuming a RISC machine needs a fast equivalent of a procedure call,
what are the alternatives to register banking?  Three things happen
at procedure call time: (a) the PC changes, (b) parameters must be passed,
and (c) new working storage is required.  The first is common to branches
I won't discuss it further (aside: Ridge has bits in its branch instructions
to help the instruction pre-fetcher guess which way to go.)
Overlapping register banking, as in the Pyramid and Berkeley-"RISC"
architectures, achieves (b) and (c) wonderfully.  Alternatives:

1. Expand calls in-line.  This adds to compile time and code space,
and doesn't work for external procedures.  By itself it does not
actually eliminate much overhead (because one must still simulate
by variable assignment the moving of parameters into and out of
the in-line procedures name space).  But coupled with a real good
global optimizer it could be a win.

2. Half way to in-line expansion is to compile-in working 
storage for called procedures in the calling procedure.
The pascal compiler of MDSI, written up 5 years ago in Transactions on
Software Engineering, used this trick for internal procedures.  The idea
is for the compiler to use the information that a certain procedure is 
only called by certain other procedures to improve their data sharing.
Specifically, the caller, when it is called, can pre-allocate any
working storage for the callee, so there is no overhead at call time
to the callee, and very little additional when the caller is called.
Furthermore, the compiler can be clever about where it puts the parameters
in the caller's space so parameter passing overhead is minimized and the callee
can get the parameters easily, possibly by reaching into the callers data
area.  Disadvantages of this scheme is that it only works if callers and
callees are simply related (no external procedures, please), and even
then often gets too complicated to work out.

3.  (this one is made up, I know of no implementations that do it)
Do a pipe-lined mini-bank switch.  The idea is that if
the processor could start the procedure call before it was needed
it could do the call in parallel with the last few instructions
before the call.  (Several machines have a delayed branch instruction,
in which the branch is taken an instruction or two after it is 
first seen in the instruction stream.  Are there machines that do this for 
calls?)  Only thing is, usually those last few instructions before the
call are getting ready for the call, and the call itself is mostly
moving data values around.  The bank-switch call permits pipelining
because it involves changing the machines internal memory mapping
so that after the call certain caller locations are secretly mapped
into certain callee locations.  This can happen in parallel with
placing values into those locations because the call instruction
doesn't move the data, just remap it.  This is a lot like register
remapping, as in SOME RISC machines, but may be less work for
the compiler at the expense of complicated hardware.  Since
the trend these days is to overwork compilers to simplify hardware,
it may not be a good idea.

What other alternatives to register bank switching are there to
speed up call instructions?
-- 
Spoken: Mark Weiser 	ARPA:	mark@maryland
CSNet:	mark@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!mark