Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
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.
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:
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.
