avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] avr-g++ local variable constructor / block body/destr


From: Dave Hansen
Subject: Re: [avr-gcc-list] avr-g++ local variable constructor / block body/destructor ex
Date: Thu, 06 Sep 2007 10:07:38 -0400




From: "Graham Davies" <address@hidden>

David Brown wrote:
I believe [the compiler] can [change order of ... volatile objects access]. Obviously it is only legal if such moves do not affect the volatile accesses themselves. Perhaps someone here who has a better knowledge of the standards ...

I wouldn't claim better knowledge, but this is a sore spot for me so I'm going to chime in anyway.

I think that the compiler is not permitted to change the order in which volatile objects are accessed. This would undermine the intent of volatile, which is to give the user exactly what he asks for. My impression is that the C language is defined in terms of the behavior of an abstract machine, which lacks all optimization and operates in a very simplistic but easy-to-describe manner. An actual compiler is allowed to deviate from this, in order to perform optimization, on condition that the resulting behavior is indistinguishable from the abstract machine at certain places called sequence points. In addition, when manipulating volatile objects, it is not allowed to deviate at all from the abstract machine.


This is all true, but I think the key is that the volatile qualifier only affects what it qualifies. For example, given the following code

  x = 1;
  y = 2;
  x = 3;
  y = 4;

If none of the variables is volatile, only the last three lines need generate any code, and they may be reordered any way the compiler likes.

If both variables ar volatile, each line must be executed in exactly the order shown.

If only x is volatile, the generated code must write a 1 to x, then a 3. The write of 2 to y can be elided, and the write of 4 to y can occur before, between, or after the writes to x.

As long as the final result is as-if the code had been performed by the abstract machine, and any volatile value is handled exactly as the abstract machine would have.

HTH,

  -=Dave

_________________________________________________________________
Test your celebrity IQ.  Play Red Carpet Reveal and earn great prizes! http://club.live.com/red_carpet_reveal.aspx?icid=redcarpet_hotmailtextlink2





reply via email to

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