Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS VOLUME 3 REV 2.3, Manual

Page: 331 / 1898

Volume 2, Part 1: Addressing and Protection 2:83
Table 4-15 defines a set of “Orderable Instructions” that follow one of four ordering
semantics: unordered , release , acquire or fence . The table defines the ordering
semantics and the instructions of each category. Only these Itanium instructions can be
used to establish multiprocessor ordering relations.
In the following discussion, the terms previous and subsequent are used to refer to
the program specified order. The term visible is used to refer to all architecturally
visible effects of performing an instruction. For memory accesses and semaphores this
involves at least reading or writing memory. For
mf.a
, visibility is defined by platform
acceptance of previous memory accesses. Visibility of
sync.i
is defined by visibility of
previous flush cache (
fc
,
fc.i
) operations. For ALAT lookups (
ld.c
,
chk.a
), visibility is
determination of ALAT hit or miss. For global TLB purge operations, visibility is defined
by removal of an address translation from the TLBs on all processors in the TLB
coherence domain. Global TLB purge instructions (
ptc.g
and
ptc.ga
) follow release
semantics on the local processor. They are also broadcast to all other processors in the
TLB coherence domain. On each such remote processor, a point is chosen in its
program-order execution and a local TLB purge operation is inserted at that point; this
local TLB purge operation follows release semantics, except with respect to global purge
instructions being executed by that remote processor. For local TLB purge operations,
visibility is defined by removal of an address translation on the local processor. Local
TLB purge instructions (
ptc.l
,
ptc.e
) ensure that all prior stores are made locally
visible before the actual purge operation is performed.
Itanium memory accesses to sequential pages occur in program order with respect to
all other sequential pages in the same peripheral domain, but are not necessarily
ordered with respect to non-sequential page accesses. A peripheral domain is a
platform-specific collection of uncacheable addresses. An I/O device is normally
contained in a peripheral domain and all sequential accesses from one processor to that
device will be ordered with respect to each other. Sequentiality ensures that
uncacheable, non-coalescing memory references from one processor to a peripheral
domain reach that domain in program order. Sequentiality does not imply visibility.
Table 4-15. Ordering Semantics and Instructions
Ordering
Semantics
Description Orderable Intel
®
Itanium
®
Instructions
Unordered
Unordered instructions may become visible in
any order.
ld, ld.s, ld.a, ld.sa, ld.fill,
ldf, ldf.s, ldf.sa, ldf.fill,
ldfp, ldfp.s, ldfp.sa,
st, st.spill,
stf, stf.spill,
mf.a, sync.i,
ld.c, chk.a
Release
Release instructions guarantee that all
previous orderable instructions are made
visible prior to being made visible themselves.
cmp8xchg16.rel, cmpxchg.rel,
fetchadd.rel, st.rel, ptc.g,
ptc.ga
Acquire
Acquire instructions guarantee that they are
made visible prior to all subsequent orderable
instructions.
cmp8xchg16.acq, cmpxchg.acq,
fetchadd.acq, xchg, ld.acq,
ld.c.clr.acq
Fence
Fence instructions combine the release and
acquire semantics into a bi-directional fence;
i.e., they guarantee that all previous orderable
instructions are made visible prior to any
subsequent orderable instruction being made
visible.
mf