Author: Matt Taylor
Date: 14:49:00 12/09/02
Go up one level in this thread
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
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.