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

[E. Weddington]

Joerg Wunsch wrote:

> Oh well, yet another mass followup.  Sorry if that's messing up your
> thread displays. ;-)
>
>  
>
>  
I think it's hopeless now. :-)

Do we still need copies to avr-gcc-list? Or can everyone agree to go 
take this to avr-libc-dev only? (I'd like to not get two copies of 
everything.)

> As Dave Hansen wrote:
>
>  
>
> > Has anyone put any thought into how we might get avr-gcc to do
> > something other than silently generate incorrect code when the user
> > specifies an incorrect SIG_* (or *_vect) symbol?
> >    
>
> Marek already did, but I think it's only available starting with GCC
> 4.x.  The compiler generates a warning when it sees a function that
> has the interrupt or signal attribute, yet where the name doesn't
> start with __vector.
>  

And I put in that patch in the latest WinAVR release too. So one doesn't 
have to wait for gcc 4.x to get that functionality.

> As E. Weddington wrote:
>  
>
>
> > - I like isr.h too. Combine interrupt.h and signal.h.
> >    
>
> I'd prefer interrupt.h (though won't insist on it).  The name is
> descriptive enough, and it contains more than just the ISR handling
> (like the macros to enable/disable interrupts).
>  
I won't insist on isr.h either. In fact I agree with your logic above. 
Ok, it's interrupt.h. :-)


> As Marek Michalkiewicz 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.
> >    
>
> I didn't doubt it could be done, but I'm afraid of the API change.
> With only you and Björn actively committing to GCC and binutils, and
> the need to coordinate an API change in GCC with the respective
> changes in avr-libc, that's too much effort for me for too little win.
> Actually, the only win is that there are no silly __vector_* names
> anymore in the binary (and thus in the debugger).
>
> I'd rather see that energy spent into optimizing ISRs so the compiler
> could effectively issue a `naked' ISR automatically for things like:
>
> ISR(XXX_vect)
> {
>  PORTB |= _BV(4);
> }
>
> (No __zero_reg__ needed, not even SREG will be changed.  No pushes, no
> pops needed.)
>
>  
*Very* good points. I think we have more users upset at how little the 
ISRs are optimized (with the prologues and epilogues), than we have 
users upset at the non-descriptive names in the binary. Though I think 
that it is a great idea to implement. It's just a matter of constrained 
resources. :-)

Eric