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

[Stu Bell]

As J"org Wunsch wrote:
> 
> 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.

Interesting.  I'd have never guessed.

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

Linux, as a whole, is not time critical.  However, basic mechanism
inside Linux (semaphores, mutexes, spinlocks all come to mind) would be
very upset if their innards were reordered.

On the other hand, it's likely that these mechanism use some kind of
atomic instruction at the hardware level.  Eh, I'll let it pass.

> 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();
> }

I see your point.  By the time the optimizer sees the code, it doesn't
see the computation as being separate from the assignment.  Since they
are one-and-the-same, it is free to drag whateever part of it it wants
to anywhere it wants.

As Eric Weddington wrote:
> 
> As a side note, wouldn't declaring some_temp_variable as 
> volatile solve the issue above?
> 

Good question, but somehow I think not.  Even volatile, the optimizer
recognizes that the variable is local and there is only one source and
destination for the variable, so the volatile wouldn't matter.  It would
be an interesting experiment.

I think you *might* get around it by making some_temp_variable global
and volatile.  But that's just silly.   ... Or is it...?


Best regards, 

Stu Bell 
DataPlay (DPHI, Inc.)