HP Pascal/iX Programmer's Guide (31502-90023)
11- 13
numbers have the format of reals on the MPE V system. The compiler
options HP3000_32 and HP3000_16 specify native and compatibility
Mode real numbers, respectively. For more information on HP3000_32
and HP3000_16, see the
HP Pascal/iX Reference Manual
or the
HP
Pascal/HP-UX Reference Manual
, depending on your implementation.
The user's trap handler must be declared this way:
TYPE
TrapInfo= RECORD
Instruction : integer; {the actual instruction word that
caused the arithmetic trap}
PC_Offset : integer; {offset of the above instruction
within the user's code space}
PC_Space : integer; {space id of user's code space}
Error_Code : integer; {Trap type. This word is formed
by setting the bit corresponding
to the trap condition in a 32-bit
integer, with all other bits zero.
More than 1 bit will be turned on
if multiple traps occur together}
{more fields are returned for certain of the trap conditions.
See below for details}
END;
PROCEDURE My_Arith_Trap_Handler (VAR Info : TrapInfo );
BEGIN {My_Arith_Trap_Handler}
.
.
.
END; {My_Arith_Trap_Handler}
To enable (for example) all integer and IEEE floating-point traps, as
well as all pointer traps, call XARITRAP this way:
XARITRAP (
{bit 0 1 2 3 }
{ 01234567890123456789012345678901}
Binary ('00000000001111111000000000010010'),
BAddress (My_Arith_Trap_Handler),
OldMask,
OldPLabel
);
NOTE In the preceding example, the IEEE inexact result trap is not
enabled.
HP Precision Architecture has only three distinct hardware
arithmetic trap conditions:
condition,
[integer]
overflow,
and
assist exception
(IEEE floating-point traps are in the last
category). The system is able to categorize most integer and
decimal traps (except integer overflow) because each category has
its own unique trapping instructions. If a condition trap occurs,
and the system cannot categorize it,
unimplemented condition trap
(bit 9) is raised.
The
IEEE inexact result trap
(bit 17), a trap required by the IEEE
floating-point standard, indicates that a floating-point operation
may have caused an inexact result (for example, the result of
10.0/3.0 is 3.333... regardless of the number of bits of precision
you use). This trap is useful only for specialty number-crunching
programs. Indiscriminate arming of this trap can severely degrade
program performance, because almost any floating-point operation