Author: Robert Hyatt
Date: 14:57:41 12/09/02
Go up one level in this thread
On December 09, 2002 at 17:49:00, Matt Taylor wrote:
>On December 09, 2002 at 17:26:07, Dieter Buerssner wrote:
>
>>On December 09, 2002 at 17:15:12, Robert Hyatt wrote:
>>
>>
>>>void __inline__ LockX86(volatile int * lock) {
>>> int dummy;
>>> asm __volatile__ (
>>> "1: movl $1, %0" "\n\t"
>>> " xchgl (%1), %0" "\n\t"
>>> " test %0, %0" "\n\t"
>>> " jz 3f" "\n\t"
>>> "2: pause" "\n\t"
>>> " movl (%1), %0" "\n\t"
>>> " test %0, %0" "\n\t"
>>> " jz 2b" "\n\t"
>>> " jmp 1b" "\n\t"
>>> "3:" "\n\t"
>>> : "=&r" (dummy)
>>> : "r" (lock)
>>> : "cc");
>>: "cc", "memory");
>>>}
>>>
>>>I tried changing the "r" to "q" to limit the register choices in case esi/edi
>>>won't work
>>>in some of the above, but I don't see anything wrong. If I remove the
>>>__inline__ then it
>>>seems to work just fine. With the inline in, it breaks things in unpredictable
>>>ways...
>>>
>>>Anything obvious (or not-so-obvious) that jumps out at you?
>>
>>I don't know much about locks. Have you tried to give the lock prefix in front
>>of the xchgl? To me it looks, like any register should do, so I agree with "r"
>>(and "q" seems unneeded).
>>
>>I never tried "=&r". I allways used "=r&" when the "&" was needed. However I
>>cannot remember, if this is needed. Another formal error, is that you don't tell
>>the compiler, that you change memory. However, I don't know, if he actually uses
>>this info. See the line above in the code.
>>
>>I would use testl instead of test, but I think, it won't make a difference.
>>
>>Regards,
>>Dieter
>
>The xchg instruction doesn't need a lock prefix because the lock is implicit.
>Also, it seems to me that "q" should not be necessary. I'll confess that I have
>not done a lot of inline assembly in gcc, but of the little I have done, I've
>never had trouble with my inline assembly breaking.
>
>It technically is an error not to communicate the modified memory back, but I
>don't think gcc actually requires that. Routines that use instructions like "rep
>stosb" would become very complicated very quickly. Also, the volatile pointer
>should force the compiler to reload the memory anyway. The whole point of
>communicating changed memory back is to tell the compiler that it can't cache a
>value.
>
>I didn't see any bugs in the code the first couple times I stared at it, but
>I'll look again.
>
>-Matt
Neither did I, but something is definitely rotten in Denmark...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.