🚀 go-pugleaf

>Sure, AAM (ASCII adjust after multiplication) is a well known instruction.

Yup.

In fact, unless you're referring to some *other* AAM instruction, AAM is
so well-known it's even on page 17-20 of the 1986 edition of the "80386
Programmer's Reference Manual"....

However, it *doesn't* mention what happens in AAM if the second byte of
the instruction *isn't* 0A.  The "One-Byte Opcode Map" on page A-4
shows AAM in the D4 location, which seems to indicate that D4 is the AAM
opcode, so maybe, in fact, the second byte is a secret operand that's
the base of the number system for which it's doing the adjustment.

In addition, AAM is claimed to take 17 cycles in the table on page E-5,
and an unsigned divide is claimed to take - surprise, surprise - 14 to
17 cycles with a one-byte operand.

Sounds as if AAM was - at least in the implementations on which you
tried it - really the "divide AL by a one-byte immediate operand,
stuffing the quotient into AH and remainder in AL" instruction....

10 hex is 16 decimal, and if D4 10 does a base-16 AAM, then it would be

	AH = AL >> 4
	AL = AL & 0xF

Try it with hex 11, and see if it does

	AH = AL / 17
	AL = AL MOD 17

Note, though, that they may have cut corners in future implementations,
such as the 586^H^H^HPentium, so that hex A is the only operand that
works correctly.

The same, of course, may well apply to *other* undocumented
instructions; programmer, beware!  (What's Latin for "programmer"? :-))
I've heard a claim that the bit-field instructions didn't completely
work, even on the 386; I've no idea whether there's any truth to that
claim or not.