Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS VOLUME 3 REV 2.3, Manual

Page: 799 / 1898

Volume 2, Part 2: Context Management 2:551
4.1.2 Preserving Floating-point Registers
The Itanium architecture encodes a floating-point register’s control speculative state as
a special unnormalized floating-point number called NaTVal. As a result, Itanium
floating-point registers do not have a NaT bit. The architecture provides the
stf.spill
and
ldf.fill
instructions to save and restore floating-point register values and control
speculative state. These instructions always generate a 16-byte memory image
regardless of the precision of the floating-point number contained in the register.
Preservation of data speculative state associated with floating-point registers needs to
be managed by software. As with the general registers, software is required to explicitly
invalidate a register’s ALAT entry using the
invala.e
instruction when restoring a
floating-point register. The Itanium calling conventions avoid such explicit ALAT
invalidations by disallowing data speculation to preserved floating-point registers
(FR2-5, FR16-31) across procedure calls.
4.2 Preserving Register State in the OS
The software calling conventions described in the previous section apply to state
preservation across procedure call boundaries. When entering the operating system
kernel either voluntarily (for a system call) or involuntarily (for handling an exception or
an external interrupt) additional concerns arise because the interrupted user’s context
needs to be preserved in its entirety.
The Itanium architecture defines a large register set: 128 general registers and 128
floating-point registers account for approximately 1 KByte and 2 KBytes of state,
respectively. The architecture provides a variety of mechanisms to reduce the amount
of state preservation that is needed on commonly executed code paths such as system
calls and high frequency exceptions such as TLB miss handlers.
Additionally, Itanium architecture-based operating systems have opportunities to
reduce the amount of context they need to save by distinguishing various kernel entry
and exit points. For instance, when entering the kernel on behalf of a voluntary system
call, the kernel need only preserve registers as outlined by the calling conventions.
Furthermore, the operating system can be sensitive to whether the preserved context is
coming from the IA-32 or Itanium instruction set, especially since the IA-32 register
context is substantially smaller than the full Itanium register set. Ideally, an Itanium
architecture-based operating system should use a single state storage structure which
contains a field that indicates the amount of populated state.
Table 4-2 summarizes several key operating system points at which state preservation
is needed.
Scratch GRs and FRs, the bulk of all state, only need to be preserved at involuntary
interruptions resulting from unexpected external interrupts or from exceptions that
need to call code written in a high-level programming language. The demarcation of
floating-point registers FR32-127 as “scratch” along with architectural support for lazy
state save/restore of the floating-point register file allows software to substantially
reduce the overhead of preserving the scratch FRs. See
Section 4.2.2 for details.