Extended precision

x86 extended-precision format

The x86 extended-precision format is an 80-bit format first implemented in the Intel 8087 math coprocessor and is supported by all processors that are based on the x86 design that incorporate a floating-point unit (FPU).

The Intel 8087 was the first x86 device which supported floating-point arithmetic in hardware. It was designed to support a 32-bit "single precision" format and a 64-bit "double-precision" format for encoding and interchanging floating-point numbers. The extended format was designed not to store data at higher precision, but rather to allow for the computation of temporary double results more reliably and accurately by minimising overflow and roundoff-errors in intermediate calculations. All the floating-point registers in the 8087 hold this format, and it automatically converts numbers to this format when loading registers from memory and also converts results back to the more conventional formats when storing the registers back into memory. To enable intermediate subexpression results to be saved in extended precision scratch variables and continued across programming language statements, and otherwise interrupted calculations to resume where they were interrupted, it provides instructions which transfer values between these internal registers and memory without performing any conversion, which therefore enables access to the extended format for calculations – also reviving the issue of the accuracy of functions of such numbers, but at a higher precision.

The floating-point units (FPU) on all subsequent x86 processors have supported this format. As a result, software can be developed which takes advantage of the higher precision provided by this format. William Kahan, a primary designer of the x87 arithmetic and initial IEEE 754 standard proposal notes on the development of the x87 floating point: "An extended format as wide as we dared (80 bits) was included to serve the same support role as the 13 decimal internal format serves in Hewlett-Packard's 10 decimal calculators." Moreover, Kahan notes that 64 bits was the widest significand across which carry propagation could be done without increasing the cycle time on the 8087, and that the x87 extended precision was designed to be extensible to higher precision in future processors:

For now the 10 byte extended format is a tolerable compromise between the value of extra-precise arithmetic and the price of implementing it to run fast; very soon two more bytes of precision will become tolerable, and ultimately a 16 byte format. ... That kind of gradual evolution towards wider precision was already in view when IEEE Standard 754 for Floating-Point Arithmetic was framed.

This 80-bit format uses one bit for the sign of the significand, 15 bits for the exponent field (i.e. the same range as the 128-bit quadruple precision IEEE 754 format) and 64 bits for the significand. The exponent field is biased by 16383, meaning that 16383 has to be subtracted from the value in the exponent field to compute the actual power of 2. An exponent field value of 32767 (all fifteen bits 1) is reserved so as to enable the representation of special states such as infinity and Not a Number. If the exponent field is zero, the value is a subnormal number and the exponent of 2 is −16382.

In the following table, "s" is the value of the sign bit (0 means positive, 1 means negative), "e" is the value of the exponent field interpreted as a positive integer, and "m" is the significand interpreted as a positive binary number, where the binary point is located between bits 63 and 62. The "m" field is the combination of the integer and fraction parts in the above diagram.

In contrast to the single- and double-precision formats, this format does not utilize an implicit / hidden bit. Rather, bit 63 contains the integer part of the significand and bits 62–0 hold the fractional part. Bit 63 will be 1 on all normalized numbers. There were several advantages to this design when the 8087 was being developed:

• Calculations can be completed a little faster if all bits of the significand are present in the register.
• A 64-bit significand provides sufficient precision to avoid loss of precision when the results are converted back to double-precision format in the vast number of cases.
• This format provides a mechanism for indicating precision loss due to underflow which can be carried through further operations. For example, the calculation 2 × 10⁻⁴⁹³⁰ × 3 × 10⁻¹⁰ × 4 × 10²⁰ generates the intermediate result 6 × 10⁻⁴⁹⁴⁰ which is a subnormal and also involves precision loss. The product of all of the terms is 24 × 10⁻⁴⁹²⁰ which can be represented as a normalized number. The 80287 could complete this calculation and indicate the loss of precision by returning a "subnormal" result (exponent not 0, bit 63 = 0). Processors since the 80387 no longer generate unnormal values and do not support unnormal inputs to operations. They will generate a subnormal if an underflow occurs but will generate a normalized result if subsequent operations on the subnormal can be normalized.

