![Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS VOLUME 3 REV 2.3 Manual Download Page 84](http://html.mh-extra.com/html/intel/itanium-architecture-software-developers-volume-3-rev-2-3/itanium-architecture-software-developers-volume-3-rev-2-3_manual_2073404084.webp)
Volume 1, Part 1: Application Programming Model
1:73
purpose. Memory updates by DMA devices are coherent with respect to instruction and
data accesses of processors. The consistency between instruction and data caches of
processors with respect to memory updates by DMA devices is provided by the
hardware. In case a program modifies its own instructions, the
sync.i
and
srlz.i
instructions are used to ensure that prior coherency actions are observed by a given
point in the program. Refer to the description
sync.i
Intel® Itanium® Instruction Set Reference
for an example of self-modifying code.
4.4.7
Memory Access Ordering
Memory data access ordering must satisfy read-after-write (RAW), write-after-write
(WAW), and write-after-read (WAR) data dependencies to the same memory location.
In addition, memory writes and flushes must observe control dependencies. Except for
these restrictions, reads, writes, and flushes may occur in an order different from the
specified program order. Note that no ordering exists between instruction accesses and
data accesses or between any two instruction accesses. The mechanisms described
below are defined to enforce a particular memory access order. 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 a memory access (at a minimum this involves reading or writing memory).
Memory accesses follow one of four memory ordering semantics: unordered, release,
acquire or fence. Unordered data accesses may become visible in any order. Release
data accesses guarantee that all previous data accesses are made visible prior to being
made visible themselves. Acquire data accesses guarantee that they are made visible
prior to all subsequent data accesses. Fence operations combine the release and
acquire semantics into a bi-directional fence, i.e., they guarantee that all previous data
accesses are made visible prior to any subsequent data accesses being made visible.
Explicit memory ordering takes the form of a set of instructions: ordered load and
ordered check load (
ld.acq
,
ld.c.clr.acq
), ordered store (
st.rel
), semaphores
(
cmpxchg
,
xchg
,
fetchadd
), and memory fence (
mf
). The
ld.acq
and
ld.c.clr.acq
instructions follow acquire semantics. The
st.rel
follows release semantics. The
mf
instruction is a fence operation. The
xchg
,
fetchadd.acq
, and
cmpxchg.acq
instructions have acquire semantics. The
cmpxchg.rel
, and
fetchadd.rel
instructions
have release semantics. The semaphore instructions also have implicit ordering. If
there is a write, it will always follow the read. In addition, the read and write will be
performed atomically with no intervening accesses to the same memory region.
illustrates the ordering interactions between memory accesses with different
ordering semantics. “O” indicates that the first and second reference are performed in
order with respect to each other. A “-” indicates that no ordering is implied other than
data dependencies (and control dependencies for writes and flushes).
Table 4-20.
Memory Ordering Rules
First Reference
Second Reference
Fence
Acquire
Release
Unordered
fence
O
O
O
O
acquire
O
O
O
O
release
O
–
O
–
unordered
O
–
O
–
Summary of Contents for ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS VOLUME 3 REV 2.3
Page 1: ......
Page 11: ...x Intel Itanium Architecture Software Developer s Manual Rev 2 3 ...
Page 13: ...1 2 Intel Itanium Architecture Software Developer s Manual Rev 2 3 ...
Page 33: ...1 22 Volume 1 Part 1 Introduction to the Intel Itanium Architecture ...
Page 57: ...1 46 Volume 1 Part 1 Execution Environment ...
Page 147: ...1 136 Intel Itanium Architecture Software Developer s Manual Rev 2 3 ...
Page 149: ...1 138 Volume 1 Part 2 About the Optimization Guide ...
Page 191: ...1 180 Volume 1 Part 2 Predication Control Flow and Instruction Stream ...
Page 230: ......
Page 248: ...236 Intel Itanium Architecture Software Developer s Manual Rev 2 3 ...
Page 250: ...2 2 Intel Itanium Architecture Software Developer s Manual Rev 2 3 ...
Page 264: ...2 16 Volume 2 Part 1 Intel Itanium System Environment ...
Page 380: ...2 132 Volume 2 Part 1 Interruptions ...
Page 398: ...2 150 Volume 2 Part 1 Register Stack Engine ...
Page 486: ...2 238 Volume 2 Part 1 IA 32 Interruption Vector Descriptions ...
Page 750: ...2 502 Intel Itanium Architecture Software Developer s Manual Rev 2 3 ...
Page 754: ...2 506 Volume 2 Part 2 About the System Programmer s Guide ...
Page 796: ...2 548 Volume 2 Part 2 Interruptions and Serialization ...
Page 808: ...2 560 Volume 2 Part 2 Context Management ...
Page 842: ...2 594 Volume 2 Part 2 Floating point System Software ...
Page 850: ...2 602 Volume 2 Part 2 IA 32 Application Support ...
Page 862: ...2 614 Volume 2 Part 2 External Interrupt Architecture ...
Page 870: ...2 622 Volume 2 Part 2 Performance Monitoring Support ...
Page 891: ......
Page 1099: ...3 200 Volume 3 Instruction Reference padd Interruptions Illegal Operation fault ...
Page 1295: ...3 396 Volume 3 Resource and Dependency Semantics ...
Page 1296: ......
Page 1302: ...402 Intel Itanium Architecture Software Developer s Manual Rev 2 3 ...
Page 1494: ...4 192 Volume 4 Base IA 32 Instruction Reference FWAIT Wait See entry for WAIT ...
Page 1647: ...Volume 4 Base IA 32 Instruction Reference 4 345 ROL ROR Rotate See entry for RCL RCR ROL ROR ...
Page 1884: ...4 582 Volume 4 IA 32 SSE Instruction Reference ...
Page 1885: ...Index Intel Itanium Architecture Software Developer s Manual Rev 2 3 Index ...
Page 1886: ...Index Intel Itanium Architecture Software Developer s Manual Rev 2 3 ...
Page 1898: ...INDEX Index 12 Index for Volumes 1 2 3 and 4 ...