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. ;-) _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
