The DAA general-purpose instruction adjusts the EFLAGS for a decimal carry after an addition.

Flags: The Aux and Carry flags are set to 1 if an addition resulted in a decimal carry in their associated 4-bit nibble; otherwise they are cleared to 0.

        xor     eax,eax         ; Reset Carry(s)
   $L1: mov     al,[edi]        ; D = D + A
        adc     al,[esi]
        daa
        mov     [edi],al        ; Store result
        dec     esi
        dec     edi
        dec     ecx
        jne     $L1             ; Loop for n BCD bytes

Note that this function steps through memory in reverse byte order, which is not processor efficient. High digits are in low offset bytes, and low digits are in high offset bytes: {N...0}. So the operation must go to the end of the buffer and traverse memory backward from low-digit pairs to high-digit pairs. If not working with the FPU to handle BCD, then each nibble pair could be stored in reverse order: {0...N}. Only when they need to be displayed or printed would there be a reverse increment through memory. Note this is backward to the ordering of the FPU! The sample code uses this method.

The DAS general-purpose instruction adjusts the EFLAGS for a decimal borrow after a subtraction.

Flags: The Aux and Carry flags are set to 1 if a subtraction resulted in a decimal carry set due to a borrow in their associated 4-bit nibble; otherwise they are cleared to 0.

        xor  eax,eax     ; Reset Carry(s)
   $L1: mov  al,[edi]    ; D = D + A
        sbb  al,[esi]
        das
        mov  [edi],al    ; Store result
        dec  esi
        dec  edi
        dec  ecx
        jne  $L1         ; Loop for n BCD bytes

The AAA general-purpose instruction adjusts the EFLAGS for a decimal carry. If a resulting calculation is greater than 9, then AL is set to the remainder between (0...9) and AH is incremented.

Flags: The Aux and Carry flags are set to 1 if a decimal carry resulted; otherwise they are cleared to 0.

        add     al,ah
        aaa
        or      al,'0'    ; '0' + {0...9} = ASCII '0...9'

The AAS general-purpose instruction adjusts the EFLAGS depending on the results of the AL register after a multiplication operation. If a resulting calculation sets the carry indicating a borrow has occurred, then AL is set to the remainder between (0...9) and AH is decremented.

Flags: The Aux and Carry flags are set to 1 if a decimal borrow resulted; otherwise they are cleared to 0.

        sub     al,'7'
        aas
        or      al,'0'        ; '0' + {0...9} = ASCII '0...9'

The AAM general-purpose instruction adjusts the EFLAGS depending on the results of the AL register after a multiplication operation.

Flags: The Sign, Zero, and Parity flags are set to the resulting value in theAL register.

        mul     al,bh
        aam

The AAD general-purpose instruction adjusts the EFLAGS in preparation for a division operation.

Flags: The Sign, Zero, and Parity flags are set to the resulting value in the AL register.

        and     eax,0000111100001111b
        aad

How does this all work? Well, the FPU has a single instruction that loads a BCD value and converts it to an 80-bit (10-byte) double extended precision floating-point value that it stores on the FPU stack. This can then be written back to computer memory as double-precision floating-point. Simple, fast, and minimal excess code and nothing time intensive.

    unsigned char bcd[10];
    double f;

    __asm {
      fbld tbyte ptr bcd        ; Load (80-bit) BCD
      fstp f                    ; Write 64-bit double-precision
    }

The returned floating-point value contains the BCD number as an integer with no fractional component. For example:

   byte bcd[10] = {0x68, 0x23, 0x45, 0x67, 0x89, 0x98, 0x87, 0x76, 0x65,
                   0x80};

The float returned is –657,687,988,967,452,368.0

At this point the decimal place needs to be adjusted to its correct position using the product of an exponential 10^-n. This can be done with either a simple table lookup or a call to the function pow(10,-e), but the table lookup is faster. And speed is what it is all about.

