Subject: Re: The ELF ABI issue
To: Reinoud Zandijk <email@example.com>
From: Richard Earnshaw <firstname.lastname@example.org>
Date: 03/27/2002 11:31:10
> > *If* I had complete freedom to implement the ABI from scratch, then r11
> > would probably be my choice too. However, there is too much legacy use of
> > r11 as a frame pointer to even consider that one now.
> In legacy code ok... but still NetBSD could use it as a temp. storage of
> the TLS ;) ... and why not use that r11 now in the ABI? ppl. are either
> conforming with it or now ... so i don't think its gonna bite anyway ...
Not quite that simple. Although the new ABI is a major change for gcc,
it's not much more than a tidying up of a few corners for ADS users
(except for C++ code). GCC has languished well behind the curve on ABI
"conformance"; it could justify doing that when it was changing, but now
that it is being stabilized the excuses become more feeble.
> > Note that the new ABI won't require a frame pointer, and I intend turning
> > it's use in the compiler off, just as soon as we can make other tools
> > (such as gdb) manage without it.
> Hope so ... allthough a frame pointer is handy at times.... but if it gets
> loaded again and again anyway then its silly to waste a register on it
A frame pointer is only of any use if you use silly (generally
non-portable) things like alloca, or other hacks that mean that the
stack pointer has to move more than once in each function. In all
"normal" code, the frame pointer and stack pointer have a known
relationship (fp = sp + const), so one of them is redundant.
 Consider the situation of finite, non-extensible, stacks such as can
happen when you have threads, or on small embedded systems and you'll soon
agree that alloca is a nightmare.