Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS VOLUME 3 REV 2.3, Руководство пользователя

Страница: 833 / 1898

Volume 2, Part 2: Instruction Emulation and Other Fault Handlers 2:585
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
Section 4.5, “Memory Datum Alignment
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
Section 3.4.2, “Heavyweight
Interruptions” on page 2:544 . Once the opcode has been read from memory
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
1
fields of slot 2). It also determines the
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