SPARC stack frames (was Unix Stack Frame Questions)

[Chris Torek]

In article <7468 at idunno.Princeton.EDU> pfalstad at lit.Princeton.EDU
(Paul Falstad) writes:
>With a SPARC, a procedure almost always creates a stack frame of 96
>bytes, plus whatever space for local variables it needs.  This is done
>because the window_overflow trap handler needs somewhere to dump your
>register window if you run out of windows (96 bytes is the size of a
>window).

Actually, the size is 64 bytes (16 words): 8 `local' registers and 8
`in' registers.  The remaining 8 words are due to Sun's (wrong) calling
convention:

	1 word for `structure return pointer'.

(Compiler should pass structure return pointer in a register, as GCC
does.  The hairy `unimp' size magic does not belong in the runtime
system.  The compiler should pass and return small structures in the
registers, which means the size-checking would fail anyway.)

	6 words for `arg dump area'.

This is a place where the callee can write the caller's `out' registers
%o0 through %o5 (aka the calle's `in' registers %i0..%i5).  This is
sheer lunacy: if the callee needs to store its %i0 through %i5 for some
reason, it can allocate its own space!  (I suppose the argument here is
that the callee might not use a new window.  My counterargument is that
if the callee needs to hold that many arguments, it is probably better
off getting a new window anyway.)

	1 or more words for `arguments past the sixth'.

This should be `zero or more words' and should start at [%fp+64], not
[%fp+92].  (Oops, I need to go change my kernel, I used 96.  I guess
I should clean up these magic constants....  Maybe after it boots :-)
which will not occur until after it links :-p and then we need drivers
and autoconfiguration code and . . . sigh.)

>The sun compiler, I gather, puts the local variables at the
>top of the stack frame, and the 96-byte buffer underneath.

Right.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov