[ Marquette | MSCS | Corliss | Vladik's Intervals ]
Interval FAQ: [ Entry page | Contents | Search ]
About Sun's f95 with Interval Support

Interval FAQ
Alejandro Casares -- What machines support IEEE 754?

From Alejandro Casares (ACASARES@puceuio.puce.edu.ec):

What machines support IEEE 754?

Could you tell me approximately how many (in percentage) actual computers conform themselves to the IEEE 754 floating point representation norm? Are there some known kinds of machines - ad es., supercomputers, which do not adhere to that standard?

Alejandro Casares

Response by R. Baker Kearfott:

(rbk@usl.edu), University of Southwestern Louisiana:

Intel-based machines except for flawed pentiums :-) have circuitry for conforming to the standard. All Sun machines have such circuitry, and, for the most part, Unix-based workstations do.

Some notorious older machines that do not conform are older Cray mainframes and IBM mainframes. However, the IBM mainframes, although having hexadecimal arithmetic, have an arithmetic that in many respects satisfies the spirit of IEEE. The older Cray mainframes have particularly bad arithmetic in the sense of IEEE.

When you look at every attribute specified in IEEE, it becomes somewhat more complicated. In particular, IEEE specifies the accuracy of binary-to-decimal and decimal-to-binary conversions. Such conversions occur, for example, when formatting a floating point number for printing. Because of this, conformance to the standard is tied to the compiler. A number of compilers do not have good binary to decimal conversion, in the sense of IEEE. In other words, on those compilers, "what you get is not what you see." (Incidentally, the Fortran 2000 standard will have a function that queries whether the processor conforms to IEEE. It also will have functions to access IEEE operations, such as setting the roundoff mode.)

Best regards,
R. Baker Kearfott

Response by Nelson H. F. Beebe:

(beebe@math.utah.edu), Department of Mathematics, University of Utah:

Because of the large installed base of Intel x86 processors, the answer is: almost 100%, if you simply count CPUs with floating-point hardware.

The major floating-point architectures on today's market are:

        IEEE 754:       Intel x86, and all RISC systems (IBM Power
                        and PowerPC, Compaq/DEC Alpha, HP PA-RISC,
                        Motorola 68xxx and 88xxx, SGI (MIPS) R-xxxx,
                        Sun SPARC, and others);

        VAX:            Compaq/DEC

        IBM S/390:      IBM (however, in 1998, IBM added an IEEE 754
                        option to S/390; see below)

        Cray:           X-MP, Y-MP, C-90; other Cray models have been
                        based on Alpha and SPARC processors with
                        IEEE-754 arithmetic.

However, there are many issues of how strict IEEE 754 compliance is.

Some vendors implement the standard entirely in hardware (IBM and Intel), others in a combination of hardware and software (all non-IBM RISC systems), and at least one entirely in software (Apple SANE (Standard Apple Numeric Environment) on older Macintoshes).

Compaq/DEC Alpha by default does not adhere to IEEE 754 requirements: overflow and invalid operands (NaNs) terminate the job. Compiler options can be given to choose IEEE 754 conformance, but there is then a significant run-time penalty because of the need to insert trap barrier instructions that flush the instruction pipeline, so that trapping instructions can be precisely identified, and the exception handled in software. The latest Alpha chip, the 21264, provides full hardware support for IEEE 754 (see \cite{Kessler:1999:AM} below).

Rounding mode control, which is essential for efficient interval arithmetic implementation, is absent from some systems (and from the Java programming language, which otherwise requires IEEE 754 arithmetic).

On all systems with partial software implementations, there can be a severe performance hit to handle underflows (gradual or flush-to-zero), overflows, and invalid operands. Benchmarkers must be aware of these issues.

Several vendors now follow IBM's lead from the 1990 Power architecture in offering multiply-add instructions that offer higher performance, and higher accuracy: a*b + c is computed by evaluating a*b exactly (i.e., to 2N bits), then the addition of c is made, also to 2N bits, and finally, the result is rounded to N bits. This has been shown to be exceedingly useful in careful numerical analysis, and serendipitously, provides a 2x flops rate improvement. However, it means that there will be even larger differences in accuracy between platforms. Most compilers on such systems provide a flag to suppress the use of such instructions.

Intel, alone of all the vendors cited above, does its arithmetic with the IEEE-recommended 80-bit temporary real format. Rounding to 64-bit and 32-bit values happens only in register-to-memory transfers (and consequently, suffers a severe performance penalty (10x to 100x) for a round-trip to and from memory if 64-bit rounding is needed).

The AMD K-7 (an Intel x86 compliant system) uses 80-bit temporary real format, but does much of its internal work with even longer precision (see \cite{Oberman:1999:FPD} below), in order to produce correctly-rounded results.

Several RISC architectures do all arithmetic in 64-bit mode, converting to and from 32-bit values during memory transfers as needed. The Java language forbids use of longer intermediate precision (including multiply-add instructions), a decision that raised so much debate that the language designers are reexamining Java's floating-point specification. These precision differences in intermediate values contribute further to accuracy differences between platforms.

