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

Page: 326 / 1898

2:78 Volume 2, Part 1: Addressing and Protection
maintain coherency between processor local instruction and data caches for IA-32 code.
Instruction caches are also not required to be coherent with multiprocessor Itanium
instruction set originated memory references. Instruction caches are required to be
coherent with multiprocessor IA-32 instruction set originated memory references. The
processor must ensure that transactions from other I/O agents (such as DMA) are
physically coherent with the instruction and data cache.
For non-cacheable references the processor provides no coherency mechanisms; the
memory system must ensure that a consistent view of memory is seen by each
processor. See
“Coalescing Attribute” on page 2:78 for a description of coherency for
the coalescing memory attribute.
4.4.4 Cache Write Policy Attribute
Write-back cacheable pages need only modify the processor’s copy of the physical
memory location; written data need only be passed to the memory system when the
processor’s copy is displaced, or a Flush Cache (
fc
) instruction is issued to flush a
virtual address. A cache line can only be written back to memory if a store, semaphore
(successful or not), the
ld.bias
, a mandatory RSE store, or a
.excl
hinted lfetch
instruction targeting that line has executed without a fault. These events enable
write-backs. A synchronized
fc
instruction disables subsequent write-backs (after the
line has been flushed).
As described in “Invalidating ALAT Entries” on page 1:67 , platform visible removal of
cache lines from a processor’s caches (e.g., cache line write-backs or platform visible
replacements) cause the corresponding ALAT entries to be invalidated.
4.4.5 Coalescing Attribute
For uncacheable pages, the coalescing attribute informs the processor that multiple
stores to this page may be collected in a coalescing buffer and issued later as a single
larger merged transaction. The processor may accumulate stores for an indefinite
period of time. Multiple pending loads may also be coalesced into a single larger
transaction which is placed in a coalescing buffer. Coalescing is a performance hint for
the processor; a processor may or may not implement coalescing.
A processor with multiple coalescing buffers must provide a flush policy that flushes
buffers at roughly equal rate even if some buffers are only partially full. The processor
may make coalesced buffer flushes visible in any order. Furthermore, individual bytes
within a single coalesced buffer may be flushed and made visible in any order.
Stores (including IA-32), which are coalesced, are performed out of order; coalescing
may occur in both the space and time domains. For example, a write to bytes 4 and 5
and a write to bytes 6 and 7 may be coalesced into a single write of bytes 4, 5, 6, and
7. In addition, a write of bytes 5 and 6 may be combined with a write of bytes 6 and 7
into a single write of bytes 5, 6, and 7.
Any release operation (regardless of whether it references a page with a coalescing
memory attribute), or any fence type instruction, forces write-coalesced data to be
flushed and made visible prior to the instruction itself becoming visible. (See
Table 4-15
on page 2:83 for a list of release and fence instructions.) Any IA-32 serializing
instruction, or access to an uncached memory type, forces write-coalesced data to