9

Some FPUs exhibit as much as an order of magnitude slowdown when given denormal inputs, due to having to trap to microcode to handle them.

Did early FPUs of the microprocessor era, exhibit substantial slowdown? I'm particularly interested in the 8087, 387 and 486; what sort of slowdown did they exhibit? The 8087 datasheet doesn't seem to say; it just gives a range of clock cycles for each instruction, without further comment.

4
  • 4
    I cannot answer your question, but I find it interesting that you refer to the 387 (1987) and 486 (1989) as "early". I'd probably reserve that term for the MM57109 (1977) or the AM9511 (1979). Jun 28, 2020 at 9:50
  • 1
    @MichaelGraf reading the data sheet, the MM57109 is pretty much a hand held calculator chip ("instruction times range from 1ms to 1 second") with a computer interface, unlike the 8087 which was connected to the address and data bus directly and was one or two orders of magnitude faster.
    – alephzero
    Jun 28, 2020 at 12:42
  • 2
    As well as denormal numbers, NaNs and infinity may increase the latencies. Boolean, move and shuffle instructions will probably not be affected. In the 1990s Intel replaced the 8087’s CORDIC-based approximations with polynomial-based approximations, which have greater overall accuracy and speed. Jun 28, 2020 at 12:43
  • 1
    @alephzero, that's my point, in a way. The MM57109 was a hand-held calculator chip with an 8-bit-interface tacked on. Yet National Semiconductor decided to build and market this chip, because even that was an improvement over the status quo (i.e., no FPU, and do it in software on a 8080/6800). The AM9511 was the first thing that looking back, we'd call a proper FPU. The 387 and the 486's internal FPU are at least an order of magnitude away from these both in transistor count and in sophistication; calling them "early" feels like lumping the 486 with the 8080. Jun 28, 2020 at 15:07

1 Answer 1

14

The MC68882 was relatively well-regarded among 1980s FPUs. Digging out accurate timing information takes some effort, but it appears that handling denormalised values was only moderately burdensome for this FPU. In the context of a register-to-register FADD already taking several dozen clock cycles:

  • Taking a denormalised extended-precision source operand incurs a penalty of 12 cycles,
  • Underflow in an extended-precision result incurs a 34 cycle penalty,
  • Underflow in a single or double-precision result incurs a 56 cycle penalty,
  • Saving a denormalised value from register to memory incurs a 10 cycle penalty during format conversion,
  • Underflow during format conversion incurs an approximately 30 cycle penalty.

The worst of the above penalties is comparable to executing an extra FADD or FMUL instruction. Importantly, the MC68882 could handle all of these conditions (as well as those involving Zeroes, Infinities and NaNs) without trapping to support software, provided the explicit exception flags were cleared. This was not true of the later 68040 FPU, which was otherwise much faster.

The slightly earlier MC68881 takes similar penalties, which appear smaller next to an overall longer instruction execution time.


Earlier in the 1980s, a computer might have used the Am9512, one of the first and least expensive of the IEEE-754 format FPUs. This was of course much slower than the 68882, but could still be much faster than performing floating-point operations using software routines. Typical execution times are in the hundreds of cycles for single precision, and thousands of cycles for double precision.

The Am9512 manual does not discuss denormalised numbers at all. It is entirely likely that this early FPU, produced before IEEE-754 was ratified, simply flushes such tiny numbers to zero. However, given the hardware architecture and the long execution times for each operation, I think denormalised numbers could have been handled without any performance penalty being noticeable.


The i8087 is also relevant here. While of broadly comparable performance to the Am9512, it does have full support for IEEE-754 including denormalised values. Timing penalties for handling them under most circumstances are not quoted in the manual, with execution timings of most instructions already being value-dependent.

The exception, for which a timing penalty is quoted, is for transferring an operand over the external bus. Here a denormalised operand is quoted as taking 33 cycles longer than normal, provided the denormal exception is masked.

There is a further caveat: transcendental functions on the i8087 cannot accept denormalised inputs, and will produce incorrect results. User software is responsible for checking for this condition.


The i80387 which is also integrated into the i80486DX also does not quote exact penalties for handling denormalised values. A comment in the support software routines indicates that the 387 "can normalise denormalised values faster than a software exception handler can". Instruction timings for operations are variable and value-dependent, but generally faster than in the i8087.

The i80387 also removes the limitation on supplying denormal values to transcendental operations.

4
  • 1
    @njuffa That's true of the i80387, which has better transcendental functions and more exact IEEE-754 compliance than its predecessors. The i8087 would load a denormalised single or double as an unnormalised extended precision value, and the transcendental instructions would then choke on it silently, not even triggering the denormal exception if that was unmasked. Instead you had to use the denormal exception when loading or otherwise producing the operand to manually normalise the value, possibly by zeroing it.
    – Chromatix
    Jun 28, 2020 at 17:18
  • 1
    @njuffa I think there was a good reason for that limitation in Turbo Pascal. See 80286 and 80287 Programmer's Reference Manual (1987), page 2-12.
    – Chromatix
    Jun 28, 2020 at 20:50
  • 1
    I withdraw my earlier remarks as I found a relevant reference. 8086/8088 User's Manual (Intel, 1989), p. 5-39: To be considered valid, an operand to a transcendental must be normalized; denormals, unnormals, infinities and NaNs are considered invalid.
    – njuffa
    Jun 28, 2020 at 20:51
  • 1
    FWIW, the reference for the 33-cycle penalty for a masked denormal exeception is Table 5-16 "Execution Penalties" on page 5-49 of the 8086/8088 User's Manual (Intel, 1989).
    – njuffa
    Jun 28, 2020 at 21:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .