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

Page: 78 / 1898

Volume 1, Part 1: Application Programming Model 1:67
than the load of the data.
If the check load was an ordered check load (
ld.c.clr.acq
), then it is performed with
the semantics of an ordered load (
ld.acq
). ALAT register tag lookups by advanced load
checks and check loads are subject to memory ordering constraints as outlined in
“Memory Access Ordering” on page 1:73 .
In addition to the flexibility described above, the size, organization, matching
algorithm, and replacement algorithm of the ALAT are implementation dependent.
Thus, the success or failure of specific advanced loads and checks in a program may
change: when the program is run on different processor implementations, within the
execution of a single program on the same implementation, or between different runs
on the same implementation.
4.4.5.3.2 Invalidating ALAT Entries
In addition to entries removed by advanced loads, ALAT entry invalidations can occur
implicitly by events that alter memory state or explicitly by any of the following
instructions:
ld.c.clr
,
ld.c.clr.acq
,
chk.a.clr
,
invala
,
invala.e
. Events that may
implicitly invalidate ALAT entries include those that change memory state or memory
translation state such as:
1. The execution of stores, semaphores, or
ptc.ga
on other processors in the
coherence domain.
2. The execution of store or semaphore instructions issued on the local processor.
3. Platform-visible removal of a cache line from the processor’s caches.
When one of these events occurs, hardware checks each memory region represented
by an entry in the ALAT to see if it overlaps with the locations affected by the
invalidation event. ALAT entries whose memory regions overlap with the invalidation
event locations are removed. The invalidation of ALAT entries due to the execution of
stores, semaphores or ptc.ga instructions must occur no later in visibility order than the
store of the data or the TLB purge. Note that some invalidation events may require that
multiple entries be removed from the ALAT. For example, the
ptc.ga
instruction is page
aligned, thus a
ptc.ga
from another processor would require that hardware invalidate
all ALAT entries related to that page. Stores due to RSE spills are not checked for ALAT
invalidation and do not cause ALAT entries to be removed. See
Section 6.9, “RSE and
ALAT Interaction” on page 2:146 . When an external agent can observe that the
processor has removed a physical address range from its caches, then that address
range is guaranteed to be invalidated from that processor’s ALAT as well.
An implementation may invalidate entries over areas larger than explicitly required by a
specific invalidation event, and more generally, to invalidate any ALAT entry at any
time. For example, a
st1
only accesses one byte, but an implementation could choose
to invalidate all ALAT entries whose memory region is in the same cache line. An
implementation may also provide an ALAT with zero entries (i.e., all
ld.c
/
chk.a
instructions would act as if an ALAT miss had occurred).
Software is responsible for explicitly invalidating all affected ALAT entries whenever:
1. Software explicitly changes the virtual to physical register mapping on rotating
registers that have been the target of advanced loads (
clrrrb
).
2. Software changes the virtual to physical memory mapping.