boykin@custom.UUCP (Joseph Boykin) (08/05/87)
I was looking through my handy-dandy 80X86 programmers reference and noticed something that I thought was a little strange. The AAD instruction (ASCII Adjust before division), does the following: AL = AL + (10 * AH). AH = 0 This instruction has a 'two' byte op-code, which really didn't seem necessary; i.e. why couldn't the instruction be encoded in one byte? OK, one-byte opcodes are valuable and you don't want to waste it on a semi-useless instruction. The other point was that the second byte was 0A. Humm, an instruction which multiplies the least significant nibble by 10 has a 10 as its second byte! Taking out my handy debugger I found that AAD *is* a one-byte instruction with the second byte acting as a parameter. Try coding the following: db 0d5h, 10h and you'll create an instruction which does: AL = AL + (16 * AH) AH = 0. I'm not sure what value such an instruction might have. Looking at the instruction timings a MUL is faster, but I'm sure someone will find a case where this is useful. If you do, let me know! Joe Boykin Custom Software Systems ...necntc!custom!boykin
dhesi@bsu-cs.UUCP (Rahul Dhesi) (08/06/87)
In article <767@custom.UUCP> boykin@custom.UUCP writes: >Taking out my handy debugger I found that >AAD *is* a one-byte instruction with the second byte acting >as a parameter. Try coding the following: > > db 0d5h, 10h > >and you'll create an instruction which does: > AL = AL + (16 * AH) > AH = 0. > >. . . I'm sure someone >will find a case where this is useful. If you do, let me know! When offering advice like this, please always be sure to include this disclaimer: "WARNING: SOFTWARE TAKING ADVANTAGE OF THIS INFORMATION WILL PROBABLY FAIL IN THE FUTURE." Remember, naive users may not realize this unless you tell them. The above undocumented feature of the 8086 does not work on all processors in the family. Stick to documented instructions. If you can't resist the temptation of pushing you luck, at least refrain from advising others to do the same without adequate warning of the folly of this type of programming technique. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
boykin@custom.UUCP (Joseph Boykin) (08/07/87)
In article <929@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > In article <767@custom.UUCP> boykin@custom.UUCP writes: > >Taking out my handy debugger I found that > >AAD *is* a one-byte instruction with the second byte acting > >as a parameter. > > When offering advice like this, please always be sure to include this > disclaimer: "WARNING: SOFTWARE TAKING ADVANTAGE OF THIS INFORMATION > WILL PROBABLY FAIL IN THE FUTURE." Remember, naive users may not > realize this unless you tell them. You're ABSOLUTELY correct! I've violated one of my own basic rules! I found it interesting that the instruction had the multiplier as the second byte, and that is all. I most definately do not recommend using such instructions outside of a confined set of machines. Joe Boykin Custom Software Systems ...necntc!custom!boykin
NU013809@NDSUVM1.BITNET (Greg Wettstein) (08/10/87)
I don't know how factual the following comment is but I have heard a
rationale for the two byte instruction which implements the AAD operation.
Folklore has it that when the 80x86 chipset was designed the chip designers
got caught in a microcode storage bind. Rather than wasting valuable
micro-code space they simply setup the AAD class of instructions to carry
the parameter for the adjustment in in-line code rather than coding the
full instruction in microcode.
Whether this is true or not may be the subject of much debate. However
it provides an interesting story if nothing else.
As always,
G.W. Wettstein