extend.texi (Extended Asm): Rewrite asm volatile description.

2004-10-13  Dale Johannesen  <dalej@apple.com>

       * doc/extend.texi (Extended Asm):  Rewrite asm volatile description.

From-SVN: r88999
This commit is contained in:
Dale Johannesen 2004-10-13 19:14:44 +00:00 committed by Dale Johannesen
parent ddfabf89bb
commit 2f59e40ed6
2 changed files with 31 additions and 25 deletions

View File

@ -1,3 +1,7 @@
2004-10-13 Dale Johannesen <dalej@apple.com>
* doc/extend.texi (Extended Asm): Rewrite asm volatile description.
2004-10-13 Frank Ch. Eigler <fche@redhat.com>
* toplev.c (compile_file): Call mudflap_finish_file from here ...

View File

@ -3724,8 +3724,8 @@ if your instruction does have a side effect on a variable that otherwise
appears not to change, the old value of the variable may be reused later
if it happens to be found in a register.
You can prevent an @code{asm} instruction from being deleted, moved
significantly, or combined, by writing the keyword @code{volatile} after
You can prevent an @code{asm} instruction from being deleted
by writing the keyword @code{volatile} after
the @code{asm}. For example:
@smallexample
@ -3737,40 +3737,42 @@ the @code{asm}. For example:
@end smallexample
@noindent
If you write an @code{asm} instruction with no outputs, GCC will know
the instruction has side-effects and will not delete the instruction or
move it outside of loops.
The @code{volatile} keyword indicates that the instruction has
important side-effects. GCC will not delete a volatile @code{asm} if
it is reachable. (The instruction can still be deleted if GCC can
prove that control-flow will never reach the location of the
instruction.) In addition, GCC will not reschedule instructions
across a volatile @code{asm} instruction. For example:
instruction.) Note that even a volatile @code{asm} instruction
can be moved relative to other code, including across jump
instructions. For example, on many targets there is a system
register which can be set to control the rounding mode of
floating point operations. You might try
setting it with a volatile @code{asm}, like this PowerPC example:
@smallexample
*(volatile int *)addr = foo;
asm volatile ("eieio" : : );
asm volatile("mtfsf 255,%0" : : "f" (fpenv));
sum = x + y;
@end smallexample
@noindent
Assume @code{addr} contains the address of a memory mapped device
register. The PowerPC @code{eieio} instruction (Enforce In-order
Execution of I/O) tells the CPU to make sure that the store to that
device register happens before it issues any other I/O@.
This will not work reliably, as the compiler may move the addition back
before the volatile @code{asm}. To make it work you need to add an
artificial dependency to the @code{asm} referencing a variable in the code
you don't want moved, for example:
Note that even a volatile @code{asm} instruction can be moved in ways
that appear insignificant to the compiler, such as across jump
instructions. 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} instruction; GCC does not
``forget everything'' when it encounters a volatile @code{asm}
instruction the way some other compilers do.
@smallexample
asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv));
sum = x + y;
@end smallexample
An @code{asm} instruction without any operands or clobbers (an ``old
style'' @code{asm}) will be treated identically to a volatile
@code{asm} instruction.
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}
instruction; GCC does not ``forget everything'' when it encounters
a volatile @code{asm} instruction the way some other compilers do.
An @code{asm} instruction without any output operands will be treated
identically to a volatile @code{asm} instruction.
It is a natural idea to look for a way to give access to the condition
code left by the assembler instruction. However, when we attempted to