Exception Handling in Chips

Background

The purpose of this webpage is to accumulate and disseminate information about the exception handling in currently available "comodity" chips. For my purpose, a comodity chip is one that is produced in sufficient quantity that more than one "secret" application is known.

A bit of background. As is probably known to you, William Kahan of Berkeley has led the fight for a floating point standard. This is IEEE Standard 754 (binary) and IEEE Standard 854 (decimal). A good general introduction is Goldberg's "What Every Computer Scientists Should Know About Floating Point". This is available on Sun's documentation website: doc.sun.com. It is also available in Computing Surveys, 1991. The Standard describes many things, including a standard set of exceptions that must be available.

Not so amazingly, chip manufacturers have not rushed right out to implement the standard. For example, the x86 chips have a "denormalization" exception and an "inexact"; the semantics of denormalization are not immediately obvious.

Something that is amazing, however, is the cavalier attitudes toward integer exceptions. This has been tossed around in the "arithmetic" community but is not so widely understood by the general programmer. The following quote is from Sun's documentation site:

.... Integer division by zero (FPE_INTDIV) and integer overflow (FPE_INTOVF) are also included among the SIGFPE types, but because they are not IEEE floating point exceptions you cannot install handlers for them via ieee_handler. (You can install handlers for these SIGFPE types via sigfpe(3); note, though, that integer division by zero is either ignored or generates SIGILL on PowerPC systems, and integer overflow is ignored on all SPARC, Intel, and PowerPC systems. On SPARC and Intel systems, special instructions can cause the delivery of a SIGFPE signal of type FPE_INTOVF, but Sun compilers do not generate these instructions.)
This is clearly lunacy!

The Survey

The survey, then, is to determine how chips support the IEEE floating point exceptions and how they support a "reasonable" set of integer exceptions. For the record, the floating point exceptions are
  1. Invalid Instruction

  2. Overflow

  3. Underflow

  4. Divide by Zero

  5. Inexact Result

There is, for some (I'm sure rational) reason, no standard integer exceptions. However, it seems reasonable that there be at least two:
  1. Overflow

  2. Divide by Zero

In the table below, "floating-point compliance" means having exactly the five listed exceptions and "integer compliance" means having exactly the two listed. Chips can comply or not comply in lots of ways. I'll worry about how they do/do not comply after I see what the possible ideas are.

If you know a chip not on this list, won't you please send me email with the characteristics?

Steve Stevenson

Floating Point Compliance
ManufacturerDesignationCompliant?Remarks
Sun Ultra Yes
Intel x86 No Extras
Motorola PowerPC Yes fpscr register
DEC Alpha Very messy
QED MIPS R4600 YesSold By IDT, NKK, Toishiba
QED MIPS R4700 Yes
QED MIPS R4640 Yes Sold By IDT, NKK, Toishiba
QED MIPS R4650 Yes Sold By IDT, NKK, Toishiba
QED MIPS R5000 Yes Sold By IDT, NKK, Toishiba
QED MIPS RM52xx Yes
QED MIPS RM7000 Yes

Integer Compliance
ManufacturerDesignationCompliant?Remarks
Sun Ultra Conditionally
Intel x86 Conditionally
Motorola PowerPC Overflow No 0 divide
ARM C No Flag state only
QED MIPS R4600 No divby2Sold By IDT, NKK, Toishiba
QED MIPS R4700 No divby2
QED MIPS R4640 No divby2 Sold By IDT, NKK, Toishiba
QED MIPS R4650 No divby2 Sold By IDT, NKK, Toishiba
QED MIPS R5000 No divby2 Sold By IDT, NKK, Toishiba
QED MIPS RM52xx No divby2
QED MIPS RM7000 No divby2

Last modified: Wed Aug 5 10:50:15 EDT 1998