Hello,
> The whole extended-asm section could use an intelligent rewrite. This
> is difficult. Patches welcome.
Please find attached a small diff for "extend.texi", trying to explain what I understood about "asm
volatile".
I am not sure if this mailing list is the best place for that (hints where instead to propose this
welcome).
Additionally I do not know if what I inserted is correct; especially since the semantics of
"volatiles" seem to be complicated (I just read about sequence points and so on).
I am also not a native speaker so the syntax might not be correct too; still I think it really would
help to include something similar as in the patch in the documentation.
so long
Ingo
Ian Lance Taylor wrote:
> Ingo Rohloff <Ingo.Rohloff@xxxxxxxxxxxxxx> 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
>
>
Index: extend.texi
===================================================================
--- extend.texi (revision 172305)
+++ extend.texi (working copy)
@@ -5784,8 +5784,20 @@
Similarly, you can't expect a
sequence of volatile @code{asm} instructions to remain perfectly
-consecutive. If you want consecutive output, use a single @code{asm}.
-Also, GCC will perform some optimizations across a volatile @code{asm}
+consecutive, meaning that the different volatile @code{asm} instructions
+might get interspersed with assembler instructions from other code parts.
+The volatile @code{asm} instructions will not be reordered though, so the
+volatile @code{asm} instructions will appear in the same order in the
+assembler output as they appear in the source code.
+If you want completely consecutive output (not interspersed with
+assembler instructions from other code parts), use a single @code{asm}.
+volatile @code{asm} instructions are treated in a similar
+manner as accesses to volatile objects. That means that
+volatile @code{asm} instructions will not be moved across accesses to
+volatile objects, so all accesses to volatile objects and all
+volatile @code{asm} instructions will stay in the order as defined
+by the source code.
+GCC will perform some optimizations across a volatile @code{asm}
instruction; GCC does not ``forget everything'' when it encounters
a volatile @code{asm} instruction the way some other compilers do.
