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

[Joerg Wunsch]

Georg-Johann Lay <address@hidden> wrote:

> Well, if a Linux programmer comes over and expects anything, ...

That's not my point.  My point is that the chosen name bears *neither*
any relationship to what a "signal" in a microcontroller environment
is (that would be a hardware signal, attaching to an IO pin), *nor*
what a seasoned Unix programmer could expect.  Consequently, I say
it's a misnomer.

>> 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.

Based on what reasoning?

Sometimes it's time to accept something has been a mistake.  I'm sure
even Marek Michalkiewicz and Denis Chertykov (who introduced the
current wording) might agree on it being a misnomer now, 12 years
later.

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

No.  Users aren't supposed to use these attributes directly anyway.
They are supposed to use the library API provided, and that's what
they are doing.  (Don't tell me the compiler is usable without the
library.  Yes, it is, but that's not the typical usage pattern.)

Just accusing the users of being too stupid to read the documentation
is a lazy path.  Please consider the users being our customers, not
our enemies, or our students we have to teach good manners.  The tools
should be a help to them in getting their way through microcontroller-
land, rather than teaching them how stupid they are to not grasp the
fine-print of the manual.

>> 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 :-/

If they hadn't read the documentation, they would neither have known
of the old, dreadful INTERRUPT, nor of the current ISR.  So obviously,
they *did* read the documentation.  The old names have proven to be
confusing, and we have to accept this.

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

Please get out of your ivory tower, back to the users.  They aren't
helped by teaching them how to attach half a dozen of attributes to
their functions.  They are served best by providing them a good and
easy to grasp API on interrupt handlers.  They don't care whether we
implement it with attributes, pragmas, by modifying global variables,
whatever, they just want to be able to write the interrupt handlers.

The usability of the current ISR implementation has proven to be
excellent, and I'm glad Dean Camera crafted the current
implementation.

> Deprecations are always really inconvenient.

Agreed, but sometimes they are worth it.

> 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?

The "interruptible ISR" is meant as a special case where the compiler
re-enables interrupts as soon as possible, as part of the prologue (at
whatever point appears to be safe to the compiler).  The purpose is to
be able to gain a few cycles less of interrupt latency to possible
other interrupts.  Kind of a poor man's way out of the lack of
interrupt priorities on classic AVRs.  Consequently, on the Xmega,
this part of the API is probably not useful anymore.  Even for classic
AVRs, it's a rare case where it is useful, but there are situations
where it counts, and if the compiler doesn't offer it, the only other
option for the users would be to resort to assembly.

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

This option is always available to the users, without any compiler
interaction.  The entire point of involving the compiler is to get the
SEI out a few cycles before, just in those situations where it is
needed.

If you don't agree on a better wording of the attribute names, then
please, just make "interrupt" being a priority over "signal" in case
both are present, so everything will continue the way it used to be.
There's more important things to fight than the names of a couple of
attributes which are well hidden from the end users anyway.
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

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