[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