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

7.4 Long Branch
The Itanium architecture supports "long" branches with a 64-bit offset. This provides
IP-relative conditional- and call-type branches that can reach any address in a 64-bit
address space. These instructions use the MLX template, and similar to the move long
instruction (movl), they encode their immediate in the L and the X slot of the bundle.
The Intel Itanium processor does not support the long branch instruction, brl, and
requires the operating system to emulate its behavior. When an Itanium processor
encounters a brl instruction, it vectors to the Illegal Operation Fault handler,
regardless of the branches' qualifying predicate. This handler is expected to emulate
the long branch instruction in software. A general outline of the long branch emulation
handler is as follows:
• The emulation handler reads the IIP, IPSR, and predicates at the time of the fault.
• If the fault occurred in IA-32 code or if the fault did not occur in slot 2 of a bundle
(IPSR.ri is not 2), the handler passes the fault to regular illegal operation fault
handler.
• Two floating-point registers are spilled into the integer register file to get ready to
load the bundle.
• The emulation handler speculatively loads the 128-bit bundle at the faulting IP
using the integer form of the floating-point load pair instruction. This instruction is
chosen because it operates atomically (see
and Atomicity"). Using two 64-bit integer loads would require the handler to ensure
that another agent does not update the bundle between the two reads.
• If the speculation fails, the recovery code re-issues the load. Before re-issuing an
architectural load, the processor must first re-enable PSR.ic to be able to handle
potential TLB misses when reading the opcode from memory. In other words, this
becomes a heavyweight handler. For details see
Interruptions" on page
successfully flow of the emulation continues at the next step.
• The 128-bit bundle is moved from the FP register file into two integer registers and
the FP registers are restored to their contents at the time of the fault.
• The handler extracts the fields necessary to decode the instruction (specifically, the
qp, template, major opcode, and btype or b
value of the qualifying predicate of the instruction in slot 2 from the contents of the
predicate register at the time of the fault. Itanium instruction are always stored in
memory in little-endian memory format. When extracting bit fields from the loaded
opcode current processor endianness (PSR.be) must be taken into account.
• The emulation handler passes the fault off to the regular illegal operation fault
handler if the bundle is not an MLX or if the faulting instruction is not a brl.cond or
brl.call.
• If the faulting instruction is a not-taken brl.cond or brl.call, the code prepares
to change the IIP to the address of the sequential successor of the faulting branch
(i.e. IIP + 16) and jumps ahead to the trap detection code mentioned below.
• If the faulting instruction is a taken brl.call, the handler emulates the
appropriate behavior of the call. The code uses a br.call to move the appropriate
values into CFM and AR[PFS]. There are several details, however. First, the branch
register update from the call must be backed out (as it is not the correct update for
the brl.call). Second, AR[PFS].ppl must be set based on the cpl at the time of the
fault (which is given by IPSR.cpl). Finally, the code must update the branch register
Volume 2, Part 2: Instruction Emulation and Other Fault Handlers
Section 4.5, "Memory Datum Alignment
2:544. Once the opcode has been read from memory
fields of slot 2). It also determines the
1
Section 3.4.2, "Heavyweight
2:585