Author: Eugene Nalimov
Date: 15:02:48 12/09/02
Go up one level in this thread
Looks like compiler bug to me.
Try to use inline asm for "pause" and "xchg" only, and write remainder in the C.
I.e. something like
int __inline__ xchg86 (volatile int * lock) {
...
}
void __inline__ pause86 (void) {
...
}
void __inline__ LockX86(volatile int * lock) {
while (xchg86 (lock)) {
do {
pause86();
} while (lock);
}
}
Thanks,
Eugene
On December 09, 2002 at 17:57:41, Robert Hyatt wrote:
>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.