by Jeanne Adams
F ortran 95 is currently in balloting phase as a draft international standard. This standard will be published in 1996 or 1997. Another draft standard (Fortran 2000) is in progress, planned for release early in the next century.
In the interim between standards, the user community expressses needs for various features they want in Fortran. To respond to these needs, the international working group on Fortran has established a plan for "technical reports" to be released between formal standards. These reports are auxiliary to the current Fortran standard, and the features that are approved will be included in the next draft standard. This will allow those features to be available for use in the interim between standards, before the next draft standard is released.
The following topics are in various stages of development for release as technical reports in the international community:
This article discusses various aspects of the exception-handling technical report, while the other two reports will be discussed in subsequent articles.
- Exception handling
- Allocatable components and dummy arguments
- Interoperability with C
Many users of Fortran 90/95 employ numerical techniques to solve programming problems. These users are physicists and engineers who rely on robust numerical software for their results. However, current Fortran does not provide a means in the standard for handling exceptions such as division by zero and other floating-point exceptions.
Instead, if there are any mechanisms, they are provided in a variety of forms by vendors and the suppliers of library software. When many different options (or possibly no options) are used to handle exceptions, especially in floating-point arithmetic, there is little possibility of generating programs that are portable. If a floating-point overflow occurs, for example, the program may stop with an error, print a message and stop, or print a message and continue, depending on the vendor software.
The Institute of Electrical and Electronics Engineers (IEEE) has provided a standard for floating-point arithmetic, IEEE 754-1985, and has built into it five floating-point exceptions:
The standard also includes a flag for rounding mode (nearest, up, down, to zero) and flags for stopping when an exception does occur. These flags may be either software- or hardware-generated.
- Invalid operation
For compilers that do not support the IEEE arithmetic standard, the plan for exception handling is to require support only of overflow and divide-by-zero in Fortran.
Fortran experts from the European community have been lobbying for exception handling for more than ten years. In fact, as early as 1980, members were sent to meetings of X3J3 (the U.S. Fortran standards committee) with proposals they wanted for "Fortran 88." The members of X3J3 could not reach an agreement and rejected the proposals at that time as too complex.
More recently, two new approaches have been considered. One was to introduce a new construct (ENABLE) and all that it required into the language. The approach was to offer a considerably simplified version of the ENABLE construct proposal that had the possibility of extension in the future. This approach has general support for the long term. However, X3J3 rejected this for Fortran 95 in a formal ballot and the international community agreed to discontinue work on it because it was felt that it would slow progress on the completion of Fortran 95.
The other approach, discussed in this article, was to use a set of intrinsic procedures. This approach was approved at the international meeting in 1995, where participants felt that handling at least the IEEE floating-point exceptions was too important to delay any further in the Fortran standardization process. Both the ENABLE construct approach and the set of intrinsic procedures are compatible, and can be included side by side in a future standard.
The technical report using the set of intrinsic procedures is expected to be approved at the international meeting held in Germany in July. It should be available officially by the end of 1996.
At this time, only the five floating-point exceptions mentioned above are proposed for the intrinsic-procedure technical report and the Fortran 2000 standard. Other conditions, such as insufficient storage or integer overflow, might be included in future exception-handling facilities.
The intrinsic-procedure proposal uses modules and derived types (new features in Fortran 90/95) in its definition. It also include facilities to permit vendors to provide more than one level of support, to avoid unwanted features that might cause a loss of efficient execution.
The intrinsic-procedure proposal includes four new data types, plus exceptions:
- IEEE-FLAG-TYPE is a derived type for identifying a particular exception flag.
- IEEE-CLASS-TYPE is used to identify values such as NANS, normal, and infinity.
- IEEE-ROUND-TYPE is used to identify a particular rounding type, nearest, to zero, up, down, and other.
- IEEE-STATUS-TYPE saves the current floating-point status.
- Exceptions. The intrinsic-procedure proposal includes two elemental subroutines as processing flags for conditions or exceptions:
The flags are initially not set. The get flag routine returns with the status of the flag and the set flag routine establishes a value for the flag.
A "halting mode" can also be established by using either of the following two routines, which determine whether the program stops on an exception or continues:
Two nonelemental subroutines provide control to the program on rounding conventions:
The rounding conventions are nearest, to zero, up, down, and other.
There are also two routines that establish the status of exceptions in the floating-point environment:
The proposal also includes ten inquiry functions that return true or false for determining if the processor supports various features of the IEEE standard for exception handling and rounding.
You can obtain the draft technical report with all the details of procedures, flags, data types, and inquiry functions from Jeanne Adams (303-497-1275, firstname.lastname@example.org). Your comments on this report are welcome.
Here is a simple example taken from Reid's article (cited below) for matrix inversion using in-line code.
CALL IEEE_GET_FLAG (FLAGS, FLAG_VALUES) IF (ANY(FLAG_VALUES)) RETURN : CALL IEEE-GET-FLAG (FLAGS, FLAG_VALUES) IF (.NOT.ANY (FLAG_VALUES)) THEN DO K = 1, N : CALL IEEE_GET_FLAG (FLAGS, FLAG_VALUES) IF (ANY(FLAG_VALUES)) EXIT END DO END IF IF (ANY(FLAG_VALUES)) THEN !Alternative code which knows that K-1 steps have executed normally. :
The intrinsic-procedures approach, as this example makes clear, is easier to understand and use than the ENABLE approach, which has a "handler" for exceptions.