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

[Georg-Johann Lay]

Joerg Wunsch schrieb:
> Users aren't supposed to use these attributes directly anyway.

I am not in the position to tell users what they are supposed to
do and what they are not supposed to do.

Anyway, the compiler won't notice if a feature like interrupt
or signal is used through a macro or API or whatever.

I don't know what the exact specification of interrupt + signal
is or was designed to be or if anyone ever thought about it.

An API can, of course, "attach" a semantic to a specific construct
like here by reverse engineering what code is emit by the compiler
and use it that way.

This might work for some time, but then bugs might pop up like now.

If you are lucky, the fix is obvious and does not change semantic
of pre-existing code, and semantic is extended in the way the API
silently assumed.

If you are not so lucky, then the API offered scrap to the user.
We just had this scenario with prog_types.

> They are supposed to use the library API provided, [...]


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

This is not an ivory tower.

This is simply wrong code generated at the moment.

We all know that fixing warnings and errors at compile time is
very much easier than fixing errors at run time. And has much
less potential to cause harm, by the way.

You really think striving for correct code and be strict with
questionable constructs is "ivory tower"?

> 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 compiler is just a dumb program that transforms text to text.
It won't care if attributes come from an API or are typed by hand,
just as well as it did not care were prog_char came from...

The documentation of these features is really bad and in some cases was 
non-existent for many years.  For example, OS_task and OS_main were 
present in the compiler for several years without even a single letter 
of documentation, see PR49824.

Whatever documentation is floating around and how good or bad it might 
be -- I thing a software should document itself in a complete, correct 
and comprehensible way.  Anything else will lead to confusion and bugs 
sooner or later, both because developers misunderstand the feature or 
because users (like AVR-LibC which uses avr-gcc) misinterpret what's 
there, make assumptions that are not true or are mislead and confused, 
or reverse-engineer and come up with wrong or incomplete conclusions.

Since I am contributing to avr-gcc I am trying to improve the situation 
and establish better primary literature like code clean-ups, source 
comments and documentation.

But it's still incomplete and in many cases I have to guess myself, for 
example with EIND handling where I misunderstood details and installed 
incorrect changes.  And I am not a native speaker and might explain too 
complicated on a technical, gcc-speek level.

What happens if the documentation is unclear or non-existent can bee 
seen in "avr-ld: Do linker stubs need --relax?" Is it a bug or a 
feature? We don't know.

Some will guess and come up whith whatever result, some will reverse 
engineer, some will make bug reports, some will say the tools are scrap, 
some will switch to alternatives.

It's all déjà-vu...


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

It' also about changing SP atomically. There is nothing known about user 
code and if it might enable IRQs at some place.

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

That's what I already proposed and opened as http://gcc.gnu.org/PR53256

As I already said, changing the API is not helpful in my opinion.

I will try to fix it as soon as possible. But I don't understand all 
explanations from tree.h and hop it will not introduce other problems.

The explanation in GCC's documentation is really short and may lead to 
misunderstandings or wrong conclusions.  The prologue code in avr BE is 
really complicated and there is not a single test case for ISR 
prologues/epilogues in the test suite. I am open for propositions on how 
to improve that and how to torture avr-gcc's ISR code.

> There's more important things to fight than the names of a couple of
> attributes which are well hidden from the end users anyway.

ACK. There is no need for new attributes or attribute names or deprecation.