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

Page: 772 / 1898

2:524 Volume 2, Part 2: MP Coherence and Synchronization
2.2.2 Memory Attributes
In addition to the ordering semantics and data dependencies, the memory attributes of
the page that is being referenced also influence access ordering and visibility. Using
memory attributes allows the Itanium architecture to match the performance and the
usage model to the type of device (e.g. main memory, memory-mapped I/O device,
frame buffer, locations with side-effects, etc.) that backs a page of memory. Typically,
memory with side-effects is mapped uncacheable while memory without side-effects is
mapped as write-back cacheable.
Section 4.4, “Memory Attributes” describes memory attributes in the Itanium
architecture in greater depth.
Memory with the uncacheable UC or UCE attributes is sequential by definition. A
processor based on the Itanium architecture ensures that accesses to sequential
memory locations reach a peripheral domain (a platform-specific collection of
uncacheable locations, colloquially known as “a device”) in program order with respect
to all other accesses to sequential locations in the same peripheral domain. The
sequential behavior of UC or UCE memory is independent of the ordering semantics
(i.e. acquire, release, fence, or unordered) attached to the accesses.
Other observers (e.g. processors or other peripheral domains) need not see references
to UC or UCE memory in sequential order if at all. When multiple agents are writing to
the same device, it is up to software to synchronize the accesses to the device to
ensure the proper interleaving.
The ordering semantics of an access to sequential memory determines how the access
becomes visible to the peripheral domain with respect to other operations. For
example, consider the code sequence shown in
Figure 2-2 .
In this code, assume that
data_0
and
data_1
are cacheable locations and
start
and
ready
are an uncacheable UC or UCE locations.
Sequentiality ensures that M3 and M4 reach the peripheral domain in program order
(i.e. M3 before M4). Further, the release semantics on M3 ensures that it is not made
visible to the peripheral domain until after M1 and M2 are made visible to the coherence
domain. The M1 and M2 accesses may become visible to the coherence domains in any
order as they both have unordered semantics. Even though the memory ordering
semantics allow M4 to become visible before M3, the processor must make M3 visible
before M4 because both
ready
and
start
are sequential locations.
Figure 2-2. Interaction of Ordering and Accesses to Sequential Locations
sequential_example:
st [data_0] = 0 // M1: put data in cacheable mem
st [data_1] = 0 // M2: put data in cacheable mem
st.rel [ready] = 1 // M3: tell device to get ready
st [start] = 1 // M4: tell device to start