Re: SPARC code generation for compiler course

salomon@silver.cs.umanitoba.ca (Daniel J. Salomon) writes:


|> The floating registers are caller-preserved. The %o, %l, and %i registers
|> are rotated by the callee to obtain a new window in the register bank, and
|> so are not saved explicitly by either the caller or the callee. If the
|> register bank is full, the reused window is saved on the stack
|> automatically by the hardware.


Err, I think this is a little misleading. From the caller's point of view,
a called subroutine must preserve the following:


    %i, %l registers.
    %o6, unless specified otherwise (that is, altering the stack pointer
              is only allowed under certain circumstances and with certain
              handshakes going on).


    %o0-%o7 are otherwise free to be modified by the called subroutine.


The register saving by the called subroutine is NOT automatic -- execution
of a SAVE instruction in the prologue of the called subroutine is what makes
that happen. If there is no window available, there is a trap to the OS,
(not the hardware) which fixes it up.


|> > Any detailed description of the memory stack frame conventions?
|>
|> The stack frame conventions are given in the SPARC Architecture Manual
|> Appendix D, and again in the ABI. One important point is not to use the
|> program stack for temporaries. The SPARC expects the stack structure to
|> be consistent at all times so it can save overflow register windows
|> properly.


Again, close, but not quite right. The register window save area, at SP+0
through SP+63 (that is, 16 registers) must be regarded as possibly being
written OR read at any point at all -- that is, leave it alone. However,
the rest of the stack is not so volatile, and may well be used for storage
of temporaries. See "certain handshakes" above, however for dealing with
allocation of SP-relative temporaries. Basically, "alloca" has to be
passed a secret (compiler-generated) parameter that informs it as to how
large the SP-relative temp area is, and it has to move those temps when it
slides the stack.


Here's some more info on the calling conventions, from memory (you might
want to check these with a compiler):


SP+64-67 ==> structure return pointer


SP+68,72,76,80,84,88 ==> reserved memory for storage of parameter
    registers in the event of varargs (the compiler is NOT required to
    store them here, but it MAY).


SP+92 and beyond ==> additional parameters beyond the first six words.


Note that one thing that a SAVE instruction does is that it turns the
caller's SP (%o6) into the callee's FP (%i6). Note that a SAVE
instruction also performs a peculiar sort of addition, in that it the
addressed registers are from both the old and new bank, as in:


    SAVE old_SP,-96,new_SP


    old_SP is %o6 in the caller's (old) window,
    new_SP is %o6 in the callee's (new) window.


|> It does take quite a while to get this information nailed down properly.


Yes, agreed. I hope this is helpful. In general, it pays to read the
books, look at the code that is generated, and take yourself through the
prologue and epilogue step-by-step. Think about the nasty corner cases,
too, like setjmp and longjmp -- those can prevent you from doing things
that would otherwise be quite reasonable, depending upon assumptions made
by compilers-and/or-programmers about the state of registers post-longjmp.


In general, there's an awful lot to learn here -- it's ALL details.


David Chase, speaking for myself.
Thinking Machines
--

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