Re: asm issues

[Joern Rennecke <amylaar at cygnus dot co dot uk>]

> And even without the volatile, gcc knows certain things about such a
> pointer: in particular, gcc knows that it can't just pass a pointer to
> another object that just happens to contain the same values. And it knows
> that it cannot cache whatever the pointer points to over the function call
> (or over the asm). And it knows that even if the function is going to
> change the value (ie a "=m" kind of asm), that doesn't mean that it can
> optimize away the previous writer. 

If you don't completely replace the value, you shouldn't use just =m;
it should be +m.

> Looking at the asms _I_ use, that is exactly what I want when I say "m".

Well, you are not the only one to use asms.
And if you make =m the same as +m, you loose the ability to express when
an asm really overwrites the old value.

And what would become of an =rm constraint?  Would you disallow copy-in
copy-out for the register variant too?

If you are just manipulating data, the correctness of the program shouldn't
suffer when a value is moves from one memory location to the other during
the program.
And if you need a pointer to store somewhere, you can explicitly obtain one
using the address operator.  This makes the intend much clearer.
This is sort of like the difference between pasing a reference and passing
a pointer to a C++ function.

> That, of course, does not mean that the above are the semantics that
> anybody else would want, but they do kind of make sense, and they clarify
> the issue with any asms that _require_ a certian memory location (ie
> things like spinlocks and atomic updates where we cannot allow the
> compiler to play games with the accesses). 

splinlocks and values to be atomically updated should really be marked as
volatile.  Otherwise the compiler would be allowed to use it as a temporary
if it saves the value in a register in the meantime, and restores it later.

Could be handy when you need secondary memory for integer <-> FP
conversions...