5

Every implementer of floating-point arithmetic, needs to think about how to signal overflow.

One possible way to do it is by raising an exception, though this creates the problem that 'exception' can end up getting interpreted as 'precise exception', and precise exceptions are a big headache to implement in the kind of heavily pipelined vector unit you want for high-performance floating point, so it's more common to do it by setting some bit(s) that the software can examine later, at some point where it doesn't mind a pipeline flush.

Also, there are occasions when you want to react to floating-point overflow by doing something other than terminating the program, e.g. you might implement logic along the lines of 'try this calculation, if it overflowed, then rescale the values and try again'. I don't know how common it is for this to be a useful thing to do. 50%, 5%, 0.5%?

Also, interactive programs like spreadsheets definitely want to react to overflow by e.g. printing asterisks in the overflowed cell, not by crashing and losing work.

Another way to do it is with an in-band marker, a special value that occupies the place of a floating-point value, but indicates 'this is not actually a valid value; overflow has occurred'.

A third way to do it is with an out-of-band marker, a sticky status flag. Clear it at the beginning of calculation, check it at the end; if it is set, that means overflow occurred at some point.

IEEE 754, which is what nearly everything implements nowadays, specifies all of the above plus the kitchen sink: signaling NaN, quiet NaN, multiple NaN values plus positive and negative infinity, overflow flag.

In the days before that standard, hardware typically implemented less of a profusion of ways to detect overflow. According to some of the answers to How did dusty deck Fortran handle overflow? some early machines signaled overflow by simply crashing the program.

Did any computers signal overflow purely with a sticky flag?

3
  • I guess that your "in-band marker" is a bit like an infinity or NaN, but useless as an input for subsequent operations, rather than having fully-defined behaviour as they do? Oct 23 at 8:18
  • @TobySpeight No, infinity and NaN are examples of in-band markers: values that fit in a floating-point register, that are distinguishable from valid floating-point numbers, and that if input to subsequent operations, cause those operations to produce outputs that propagate those properties.
    – rwallace
    Oct 24 at 11:28
  • 1
    It seems I didn't read carefully enough. The three different indicators are: (1) non-local exit via exception or trap instruction, (2) in-band signal such as NaN, (3) flag bit in a status register. Oct 24 at 12:04
6

A floating-overflow flag that get set on overflow, and stays set until explicitly cleared, seems in my recollection to be fairly common. Not only that, but this was all you got.


The English Electric KDF9 used this technique; it had a jump-on-overflow instruction to test and clear the overflow flag.

The KDF9 Usercode (assembler) manual describes each arithmetic instruction with respect to setting overflow, for example the 'add' instruction - no operands, arithmetic takes place in the nesting store, a stack of accumulatord.

+; Adds the number in N1 to that in N2, leaving the result in N1. Overflow set if both numbers have the same sign and the result exceeds single-length capacity.

Elsewhere we have

10.6.3 Overflow Jumps

It has been seen that if numbers get too large the overflow register is set but the computer will not stop. An instruction to clear the overflow register, and jumps to see if it is set or not, are provided to enable the program to discover if overflow has occurred.

The instructions are:-

VR; Clear overflow register. No other part of the machine is affected.

JrV; Jump to instruction labelled r if the overflow register is set, otherwise proceed to the next instruction in sequence. Clear the overflow register.

JrNV; Jump to instruction labelled r if the overflow register is not set. If it is, proceed to the next instruction after clearing the overflow register


The ICT 1900 (at least the ones with floating-point hardware) similarly had sticky overflow flags, though separate indicators for integer overflow and floating-point overflow.

Later editions of the PLAN Reference Manual (TP4322, link), describe floating-overflow operations as follows:

Floating-point overflow may be set (FOVR=1) by the following instructions:

FAD FSB FMPY FDVD LEFP LFP NEFPS NFPS

Floating-point overflow is cleared (FOVR=0) by the following instructions:

LFPZ SEFP ZSFPZ ZEFPS ZFPS

and may by cleared by LFP.

The basic scheme is that the calculation instructions conditionally set the flag, and it is unconditionally cleared by load/set instructions.

Somewhat oddly to my mind, the actual flag is an otherwise-used bit in the middle of the floating point accumulator.

2

Did any computers signal overflow purely with a sticky flag?

The Mill CPU does this, see e.g. slide 40 ff., in particular slide 47 for integer overflow. (I can't find floating point overflow handling right now, it's probably in some other talk).

But then, there is no real implementation of the Mill in silicon yet, only PoC FPGA implementations, and it looks like the project is stalled, so you decide if this counts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.