Examples

These examples are given in bit representation, in hexadecimal, of the floating-point value. This includes the sign, (biased) exponent, and significand.

0000 0000 0000 0000 0001<sub id="mwASo">16</sub> = 2<sup id="mwASs">−16382</sup> × 2<sup id="mwASw">−63</sup> = 2<sup id="mwAS0">−16445</sup> ≈ 3.64519953188247460252841 × 10<sup id="mwAS4">−4951</sup> (smallest positive subnormal number)

0000 7fff ffff ffff ffff<sub id="mwATA">16</sub> = 2<sup id="mwATE">−16382</sup> × (1 − 2<sup id="mwATI">−63</sup>) ≈ 3.36210314311209350589816 × 10<sup id="mwATM">−4932</sup> (largest subnormal number)

0001 8000 0000 0000 0000<sub id="mwATU">16</sub> = 2<sup id="mwATY">−16382</sup> ≈ 3.36210314311209350626268 × 10<sup id="mwATc">−4932</sup> (smallest positive normal number)

7ffe ffff ffff ffff ffff<sub id="mwATk">16</sub> = 2<sup id="mwATo">16384</sup> × (1 − 2<sup id="mwATs">−64</sup>) ≈ 1.18973149535723176502126 × 10<sup id="mwATw">4932</sup> (largest normal number)

3ffe ffff ffff ffff ffff<sub id="mwAT4">16</sub> = 1 − 2<sup id="mwAT8">−64</sup> ≈ 0.99999999999999999994579 (largest number less than one)

3fff 8000 0000 0000 0000<sub id="mwAUE">16</sub> = 1 (one)

3fff 8000 0000 0000 0001<sub id="mwAUM">16</sub> = 1 + 2<sup id="mwAUQ">−63</sup> ≈ 1.00000000000000000010842 (smallest number larger than one)

4000 8000 0000 0000 0000<sub id="mwAUY">16</sub> = 2 c000 8000 0000 0000 0000<sub id="mwAUc">16</sub> = −2

0000 0000 0000 0000 0000<sub id="mwAUk">16</sub> = 0 8000 0000 0000 0000 0000<sub id="mwAUo">16</sub> = −0

3ffd aaaa aaaa aaaa aaab<sub id="mwAUw">16</sub> ≈ 0.33333333333333333334237 (closest approximation to <span typeof="mw:Entity" id="mwAU0">⅓</span>)

4000 adf8 5458 a2bb 4a9b<sub id="mwAU8">16</sub> ≈ 2.71828182845904523542817 (closest approximation to e)

4000 c90f daa2 2168 c235<sub id="mwAVE">16</sub> ≈ 3.14159265358979323851281 (closest approximation to π)

Introduction to use

The 80-bit floating-point format was widely available by 1984, after the development of C, Fortran and similar computer languages, which initially offered only the common 32- and 64-bit floating-point sizes. On the x86 design most C compilers now support 80-bit extended precision via the long double type, and this was specified in the C99 / C11 standards (IEC 60559 floating-point arithmetic (Annex F)). Compilers on x86 for other languages often support extended precision as well, sometimes via nonstandard extensions: For example, Turbo Pascal offers an extended type, and several Fortran compilers have a REAL*10 type (analogous to REAL*4 and REAL*8). Such compilers also typically include extended-precision mathematical subroutines, such as square root and trigonometric functions, in their standard libraries.

Working range

