Author: Robert Hyatt
Date: 20:00:02 12/09/02
Go up one level in this thread
On December 09, 2002 at 18:02:48, Eugene Nalimov wrote:
>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
That was my current attempt, in fact. And another mistake I made was that
I was looking at -S output from gcc, but in reality I am using Intel's
compiler version 7.0. I am going to look at what it is producing for my
inline function as well to make sure it isn't screwing up on the dynamic
register assignments...
I had already done a Pause() one-liner as I needed that for my spinwait
in Thread(), And I had made the change to my lock to do this:
while (Exchange(&lock,1)) while(lock) Pause();
but I didn't have time to check it prior to leaving the office. I am going
to try that tonight as it should be just as good as the inline asm, overall.
I was mainly playing with this to see how this nonsense works for gcc. :)
>
>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.