John R. Hauser

EECS Department
University of California, Berkeley
Technical Report No. UCB/CSD-95-870
March 1995

http://www2.eecs.berkeley.edu/Pubs/TechRpts/1995/CSD-95-870.pdf

There are a number of different schemes for handling arithmetic exceptions that can be used to improve the speed (or alternatively the reliability) of numeric code, sometimes substantially. Which scheme is best for a particular exception depends on the context of the calculation in which it occurs. Overflow and underflow are the most troublesome exceptions and correspondingly have the largest set of options. Depending on the context, overflow and underflow exceptions may be addressed either: (1) through a "brute force" re-evaluation with extended range, (2) by re-evaluating using a technique known as scaling, (3) by substituting an infinity or zero, or (4) in the case of underflow, with gradual underflow. In the first two of these cases, the offending computation is simply re-evaluated using a safer but slower method. Explicit exception handling is used to avoid the extra cost of the safer method when it is not needed. The latter two cases are cheaper, more automated schemes that ideally are built in as options within the computer system. Other arithmetic exceptions can also be handled with methods that look similar to these. For instance, for "division by zero" exceptions, the best response typically is to return an infinity value.

This paper examines these and some other techniques with an eye toward determining the support programming languages and computer systems ought to provide for floating-point exception handling. It is argued that the cheapest short­-term solution would be to give full support to most of the required (as opposed to recommended) special features of the IEEE Standard for Binary Floating-Point Arithmetic. An essential part of this support would include standardized access from high-level languages to the exception flags defined by the standard. These flags have existed in the hardware of most computer systems for several years, but cannot yet be utilized by portable programs. Some possibilities outside the IEEE Standard are also considered, and at least a couple of ideas on possible better-structured support within programming languages are presented.

BibTeX citation:

@techreport{Hauser:CSD-95-870,
    Author = {Hauser, John R.},
    Title = {Handling Floating-point Exceptions in Numeric Programs},
    Institution = {EECS Department, University of California, Berkeley},
    Year = {1995},
    Month = {Mar},
    URL = {http://www2.eecs.berkeley.edu/Pubs/TechRpts/1995/5594.html},
    Number = {UCB/CSD-95-870},
    Abstract = {There are a number of different schemes for handling arithmetic exceptions that can be used to improve the speed (or alternatively the reliability) of numeric code, sometimes substantially.  Which scheme is best for a particular exception depends on the context of the calculation in which it occurs. Overflow and underflow are the most troublesome exceptions and correspondingly have the largest set of options. Depending on the context, overflow and underflow exceptions may be addressed either: (1) through a "brute force" re-evaluation with extended range, (2) by re-evaluating using a technique known as scaling, (3) by substituting an infinity or zero, or (4) in the case of underflow, with gradual underflow. In the first two of these cases, the offending computation is simply re-evaluated using a safer but slower method. Explicit exception handling is used to avoid the extra cost of the safer method when it is not needed. The latter two cases are cheaper, more automated schemes that ideally are built in as options within the computer system. Other arithmetic exceptions can also be handled with methods that look similar to these. For instance, for "division by zero" exceptions, the best response typically is to return an infinity value.  <p>This paper examines these and some other techniques with an eye toward determining the support programming languages and computer systems ought to provide for floating-point exception handling. It is argued that the cheapest short­-term solution would be to give full support to most of the required (as opposed to recommended) special features of the IEEE Standard for Binary Floating-Point Arithmetic. An essential part of this support would include standardized access from high-level languages to the exception flags defined by the standard. These flags have existed in the hardware of most computer systems for several years, but cannot yet be utilized by portable programs. Some possibilities outside the IEEE Standard are also considered, and at least a couple of ideas on possible better-structured support within programming languages are presented.}
}

EndNote citation:

%0 Report
%A Hauser, John R.
%T Handling Floating-point Exceptions in Numeric Programs
%I EECS Department, University of California, Berkeley
%D 1995
%@ UCB/CSD-95-870
%U http://www2.eecs.berkeley.edu/Pubs/TechRpts/1995/5594.html
%F Hauser:CSD-95-870