[M3devel] m3back atomic current summary
Jay K
jay.krell at cornell.edu
Fri Feb 12 15:20:39 CET 2010
"m3back atomics summary"
After a while of looking at this, I conclude
that the atomics interface has a bunch
of functionality that doesn't map all that
well to what x86 provides, and vice versa.
In particular x86 allows
lock mem or reg
lock mem xor reg
lock mem and reg
lock not mem
lock neg mem
and several others
but the requirement of the atomic interface
to return the new value makes these not line up.
The new value doesn't come back in a register
and rereading memory will not be atomic.
Now I see why the C compiler's _InterlockedOr and such
use _InterlockedCompareExchange in a small loop.
Any xchg with a memory operand on x86 is always atomic.
fetch_and_op for add/sub can probably be more efficient using xadd.
You get back the old value but you can do the add a second time.
I understand the point isn't necessarily to expose whatever x86 can do,
but also to provide an interface that can be reasonably implemented
across various hardware (mips, alpha, powerpc, sparc, arm, hppa, ia64, maybe 68k).
It's possible the front end (or backend) should notice if the return value
is ignored, such as by preceding it with EVAL, and then those can be
implemented more efficiently.
The NT386 backend does not have the level of sophistication required to do that.
I'm torn on even providing this stuff.
It's all very tricky to use.
However any "systems" language should probobably
provide for a portable efficient lock package, that
others can then easily use.
- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100212/68d9263c/attachment-0001.html>
More information about the M3devel
mailing list