The waters are even more muddied by the introduced of `multimedia instruction sets' from most of the cited vendors in recent processor offerings. Some of these have 32-bit floating-point in the IEEE-754 format, but without gradual underflow, NaN, and infinity. Because these instructions can do 2 to 8 flops in parallel, compilers will begin to use them for performance reasons, but then there will be even more variance from IEEE 754 requirements.

The IEEE 754 standard requires correct rounding, in one of four modes (to nearest, +infinity, -infinity, and zero), yet not all vendors strictly conform. At least one (Compaq/DEC Alpha) normally provides only a compile-time choice of rounding mode; you have to specify an additional compiler option to get dynamic rounding (presumably because there is a performance hit for doing so).

The Intel/HP IA-64 architecture (codenamed Merced) is reported (\cite{Story:1999:NAI}: see below) to produce results for the transcendental function primitives (not part of the IEEE 754 standard) which are accurate to less that 0.6 ulp (compared to Intel Pentium, which reaches only 1 ulp); the paper goes on to note ``Since these functions do not always yield a correctly-rounded value, invoking them twice under two directed rounding modes does not always produce an interval that includes the true mathematical value.'' That point should be of considerable importance to readers of this list, since the evolutionary path for the 250M+ Intel x86-based desktops world wide is to IA-64, and interval arithmetic deserves to have increasing importance in scientific computation.

For more information on the current state of floating-point arithmetic, see papers from the ARITH conference series, many of which are recorded in


The two Swartzlander reprint volumes there contain many historically important papers.

The IBM S/390 paper from the 1999 ARITH-14 meeting is:

  author =       "E. M. Schwarz and R. M. Smith and C. A. Krygowski",
  title =        "The {S/390 G5} Floating Point Unit Supporting Hex and
                 Binary Architectures",
  crossref =     "Koren:1999:ISC",
  pages =        "258--265",
  year =         "1999",
  bibdate =      "Mon Feb 7 07:28:26 MST 2000",
  URL =          "http://euler.ecs.umass.edu/paper/final/paper-112.ps;
  acknowledgement = ack-nhfb,
  keywords =     "computer arithmetic; ARITH; IEEE",

  author =       "S. F. Oberman",
  title =        "Floating Point Division and Square Root Algorithms and
                 Implementation in the {AMD-K7[TM]} Microprocessor",
  crossref =     "Koren:1999:ISC",
  pages =        "106--115",
  year =         "1999",
  bibdate =      "Mon Feb 7 07:28:26 MST 2000",
  URL =          "http://euler.ecs.umass.edu/paper/final/paper-139.ps;
  acknowledgement = ack-nhfb,
  keywords =     "computer arithmetic; ARITH; IEEE",

  author =       "S. Story and P. T. P. Tang",
  title =        "New Algorithms for Improved Transcendental Functions
                 on {IA-64}",
  crossref =     "Koren:1999:ISC",
  pages =        "4--11",
  year =         "1999",
  bibdate =      "Mon Feb 7 07:28:26 MST 2000",
  URL =          "http://euler.ecs.umass.edu/paper/final/paper-118.ps;
  acknowledgement = ack-nhfb,
  keywords =     "computer arithmetic; ARITH; IEEE",

  editor =       "Israel Koren and Peter Kornerup",
  booktitle =    "14th IEEE Symposium on Computer Arithmetic:
                 proceedings: April 14--16, 1999, Adelaide, Australia",
  title =        "14th {IEEE} Symposium on Computer Arithmetic:
                 proceedings: April 14--16, 1999, Adelaide, Australia",
  publisher =    pub-IEEE,
  address =      pub-IEEE:adr,
  pages =        "xi + 274",
  year =         "1999",
  ISBN =         "0-7803-5609-8, 0-7695-0116-8, 0-7695-0118-4",
  ISSN =         "1063-6889",
  LCCN =         "QA76.6 .S887 1999",
  bibdate =      "Mon Feb 7 07:28:26 MST 2000",
  note =         "IEEE Computer Society Order Number PR00116. IEEE Order
                 Plan Catalog Number 99CB36336.",
  URL =          "http://computer.org/conferen/home/arith/;
  acknowledgement = ack-nhfb,
  annote =       "Also known as ARITH-14.",
  source =       "Computer arithmetic",
  sponsor =      "IEEE.",

  author =       "R. E. Kessler",
  title =        "The {Alpha 21264} Microprocessor",
  journal =      j-IEEE-MICRO,
  volume =       "19",
  number =       "2",
  pages =        "24--36",
  month =        mar # "\slash " # apr,
  year =         "1999",
  CODEN =        "IEMIDZ",
  ISSN =         "0272-1732",
  bibsource =    "http://www.computer.org/micro/mi1999/",
  URL =          "http://www.computer.org/micro/mi1999/m2024abs.htm;
  acknowledgement = ack-nhfb,
  bibdate =      "Fri Apr 2 09:14:32 MST 1999",
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- Center for Scientific Computing       FAX: +1 801 585 1640, +1 801 581 4148 -
- University of Utah                    Internet e-mail: beebe@math.utah.edu  -
- Department of Mathematics, 322 INSCC                   beebe@acm.org        -
- 155 S 1400 E RM 233                                    beebe@ieee.org       -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -

Response by Marc Daumas:

(Marc.Daumas@ENS-Lyon.Fr), Charge de recherches au CNRS (LIP - ENS de Lyon):

It is interesting to know that some systems / applications are shipped with denorm un-activated as this is the case in a network of DEC Alpha 21164 clusters operating at the University of Lyon, France. This situation is difficult to understand since the user assumes that the machine IS IEEE compliant. You can read the result of a Paranoia test on this machine at

More traces of UCB tests on other (IEEE compliant) systems / machines are available at

Marc Daumas - Charge de recherches au CNRS (LIP - ENS de Lyon)

[ Marquette | MSCS | Corliss | Vladik's Intervals ]
Interval FAQ: [ Entry page | Contents | Search ]
About Sun's f95 with Interval Support

If you have a question related to validated computing, interval analysis, or related matters, I recommend

This page URL: http://www.mscs.mu.edu/~georgec/IFAQ/casares1.html
Last modified February 15, 19100. Send comments to (georgec@mscs.mu.edu)
Access count since 20 Apr 1999 : Graphical counter