[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: E. Weddington
Subject: Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes
Date: Fri, 09 Sep 2005 14:29:41 -0600
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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:

 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. :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]