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/calleesaved registers:


The idea is a compromise.


Using a caller-saves discipline (where the caller saves only the registers
with useful information in them) may result in the caller saving registers
that the calle wasn't going to trash; hence, wasted saves.


Using a callee-saves discipline (where the callee saves only the registers
that will be trashed by the callee) may result in the callee saving
registers that had no useful information in them; hence, wasted saves.


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


The kind is usually determined by a local competition. If a variable is
live across a call, then it needs to go into the set of callee-saves
registers. If a variable isn't live across a call, then it can go into
either set, but should be placed in the set of caller-saves registers to
avoid wasting the callee-saves regs.


When using graph coloring allocators, it's a matter of making the
long-leved variables interfere with the caller-saves registers at each
procedure call. Note that caller-saves registers are usually not
explicitely saved at the call; instead, we just ensure that there's
nothing in them that needs saving. Similarly, callee-saves registers need
not be saved unless they are actually trashed.


>Why are there no callee saved parameter registers ?


Usually the value isn't required after the procedure call.


>How did the designers of the architecture decide on the relative number of
>caller/callee saved registers ?


Experiments!


>Should the division be chosen differently for different high level languages ?


Probably, though this would make it harder to arrange calls between
routines written in different languages.


Preston Briggs
--

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