[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK
From: |
Weddington, Eric |
Subject: |
Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK |
Date: |
Tue, 1 May 2012 20:37:47 +0000 |
> -----Original Message-----
> From: address@hidden [mailto:avr-
> address@hidden On Behalf Of Joerg
> Wunsch
> Sent: Tuesday, May 01, 2012 2:35 PM
> To: address@hidden
> Subject: Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK
>
> Georg-Johann Lay <address@hidden> wrote:
>
> > I just don't see a trick how to add "signal" only if NO_INTERRUPT
> > is not specified.
>
> Neither do I.
>
> > The compiler could be changed to handle it, of course.
> > But I am no fan of trying to support mutually exclusive/contradicting
> > things...
>
> I wonder whether we should just keep the old "interrupt" and "signal"
> attributes for historical backwards compatibility, and invent new
> ones, like:
>
> __attribute__((isr)) -- this function implements an ISR (needs
> RETI, must guarantee to completely save
> state)
> __attribute__((interruptible)) -- this function is supposed to also
> have the "isr" attribute, but it
> is asked to re-enable interrupts
> as soon as possible
>
> These names would be a lot clearer. The old "interrupt" attribute
> would be equivalent to "isr, interruptible", while the old "signal"
> one is the same as "isr" (except "signal" was never supposed to be
> accompanied by "interrupt").
Only if we can deprecate the old names, otherwise we're going to have the GCC
maintainers ask us how many attribute names do we need! ;-)
Eric