[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-compiler-dev
Subject:    MFENCE vs. LOCK addl
From:       Paul.Hohensee () Sun ! COM (Paul Hohensee)
Date:       2009-02-26 15:20:39
Message-ID: 49A6B347.2020003 () sun ! com
[Download RAW message or body]

Yes, xchg only implies lock if one of the operands is in memory.  Might also
be restricted to the destination operand being in memory.  AMD has to do
the same thing as Intel, so the Intel books rule.

Paul

Peter B. Kessler wrote:
> I think xchg only implies lock if one of the operands is in memory, 
> but I'm looking at the Intel books, not the AMD ones.  You only show 
> one register operand, so it's hard to tell if you mean, for example, 
> "lock; xchg rax, rax", which doesn't reference memory.  If that's what 
> you mean, I don't think you need the push/pop around the xchg, because 
> rax will be unaffected by the xchg.
>
> Also note that "xchg rax, rax" is the encoding for the one-byte nop.  
> Is the effect of the lock the same on a nop as it is for a real 
> instruction, or is someone too clever for our purposes?  You could 
> choose to do a locked exchange of some other register with itself.
>
>             ... peter
>
> John Rose wrote:
>> What about XCHG?  It doesn't set flags, and (as a bonus) it implies 
>> the effect of a LOCK prefix:
>>     push rax
>>     xchg rax
>>     pop rax
>>
>> -- John
>>
>> On Feb 25, 2009, at 7:05 AM, Jiva, Azeem wrote:
>>
>>> Paul,
>>>  Ahh right, I did some experiments with running MFENCE vs. LOCK ADDL
>>> and MFENCE vs. PUSH/LOCK ADDL/POPF and found that MFENCE is faster than
>>> PUSH/LOCK/POP but not faster than just using the LOCK instruction by
>>> itself.  A nice optimization would be if the JVM could detect if the
>>> condition codes needed to be saved instead of saving them always.   
>>> This
>>> is on AMD hardware, and other systems might have different performance
>>> issues.


[prev in list] [next in list] [prev in thread] [next in thread]