Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes

[Björn Haase]

Marek Michalkiewicz wrote on Freitag, 9. September 2005 19:18 :
> On Fri, Sep 09, 2005 at 10:35:46AM -0600, E. Weddington wrote:
> > - I do like the idea that Royce has (above) about naming the ISR
> > function any name. However, I agree with Joerg, in that it would take an
> > awful lot of effort. Perhaps someday, but not now.
>
> Probably not that awful :) - see how it is done in the msp430 port.
>
> If the API is going to change soon, doing this too at the same time
> would be nice.  Unfortunately, we can't follow msp430 exactly, as
> their "interrupt" and "signal" attributes have swapped (!) meanings
> compared to ours, so we need different names to avoid even more
> confusion.  But the basic idea (attribute with numeric argument
> specifying the vector to override, or none) looks nice and clean.
Could then possibly be implemented at the same time as switching towards RTL 
prologues and defining main() to be a standard function.

FYI, I'm presently having a private gcc with RTL prologue that I think to be 
functional already. However, I did not check sufficiently well that all the 
different individual combinations of options like "tiny stack" "no_irq", etc 
work.

BTW: 
In case that you find it interresting: I have spend quite a time trying in 
vain to find a way to shorten the prologue sequence. In fact I found out that 
the present implementation is already the optimum given that one continues to 
work with one unified stack for data and return addresses and given that one 
has no knowledge on r0/r1 for the irqs. 
The only way I found how one could make the prologues shorter was working with 
a separate stack for data and one other (SPL:SPH) for the return addresses. 
This way one could reduce the prologue size considerably. However, I found 
out for my *real-world* applications for avr that despite smaller prologues 
the overall code size was worse (comparing with -mcall-prologues). When not 
using Y as stack pointer one has an additional precious pointer register 
available in many functions. This additional register seems to be much more 
important than the reduction of code size in the prologues.

So finally I can't help to admit that Denis Chertykov's original choice seems 
to be much better than one might assume at first sight when seeing the ugly 
prologue/epilogue sequences for functions that need a frame pointer.