The single-precision format uses a 24-bit mantissa and an 8-bit exponent. The mantissa usually represents a value between 1.0 and just less than 2.0. The HO bit of the mantissa is always assumed to be one and represents a value just to the left of the binary point. The remaining 23 mantissa bits appear to the right of the binary point and represent the value:

1.mmmmmmm mmmmmmmm mmmmmmmm

The presence of the implied one bit is why the mantissa is always greater than or equal to one. Even if the other mantissa bits are all zero, the implied one bit always gives us the value one. Each position to the right of the binary point represents a value (zero or one) times a successive negative power of two, but even if we had an almost infinite number of one bits after the binary point, they still would not add up to two. So the mantissa can represent values in the range 1.0 to just less than 2.0.

Some examples would probably be useful here. Consider the decimal value 1.7997. Here are the steps we could go though to compute the binary mantissa for this value:

Although there is an infinite number of values between one and two, we can only represent eight million (2²³) of them because we use a 23-bit mantissa (the 24th bit is always one). This is the reason for inaccuracy in floating-point arithmetic — we only have 23 bits of precision in computations involving single-precision floating-point values.

The mantissa uses a one’s complement format rather than two’s complement. This means that the 24-bit value of the mantissa is simply an unsigned binary number, and the sign bit, in bit position 31, determines whether that value is positive or negative. One’s complement numbers have the unusual property that there are two representations for zero (with the sign bit set or clear). Generally, this is important only to the person designing the floating-point software or hardware system. We will assume that the value zero always has the sign bit clear. The single-precision floating-point format takes the form shown in Figure 4-2.

Figure 4-2. Single-precision (32-bit) floating-point format

To represent values outside the range 1.0 to just under 2.0, the exponent portion of the floating-point format comes into play. The floating-point format raises two to the power specified by the exponent and then multiplies the mantissa by this value. The exponent is eight bits and uses an excess-127 format (sometimes called bias-127 exponents). In excess-127 format, the exponent 2⁰ is represented by the value 127 ($7f). Therefore, to convert an exponent to excess-127 format, simply add 127 to the exponent value. For example, the single precision representation for 1.0 is $3f800000. The mantissa is 1.0 (including the implied bit) and the exponent is 2⁰, or 127 ($7f) when you add in the excess-127 exponent value.

The use of excess-127 format for the exponent makes it easier to compare floating-point values. As it turns out, if we handle the sign bit (bit 31) separately, we can easily compare two floating-point numbers for less than or greater than by simply comparing them as though they were unsigned integers. To handle the sign bit, we simply note the signs of the two values. If the signs are not equal, then the positive value (the one with bit 31 set to zero) will be greater than the number that has the HO bit set to one.^[12] If the sign bits are both zero, then we can use a straight unsigned binary comparison. If the signs are both one, then we do an unsigned comparison but invert the result (so if the sign bits are set, we treat less than as greater than and vice versa). On some CPUs a 32-bit unsigned comparison is much faster than a 32-bit floating-point comparison. In such situations, it’s probably worthwhile to do the comparison using integer arithmetic rather than floating-point arithmetic.

With a 24-bit mantissa, you will get approximately 6 ¹/₂ decimal digits of precision (one half digit of precision means that the first six digits can all be in the range 0..9 but the seventh digit can only be in the range 0..x where x < 9 and is generally close to 5). With an 8-bit excess-127 exponent, the dynamic range of single-precision floating-point numbers is approximately 2^±128 or about 10^±38.

Although single-precision floating-point numbers are perfectly suitable for many applications, the dynamic range is somewhat limited and is unsuitable for many financial, scientific, and other applications. Furthermore, during long chains of computations, the limited accuracy of the single precision format may introduce serious error. For serious calculations, a floating-point format with more precision is necessary.

The double-precision format helps overcome the problems of the single-precision floating-point. Using twice the space, the double-precision format has an 11-bit excess-1,023 exponent and a 53-bit mantissa (including an implied HO bit of one) plus a sign bit. This provides a dynamic range of about 10^±308 and 14 ¹/₂ digits of precision, which is sufficient for most applications. Double-precision floating-point values take the form shown in Figure 4-3.

