How can an underflow lead to an overflow?

Question

I'm reading the Intel Manual (Intel® 64 and IA-32 Architectures Software Developer Manuals *2016) and am curious if I understand this one excerpt correctly about the need for an Underflow Exception:

The ability to detect and handle underflow is provided to prevent a very small result from propagating through a computation and causing another exception (such as overflow during division) to be generated at a later time.

-Section 4.9.1.5

So my question is what would this scenario look like? Could one possible pseudocode computation be

veryVerySmallNumber = SmallestFloatpossible -1
veryVeryLargeNumber = BigBigFloat
answer = veryVerySmallNumber / veryVeryLargeNumber

I read there are two ways the processor can handle this but I'm more concerned with HOW an underflow could lead to an overflow. I'd also appreciate any clarification on the general spirit of handling these scenarios.

Answer 1

The Intel reference to underflow is about floating-point operations.

This program:

#include <stdio.h>

int main(void)
{
    float x = 0x1.23456p-70f;   //  Set x to a number around 2**-70.
    float y = x*x;
    float z = 1/y;
    printf("x = %g.\n", x);
    printf("y = %g.\n", y);
    printf("z = %g.\n", z);
}   

in common C implementations that use IEEE-754 binary32 for float prints:

x = 9.63735e-22.
y = 9.29061e-43.
z = inf.

In x*x, the computation underflows—the result is in the subnormal range, where the float format cannot represent it with full precision (and, in particular, some of the value of the result is lost while rounding it to fit into the format).

Then, because the number is so small, attempting to take its reciprocal fails to produce a finite result—the result is out of the float range of finite numbers, so it produces infinity. The operation is said to overflow.

Intel hardware provides a means to detect underflow: with FP exceptions unmasked, the underflow exception will actually trap (e.g. on Linux/Unix, the OS will deliver a SIGFPE floating point exception). Or with FP exceptions masked like normal, it will just set a sticky flag bit in MXCSR to record that an underflow exception happened since that last time exception status flags were zeroed. There are other exception flags for overflow, inexact (non-zero rounding error), invalid (NaN result). See a table of the MXCSR bits, or look in the Intel x86 manuals. There are similar separate masked-exception recording flags for legacy x87.

A program can take advantage of this by detecting the underflow in x*x and performing whatever steps it wants to avoid losing track of the value completely in later operations.

Answer 2

I love Eric's answer but wanted to post some additional information about observing and reacting to the underflow & overflow flags via the MXCSR register Eric mentioned.

First, the MXCSR register is an additional control register, made available for SSE instructions to control and check the status of exceptions. This register is 32-bits, as of SSE3, only bits 0-15 have been defined (use the CPUID instruction to see what features your processor allows).

Here is another way to look at what each bit indicates in MXCSR:

+----------+----------------------+------------------------+
| Mnemonic |     Bit Location     |      Description       |
+----------+----------------------+------------------------+
| FZ       | bit 15               | Flush To Zero          |
| R+       | bit 14               | Round Positive         |
| R-       | bit 13               | Round Negative         |
| RZ       | bits 13 and 14       | Round To Zero          |
| RN       | bits 13 and 14 are 0 | Round To Nearest       |
| PM       | bit 12               | Precision Mask         |
| UM       | bit 11               | Underflow Mask         |
| OM       | bit 10               | Overflow Mask          |
| ZM       | bit 9                | Divide By Zero Mask    |
| DM       | bit 8                | Denormal Mask          |
| IM       | bit 7                | Invalid Operation Mask |
| DAZ      | bit 6                | Denormals Are Zero     |
| PE       | bit 5                | Precision Flag         |
| UE       | bit 4                | Underflow Flag         |
| OE       | bit 3                | Overflow Flag          |
| ZE       | bit 2                | Divide By Zero Flag    |
| DE       | bit 1                | Denormal Flag          |
| IE       | bit 0                | Invalid Operation Flag |
+----------+----------------------+------------------------+

I really like this instruction cheat sheet I found on http://softpixel.com/~cwright/programming/simd/sse.php

FZ mode causes all underflowing operations to simply go to zero. This saves some processing time, but loses precision.

The R+, R-, RN, and RZ rounding modes determine how the lowest bit is generated. Normally, RN is used.

PM, UM, MM, ZM, DM, and IM are masks that tell the processor to ignore the exceptions that happen, if they do. This keeps the program from having to deal with problems, but might cause invalid results.

DAZ tells the CPU to force all Denormals to zero. A Denormal is a number that is so small that FPU can't renormalize it due to limited exponent ranges. They're just like normal numbers, but they take considerably longer to process. Note that not all processors support DAZ.

PE, UE, ME, ZE, DE, and IE are the exception flags that are set if they happen, and aren't unmasked. Programs can check these to see if something interesting happened. These bits are "sticky", which means that once they're set, they stay set forever until the program clears them. This means that the indicated exception could have happened several operations ago, but nobody bothered to clear it.

Now the challenge/fun will be to use the information from these instructions and the values they return to watch when underflows lead to overflows, not that this is a common occurrence, just interesting.