Re: Caller allocates space for callee-save registers

[Forwarded by gaynor@brushfire.rutgers.edu (Silver)]


In article 92-05-153 you write:
>[Register windows opinions?]


There are several overlapping issues:
  - Do windows help performance?
  - Do windows hurt performance?
  - Could the chip real estate be used for something else?
  - How can evolving compiler technology affect the answers?


For starters, all of these issues depend on workload. Workload depends on
the compiler technology. It is easy to imagine a compiler that tries to
organize the program as one big graph and then walks the graph breaking it
up in to procedures based on the register usage so that each ``procedure''
is optimized to the amount of space given by each register window and the
nesting (call/return) behavior. For example, a loop prologue could
allocate a set of registers for the loop and free them on loop exit,
avoiding saves and restores of registers that are needed on either side of
the loop but not in the loop body.


The SPARC architecture does not define user-level traps. Window
management (except for executing `save' and `restore' instructions)
requires kernel-mode access. I believe that one better design would have
an array of registers and a current base pointer similar to the current
SPARC but would put management entirely in user space, have user-level
traps for over- and underflow and dedicate a global for kernel use and a
global for window handler use. [This is essentially the construct I had
in mind. [Ag]]


I believe that such a design would allow a smart compiler to optimize
window usage for each program. Except for a loss of two globals (which
is probably acceptable given the current ABI restrictions on globals),
such a design would also transparantly emulate the current system.
There might even be ways to avoid using up two globals.


These are all just educated guesses, of course. I don't have any facts
to back them up.


;-D on ( Register widows? Typesetting orphans! ) Pardo
--

Return to the comp.compilers page.
Search the comp.compilers archives again.