This is the mail archive of the
mailing list for the GCC project.
Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jeff Sturm <jsturm at one-point dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Brad Lucier <lucier at math dot purdue dot edu>, gcc at gcc dot gnu dot org
- Date: Thu, 7 Feb 2002 17:04:48 +0100
- Subject: Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
- References: <20020207000338.B28571@redhat.com> <Pine.LNX.email@example.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Feb 07, 2002 at 10:51:30AM -0500, Jeff Sturm wrote:
> On Thu, 7 Feb 2002, Richard Henderson wrote:
> > Looks close. The stack frame has been irritatingly complex to change.
> I think your soft fp patch will improve things in the long run. Thanks
> for doing that.
> To satisfy my curiosity, does anybody know why v9 has a stack bias?
Sparc load/store instruction addresses are either reg + reg or reg + 13 bit
signed immediate. This is +-4KB. In most functions, the region accessed
above frame pointer is quite small (function arguments) while below it is
much larger. So, the stack bias makes these areas 2KB above and 6KB below.
And the 1 subtracted from it is so that in mixed 32-bit and 64-bit saving
environment register spill/fill handler can figure out whether it needs to
save 32 or 64 bits from each register.
> realize it's part of the platform ABI, but why? (Along with register
> windows and other brain damage... gosh I miss my Alpha.)
Register windows aren't brain damaged as you think, it means that typical
programs pass all arguments/return values in registers all the time without
need for their saving.