Xref: utzoo comp.lang.c:26992 comp.lang.misc:4497
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!yale!mintaka!ogicse!decwrl!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: function calls
Message-ID: <12350@goofy.megatest.UUCP>
Date: 16 Mar 90 22:13:39 GMT
References: <29509@amdcad.AMD.COM>
Organization: Megatest Corporation, San Jose, Ca
Lines: 27

From article <29509@amdcad.AMD.COM>, by tim@nucleus.amd.com (Tim Olson):
> 
> If you partition your registers into a set that is live across a
> function call and a set that is killed, then leaf routines can run
> entirely out of the later set, not having to save any registers.  For
> example, in the Am29000 calling-convention, a function can allocate up
> to 126 local registers which are saved across function calls and
> also has use of 24 "temporary" registers which are not.  ...

The RISC machines have an internal register which acts something
like a frame-pointer with respect to the user-registers, yielding
what they call 'overlapping register windows'.  Thus user-registers need
not be saved and restored except when the window moves off one end of
the register set or the other.

Back in the 70's, TI's 990 and 99000 series chips had the about same thing,
but the "work-spaces", as they called the register-windows, were accessed
by way of the main-memory busses. (But that architecture had some bad
problems also: poor jbsr/rtn implementation and 16-bit addresses.)

What I would like to see is a register-set that acts as the cache for
a virtual stack in a machine with true stack machine instructions. That
would be my idea of a really good time, although it might put some graph
colorers out of business, having no registers to allocate. Does anybody
know if such a scheme was proposed for SPARC, and if so, why it was
rejected? Seems like such a win, and not all that big a step
beyond the register-window approach.