🚀 go-pugleaf

>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