<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
"m3back atomics summary"<BR>
<BR>After a while of looking at this, I conclude<BR>that the atomics interface has a bunch<BR>of functionality that doesn't map all that<BR>well to what x86 provides, and vice versa.<BR>
<BR>
<BR>In particular x86 allows<BR>
lock mem or reg<BR> lock mem xor reg<BR> lock mem and reg<BR> lock not mem<BR> lock neg mem<BR> and several others<BR>
<BR>
<BR>but the requirement of the atomic interface<BR>to return the new value makes these not line up.<BR>The new value doesn't come back in a register<BR>and rereading memory will not be atomic.<BR>
<BR>
<BR>Now I see why the C compiler's _InterlockedOr and such<BR>use _InterlockedCompareExchange in a small loop.<BR>
<BR> <BR>
Any xchg with a memory operand on x86 is always atomic.<BR>
<BR>
<BR>
fetch_and_op for add/sub can probably be more efficient using xadd.<BR>
You get back the old value but you can do the add a second time.<BR>
<BR>
<BR>
I understand the point isn't necessarily to expose whatever x86 can do,<BR>
but also to provide an interface that can be reasonably implemented<BR>
across various hardware (mips, alpha, powerpc, sparc, arm, hppa, ia64, maybe 68k).<BR>
<BR>
<BR>
It's possible the front end (or backend) should notice if the return value<BR>
is ignored, such as by preceding it with EVAL, and then those can be<BR>
implemented more efficiently.<BR>
The NT386 backend does not have the level of sophistication required to do that.<BR>
<BR>
<BR>
I'm torn on even providing this stuff.<BR>
It's all very tricky to use.<BR>
However any "systems" language should probobably<BR>
provide for a portable efficient lock package, that<BR>
others can then easily use.<BR>
<BR>
<BR> - Jay<BR><BR> </body>
</html>