Filter
Top Products
Alpha 21264/EV67 Hardware Reference Manual
PALcode Restrictions and Guidelines D–11
Restriction 11: Ibox IPR Update Synchronization
D.8 Restriction 11: Ibox IPR Update Synchronization
When updating any Ibox IPR, a return to native (virtual) mode should use the HW_RET
instruction with the associated STALL bit set to ensure that the updated IPR value
affects all instructions following the return path. The new IPR value takes effect only
after the associated HW_MTPR instruction is retired.
For update to some IPR fields with propagation delay, such as I_CTL[SDE] and
PCTX[FPE], synchronization as described in Section D.32 is the preferred method of
synchronization.
D.9 Restriction 12: MFPR of Implicitly-Written IPRs EXC_ADDR,
IVA_FORM, and EXC_SUM
Implicitly written IPRs are non-renamed hardware registers that must be available for
subsequent traps. After any trap to PALcode, hardware protects the values from a sec-
ond implicit write by locking these registers and delaying subsequent traps for a safe
(limited time). Their values can be read reliably by a HW_MFPR within the first four
instructions of a PALcode flow and prior to any taken branch in that PALcode flow,
whichever is earlier. These instructions should not include PALmode trapping instruc-
tions. After the delimiting instruction defined above retires, these registers are unlocked
and may change due to new exception conditions.
If a second exception occurs before the registers are unlocked, it will be either delayed
or forced to replay trap (a non-PALmode trap) until the register has been unlocked.
After being unlocked, a subsequent new path exception condition will be allowed to
reload the register and trap to PALcode. The 21264/EV67 may complete execution of
the first PALcode flow, encountering the second exception condition before the delimit-
ing instruction is retired, hence the need for the locking mechanism to ensure visibility
of the initial register value.
The VA_FORM, VA, and MM_STAT registers are not included in this list of protected
IPRS. See Section D.24 for a description of how to protect these IPRs from subsequent
implicit writers.
D.10 Restriction 13 : DTB Fill Flow Collision
Two DTB fill flows might collide such that the HW_MTPR’s in the second fill could be
issued before all of the HW_MTPR’s in the first PALcode flow are retired. This can be
prevented by putting appropriate software scoreboard barriers in the PALcode flow.
D.11 Restriction 14 : HW_RET
There can be no HW_RET in the first fetch block of a PALcode routine, other
than CALL_PAL routines. With a HW_RET in the first fetch block of a PALcode rou-
tine, the HW_RET will be mispredicted and the JSR/RETURN stack could lose its syn-
chronization.