>>>>> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 14 2002 - 12:00:11 EST