SPARC Behavior and Implementation |
B |
![]() |
This appendix has the following organization:
Floating-point Hardware
This section describes details of SPARC implementation of IEEE exceptions. See the SPARC Architecture Manual, Version 8, Appendix N "SPARC IEEE 754 Implementation Recommendations" for a brief description of what happens when a trap is taken, the distinction between trapped and untrapped underflow, and recommended possible courses of action for SPARC implementations that choose to provide non-IEEE (nonstandard) arithmetic mode.
Table B-1 lists the hardware floating-point implementations used by SPARC workstations. Because the SPARC architecture defines the instruction set implemented by a SPARC floating-point unit, the chips differ more in the technology used to construct them than in functionality.
The systems based on SPARC FPUs preceding SuperSPARC, SuperSPARC+ and microSPARC implement the floating-point instruction set defined in the SPARC Architecture Manual Version 7. The systems based on the SuperSPARC, SuperSPARC+ and microSPARC FPUs implement the floating-point instruction set defined in the SPARC Architecture Manual Version 8.
Handling Subnormal Results
On the TI-derived FPUs, a combined ALU and multiplier unit, the ALU wraps subnormal results whether SIGFPE has been enabled or not. (A wrapped number is created by multiplying the correct result by a constant power of two, prior to rounding.) But this wrapped result is never seen by software, because destination registers are never changed when traps occur. The correct subnormal result is computed by system software. The TI 8847 chip can be operated in nonstandard underflow mode, which forces all subnormal inputs and outputs to be flushed to zero without system software intervention. Status and Control Registers
The SPARC FPU has status and control registers associated with it: the floating-point status register (FSR) and the floating-point queue (FQ) set of control registers. Kernel software uses the FQ to recover from floating-point exceptions. Figure B-1 shows the bit assignments of the Floating-Point Status Register.
Figure B-1 SPARC Floating-Point Status Register
The trap enable masks, the bit that indicates nonstandard floating-point, and the exception bits are either on or off. The low-order bit is bit 0.
Handling Floating-point Exceptions
There are two cases when the hardware does not successfully complete a floating-point operation:
If a floating-point exception results in a trap, then the destination floating-point register, the floating-point condition codes, (fcc), and the aexc fields remain unchanged. The cexc field is updated to show which exception caused the trap. (If the trap is caused by an unfinished or unimplemented floating point operation, instead of by one of the IEEE 754 floating point exceptions, then cexc is also unchanged.)
If the exception does not result in a trap, then the destination register, fcc, aexc and cexc are updated to their new values.
The following pseudo-code summarizes the handling of IEEE traps. Note that the aexc field can normally only be cleared by software.
FPop generates an IEEE exception; texc if (texc and TEM) = 0 then(aexc fcc else (cause fp_exception_trap) |
Handling Gradual Underflow
In floating-point environments built on the architecture of some of the SPARC processors (TI TMS390Z5 and TI TMS390S10), and the Intel family, gradually underflowed results are almost always calculated by the floating-point unit in the CPU or coprocessor. Therefore, gradual underflow is much less likely to cause a performance degradation than it is when implemented in software. (For more information about gradual underflow, see the discussion of "Underflow" in Chapter 2, "IEEE Arithmetic," on page 3.)
demo% /bin/time myprog > myprog.output 305.3 real 32.4 user 271.9 sys |
To determine if underflows occurred in an application, you can use the math library function ieee_retrospective to check whether or not the underflow exception flag is raised when the program exits. FORTRAN programs call ieee_retrospective by default and C and C++ programs need to call ieee_retrospective prior to any exit points.
Note: IEEE floating-point exception flags raised: |
C, C++ |
nonstandard_arithmetic(); standard_arithmetic(); |
FORTRAN |
call nonstandard_arithmetic() call standard_arithmetic() |
You should use nonstandard_arithmetic with caution, because it causes the loss of the accuracy benefits of gradual underflow.
Nonstandard Arithmetic and Kernel Emulation (SPARC)
There are several ways to set the FPU to nonstandard mode: compile with
-fast or -fnonstd or invoke nonstandard_arithmetic() from inside the program.
fpversion(1) Function -- Finding Information About the FPU
The utility fpversion(1), distributed with the unbundled compilers, identifies the installed CPU and FPU and estimates their clock speeds.
Note that fpversion is not instantaneous. Indeed, fpversion might take about a minute of user time to run--this is deliberate. fpversion determines the approximate clock rates for the CPU and FPU by timing a loop that executes simple instructions that run in a predictable amount of time.
Floating-Point Hardware--Disable/Enable
It is possible to disable the Floating-Point Unit (FPU) on a SPARC workstation. This might be useful when trying to establish that the FPU is faulty. The probability of faulty hardware is far exceeded by the probability of programming error, and so the following examples should be used with extreme caution.
#!/bin/sh - # script to turn the FPU off # adb -k -w /kernel/unix /dev/mem <<! fpu_exists/W0 ! |
It can be enabled again this way:
#!/bin/sh - # script to turn the FPU on # adb -k -w /kernel/unix /dev/mem <<! fpu_exists/W1 ! |
These scripts can be run in normal multi-user mode without rebooting, but you should avoid running them if any processes that use floating-point instructions are executing.