Re: SPARC code generation for compiler course

nickh@harlequin.co.uk (Nick Haines) writes:
|> When adhering to the ABI, the meaning is not clear, and probably requires
|> reading the Sparc ABI definition. Any Sun experts out there want to
|> comment? My non-expert eye says that g1 is caller-save, g2-g4 are up to
|> the compiler writer (caller-save, or global variables, or some kind of
|> program state; this is what is meant by "the execution environment"
|> elsewhere in the manual) and g5-g7 are "reserved" to the ABI (although how
|> the ABI copes with non-conforming code is unstated).


Note that the ABI officially only applies to Solaris 2.* (aka SunOS 5.*)
system, though most of the conventions being discussed here are followed
in SunOS 4.*.


%g1 is "extremely volatile", meaning that it is used as a scratch register
by the code in a procedure linkage table (that is, the code that you
execute to call a subroutine in a shared library, or to call out of a
shared library).




%g2-%g4 are, as near as I can tell, up for grabs. The ABI is pretty
ambiguous about this, except in the case of system library code -- that
code must leave those registers alone. In general, I think they make fine
(caller-saves) temporaries, though that conflicts with global register
assignment. However, since one global register assignment conflicts with
another global register assignment, I regard that as special purpose
(useless in libraries, for instance).


I think that there was some intent that these registers might be used to
support (for example) run-time systems for Lisp or Prolog, but from the
point of view of C and Fortran programmers, those languages are
(unfortunately) insignificant and ignorable. Furthermore, there are fine
Lisp/Scheme implementations available that do not use those registers
anyway, so perhaps it was not necessary to reserve them for this purpose
in the first place. There are also Scheme (and other language)
implementations that work by first compiling to C, so (in those cases)
what is good for C is good for Scheme.


One fun, non-compiler use of the registers is to pass hidden parameters
from thunks (I posted something on this to comp.compilers earlier this
year). There, it must be possible to get a guarantee from the compiler
that %g2-%g4 (or some subset of those) is not trashed within the code
generated for a particular subroutine, because they must be preserved up
to the point where the subroutine reads them. Note that this is still
compatible with other subroutines using these registers as caller-saves
temps.


Note that the ABI will continue to work, no matter how you abuse %g2-%g4.
However, your piece of code might not work with someone else's piece of
code.




Don't mess with %g5-%g7, ever. The run-time system might use them to
implement (for example) thread-local storage, or some such. Remember that
no matter what the various standards may say about it, all sorts of
interesting code is run within signal handlers. Other uses of these
registers include enabling various patched-binary profiling tools. Even
if it works for you today, in a particular situation, there is no
guarantee that it will continue to work with the next revision of the OS,
libc, or whatever. "Not work" means "segmentation violation" when (e.g.)
some piece of code tries to set the thread-local errno, and writes to page
zero instead.


David Chase, speaking for myself
Thinking Machines Corp.
--

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