Figure 4-3. Double-precision (64-bit) floating-point format

In order to help ensure accuracy during long chains of computations involving double-precision floating-point numbers, Intel designed the extended-precision format. The extended-precision format uses 80 bits. Twelve of the additional 16 bits are appended to the mantissa, and 4 of the additional bits are appended to the exponent. Unlike the single- and double-precision values, the extended-precision format’s mantissa does not have an implied HO bit that is always one. Therefore, the extended-precision format provides a 64-bit mantissa, a 15-bit excess-16,383 exponent, and a 1-bit sign. The format for the extended-precision floating-point value appears in Figure 4-4.

Figure 4-4. Extended-precision (80-bit) floating-point format

On the 80x86 FPUs, all computations are done using the extended-precision form. Whenever you load a single- or double-precision value, the FPU automatically converts it to an extended-precision value. Likewise, when you store a single or double precision value to memory, the FPU automatically rounds the value down to the appropriate size before storing it. By always working with the extended-precision format, Intel guarantees a large number of guard bits are present to ensure the accuracy of your computations. By performing all computations using 80 bits, Intel helps ensure (but not guarantee) that you will get full 32- or 64-bit accuracy in your computations. Because the FPUs do not provide a large number of guard bits in 80-bit computations, some error will inevitably creep into the LO bits of an extended-precision computation. However, if your computation is correct to 64 bits, the 80-bit computation will generally provide at least 64 accurate bits. Most of the time you will get even more. While you cannot assume that you get an accurate 80-bit computation, you can usually do better than 64 bits when using the extended-precision format.

Non-Intel CPUs that support floating-point arithmetic generally provide only the 32-bit and 64-bit formats. As such, calculations on those CPUs may produce less accurate results than the equivalent string of calculations on the 80x86 using 80-bit calculations.

For the purposes of the floating-point functions we’re about to develop, this section will use the IEEE 32-bit single-precision floating-point format (shown earlier in Figure 4-2), which uses a one’s complement representation for signed values. This means that the sign bit (bit 31) contains a one if the number is negative and a zero if the number is positive. The exponent is an 8-bit excess-127 exponent sitting in bits 23..30, and the mantissa is a 24-bit value with an implied HO bit of one. Because of the implied HO bit, this format does not support denormalized values.

Because the IEEE floating-point format supports signed real values, it turns out that addition and subtraction use essentially the same code. After all, computing X − Y is equivalent to computing X + (−Y). So if we can add a negative number with some other value, then we can also perform subtraction by first negating some number and then adding them. And because the IEEE floating-point format uses the one’s complement representation, negating a value is trivial — we just invert the sign bit.

Because we’re using the standard IEEE 32-bit single-precision floating-point format, we could theoretically get away with using the C/C++ float data type (assuming the underlying C/C++ compiler also uses this format, as most do on modern machines). However, you’ll soon see that when doing floating-point calculations in software, we need to manipulate various fields within the floating-point format as bit strings and integer values. Therefore, it’s more convenient to use a 32-bit unsigned integer type to hold the bit representation for our floating-point values. To avoid confusing our real values with actual integer values in a program, we’ll define the following real data type (which assumes that unsigned longs are 32-bit values in your implementation of C/C++) and declare all our real variables using this type:

typedef long unsigned real;

One advantage of using the same floating-point format that C/C++ uses for float values is that we can assign floating-point literal constants to our real variables, and we can do other floating-point operations such as input and output using existing library routines. However, one potential problem is that C/C++ will attempt to automatically convert between integer and floating-point formats if we use a real variable in a floating-point expression (remember, as far as C/C++ is concerned, real is just a long unsigned integer value). This means that we need to tell the compiler to treat the bit patterns found in our real variables as though they were float objects.

