Re: [Valgrind-developers] Atomic ppc instructions versus Imbe_BusLock / Imbe_BusUnlock

[Julian S. <js...@ac...>]

> If I remember correctly you added some time ago Imbe_BusLock /
> Imbe_BusUnlock to VEX. Were these intended to be instruction-set
> independent, or only to handle x86 bus locking ? In the last case, how
> should tools like Helgrind or exp-drd handle atomic ppc instructions ?
> See also http://bugs.kde.org/show_bug.cgi?id=162354.

Well, the difficulty is that the powerpc way of doing atomic
test-and-set (etc) is completely different from the x86/amd64
way.  x86 and amd64 make it easy, by allowing a 1-byte LOCK prefix
byte (0xF0) in front of the instruction.  Vex sees that and puts
Imbe_BusLock and Imbe_BusUnlock around the translation of the
instruction, so helgrind and drd (and anybody else who cares) can
see the locking.

ppc has no direct equivalent.  There is nothing to indicate that
any single instruction is atomic.  In any case, since ppc only allows
simple load and store instructions, and not load-op-store insns,
it would be useless to say that a single load or store is atomic
(so what?)

Instead ppc supplies what amounts to a programmable bus snoop
mechanism, the lwarx and stwcx. instructions.  These can be used
to create atomic test-and-set sequences, etc, all the primitives 
you need.  Google for these; there are many examples on the net.

lwarx and stwcx. are used together to create such sequences, but
there is no real constraint on what insns go between them, either
statically or dynamically.  So there is no easy way, at JIT time,
to guarantee to observe that a given sequence represents an
atomic test-and-set (or whatever).  At a guess I'd say it's
undecideable in general.  That said, it is probably possible to
do better than at present by using some kind of idiom recognition
scheme, or IR analysis.  But neither of those will be simple or
completely robust.

J