The 80-bit floating-point format has a range (including subnormals) from approximately 3.65 × 10⁻⁴⁹⁵¹ to 1.18 × 10⁺⁴⁹³² . Although log₁₀( 2⁶⁴ ) ≈ 19.266 , this format is usually described as giving approximately eighteen significant digits of precision (the floor of log₁₀( 2⁶³ ) , the minimum guaranteed precision). The use of decimal when talking about binary is unfortunate because most decimal fractions are recurring sequences in binary just as ⅔ is in decimal. Thus, a value such as 10.15, is represented in binary as equivalent to 10.1499996185 etc. in decimal for REAL*4 but 10.15000000000000035527 etc. in REAL*8: inter-conversion will involve approximation, except for those few decimal fractions that represent an exact binary value, such as 0.625 . For REAL*10, the decimal string is 10.1499999999999999996530553 etc. The last 9 digit is the eighteenth fractional digit and thus the twentieth significant digit of the string. Bounds on conversion between decimal and binary for the 80-bit format can be given as follows: If a decimal string with at most 18 significant digits is correctly rounded to an 80-bit IEEE 754 binary floating-point value (as on input) then converted back to the same number of significant decimal digits (as for output), then the final string will exactly match the original; while, conversely, if an 80-bit IEEE 754 binary floating-point value is correctly converted and (nearest) rounded to a decimal string with at least 21 significant decimal digits then converted back to binary format it will exactly match the original. These approximations are particularly troublesome when specifying the best value for constants in formulae to high precision, as might be calculated via arbitrary-precision arithmetic.

Need for the 80-bit format

A notable example of the need for a minimum of 64 bits of precision in the significand of the extended-precision format is the need to avoid precision loss when performing exponentiation on double-precision values. The x86 floating-point units do not provide an instruction that directly performs exponentiation: Instead they provide a set of instructions that a program can use in sequence to perform exponentiation using the equation:

$${\displaystyle x^y=2^{y\cdot {\log }_2(x)}}$$

In order to avoid precision loss, the intermediate results "log₂(x)" and "y·log₂(x)" must be computed with much higher precision, because effectively both the exponent and the significand fields of x must fit into the significand field of the intermediate result. Subsequently, the significand field of the intermediate result is split between the exponent and significand fields of the final result when 2^{intermediate result} is calculated. The following discussion describes this requirement in more detail.

With a little unpacking, an IEEE 754 double-precision value can be represented as:

$${\displaystyle 2^{(-1{)}^s\cdot E}\cdot M}$$

where s is the sign of the exponent (either 0 or 1), E is the unbiased exponent, which is an integer that ranges from 0 to 1023, and M is the significand which is a 53-bit value that falls in the range 1 ≤ M < 2 . Negative numbers and zero can be ignored because the logarithm of these values is undefined. For purposes of this discussion M does not have 53 bits of precision because it is constrained to be greater than or equal to one i.e. the hidden bit does not count towards the precision (Note that in situations where M is less than 1, the value is actually a de-normal and therefore may have already suffered precision loss. This situation is beyond the scope of this article).

Taking the log of this representation of a double-precision number and simplifying results in the following:

$${\displaystyle {\log }_2(2^{(-1{)}^s\cdot E}\cdot M)=(-1{)}^s\cdot E\cdot {\log }_2(2)+{\log }_2(M)=\pm E+{\log }_2(M)}$$

This result demonstrates that when taking base 2 logarithm of a number, the sign of the exponent of the original value becomes the sign of the logarithm, the exponent of the original value becomes the integer part of the significand of the logarithm, and the significand of the original value is transformed into the fractional part of the significand of the logarithm.

Because E is an integer in the range 0 to 1023, up to 10 bits to the left of the radix point are needed to represent the integer part of the logarithm. Because M falls in the range 1 ≤ M < 2 , the value of log₂ M will fall in the range 0 ≤ log₂ M < 1 so at least 52 bits are needed to the right of the radix point to represent the fractional part of the logarithm. Combining 10 bits to the left of the radix point with 52 bits to the right of the radix point means that the significand part of the logarithm must be computed to at least 62 bits of precision. In practice values of M less than ${\displaystyle \sqrt{2}}$ require 53 bits to the right of the radix point and values of M less than ${\displaystyle \sqrt[4]{2}}$ require 54 bits to the right of the radix point to avoid precision loss. Balancing this requirement for added precision to the right of the radix point, exponents less than 512 only require 9 bits to the left of the radix point and exponents less than 256 require only 8 bits to the left of the radix point.