A simple type coercion like (float) realVariable will not work. The C/C++ compiler will emit code to convert the integer it believes realVariable to contain into the equivalent floating-point value. However, the bit pattern in realVariable is a floating-point value, so no conversion is required. We want the C/C++ compiler to treat the bit pattern it finds in realVariable as a float without doing any conversion. The following C/C++ macro is a sneaky way to do this:

#define asreal(x) (*((float *) &x))

Note that this macro requires a single parameter that must be a real variable. The result of this macro is a variable that the compiler believes is a float variable.

Now that we have our float variable, we’ll develop two C/C++ functions to compute floating-point addition and subtraction: fpadd and fpsub. These two functions will each take three parameters: the left and right operands of the operator and a pointer to a destination where these functions will store their result. The prototypes for these functions are the following:

void fpadd( real left, real right, real *dest );
void fpsub( real left, real right, real *dest );

The fpsub function is almost trivial. All it has to do is negate the right operand and call the fpadd function to do the real work. Here’s the code for the fpsub function:

void fpsub( real left, real right, real *dest )
{
    right = right ^ 0x80000000;   // Invert the sign bit of the right operand.
    fpadd( left, right, dest );   // Let fpadd do the real work.
}

The fpadd function is where all the real work is done. To make fpadd a little easier to understand and maintain, we’ll decompose the function into several different functions that help with various activities that take place. In an actual software floating-point library routine, you’d probably not do this decomposition because the extra subroutine calls would be a little slower; however, we’re developing fpadd for educational purposes, not for actual use as part of a software floating-point library, and readability is a bit more important than performance in this particular instance. Besides, if you need high-performance floating-point addition, you’ll probably use a hardware FPU rather than a software implementation.

The IEEE floating-point formats are good examples of packed data types. As you’ve seen in previous chapters, packed data types are great for reducing storage requirements for a data type, but they’re not the best format when you need to use the packed fields in actual calculations. Therefore, one of the first things our floating-point functions will do is unpack the sign, exponent, and mantissa fields from the floating-point representation. The following C/C++ functions handle these simple tasks.

The first unpacking function is the extractSign function. This function extracts the sign bit (bit 31) from our packed floating-point representation and returns the value zero (for positive numbers) or one (for negative numbers).

inline int extractSign( real from )
{
    return( from >> 31);
}

This code could have also extracted the sign bit using this (possibly more efficient) expression:

(from & 0x80000000) != 0

However, shifting bit 31 down to bit 0 is, arguably, easier to understand.

The next utility function we’ll look at unpacks the exponent from bits 23..30 in the packed real format. It does this by shifting the real value to the right by 23 bits, and then it masks out the sign bit. One other thing that this function will do is convert the excess-127 exponent to a two’s complement format (this is easily achieved by subtracting 127 from the excess-127 exponent we extract). Here’s the function that does this:

inline int extractExponent( real from )
{
    return ((from >> 23) & 0xff) − 127;
}

Extracting the mantissa is easy. All we have to do is mask out the exponent and sign bits and then insert the implied HO bit of one. The only catch is that we must return zero if the entire value is zero. Here’s the function that extracts the mantissa from the real value:

inline int extractMantissa( real from )
{
    if( (from & 0x7fffffff) == 0 ) return 0;
    return ((from & 0x7FFFFF) | 0x800000 );
}

As you learned earlier, whenever adding or subtracting two values using scientific notation (and the IEEE floating-point format uses scientific notation), you must first adjust the two values so that they have the same exponent. For example, consider the addition of the following two decimal (base-10) numbers: 1.2345e3 + 8.7654e1.

To add these two numbers together, we must first adjust one or the other so that their exponents are the same. We can reduce the exponent of the first number by shifting the decimal point to the right. For example, the following values are all equivalent to 1.2345e3:

12.345e2 123.45e1 1234.5 12345e−1

Likewise, we can increase the value of an exponent by shifting the decimal point to the left. The following values are all equal to 8.7654e1:

0.87654e2 0.087654e3 0.0087654e4

For floating-point addition and subtraction involving binary numbers, we can make the binary exponents the same by shifting the mantissa one position to the left and decrementing the exponent, or by shifting the mantissa one position to the right and incrementing the exponent.

