> > *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 
> yes...

A frame pointer is only of any use if you use silly (generally 
non-portable) things like alloca[1], 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.

R.

[1]  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.