Re: [avr-libc-dev] Re: bug #22163 (atomic not working as expected inC++)

[Joerg Wunsch]

As Stu Bell wrote:

> Before the rant below, let me make sure: I interpret this command to
> mean that there is no way for the AVR GCC compiler writers to tell
> the optimizer, "Thou Shalt Not Reorder Code Around This Boundary".
> Even more, there is no way for any mechanism (even #pragma?) for C
> source to tell the compiler this.

That's how I recognize it, yes.  A couple of years ago, we've been
analyzing a snippet of code in a German-language forum, and that's
been the conclusion.  Interestingly enough, IAR produced the very same
code reordering as GCC then.

Like as it's been time to introduce "volatile" in 1989 when
standardizing C for the first time, I think it's time to add another
tweak to the language to tell the compiler "do not reorder code around
this point".

> So, blaming the language to say, "well, it just happens" is
> specious.  GCC allows Linux to run, somehow.

Linux is not time-critical, unlike many things that run on
microcontrollers.  Moving a couple of instructions around does not
matter in a complex operating system.  The code where we came to
the conclusion mentioned above was something like:

void foo(void)
{
   some_temp_variable = result_of_expensive_computation;
                        /* I think it's been a division. */
   cli();
   something_time_cricital = some_temp_variable;
   sei();
}

Both, GCC and IAR reordered the expensive computation *into* the
cli/sei sequence, as they realized it was only once, so there was no
point in executing the instructions earlier.  Adding a memory barrier
doesn't change this, as some_temp_variable won't end up in memory
anyway.

Code reordering like that would likely go unnoticed in any high-level
operating system.

If I remember a remark from Eric correctly, GCC recently introduce
per-function optimization settings.  Quite possible that one reason
for this is that it allows for workarounds around similar problems...

Now assume, the language would be extended to allow for what I'd
call a "volatile block", then the above could become:

void foo(void)
{
   some_temp_variable = result_of_expensive_computation;
                        /* I think it's been a division. */
   volatile {
      cli();
      something_time_cricital = some_temp_variable;
      sei();
   }
}

...telling the compiler to not reorder code across the borders of that
block.  Suddenly, cli/sei wouldn't even need to imply a memory barrier
anymore.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

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