Compaq EV67 User Manual

PALcode Restrictions and Guidelines

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.

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.

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.

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.