Subj : Re: Memory visibility and MS Interlocked instructions
To   : comp.programming.threads
From : Joe Seigh
Date : Tue Aug 30 2005 11:44 pm

David Hopwood wrote:
> Joe Seigh wrote:
> 
>> We're talking about whether PC implies loads (not stores) are in order 
>> or not.
> 
> 
> I don't even know what "loads are in order" would mean. What Alexander 
> was claiming
> was that on x86 load implies load.acq. This *is* consistent with what 
> the P4 manual
> says, insofar as the manual makes sense.
> 
I just notice this in the Itanium System Architecture manual.

2.1.2 Loads and Stores
 In the Itanium architecture, a load instruction has either unordered or acquire semantics while a
 store instruction has either unordered or release semantics. By using acquire loads (ld.acq) and
 release stores (st.rel), the memory reference stream of an Itanium-based program can be made to
 operate according to the IA-32 ordering model. The Itanium architecture uses this behavior to
 provide IA-32 compatibility. That is, an Itanium acquire load is equivalent to an IA-32 load and an
 Itanium release store is equivalent to an IA-32 store, from a memory ordering perspective.

Go figure. :)

Now if this can be reconciled with AMD's 

  Out-of-order reads are allowed. Out-of-order reads can occur
  as a result of out-of-order instruction execution or
  speculative execution. The processor can read memory outof-
  order to allow out-of-order execution to proceed.


-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.