>>>>> On Mon, 13 May 2002 13:26:05 +1000, Rusty Russell <rusty@rustcorp.com.au> said:
Rusty> OK. So ignoring the fact that you somehow have to attach
Rusty> your barriers to a load or store for the moment, we have
Rusty> before vs. after (ia64), read vs. write (most archs), io vs
Rusty> mem (ppc, ppc64), data dependency vs non-data dependency
Rusty> (alpha), and smp vs up.
An alternative way to think about the ia64 model is that it provides
"ordering" variables. Accesses to those variables won't be reordered
by the compiler or the CPU and also order other (normally unordered
accesses). One way to support this is have an ORDERING attribute for
variables (which would expand into "volatile" on ia64). This would
have to be complemented by a set of barrier routines which will
achieve the desired ordering on machines that don't have the
acquire/release model of ia64 (and on ia64, they would expand into
nothing).
--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:21 EST