Re: Memory Barrier Definitions

[David Mosberger <davidm@napali.hpl.hp.com>]

>>>>> On Thu, 9 May 2002 17:36:46 +1000, Rusty Russell <rusty@rustcorp.com.au> said:

  Rusty> On Wed, 8 May 2002 10:07:08 -0700 David Mosberger
  Rusty> <davidm@napali.hpl.hp.com> wrote:

  >> The ia64 memory ordering model is quite orthogonal to the one
  >> that Linux uses (which is based on the Alpha instructions): Linux
  >> distinguishes between read and write memory barriers.  ia64 uses
  >> an acquire/release model instead.  An acquire orders all *later*
  >> memory accesses and a release orders all *earlier* accesses
  >> (regardless of whether they are reads or writes).  Another
  >> difference is that the acquire/release semantics is attached to
  >> load/store instructions, respectively.  This means that in an
  >> ideal world, ia64 would rarely need to use the memory barrier
  >> instruction.

  Rusty> Hmmm... could you explain more?  You're saying that every
  Rusty> load is an "acquire" and every store a "release"?  Or that
  Rusty> they can be flagged that way, but aren't always?

The latter: loads can have "acquire" semantics and stores can have
"release" semantics.  For example, at the assembly level, ld8.acq
would be an 8-byte load with acquire semantics, st8.rel an 8-byte
store with release semantics.  At the C level, acquire/release
semantics is used for all accesses to "volatile" variables.

One way to think of all this is that using .acq/.rel for *all* memory
accesses will give you a memory model that exactly matches that of a
Pentium III.

  Rusty> Does this means that an "acquire" means "all accesses after
  Rusty> this insn (in the code stream) must occur after this insn (in
  Rusty> time)"?

Yes.

  Rusty> Does that only apply to the address that instruction
  Rusty> touched, or all?

No, the address doesn't matter (data dependencies are always honored).

	--david