More questions about "asm volatile"

[Ingo Rohloff <Ingo dot Rohloff at lauterbach dot com>]

Hello,

I just read a lot of stuff about what "asm volatile" means, or to be more precise what it DOES NOT
mean.
Unfortunately "http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html"; explains a lot about what "asm
volatile" does NOT mean, but not about what it means.

So here are my questions:

1st Question:
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 ?

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

2nd Question:
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 ?

Again if this is guaranteed, the "Extended-Asm.html" document mentioned above should say so.

with best regards
  Ingo