Calling the standard C language function atof() to convert an ASCII floating-point value to single or double-precision will add significant time onto your processing time for those large ASE files.

But I have good news for you. The following function will carve those hours back to something a lot more reasonable. What it does is take advantage of a little-known functionality within the floating-point unit of the 80×86 processor.

As discussed in Chapter 8, the FPU loads and handles the following data types:

Note that the following code sample expects a normal floating-point number and no exponential. The ASE files do not contain exponential, just really long ASCII floating-point numbers; thus, the reason this code traps for more than 18 digits.

   double exptbl[] = // -e
   {
     1.0,                 0.1,
     0.01,                0.001,
     0.0001,              0.00001,
     0.000001,            0.0000001,
     0.00000001,          0.000000001,
     0.0000000001,        0.00000000001,
     0.000000000001,      0.0000000000001,
     0.00000000000001,    0.000000000000001,
     0.0000000000000001,  0.00000000000000001,
     0.000000000000000001
   };                             // Limit 18 places

   double ASCIItoDouble(const char *pStr)
   {
   #ifdef CC_VMP_WIN32
     unsigned int dig[80], *pd;
     unsigned char bcd[10+2], *pb;
     double f;
     int n, e;
     const char *p;

     ASSERT_PTR(pStr);

     *(((uint32*)bcd)+0) = 0;   // Clear (12 bytes)
     *(((uint32*)bcd)+1) = 0;
     *(((uint32*)bcd)+2) = 0;   // 2 + 2 spare bytes

        // Collect negative/positive – and delimiters are pre-stripped.

     p = pStr;
     if ('-' == *p)

   {
     *(bcd+9) = 0x80; // Set the negative bit into the BCD
     p++;
   }
      // Collect digits and remember position of decimal point

   *dig = 0;             // Prepend a leading zero
   e = n = 0;
   pd = dig+1;

   while (('0' <= *p) && (*p <= '9'))
   {
     *pd++ = (*p++ - '0'), // Collect a digit
     n++;

     // The decimal place is checked after the first digit as no
     // floating-point value should start with a decimal point.
     // Even values between 0 and 1 should have a leading zero! 0.1
     if ('.' == *p)      // Decimal place?
     {                   // Remember its position
       e = n;
       p++;
     }
   }

   // Check for a really BIG (and thus ridiculous) number

   if (n > 18)          // More than 18 digits?
   {
     return atof(pStr);
   }

   if (e)               // 0=1.0 1=0.1 2=0.01 3=0.001, etc.
   {
     e = n - e;         // Get correct exponent
   }

      // repack into BCD (preset lead zeros)
      // last to first digit

   n = (n+1)>>1;          // Start in middle of BCD buffer
   pb = bcd;              // Calc. 1st BCD character position

   while(n--)             // loop for digit pairs
   {
     pd-=2;               // Roll back to last 2 digits
     *pb++ = ((*(pd+0)<<4) | *(pd+1)); // blend two digits
   }

    __asm {
      fbld tbyte ptr bcd    ; Load (10-byte) BCD
      fstp f                ; Write 64-bit double-precision
    }

      return f * exptbl[e];                  // FASTER
  //  return f * pow( 10.0, (double) -e );   // FAST
  #else
    return atof(p);                          // Really SLOW
  #endif
  }

If you do not believe me about the speed, then replace all the atof() functions in your current tool with a macro to assign 0.0 and measure the difference in speed. Or better yet, embed the atof() function within this function and then do a float comparison with the precision slop factor since by now you should be very aware that you never ever compare two floating-point numbers to each other to test for equivalence unless a precision slop factor (accuracy) is utilized.

One more thing: If you insist on using atof() or sscanf(), copy the ASCII number to a scratch buffer before processing it with either of these two functions because processing them within a 20MB file dramatically increases the processing time by hours. Apparently these conversion functions scan the string until they reach the terminator, which in the case of an ASE file can be a few megabytes away instead of a few bytes.