🚀 go-pugleaf

In article <443@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes:
>Some RISC machines have multiple sets of registers, organized as overlapping
>windows.  This approach to speeding up calls/returns was suggested to the
>RISC I team at Berkeley by Forest Baskett; simulations convinced us it would
>work for typical UNIX code, so we implemented it.  It worked.  
>	Howard A. Landman

As I understand it, each register window is a fixed size, and each window
is divided into three fixed size subwindows.  (I don't remember what
these three subwindows are meant to be used for.)  One particular aspect
of the implementation has been bothering me; namely, the amount of
overlap between two windows is a constant size.  This has two consequences.

First, subroutines which don't use all of their window waste register storage.
Typical programs that I write tend to contain short routines that use
few variables and need few registers.  Thus, my programs can't get the
full benefits of the register windows; many of the registers remain 
unused.

Second, subroutines that want to pass more parameters than will fit
in an overlapped window, but fewer parameters than would fit in a complete
window are also penalized.  Not all parameters will be able to be passed
inside of registers, and some must be saved in memory.

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.

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

thanks, Chuck