More questions about "asm volatile"

Ian Lance Taylor iant@google.com
Mon Apr 11 20:52:00 GMT 2011


Ingo Rohloff <Ingo.Rohloff@lauterbach.com> writes:

> The document mentioned above says:
> "Similarly, you can't expect a sequence of volatile asm instructions to remain perfectly
> consecutive. If you want consecutive output, use a single asm."
>
> Does that mean that the order of "volatile asm" instructions might be swapped, or does this just
> mean that the different "volatile asm" instructions might be interspersed with other instructions ?

Different non-volatile asm instructions might be interspersed with
volatile asm instructions.

> If there is a guarantee that "volatile asm" instructions CANNOT be swapped, then I think the
> "Extended-Asm.html" document should state this.

The whole extended-asm section could use an intelligent rewrite.  This
is difficult.  Patches welcome.


> The document mentioned above says
> "Note that even a volatile asm instruction can be moved relative to other code, including across
> jump instructions. "
> and there are a number of old discussions about that behavior.
>
> Unfortunately neither the document above nor the discussions I have read make any statement if this
> just means that "volatile" has no meaning or if there are circumstances in which there still is SOME
> guarantee.
>
> What I am wondering in particular: If I have this code:
>
>
> extern volatile int *gPtr;
> void foo()
> {
>   int v;
>   v=*gPtr;
>   asm volatile ( <Something> );
>   *gPtr=5;
> }
>
> Is it possible that the "asm volatile" is swapped with the accesses to the "volatile" pointer, or
> does the "asm volatile" interact with "volatile" pointer accesses, so that it is guaranteed that a
> "asm volatile" will not be swapped with a "volatile" pointer access ?
> Of course I am interested in the general case: Is there a guarantee that "asm volatile" will stay in
> order with accesses to volatile pointers ?

A volatile asm is very much like a volatile load or store from memory.
They can not be interchanged.

Ian



More information about the Gcc-help mailing list