<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Tony, hm, the full generality, in the backend, I think it should be a parameter whether or not the old value or new value or both or neither are returned.<BR>
<BR>
See how the Microsoft intrinsics return the old value, but the x86 instructions return the new value, necessitating compare/exchange loops, unless the value is ignored, in which case much more efficient:<BR>
<BR>
"v" for void:<BR>
<BR>
void __fastcall vor(long a, long b) { _InterlockedOr(a, b); }<BR>long __fastcall or(long a, long b) { return _InterlockedOr(a, b); }<BR>
<BR>
void __fastcall vxor(long a, long b) { _InterlockedXor(a, b); }<BR>long __fastcall xor(long a, long b) { return _InterlockedXor(a, b); }<BR>
<BR>
void __fastcall vand(long a, long b) { _InterlockedAnd(a, b); }<BR>long __fastcall and(long a, long b) { return _InterlockedAnd(a, b); }<BR><BR>
<BR>
C:\>cl -c 1.c -FAsc -Ox && more 1.cod<BR><BR>
; 3 : void __fastcall vor(long a, long b) { _InterlockedOr(a, b); }<BR>
00000 f0 09 11 lock or DWORD PTR [ecx], edx<BR> 00003 c3 ret 0<BR><BR>
; 4 : long __fastcall or(long a, long b) { return _InterlockedOr(a, b); }<BR>
00010 56 push esi<BR> 00011 8b 01 mov eax, DWORD PTR [ecx]<BR>$LN3@:<BR> 00013 8b f0 mov esi, eax<BR> 00015 0b f2 or esi, edx<BR> 00017 f0 0f b1 31 lock cmpxchg DWORD PTR [ecx], esi<BR> 0001b 75 f6 jne SHORT $LN3@<BR> 0001d 5e pop esi<BR> 0001e c3 ret 0<BR><BR>
<BR>
; 6 : void __fastcall vxor(long a, long b) { _InterlockedXor(a, b); }<BR>
00020 f0 31 11 lock xor DWORD PTR [ecx], edx<BR> 00023 c3 ret 0<BR><BR>
<BR>
; 7 : long __fastcall xor(long a, long b) { return _InterlockedXor(a, b); }<BR>
00030 56 push esi<BR> 00031 8b 01 mov eax, DWORD PTR [ecx]<BR>$LN3@:<BR> 00033 8b f0 mov esi, eax<BR> 00035 33 f2 xor esi, edx<BR> 00037 f0 0f b1 31 lock cmpxchg DWORD PTR [ecx], esi<BR> 0003b 75 f6 jne SHORT $LN3@<BR> 0003d 5e pop esi<BR> 0003e c3 ret 0<BR><BR>
<BR>
; 9 : void __fastcall vand(long a, long b) { _InterlockedAnd(a, b); }<BR>
00040 f0 21 11 lock and DWORD PTR [ecx], edx<BR> 00043 c3 ret 0<BR><BR>
<BR>
; 10 : long __fastcall and(long a, long b) { return _InterlockedAnd(a, b); }<BR>
00050 56 push esi<BR> 00051 8b 01 mov eax, DWORD PTR [ecx]<BR>$LN3@:<BR> 00053 8b f0 mov esi, eax<BR> 00055 23 f2 and esi, edx<BR> 00057 f0 0f b1 31 lock cmpxchg DWORD PTR [ecx], esi<BR> 0005b 75 f6 jne SHORT $LN3@<BR> 0005d 5e pop esi<BR> 0005e c3 ret 0<BR>@and@8 ENDP<BR>_TEXT ENDS<BR>END<BR>
<BR>
<BR>
- Jay<BR><BR><BR> <BR>
> Subject: Re: [M3devel] firming up atomics?<BR>> From: hosking@cs.purdue.edu<BR>> Date: Sun, 17 Oct 2010 08:48:09 -0400<BR>> CC: m3devel@elegosoft.com<BR>> To: jay.krell@cornell.edu<BR>> <BR>> I still have some fixes to check in before turning it on again.<BR>> They are intended to match the approved C++0x standard.<BR>> <BR>> On 16 Oct 2010, at 20:27, Jay K wrote:<BR>> <BR>> > <BR>> > Tony,<BR>> > <BR>> > Can we firm up the atomic semantics/implementatino?<BR>> > <BR>> > Now might be a good time for me to make the NT/x86 backend<BR>> > definitely work, test it, and make it more efficient.<BR>> > (ie. not using InterlockedCompareExchange loop for InterlockedIncrement when a simple xadd will work).<BR>> > <BR>> > <BR>> > Like, old value vs. new value returned?<BR>> > <BR>> > <BR>> > Off the cuff, I'd say, better to always return old value.<BR>> > The new value can always be computed from it.<BR>> > <BR>> > However we are the mercy of the processors.<BR>> > <BR>> > <BR>> > And it only matters for or/and.<BR>> > xor/add/sub/inc/dec can all compute either from either.<BR>> > <BR>> > <BR>> > Also, please, I don't find the specifications clear.<BR>> > At least the last time I studied them.<BR>> > <BR>> > <BR>> > To me they should say, things like,<BR>> > "returns the old value" <BR>> > or "returns the new value" <BR>> > <BR>> > <BR>> > or returns true if compare matched<BR>> > or returns false if the compare matched<BR>> > etc.<BR>> > <BR>> > <BR>> > The mentions of "spurious failure" or whatnot didn't make sense either.<BR>> > They should say, something like:<BR>> > returns true if the compare matched<BR>> > but sometimes even if the compare should have matched,<BR>> > it won't, and false will be returned -- specify everything that happens when there is "failure".<BR>> > <BR>> > <BR>> > Furthermore, if you look at what Microsoft compilers provide,<BR>> > they provide a bunch of very simple very clear well documented functions,<BR>> > that the compiler implements and inlines.<BR>> > (at least if you ignore the qcuire/release stuff that confuses me...<BR>> > <BR>> > <BR>> > You could specify in terms of them.<BR>> > Really. A good idea.<BR>> > <BR>> > <BR>> > ie: is our compare_exchange equivalent to InterlockedCompareExchange?<BR>> > Or maybe parameter order different?<BR>> > <BR>> > <BR>> > Of course, I understand, the types supported by the Microsoft<BR>> > intrinsics have varied through time and slowly grown.<BR>> > 8bit and 16bit might still be lacking but 32bit and 64bit are very<BR>> > complete. 64bit atomic operations on 32bit x86 processors <BR>> > since Pentium or so can be synthesized with a loop over<BR>> > InterlockedCompareExchange64.<BR>> > <BR>> > <BR>> > Or in terms of the gcc intrinsics, probably similarly ok.<BR>> > <BR>> > <BR>> > We should probably also nail down the implementation where<BR>> > they aren't available.<BR>> > <BR>> > <BR>> > And maybe put in safer defaults?<BR>> > And quickly improve where we can, e.g. on all x86/AMD64 platforms.<BR>> > <BR>> > <BR>> > Thanks,<BR>> > - Jay<BR>> > <BR>> <BR> </body>
</html>