Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS MANUAL VOLUME 1 REV 2.3 Manual page 335

Page Consumption fault. cmpxchg and xchg accesses to pages with other memory
attributes cause an Unsupported Data Reference fault.
• fetchadd: The fetchadd instruction can be executed successfully only if the access
is to a cacheable page with write-back write policy or to a UCE page. fetchadd
accesses to NaTPages cause a Data NaT Page Consumption fault. Accesses to pages
with other memory attributes cause an Unsupported Data Reference fault. When
accessing a cacheable page with write-back write policy, atomic fetch and add
operation is ensured by the processor cache-coherence protocol. For highly
contended semaphores, the cache line transactions required to guarantee atomicity
can limit performance. In such cases, a centralized "fetch and add" semaphore
mechanism may improve performance. If supported by the processor and the
platform, the UCE attribute allows the processor to "export" the fetchadd operation
to the platform as an atomic "fetch and add." Effects of the exported fetchadd are
platform dependent. If exporting of fetchadd instructions is not supported by the
processor, a fetchadd instruction to a UCE page takes an Unsupported Data
Reference fault.
• Flush Cache Instructions – fc instructions must always be "broadcast" to other
processors, independent of the memory attribute in the local processor. It is legal to
use an uncacheable memory attribute for any valid address when used as a flush
cache (fc) instruction target. This behavior is required to enable transitions from
one memory attribute to another and in case different memory attributes are
associated with the address in another processor.
• Prefetch instructions – lfetch and any implicit prefetches to pages that are not
cacheable are suppressed. No transaction is initiated. This allows programs to issue
prefetch instructions even if the program is not sure the memory is cacheable.
4.4.10 Effects of Memory Attributes on Advanced/Check Loads
The ALAT behavior of advanced and check loads is dependent on the memory attribute
of the page referenced by the load. These behaviors are required; advanced and check
load completers are not hints.
All speculative pages have identical behavior with respect to the ALAT. Advanced loads
to speculative pages always allocate an ALAT entry for the register, size, and address
tuple specified by the advanced load. Speculative advanced loads allocate an ALAT
entry if the speculative load is successful (i.e., no deferred exception); if the speculative
advanced load results in a deferred exception, any matching ALAT entry is removed and
no new ALAT entry is allocated. Check loads with clear completers (ld.c.clr,
ld.c.clr.acq, ldf.c.clr) remove a matching ALAT entry on ALAT hit and do not
change the state of the ALAT on ALAT miss. Check loads with no-clear completers
(ld.c.nc, ldf.c.nc) allocate an ALAT entry on ALAT miss. On ALAT hit, the ALAT is
unchanged if an exact ALAT match is found (register, address, and size); a new ALAT
entry with the register, address, and size specified by the no-clear check load may be
allocated if a partial ALAT match is found (match on register).
Advanced loads (speculative or non-speculative variants) to non-speculative pages
always remove any matching ALAT entry. Check loads to non-speculative pages that
miss the ALAT never allocate an ALAT entry, even in the case of a no-clear check load.
ALAT hits on check loads to non-speculative pages (which can occur if a previous
advanced load referenced that page via a speculative memory attribute) result in
Volume 2, Part 1: Addressing and Protection 2:87