Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

[Georg-Johann Lay]

Joerg Wunsch schrieb:
> Georg-Johann Lay wrote:
>
> > One hack would be that "interrupt" overrides/is stronger than "signal" 
> > and likewise for OS_task/OS_main.
>
> I don't like it much, in particular since the name "signal" does not
> mean anything to the casual embedded programmer, and it's something
> fairly different than a "signal" to the casual UNIX programmer.

Well, if a Linux programmer comes over and expects anything, including
hardware dependent GNU extensions, work without any changes, then he
will experience considerable problems.

> In other words, I think "signal" is a misnomer, and should not have
> existed in the first place.

It there. It will stay there. We have to live with it.

And I still think it's not a misnomer, it's a RTFM.

> > All the ISR() stuff and deprecation if SIGNAL and INTERRUPT was -- if
> > I understand you correctly -- because users did not read the docs
> > and instead tried to deduce the semantics of the above attributes from
> > their identifier name.
>
> Basically, yes.
>
> The difference to my suggestion is, SIGNAL and INTERRUPT exposed the
> misnamed attribute names into the library API, so users had to use
> them, and eventually got confused by it.  Yes, you might blame them
> for not reading the docs, but it's about the same as "Press start to
> shutdown" (your Windows machine): being required to declare your
> (standard) interrupt service routine by something that is not named
> "interrupt" does not match the user's expectation.

Actually, on most embedded systems it would be a Kunstfehler to
disable interrupts like that.

If, for example, an OS that claims to work with hard real-time
application disables IRQs, it is pretty much useless.

> Since the invention of the ISR API, users don't seem to have any
> troubles anymore with that.

I guess this is not because they read the docs, it's just because
they copy-paste ISR and there is no equivalent for INTERRUPT :-/

> So yes, we could just give the "interrupt" attribute a priority over
> "signal"; users won't notice it, and no further change is needed.

Yeah, so we will see yet another FIXME in avr-gcc.

IMO the best thing is to have no warning because a warning confuses
with already present code.

I wish I had introduced an error _before_ AVR-LibC started messing
with interrupt+signal...

> Or, we could use that occasion to finally also drop that misnamed
> "signal" attribute alltogether, at least in the long run.

I don't see a point here. Deprecations are always really inconvenient.

> The proposed "isr" and "interruptible" attribute names are just
> because I personally find them both, descriptive, as well as no longer
> self-contradictionary, since an "interruptible ISR" is something the
> embedded developer could immediately guess how it works.

Why is it interruptible?
Because the user enabler IRQs in the ISR /after/ the prologue)?
Or because there is an SEI emit by the compiler /before/ the prologue?

This is quite a difference with respect to generated code (SP=val)
and with respect to IRQ latency.

What if the user wants an atomic prologue but enables interrupts in the
body?

The compiler cannot see this in the code.

Johann