Browse Prior Art Database

Method to Keep History of IEEE Floating Point Exception Flags

IP.com Disclosure Number: IPCOM000107178D
Original Publication Date: 1992-Jan-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 2 page(s) / 91K

Publishing Venue

IBM

Related People

Linam, S: AUTHOR [+3]

Abstract

Described is one way of keeping a `history', or record of all floating point exceptions that an application has generated during its execution.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Method to Keep History of IEEE Floating Point Exception Flags

       Described is one way of keeping a `history', or record of
all floating point exceptions that an application has generated
during its execution.

      The IEEE-754 floating point standard was invented to provide
for a common floating point representation for all machines, rather
than have each invent its own.

      The standard states that it should be possible for an
application program to detect the occurrence of certain exceptional
conditions, such as - invalid operation, divide by zero, underflow,
overflow, and inexact result, by explicitly examining status, or,
optionally, via a trap mechanism.

      In particular, an application should have the capability to
determine upon execution of an instruction, whether or not that
instruction caused an IEEE exception or not. Also, the application
should be able to determine whether any exception has EVER occurred
during its execution, and if so, which one(s).
PROBLEM

      Most hardware implementations that support IEEE-754, implement
only ONE floating point status register, which keeps a summary of all
the exceptions that have occurred since the register was last
cleared.

      This, by itself, allows an application to determine if an
exception EVER occurred; it, however, does not, without software
assistance, provide a mechanism for allowing the application to
determine what exception a particular instruction generated.

      Consider the case where an application has been executing
floating point operations, some of which have set the
'inexact-result' exception flag. This flag will remain set until
cleared. If the application wishes to determine if a particular
future instruction generates an inexact result, it must first clear
the inexact result flag in the status register, so that it can tell
if something sets it again. It should be pointed out, that the
mechanism for detecting whether a particular instruction caused a
trap or not is irrelevant to this discussion---the mechanism could be
a floating point exception, or an explicit poll of the logical
hardware status register.

      If the application also wants, at the end of its execution, to
know what IEEE-754 exceptions occurred when it ran, it will have to
remember that...