Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!mintaka!spdcc!iecc!compilers-sender
From: pardo@june.cs.washington.edu (David Keppel)
Newsgroups: comp.compilers
Subject: Re: SPARC code generation references
Keywords: SPARC, optimize
Message-ID: <91-05-105@comp.compilers>
Date: 28 May 91 17:12:59 GMT
References: <91-05-100@comp.compilers> <91-05-101@comp.compilers>
Sender: compilers-sender@iecc.cambridge.ma.us
Reply-To: pardo@june.cs.washington.edu (David Keppel)
Organization: Computer Science & Engineering, U. of Washington, Seattle
Lines: 28
Approved: compilers@iecc.cambridge.ma.us

torek@elf.ee.lbl.gov (Chris Torek) writes:
>[You can `leaf crush' on the SPARC as long as there are enough
> registers: non-parameter (sp/ret-pc) `o' registers and 7 `g'
> registers.]

Be careful with this.  According to the SPARC ABI (Applications Binary
Interface) standard, an ABI conforming program does something like:

	%g0 is always zero
	%g1 is a caller-save `very temp'
	%g2..%g4 are reserved for application code and may not
		be modified by libraries
	%g5..%g7 may be read but not written by an application
		(e.g., the analog of %g2..%g4 for libraries)

Eek!

I don't sit on the committee.  I think some of this is useful but as
much as they've done is too much, since it potentially leaves (so to
speak :-) only one `very temp'.  As an aside, you can't manually
spill/restore reserved `g' registers because they might be needed by
an asynchronous signal.  Ah, omniscience by committee is just as hard
as any other time :-)

		;-D on  ( An opinion a day... )  Pardo
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.