Re: Caller/Callee saved Registers

pmagun@iiic.ethz.ch (Paul Jakob Magun) writes:
|> I'm having some difficulty grasping the key idea behind the division in
|> caller/callee saved registers:


When procedure A calls procedure B:
  (1) Procedure A must save any caller-saved registers it still needs, and
  (2) Procedure A relies on B to save all the callee-save registers.
Thus from A's point of view, B can trash the parameter registers (because
they are caller-save, and A, the caller, has already saved them).


|> What would happen if all registers were saved by the called procedure
|> (callee saved) ?


Then B might save some registers that A does not care about. In this
case, B does extra work (of the worst kind: memory traffic).


|> The kind (caller saved/callee saved) of register used for a variable is
|> determined locally. Won't this a suboptimal global allocation?


Why, of course. But caller and callee might be compiled in separate
object files, so must agree on which parameters are in registers and which
are not without ever seeing each other.


|> Why are there no callee saved parameter registers ?


Because the compiler-writer assumes that procedure A doesn't need the
parameter it makes for B. The value is dead after the call to B, so there
is no point in having B save and restore it.


|> How did the designers of the architecture decide on the relative number of
|> caller/callee saved registers ? Should the division be chosen differently
|> for different high level languages ?


Probably. I suspect the IBM designers used a "best-guess" approach,
perhaps backed up by a few test cases. There's a paper out there on IBM's
design decisions in the ABI, but I can't find my copy of it right now.
--
cliffc@cs.rice.edu -- Massively Scalar Compiler Group, Rice University
--

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