Related articles |
---|
SPARC code generation for compiler course mackey@cse.ucsc.edu (1993-12-10) |
Re: SPARC code generation for compiler course salomon@silver.cs.umanitoba.ca (1993-12-13) |
Re: SPARC code generation for compiler course chase@Think.COM (1993-12-13) |
Re: SPARC code generation for compiler course markt@harlequin.co.uk (1993-12-14) |
Re: SPARC code generation for compiler course salomon@silver.cs.umanitoba.ca (1993-12-15) |
Re: SPARC code generation for compiler course pardo@cs.washington.edu (1993-12-16) |
Re: SPARC code generation for compiler course nickh@harlequin.co.uk (1993-12-16) |
Re: SPARC code generation for compiler course chase@Think.COM (1993-12-16) |
Re: SPARC code generation for compiler course pardo@cs.washington.edu (1993-12-17) |
Newsgroups: | comp.compilers,comp.arch |
From: | markt@harlequin.co.uk (Mark Tillotson) |
Keywords: | sparc, courses |
Organization: | Harlequin Limited, Cambridge, England |
References: | 93-12-040 93-12-053 |
Date: | Tue, 14 Dec 1993 16:15:23 GMT |
salomon@silver.cs.umanitoba.ca (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
> properly.
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
variables/temporaries.
--
M. Tillotson Harlequin Ltd.
markt@uk.co.harlqn Barrington Hall,
+44 223 872522 Barrington, UK
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.