Filter
Top Products
26
SPARC JPS1 Implementation Supplement:
Fujitsu SPARC64 V
• Release 1.0, 1 July 2002
1. If a memory operation y resolves to a volatile memory address (location[y]),
SPARC64 V will not speculatively prefetch location[y] for any reason; location[y]
will be fetched or stored to only when operation y is commitable.
2. If a memory operation y resolves to a nonvolatile memory address (location[y]),
SPARC64 V may speculatively prefetch location[y] subject, adhering to the
following subrules:
a. If an operation y can be speculatively prefetched according to the prior rule,
operations with store semantics are speculatively prefetched for ownership
only if they are prefetched to cacheable locations. Operations without store
semantics are speculatively prefetched even if they are noncacheable as long as
they are not volatile.
b. Atomic operations (CAS(X)A, LDSTUB, SWAP) are never speculatively
prefetched.
SPARC64 V provides two mechanisms to avoid speculative execution of a load:
1. Avoid speculation by disallowing speculative accesses to certain memory pages or
I/O spaces.
This can be done by setting the E (side-effect) bit in the PTE for all
memory pages that should not allow speculation. All accesses made to memory
pages that have the E bit set in their PTE will be delayed until they are no longer
speculative or until they are cancelled
.
See Appendix F, Memory Management Unit,
for details.
2. Alternate space load instructions that force program order, such as
ASI_PHYS_BYPASS_WITH_EBIT[_L] (AS I = 15
16
, 1D
16
), will not be speculatively
executed.
6.1.2 Instruction Prefetch
The processor prefetches instructions to minimize cases where the processor must
wait for instruction fetch. In combination with branch prediction, prefetching may
cause the processor to access instructions that are not subsequently executed. In
some cases, the speculative instruction accesses will reference data pages.
SPARC64 V does not generate a trap for any exception that is caused by an
instruction fetch until all of the instructions before it (in program order) have been
committed.
1
1. Hardware errors and other asynchronous errors may generate a trap even if the instruction that caused the
trap is never committed.