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

[Joerg Wunsch]

As Matthew MacClary wrote:

(About whether to keep <avr/interrupt.h> or <avr/signal.h> after
merging their contents.)

>     My suggestion would be to change INTERRUPT to be the same as
> SIGNAL, and then deprecate SIGNAL.

Sorry, but I have to *strongly* object with that.

After an API change, code that used to work must either break
compilation, or continue working the same way as before.  It's
absolutely unacceptable to suddenly change the meaning of some API.

Perhaps, after some 10 years of waiting, eventually INTERRUPTS could
be re-used.  As can be seen from the ongoing discussion about the old
sbi/cbi hack macros, an API, once established, virtually remains
forever, as the Internet has an infinite memory.

Sure, I'd rather love to use INTERRUPT rather than SIGNAL as it's way
more descriptive, and closer to people's expectations, but that's
simply too late now.  I guess the original authors of that API simply
didn't think long enough about it, and they probably never imagined
the popularity their `baby' once would enjoy.

> After this the <avr/interrupt.h> file could be used and all naming
> would be completely obvious.

I tend to retain <avr/interrupt.h> nevertheless, and mark
<avr/signal.h> as obsoleted.

> Developers that actually need to use INTERRUPT could just use the

...always resort to __attribute__((interrupt)) anyway, as we're not
going to dismiss that (there's no reason why that needs to be thrown
away).

> new low overhead interrupt routine suggested by James A.R. Koehler:

> http://lists.gnu.org/archive/html/avr-gcc-list/2005-08/msg00150.html

I fail to see a clear idea behind that, sorry.  If someone really
wants to do it all manually, they could always resort to use
__attribute__((naked)), or to an assembly-written ISR.  For most other
people, it's probably OK to just throw an sei() at the beginning of
the ISR, and those rare cases where that doesn't suffice still have
the __attribute__((interrupt)) approach.

I agree that the compiler-generated ISRs might be smarter to not
perform any superfluous save/restore operations, but that's a
completely different matter.  It probably ``only'' needs someone
really implement that approach.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)