On 29.01.2018 14:19, Oleg Endo wrote:
On Mon, 2018-01-29 at 10:39 +0100, Georg-Johann Lay wrote:
Hence the source should read something like
__asm__ ("movua.l @%1+, %0"
: "=z" (longword), "+r" (src)
: "m" (*src));
The problem (or rather disadvantage) with this approach is that the
compiler doesn't know what the value of "src" is after it has been
modified by the asm code. Segher's suggestion looks like the better
option.
Cheers,
Oleg
YMMV, I am not even sure if it is correct or even makes complete sense.
The "m>"(*src) operand doesn't even express that src is changing, and
the constraint allows to use post-increment, but does not force it.
This means that the user cannot be sure what value src has after the asm
(either src or src+1 w.r.t to before the asm), hence it cannot be used
(e.g. in a loop to read several consecutive values or using several of
these constructs in a row).
Moreover, the explicit usage of src+1 might add additional overhead;
it's clear that the respective operation "p = src+1;" should not be
optimized away to have an effect, but /if/ is has an effect then this
might be an overhead (which Sébastien wanted to get rid of). As lined
out above, the stored value of "src+1" is of no use because the compiler
is not forced to use post-inc, hence even if the compiler knows src
after the asm, it's worthless to the user.
My proposal is based on experience with similar asm but for a different
architecture, namely post-inc reads from flash on AVR: With explicit
post-inc the compiler doesn't know the value, but that has never been a
disadvantage with the use cases I am aware of. But it was important for
ME to know the value of the address after the asm in order to reuse it.
And my experience with inline asm is this: if one doesn't express all
side effects (which is the case for "m>"(src)), then the asm will bite
you sooner or later; even it it appeared to work fine in the past.
Johann
