[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: Georg-Johann Lay
Subject: Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK
Date: Sun, 06 May 2012 14:22:05 +0200
User-agent: Thunderbird (Windows/20100228)

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

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.

reply via email to

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