Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: comp.arch
Subject: Re: subroutine frequency
Message-ID: <28200012@ccvaxa>
Date: Thu, 26-Feb-87 13:41:00 EST
Article-I.D.: ccvaxa.28200012
Posted: Thu Feb 26 13:41:00 1987
Date-Received: Sun, 1-Mar-87 14:53:55 EST
References: <13286@sun.uucp>
Lines: 46
Nf-ID: #R:sun.uucp:13286:ccvaxa:28200012:000:2104
Nf-From: ccvaxa.UUCP!aglew    Feb 26 12:41:00 1987


>So I'm wondering why the implementation of the RISC I and II don't
>allow the programmer to specify the number of registers that should
>be overlapped on the procedure call.  Obviously, this would make
>subroutine calls more expensive and difficult to implement.  The
>overlap size would have to be fetched from memory and added to the
>window pointer.  Checking to see if the register stack had overflowed
>might be more expensive...  However, these seem like trivial problems
>when compared to the benefit of effectively having a larger
>register stack.

	You've just gone and made procedure calls more expensive.
Since register stack overflows rarely occur(*), and the fixed size
window handles the 90% case, the numbers don't necessarily work out.


>Are there reasons I am missing that make fixed sized windows extremely
>advantageous?

	Register windows require that a "logical register number"
be combined with a "register window pointer" to produce the actual
"physical register number" in the register file.
Usually, this is a simple addition. 
	But then an extra addition is required on all register accesses.
This adds a delay equal to that of the fastest carry chain you can provide
to the critical path. It may not be possible to absorb this in a 
pipeline stage.
	Fixed size windows can mean that you don't have to add all the
bits together. Fewer bits => shorter carries => faster register cycle.

	Note that this was apparently NOT a concern for RISC.

---
(*) Register stack overflows rarely occur: for a fixed size register
	stack, this is true only because routines typically have a
	small dynamic range in procedure calling depth.

	The pertinent studies were made on UNIX. I'm not so sure that
	UNIX is a good example for future systems, since UNIX contains
	a lot of low level code without benefit of abstraction.
	Higher level languages, or systems that encourage the use
	of procedure calls, may well have a greater dynamic range.


Andy "Krazy" Glew. Gould CSD-Urbana.    USEnet:  ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801    ARPAnet: aglew@gswd-vms.arpa