Author: Robert Hyatt
Date: 20:04:33 12/09/02
Go up one level in this thread
On December 09, 2002 at 18:44:14, Dieter Buerssner wrote: >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= According to the Intel manual, it has no dependency on the register used, if one operand is in memory, then the lock prefix is assumed... without being required. > >>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. That was my thinking, yes. I use the "volatile" as I don't want my lock code moved around. Early on I used "lock=0" to unlock the thing and the damned compiler moved that up a bit for better scheduling and wrecked a critical section protection. :) I now have a simple movl $0,lock to clear the lock, but that also has volatile so it won't be moved around. :) > >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 I've looked at gcc's .S output and it looks fine. Unfortunately I have been using Intel's compiler. I'm now going to look at its .S output as well to see if it understands those dynamic register references which I suspect is what is breaking things...
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.