A problem with adjusting the exponent of one operand so that it matches the exponent of the other operand is that we only have so many bits to use to represent the mantissa. Shifting the mantissa bits to the right means that we reduce the precision of our number (because the bits wind up going off the LO end of the mantissa). To preserve as much accuracy as possible in our calculations, we shouldn’t truncate the bits we shift out of the mantissa. As noted earlier, we should round the result to the nearest value we can represent with the remaining mantissa bits. These are the IEEE rules for rounding, in the following order:

Shifting the mantissa and rounding it is a relatively complex operation, and it will occur a couple of times in the floating-point addition code. Therefore, it’s another candidate for a utility function. Here’s the C/C++ code that implements this functionality:

// shiftAndRound:
//
// Shifts a mantissa to the right the number of bits specified.
// Rounds the result according to the IEEE rules for rounding,
//  which are:
//
// If the bits we shift out are a value that is greater than one-half the
//  value of the LO bit we are left with, then we need
//  to round the value up by adding one to the LO bit position.
// If the bits we shift out are a value that is less than one-half the value
//  of the LO bit we are left with (after denormalization), then we need
//  to round the value down (i.e., just leave the value alone).
// If the bits we shift out are exactly one-half the value of the LO bit
//  we are left with, then we need to round the value to the next larger
//  number that has a zero in the LO bit (round up if there's currently a one,
//  or leave the value unchanged if the LO bit contains a zero).

