|SPARC code generation for compiler course firstname.lastname@example.org (1993-12-10)|
|Re: SPARC code generation for compiler course email@example.com (1993-12-13)|
|Re: SPARC code generation for compiler course chase@Think.COM (1993-12-13)|
|Re: SPARC code generation for compiler course firstname.lastname@example.org (1993-12-14)|
|Re: SPARC code generation for compiler course email@example.com (1993-12-15)|
|Re: SPARC code generation for compiler course firstname.lastname@example.org (1993-12-16)|
|Re: SPARC code generation for compiler course email@example.com (1993-12-16)|
|Re: SPARC code generation for compiler course chase@Think.COM (1993-12-16)|
|Re: SPARC code generation for compiler course firstname.lastname@example.org (1993-12-17)|
|From:||email@example.com (Mark Tillotson)|
|Organization:||Harlequin Limited, Cambridge, England|
|Date:||Tue, 14 Dec 1993 16:15:23 GMT|
firstname.lastname@example.org (Daniel J. Salomon) writes:
> %g0 always contains zero
> %g1 very volatile, a general purpose short term temporary register.
> %g2, %g3, and %g4 for use by the programmer
> %g5, %g6, and %g7 reserved for the operating system.
As I understand it g1/g2/g3/g4 and all the floating point registers
are caller save, g5/g6/g7 are reserved for the `execution environment'
or some such wording---does anyone know what this means? (they are of
no use to the kernel in a multi-tasking environment because they are
not supervisor-mode only). The wording ``very volatile'' can mean
nothing stronger than caller saved without making the register unusable.
> 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. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This isn't true---there is no problem at all with allocating
temporaries on the stack so long as you move %o6 down in multiples of
8. (C compilers seem to just preallocate the whole stack frame once in
the save instruction anyway)
> ... The SPARC expects the stack structure to
> be consistent at all times so it can save overflow register windows
Window overflow, clean or flush can potentially happen between any two
instructions due to asynchronous events. Thus you cannot expect invalid
windows to remain unchanged (they could be zeroed), %o6 must point to a
valid 64 byte save area in the address space, and be 8-byte aligned. The
chain from %i6 must be valid for all the valid register windows (those not
flushed to memory).
Also signal handling can trample the area immediately
below %o6 unless a seperate signal stack can be set up... thus keep
%o6's save area at the bottom of the stack frame below local
M. Tillotson Harlequin Ltd.
email@example.com Barrington Hall,
+44 223 872522 Barrington, UK
Return to the
Search the comp.compilers archives again.