Author: Dieter Buerssner
Date: 15:44:14 12/09/02
Go up one level in this thread
On December 09, 2002 at 17:46:03, Robert Hyatt wrote: >According to the intel docs, the xchg instruction is a interlocked instruction >already, >and the lock prefix is redundant. My current lock code does not have this and >it works >fine, so there is more than that going on. Thanks for pointing this out (also, to Matt) Is the implicit lock perhaps dependent on the actual register used, or is it independent of the register= >As far as memory, the only two things that use the locks are the Lock() and >Unlock() >asm codes so I don't think it matters. Also all locks are declared volatile and >can't be >held in registers for optimizing anyway... Looks like it - yes. However, perhaps the compiler can assume, that you won't change any memory, when you don't give the "memory" in the clobber list. Even the volatile (which I recognized) may not change this. OTOH, you gave asm volatile, which pretty much will avoid any code move of the inline assembler. And because you only use that memory in 2 well defined functions, there should be no danger of any misoptimization here. Eugene's suspision seem to be the most reasonable explaination. I have seen strange gas bugs (only with self written assembler/inline assembler, never with gcc asm-output). One was that segment overwrites did not work correctly (not easy to find bug, I had to decode the binary machine language myself). things like movl fs:some_adress, some_register would produce wrong binary now and then. After I asked some people from the develpment team, one comment was (paraphrasing): "It seems to depend on the phase of the moon, wheter this is done correclty or not by gas". It is quite a few years ago, and probably fixed now. The workaround, that functioned reliably, was to write the segment overwrite prefix as binary. .byte 0x64; /* Use fs */ movl some_adress, some_register If you don't have many invocations of the Lock function, it might be possible to look at the assembler output of Gcc and detect something. Or preferably even with an assembler level debugger. The "pause" should be rather significant, to find exactly all those cases. Regards, Dieter
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.