void shiftAndRound( int *valToShift, int bitsToShift )
{
    // Masks is used to mask out bits to check for a "sticky" bit.

    static unsigned masks[24] =
    {
        0, 1, 3, 7, 0xf, 0x1f, 0x3f, 0x7f,
        0xff, 0x1ff, 0x3ff, 0x7ff, 0xfff, 0x1fff, 0x3fff, 0x7fff,
        0xffff, 0x1ffff, 0x3ffff, 0x7ffff, 0xfffff, 0x1fffff, 0x3fffff,
        0x7fffff
    };

    // HOmasks: Masks out the HO bit of the value masked by the masks entry.

    static unsigned HOmasks[24] =
    {
        0,
        1, 2, 4, 0x8, 0x10, 0x20, 0x40, 0x80,
        0x100, 0x200, 0x400, 0x800, 0x1000, 0x2000, 0x4000, 0x8000,
        0x10000, 0x20000, 0x40000, 0x80000, 0x100000, 0x200000, 0x400000
    };

    // shiftedOut: Holds the value that will be shifted out of a mantissa
    //  during the denormalization operation (used to round a denormalized
    //  value).

    int shiftedOut;

    assert( bitsToShift <= 23 );


    // Okay, first grab the bits we're going to shift out (so we can determine
    //  how to round this value after the shift).

    shiftedOut = *valToShift & masks[ bitsToShift ];

    // Shift the value to the right the specified number of bits.
    // Note: bit 31 is always zero, so it doesn't matter if the C
    //  compiler does a logical shift right or an arithmetic shift right.

    *valToShift = *valToShift >> bitsToShift;

    // If necessary, round the value:

    if( ( shiftedOut > HOmasks[ bitsToShift ] )
    {
        // If the bits we shifted out are greater than 1/2 the LO bit, then
        //  round the value up by one.

        *valToShift = *valToShift + 1;
    }
    else if( shiftedOut == HOmasks[ bitsToShift ] )
    {
        // If the bits we shifted out are exactly 1/2 of the LO bit's value,
        //  then round the value to the nearest number whose LO bit is zero.

        *valToShift = *valToShift + (*valToShift & 1);
    }
    // else
    // We round the value down to the previous value. The current
    //  value is already truncated (rounded down), so we don't have to do
    //  anything.
}

The “trick” in this code is that it uses a couple of lookup tables, masks and HOmasks, to extract those bits that the mantissa will use from the shift right operation. The masks table entries contain one bits (set bits) in the positions that will be lost during the shift. The HOmasks table entries contain a single set bit in the position specified by the index into the table; that is, the entry at index zero contains a one in bit position zero, the entry at index one contains a one in bit position one, and so on. This code selects an entry from each of these tables based on the number of mantissa bits it needs to shift to the right.

If the original mantissa value, logically ANDed with the appropriate entry in masks, is greater than the corresponding entry in HOmasks, then the shiftAndRound function rounds the shifted mantissa to the next greater value. If the ANDed mantissa value is equal to the corresponding HOmasks element, this code rounds the shifted mantissa value according to its LO bit (note that the expression (*valToShift & 1) produces one if the mantissa’s LO bit is one, and it produces zero otherwise). Finally, if the ANDed mantissa value is less than the entry from the HOmasks table, then this code doesn’t have to do anything because the mantissa is already rounded down.

Once we’ve adjusted one of the values so that the exponents of both operands are the same, the next step in the addition algorithm is to compare the signs of the values. If the signs of the two operands are both the same, we can simply add their mantissas (using a standard integer add operation). If the signs of the operands are different, we have to subtract, rather than add, the mantissas. Because floating-point values use one’s complement representation, and standard integer arithmetic uses two’s complement, we cannot simply subtract the negative value from the positive value. Instead, we have to subtract the smaller value from the larger value and determine the sign of the result based on the signs and magnitudes of the original operands. Table 4-3 describes how to accomplish this.

Whenever adding or subtracting two 24-bit numbers, it is possible to produce a result that requires 25 bits (this, in fact, is a common result when dealing with normalized values). Immediately after an addition or subtraction, the floating-point code has to check the result for overflow. If this has happened, it needs to shift the mantissa right by one bit, round the result, and then increment the exponent. After completing this step, all that remains is to pack the resulting sign, exponent, and mantissa fields into the packed 32-bit IEEE floating-point format and the addition (or subtraction) is complete. The following packFP function is responsible for packing the sign, exponent, and mantissa fields into the 32-bit floating-point format:

// packFP:
//
// Packs the sign, exponent, and mantissa fields into a
// 32-bit "real" value. Works for normalized values, denormalized
//  values, and zero, but does not work for NaNs and infinities.

inline real packFP( int sign, int exponent, int mantissa )
{
   return
        (real)
        (
                (sign << 31)
            |   ((exponent + 127) << 23)
            |   (mantissa & 0x7fffff)
        );
}

With the utility routines out of the way, it’s time to take a look at the fpadd function, which adds two floating-point values, producting a 32-bit real result:

// fpadd:
//
//   Computes:
//      dest = left + right
// where all three operands are "real" values (32-bit floats).

void fpadd( real left, real right, real *dest )
{
    // The following variables hold the fields associated with the
    //  left operand:

    int             Lexponent;
    long unsigned   Lmantissa;
    int             Lsign;

    // The following variables hold the fields associated with the
    //  right operand:

    int             Rexponent;
    long unsigned   Rmantissa;
    int             Rsign;

    // The following variables hold the separate fields of the result:

    int   Dexponent;
    long  unsigned Dmantissa;
    int   Dsign;


    // Extract the fields so that they're easy to work with:

    Lexponent = extractExponent( left );
    Lmantissa = extractMantissa( left );
    Lsign     = extractSign( left );

    Rexponent = extractExponent( right );
    Rmantissa = extractMantissa( right );
    Rsign     = extractSign( right );


    // Code to handle special operands (infinity and NaNs):

    if( Lexponent == 127 )
    {
        if( Lmantissa == 0 )
        {
            // If the left operand is infinity, then the result
            //  depends upon the value of the right operand.

            if( Rexponent == 127 )
            {
                // If the exponent is all one bits (127 after unbiasing)
                //  then the mantissa determines if we have an infinity value
                //  (zero mantissa), a QNaN (mantissa = 0x800000) or a SNaN
                //  (nonzero mantissa not equal to 0x800000).

                if( Rmantissa == 0 )  // Do we have infinity?
                {
                    // infinity + infinity = infinity
                    // −infinity − infinity = −infinity
                    // −infinity + infinity = NaN
                    // infinity − infinity = NaN

                    if( Lsign == Rsign )
                    {
                        *dest = right;
                    }
                    else
                    {
                        *dest = 0x7fC00000;  // +QNaN
                    }
                }
                else  // Rmantissa is nonzero, so it's a NaN
                {
                    *dest = right;  // Right is a NaN, propagate it.
                }
            }

        }
        else // Lmantissa is nonzero, Lexponent is all ones.
        {
            // If the left operand is some NaN, then the result will
            //  also be the same NaN.

            *dest = left;
        }

        // We've already calculated the result, so just return.

        return;

    }
    else if( Rexponent == 127 )
    {
        // Two case: right is either a NaN (in which case we need to
        //  propagate the NaN regardless of left's value) or it is
        //  +/− infinity. Because left is a "normal" number, we'll also
        //  wind up propagating the infinity because any normal number
        //  plus infinity is infinity.

        *dest = right;  // Right is a NaN, propagate it.
        return;
    }


    // Okay, we've got two actual floating-point values. Let's add them
    //  together. First, we have to "denormalize" one of the operands if
    //  their exponents aren't the same (when adding or subtracting values,
    //  the exponents must be the same).
    //
    // Algorithm: choose the value with the smaller exponent. Shift its
    //  mantissa to the right the number of bits specified by the difference
    //  between the two exponents.

    Dexponent = Rexponent;
    if( Rexponent > Lexponent )
    {
        shiftAndRound( &Lmantissa, (Rexponent − Lexponent));
    }
    else if( Rexponent < Lexponent )
    {
        shiftAndRound( &Rmantissa, (Lexponent − Rexponent));
        Dexponent = Lexponent;
    }

    // Okay, add the mantissas. There is one catch: if the signs are opposite
    //  then we've actually got to subtract one value from the other (because
    //  the FP format is one's complement, we'll subtract the larger mantissa
    //  from the smaller and set the destination sign according to a
    //  combination of the original sign values and the largest mantissa).

    if( Rsign ^ Lsign )
    {
        // Signs are different, must subtract one value from the other.

        if( Lmantissa > Rmantissa )
        {
            // The left value is greater, so the result inherits the
            //  sign of the left operand.

            Dmantissa = Lmantissa − Rmantissa;
            Dsign = Lsign;
        }
        else
        {
            // The right value is greater, so the result inherits the
            //  sign of the right operand.

            Dmantissa = Rmantissa − Lmantissa;
            Dsign = Rsign;
        }

    }
    else
    {
        // Signs are the same, so add the values:

        Dsign = Lsign;
        Dmantissa = Lmantissa + Rmantissa;
    }

    // Normalize the result here.
    //
    // Note that during addition/subtraction, overflow of one bit is possible.
    //  deal with that possibility here (if overflow occurred, shift the
    //  mantissa to the right one position and adjust for this by incrementing
    //  the exponent). Note that this code returns infinity if overflow occurs
    //  when incrementing the exponent (infinity is a value with an exponent
    //  of $FF);

   if( Dmantissa >= 0x1000000 )
    {
        // Never more than one extra bit when doing addition/subtraction.
        // Note that by virtue of the floating-point format we're using,
        //  the maximum value we can produce via addition or subtraction is
        //  a mantissa value of 0x1fffffe. Therefore, when we round this
        //  value it will not produce an overflow into the 25th bit.

        shiftAndRound( &Dmantissa, 1 ); // Move result into 24 bits.
        ++Dexponent;                    // Shift operation did a div by two,
                                        //  this counteracts the effect of
                                        //  the shift (incrementing exponent
                                        //  multiplies the value by two).
    }
    else
    {
        // If the HO bit is clear, normalize the result
        //  by shifting bits up and simultaneously decrementing
        //  the exponent. We will treat zero as a special case
        //  because it's a common enough result.

        if( Dmantissa != 0 )
        {

            // The while loop multiplies the mantissa by two (via a shift
            //  left) and then divides the whole number by two (by
            //  decrementing the exponent. This continues until the HO bit of
            //  Dmantissa is set or the exponent becomes −127 (zero in the
            //  biased-127 form). If Dexponent drops down to −128, then we've
            //  got a denormalized number and we can stop.

            while( (Dmantissa < 0x800000) && (Dexponent > −127 ))
            {
                Dmantissa = Dmantissa << 1;
                --Dexponent;
            }

        }
        else
        {
            // If the mantissa went to zero, clear everything else, too.

            Dsign = 0;
            Dexponent = 0;
        }
    }

    // Reconstruct the result and store it away:

    *dest = packFP( Dsign, Dexponent, Dmantissa );

}

To conclude this discussion of the software implementation of the fpadd and fsub functions, here’s a C main function that demonstrates the use of these functions:

// A simple main program that does some trivial tests on fpadd and fpsub.

int main( int argc, char **argv )
{
    real l, r, d;

    asreal(l) = 1.0;

    asreal(r) = 2.0;

    fpadd( l, r, &d );
    printf( "dest = %x
", d );
    printf( "dest = %12E
", asreal( d ));

    l = d;
    asreal(r) = 4.0;
    fpsub( l, r, &d );
    printf( "dest2 = %x
", d );
    printf( "dest2 = %12E
", asreal( d ));
}

Most software floating-point libraries are actually written in hand-optimized assembly language, not in a high-level language. As the previous section shows, it’s perfectly possible to write floating-point routines in a high-level language and, particularly in the case of single-precision floating-point addition and subtraction, you could actually write the code efficiently. Given the right library routines, it’s also possible to write the floating-point multiplication and division routines in a high-level language. This section presents an HLA implementation of the single-precision floating-point multiplication and division algorithms, however, because it turns out that their implementation is actually easier in assembly language than in a high-level language like C/C++.

The HLA code in this section implements two functions, fpmul and fpdiv, that have the following prototypes:

procedure fpmul( left:real32; right:real32 );  @returns( "eax" );
procedure fpdiv( left:real32; right:real32 );  @returns( "eax" );

Beyond the fact that this code is written in assembly language rather than C, there are two main differences you should note between the code in this section and the code in the previous section. First, the HLA code uses the built-in real32 data type rather than creating a new data type for our real values. This code can do that because we can easily coerce any 32-bit memory object to real32 or dword in assembly language. Therefore, there is no reason to play games with the data types. The second thing you’ll notice about these prototypes is that they only support two parameters; there is no destination parameter. These functions simply return the real32 result in the EAX register.^[17]

mov( (type dword left), ebx );  // Result sign is the XOR of the
xor( (type dword right), ebx ); //  operand signs.
and( $8000_0000, ebx );         // Keep only the sign bit.

mov( (type dword left), ecx );    // Exponent goes into bits 23..30
and( $7f80_0000, ecx );           //  of ECX; mask these bits.
sub( 126 << 23, ecx );            // Eliminate the bias of 127.

mov( (type dword right), eax );
and( $7f80_0000, eax );

// For multiplication, we need to add the exponents:

add( eax, ecx );                  // Exponent value is now in bits
                                  //  23..30 of ECX.

mov( (type dword left), eax );
mov( (type dword right), edx );

// If we don't have a zero value then set the implied HO bit of the mantissa:

if( eax <> 0 ) then

    or( $80_0000, eax );  // Set the implied bit to one.

endif;
shl( 8, eax );  // Moves mantissa to bits 8..31 and removes sign/exp.

// Repeat this for the right operand.

if( edx <> 0 ) then

    or( $80_0000, edx );

endif;
shl( 8, edx );

mul( edx );

test( $80, edx );  // Clears zero flag if bit seven of EDX = 1.
if( @nz ) then

    add( $FFFF_FFFF, eax );  // Sets carry if EAX <> 0.
    adc( $7f, dl );          // Sets carry if DL:EAX > $80_0000_0000.
    if( @c ) then

        // If DL:EAX > $80_0000_0000 then round the mantissa
        //  up by adding one to bit position eight:

        add( 1 << 8, edx );

    else // DL:EAX = $80_0000_0000

        // We need to round to the value that has a zero
        //  in bit position zero of the mantissa (bit #8 of EDX):

        test( 8, edx );  // Clears zero flag if bit #8 contains a one.
        if( @nz ) then

            add( 1 << 8, edx );  // Adds a one starting at bit position eight.

            // If there was an overflow, renormalize:

            if( @c ) then

                rcr( 1, edx );  // Shift overflow (in carry) back into EDX.
                inc( ecx );     // Shift did a divide by two. Fix that.

        endif;

        endif;

    endif;

endif;

shr( 8, edx );          // Move mantissa into bits 0..23.
and( $7f_ffff, edx );   // Clear the implied bit.
lea( eax, [edx+ecx] );  // Merge mantissa and exponent into EAX.
or( ebx, eax );         // Merge in the sign.

mov( (type dword left), ecx );  // Exponent comes from bits 23..30.
shr( 23, ecx );
and( $ff, ecx );                // Mask out the sign bit (in bit 8).

mov( (type dword right), eax );
shr( 23, eax );
and( $ff, eax );

// Eliminate the bias from the exponents:

sub( 127, ecx );
sub( 127, eax );

// For division, we need to subtract the exponents:

sub( eax, ecx );                // Leaves result exponent in ECX.

mov (type dword left), edx );
if( edx <> 0 ) then

    or( $80_0000, edx );   // Set the implied bit to one in the left operand.
    shl( 8, edx );

endif;
mov( (type dword right), edi );
if( edi <> 0 ) then

    or( $80_0000 );        // Set the implied bit to one in the right operand.
    shl( 8, edi );

else

    // Division by zero error, here.

endif;

xor( eax, eax );    // EAX := 0;
shr( 1, edx );      // Shift EDX:EAX to the right one bit to
rcr( 1, eax );      //  prevent a division error.
div( edi );         // Compute EAX = EDX:EAX / EDI.

test( $80, al );    // See if the bit just below the LO bit of the
if( @nz ) then      //  mantissa contains a zero or one.

    // Okay, the bit just below the LO bit of our mantissa contains a one.
    // If all other bits below the mantissa and this bit contain zeros,
    //  we have to round to the nearest mantissa value whose LO bit is zero.

    test( $7f, al );             // Clears zero flag if bits 0..6 <> 0.
    if( @nz || edx <> 0 ) then   // If bits 0..6 in AL are zero and EDX
                                 //  is zero.

        // We need to round up:

        add( $100, eax );  // Mantissa starts in bit #8 );
        if( @c ) then      // Carry set if mantissa overflows.

            // If there was an overflow, renormalize.

            rcr( 1, eax );
            inc( ecx );

        endif;

    else

        // The bits below the mantissa are exactly 1/2 the value
        //  of the LO mantissa bit. So we need to round to the value
        //  that has a LO mantissa bit of zero:

        test( $100, eax );
        if( @nz ) then

            add( $100, eax );
            if( @c ) then

                // If there was an overflow, renormalize.

                rcr( 1, eax );  // Put overflow bit back into EAX.
                inc( ecx );     // Adjust exponent accordingly.

            endif;

        endif;

    endif;

endif;

if( (type int32 ecx) > 127 ) then

    mov( $ff−127, ecx );    // Set exponent value for infinity
    xor( eax, eax );        //  because we just had overflow.

elseif( (type int32 ecx) < −128 ) then

    mov( −127, ecx );       // Return zero for underflow (note that
    xor( eax, eax );        //  next we add 127 to ECX).

endif;
add( 127, ecx );            // Add the bias back in.
shl( 23, ecx );             // Move the exponent to bits 23..30.

// Okay, assemble the final real32 value:

shr( 8, eax );              // Move mantissa into bits 0..23.
and( $7f_ffff, eax );       // Clear the implied bit.
or( ecx, eax );             // Merge mantissa & exponent into EAX.
or( ebx, eax );             // Merge in the sign.