NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/sys/intel/2165

Internet Message Format | 1992-11-07 | 1.6 KB

Path: sparky!uunet!europa.asd.contel.com!emory!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!spool.mu.edu!sgiblab!munnari.oz.au!comp.vuw.ac.nz!waikato.ac.nz!aukuni.ac.nz!cs18.cs.aukuni.ac.nz!pgut1
Newsgroups: comp.sys.intel
Subject: Re: Undocumented instructions in x86 CPUs
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
Date: Fri, 6 Nov 1992 03:49:17 GMT
References: <[e-mail]> <FH==sq#@engin.umich.edu> <[e-mail]>
Organization: Computer Science Dept. University of Auckland
Lines: 25

In <[e-mail]> [e-mail] (Guy Harris) writes:

>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.

Correct.  Supposedly Intel ran out of space in the microcode for the operand
so they made it external.  You can use other operands if you want.

>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.

It works with everything up to a '386, but does *not* work on the NEC CPU's.

There is some other instruction which does this as well and which does work
on the NEC CPU's (I think), but I can't look up the exact details since all the
info is at home.

Peter.
--
    [e-mail] || [e-mail] || [e-mail]
                   (In order of preference)