DRAFT IEEE Standard for Binary Floating-Point Arithmetic - Sonic.net
DRAFT IEEE Standard for Binary Floating-Point Arithmetic - Sonic.net
DRAFT IEEE Standard for Binary Floating-Point Arithmetic - Sonic.net
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>DRAFT</strong> <strong>IEEE</strong> <strong>Standard</strong> <strong>for</strong> <strong>Floating</strong>-<strong>Point</strong> <strong>Arithmetic</strong> – 2003 August 12 10:20<br />
Appendix 8 Traps §TRAP<br />
(This Appendix is not a part of ANSI/<strong>IEEE</strong> Std 754–1985, <strong>IEEE</strong> <strong>Standard</strong> <strong>for</strong> <strong>Floating</strong>-<strong>Point</strong> <strong>Arithmetic</strong>.)<br />
A trap is a change in control flow that occurs as a result of an exception (not all<br />
exceptions trap). Such traps can be used to efficiently implement alternate<br />
exception handling (section 8). This appendix enumerates the minimum<br />
requirements <strong>for</strong> such traps. §TRAP<br />
A user should be able to request a trap on any of the five exceptions by specifying<br />
a handler <strong>for</strong> it. The user he should be able to request that an existing handler be<br />
disabled, saved, or restored. The user heshould also be able to determine<br />
whether a specific trap handler <strong>for</strong> a designated exception has been enabled.<br />
When an exception whose trap is disabled is signaled, it shall be handled in the<br />
manner specified in Section 7. When an exception whose trap is enabled is<br />
signaled the execution of the program in which the exception occurred shall be<br />
suspended, the trap handler previously specified by the user shall be activated,<br />
and a result, if specified in Section 7, shall be delivered to it.<br />
8.1. Trap Handler<br />
A trap handler should have the capabilities of a subroutine that can return a value<br />
to be used in lieu of the exceptional operation's result; this result is undefined<br />
unless delivered by the trap handler. Similarly, the status flag(s) corresponding to<br />
the exceptions being signaled with their associated traps enabled may be<br />
undefined unless raised or lowered set or reset by the trap handler.<br />
When a system traps, the trap handler should be able to determine<br />
1. Which exception(s) occurred on this operation<br />
2. The kind of operation that was being per<strong>for</strong>med<br />
3. The destination's <strong>for</strong>mat<br />
4. In overflow, underflow, and inexact exceptions, the correctly rounded<br />
result, including in<strong>for</strong>mation that might not fit in the destination's <strong>for</strong>mat<br />
5. In invalid operation and divide by zero exceptions, the operand values.<br />
Copyright © 2003 by the Institute of Electrical and Electronics Engineers, Inc. This document is an unapproved<br />
draft of a proposed <strong>IEEE</strong>-SA <strong>Standard</strong> - USE AT YOUR OWN RISK. See statement on page 1.<br />
Page 66