The final part of the exponentiation calculation is computing 2^{intermediate result} . The "intermediate result" consists of an integer part "I" added to a fractional part "F". If the intermediate result is negative then a slight adjustment is needed to get a positive fractional part because both "I" and "F" are negative numbers.

For positive intermediate results:

$${\displaystyle 2^{\mathsf{i}\mathsf{n}\mathsf{t}\mathsf{e}\mathsf{r}\mathsf{m}\mathsf{e}\mathsf{d}\mathsf{i}\mathsf{a}\mathsf{t}\mathsf{e}\mathsf{r}\mathsf{e}\mathsf{s}\mathsf{u}\mathsf{l}\mathsf{t}}=2^{I+F}=2^I{2}^F}$$

For negative intermediate results:

$${\displaystyle 2^{\mathrm{i}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{r}\mathrm{m}\mathrm{e}\mathrm{d}\mathrm{i}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{r}\mathrm{e}\mathrm{s}\mathrm{u}\mathrm{l}\mathrm{t}}=2^{I+F}=2^{I+(1-1)+F}=2^{(I-1)+(F+1)}=2^{I-1}{2}^{F+1}}$$

Thus the integer part of the intermediate result ("I" or "I − 1") plus a bias becomes the exponent of the final result and transformed positive fractional part of the intermediate result: 2^F or 2^{F + 1} becomes the significand of the final result. In order to supply 52 bits of precision to the final result, the positive fractional part must be maintained to at least 52 bits.

In conclusion, the exact number of bits of precision needed in the significand of the intermediate result is somewhat data dependent but 64 bits is sufficient to avoid precision loss in the vast majority of exponentiation computations involving double-precision numbers.

The number of bits needed for the exponent of the extended-precision format follows from the requirement that the product of two double-precision numbers should not overflow when computed using the extended format. The largest possible exponent of a double-precision value is 1023 so the exponent of the largest possible product of two double-precision numbers is 2047 (an 11-bit value). Adding in a bias to account for negative exponents means that the exponent field must be at least 12 bits wide.

Combining these requirements: 1 bit for the sign, 12 bits for the biased exponent, and 64 bits for the significand means that the extended-precision format would need at least 77 bits. Engineering considerations resulted in the final definition of the 80-bit format (in particular the IEEE 754 standard requires the exponent range of an extended-precision format to match that of the next largest, quad, precision format which is 15 bits).

Another example of calculations that benefit from extended precision arithmetic are iterative refinement schemes, used to indirectly clean out errors accumulated in the direct solution during the typically very large number of calculations made for numerical linear algebra.

Language support

• Some C / C++ implementations (e.g., GNU Compiler Collection (GCC), Clang, Intel C++) implement long double using 80-bit floating-point numbers on x86 systems. However, this is implementation-defined behavior and is not required, but allowed by the standard, as specified for IEEE 754 hardware in the C99 standard "Annex F IEC 60559 floating-point arithmetic". GCC also provides __float80 and __float128 types.
• Some Common Lisp implementations (e.g. CMU Common Lisp, Embeddable Common Lisp) implement long-float using 80-bit floating-point numbers on x86 systems.
• The D programming language implements real using the largest floating-point size implemented in hardware, for example 80 bits for x86 CPUs. On other machines, this will be the widest floating-point type natively supported by the CPU, or 64-bit double precision, whichever is wider.
• Turbo Pascal (and Object Pascal or Delphi) has an extended 80-bit type available in addition to real / single (32 bits) and double (64 bits), either natively (when a 80x87 coprocessor is present) or emulated (through the Turbo87 library); this extended type is available on 16-, 32-, and 64-bit platforms, possibly with padding.
• The Racket run-time system provides the 80-bit extflonum datatype on x86 systems.
• The Swift standard library provides the Float80 datatype.
• The PowerBASIC BASIC compiler provides EXT or EXTENDED 10-byte extended-precision floating-point data type.
• Some versions of BBC BASIC, notably BBC BASIC for Windows and BBC BASIC for SDL 2.0, support 10-byte extended-precision floats when running on an x86 CPU.
• Zig provides a f80 type since version 0.10.0.