avr-gcc-list
[Top][All Lists]
Advanced

[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



reply via email to

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