I'm just curious why the 8086 seems to be lacking in an adjust opcode for fixing up packed BCD multiplication. It seems like it would be a useful thing, and packed BCD seems to be more common to begin with.
To adjust a value, one needs to know how many carries there were out of each decimal digit. When adding two 8-bit numbers, there can be at most one carry out of each 4-bit chunk, which will fit in two flags which are devoted to that purpose. Multiplication of two decimal digits, however, may yield up to eight carries--far too many to fit into two one-bit flags.
Consider, for example, the multiplication of 0x12 by 0x04, 0x18 by 0x03, or 0x09 by 0x08. All three will yield 0x48 prior to adjustment, but they have different numbers of carries out of the bottom digit, and should thus yield different values after adjustment. The first has no carry out of the bottom digit and should stay 0x48. The second has two carries out of the bottom digit and should have 12 (6 per carry) added to yield 0x54. The third has seven carries out of the bottom digit and should have 42 added to yield 0x72.
There are ways of designing circuitry to multiply packed BCD reasonably efficiently, but doing so would require continuously updating the result for BCD during the multiplication process, rather than at the end.
AAM is needed because the result of multiplying two unpacked BCD is a 'strange' value that needs to be 'normalized' again.
The whole mechanic of using the binary multiply with BCD only woks with 'unpacked' values. Using two packed BCD values will return a result that can't be decoded as easy.
To allow multiplication with packed BCD would have required the addition of decimal multiplication functions as separate operation, a quite complex one, as the 8086 does not contain any decimal units, but repurposes the binary ALU - much like the 8080 did. And that's why it needs the 'correcting' instructions.
If one needs high performance BCD, the usage of a 8087 would be recommended