From : Joe Koss                                               1:142/8076
--------------------------------------------------------------------------
AAD - D5 IMM8 - ASCII Adjust before Division 
 
 
Undocumented:  Available to all Intel x86 processors
               Useful in production source code.
                                                              AAD
Flags:                               ASCII Adjust before Division
+-+-+-+-+-+-+-+-+-+                       +----------+----------+
|O|D|I|T|S|Z|A|P|C|                       | 11010101 |   DATA   |
+-+-+-+-+-+-+-+-+-+                       +----------+----------+
|+| | | |+|+|+|+|+|                       |    D5    |     IMM8 |
+-+-+-+-+-+-+-+-+-+                       +----------+----------+
 
 
This instruction is the multiplication counterpart to AAM. As is the 
case with AAM, AAD uses the second byte as an operand. This operand is 
the multiplicand for AAD. Like AAM, AAD provides a way to execute a MUL 
IMM8 that is unavailable through any other means in the CPU. Unlike MUL, 
or IMUL, AAD sets all of the CPU status flags according to the result. 
Intel states that the Overflow Flag (OF), Auxiliary carry Flag (AF), and 
Carry Flag (CF) are undefined. This assertion is incorrect. These flags 
are fully defined, and are set consistently with respect to any other 
integer operations. And again, like AMM, beginning with the Pentium, 
Intel has finally acknowledged the existence of the second byte of this 
instruction as its operand. Intel says:
 
"Note: imm8 has the value of the instruction's second byte. The second 
byte under normally assembly [sic] of this instruction will be 0A, 
however, explicit modification of this byte will result in the operation 
described above and may alter results."
 
This instruction exists in this form on all Intel x86 processors. See 
the file AAD.ASM for diagnostics source code for this instruction. 

----------------------------------------------------------------------------
 
AAM - D4 IMM8 - ASCII Adjust after Multiplication 
 
 
Undocumented:  Available to all Intel x86 processors.
               Useful in production source code.
                                                              AAM
Flags:                                ASCII Adjust after Multiply
+-+-+-+-+-+-+-+-+-+                       +----------+----------+   
|O|D|I|T|S|Z|A|P|C|                       | 11010100 |   DATA   |
+-+-+-+-+-+-+-+-+-+                       +----------+----------+
| | | |+|+|+|                       |    D4    |     IMM8 |
+-+-+-+-+-+-+-+-+-+                       +----------+----------+
 
 
AAM is shown as a two byte encoding used to divide AX by 10, putting the 
quotient in AH, and the remainder in AL. However, AAM is listed in the 
op code map as a single byte instruction. This leads one to wonder why a 
two-byte opcode is listed in the single-byte opcode map. In reality, the 
second byte is an undocumented operand to AAM. The operand is the 
divisor. In its documented incarnation, AAM is encoded as D4 0A. The 
operand 0A is the divisor. This divisor can be changed to any value 
between 0 and FF. Using AAM in this manner is useful -- as it extends 
the CPU instruction set to include a DIV IMM8 instruction that is not 
available from any other form of the DIV instruction. The extended form 
of the AAM instruction is also useful because it sets the flags register 
according to the results, unlike the DIV or IDIV instruction. According 
to Intel documentation, SF, ZF, and PF flags are set according to the 
result, while OF, AF, and CF are undefined. However, if AAM were used 
strictly as documented, then the Sign Flag (SF) could not be set under 
any circumstances, since anything divided by 10 will leave a remainder 
between 0 and 9. Obviously the remainder could never be between 128 and 
255 (or -1 and -128 if you prefer) if used only as documented. Since AAM 
divides an 8 bit number by another 8-bit number, a carry or overflow 
could never occur. Therefore CF and OF always=0. Intel claims they are 
undefined, but my observations are consistent with my theory. Contrary 
to documentation, AAM will generate exceptions in real mode, protected 
mode, and V86 mode. AAM can only generate Exception 0 -- divide by 0. 
Finally, in the Pentium User's Manual, this heretofore undocumented form 
of AMM is described. Intel says:
 
"Note: imm8 has the value of the instruction's second byte. The second 
byte under normally assembly [sic] of this instruction will be 0A, 
however, explicit modification of this byte will result in the operation 
described above and may alter results."
----------------------------------------------------------------------------
 
SALC - D6 - Set AL on Carry 
An undocumented op code that performs an operation common to every 
Assembly language subroutine to C and many other higher level languages. 
This instruction is a C programmers 'dream' instruction for interfacing 
to assembly language. 
 
 
Undocumented:  Available to all Intel x86 processors 
               Useful in production source code.
                                                             SALC
Flags:                                       SET Carry flag to AL  
+-+-+-+-+-+-+-+-+-+                                  +----------+
|O|D|I|T|S|Z|A|P|C|                                  | 11010110 |
+-+-+-+-+-+-+-+-+-+                                  +----------+
| | | | | | | | | |                                  |    D6    |
+-+-+-+-+-+-+-+-+-+                                  +----------+ 
 
 
The name SALC simply stands for SET the Carry flag in AL. This 
instruction is categorized as an undocumented single-byte proprietary 
instruction. Intel claims it can be emulated as a NOP. Hardly a NOP, 
this instruction sets AL=FF if the Carry Flag is set (CF=1), or resets 
AL=00 if the Carry Flag is clear (CF=0). It can best be emulated as SBB 
AL,AL. SALC doesn't change any flags, where SBB AL,AL does. This 
instruction is most useful to high-level language programmers whose 
programs call assembly language, and expect AL to indicate success or 
failure. Since it is convenient for assembly language programs to return 
status in the CF, this instruction will convert that status to a form 
compatible with high level languages.
 
Over the years, this instruction has been given many names by various 
discoverers. I originally gave it the name SETCAL, but the most common 
name I've seen in print is SETALC. The name given above, SALC is an 
official Intel name. While perusing the P6 opcode map, I always check 
for known, undocumented opcodes. After weeding through the map for many 
minutes, my patience and perseverance paid off. I found the opcode, and 
its name. Intel's name for this opcode is SALC. This would indicate that 
Intel plans to officially document this instruction, beginning with the 
P6. 

--------------------------------------------------------------------------

