Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Undocumented 8086 instructions, explained by the microcode

righto.com

Post reply on HN
Print view View original

91–100 of 104 posts

Re: Undocumented 8086 instructions, explained by the microcode

#91

Post by rep_lodsb »

kens wrote: post #61
userbinator wrote: post #35

Although these registers are normally not accessible by the programmer, some undocumented instructions provide access to these registers, as will be described later. Reminds me of the MEMPTR on Z80: https://gist.github.com/drhelius/8497817 Also, I'm not sure if you've explored 8f/1-7 yet, since it's not mentioned in the article, but I suspect it's just the same as pop r/m16 (8f/0) as it ignores the subopcode bits com…

I hadn't noticed that characteristic of 8F. Looking at the microcode, the subopcode bits are ignored, so I think your analysis is correct. I agree that it's very weird that PUSH rm and POP rm are arranged completely differently. The obvious place to put POP would be in FF/7, especially since that spot is unused. I can't think of any reason why they wouldn't do that.

The reason is that opcode FE/FF with a memory operand will always read it into the 'M' register, which would be unwanted for POP.

Re: Undocumented 8086 instructions, explained by the microcode

#93

Post by rep_lodsb »

userbinator wrote: post #28
kens wrote: post #21

Earlier quoted context omitted.

My transistor-level simulator shows that the 8086 will generate a divide by 0 interrupt if you give the AAM instruction a divisor of 0. But I haven't tried this on a real chip.

It does on newer physical hardware too.

With the one exception being the 80186, where 'AAM 00h' will result in AH=FFh. It passes the divisor directly to the ALU engine without checking for zero, most likely rationale being that operands other than 0Ah are undocumented :)

That was fixed (either in microcode or hardware) on all later generations. And the 8086/88 did the check in the CORD subroutine of course, which is used by both DIV and AAM.

Re: Undocumented 8086 instructions, explained by the microcode

#94

Post by NobodyNada »

pickledcods wrote: post #76

This begs for the challenge: How would a program look like if the opcodes it could use exclusively consists of ASCII characters? This has been a niche programming challenge which was popular before I knew it existed, so I upped the ante by using alpha-numeric only. The usable opcodes where practically IMUL and XOR with severe limitation on registers and offset. But with them I managed to create a random number genera…

A friend of mine (and one of the best CTF players I’ve ever met) once wrote shellcode that used only the [0-9A-F] ASCII character range and self-modified to access other instructions.

Re: Undocumented 8086 instructions, explained by the microcode

#95

Post by rep_lodsb »

porlw wrote: post #90

I remember back in the day these were used by the A86 assembler to identify code assembled with the unregistered version of the software.

Not exactly. It used the two different encodings possible for source/destination operand when both are registers.

For example, 'ADD AL,CL' can be encoded as (values in octal):

    000 310 : 3=reg/reg  1=source is CL  0=dest. is AL
    002 301 : 3=reg/reg  0=dest is AL    1=src. is CL
Other assemblers always use one of these consistently, A86 switches between them depending on some bits of the opcode and operands (but each instruction will always be encoded the same when it appears multiple times, there is no steganographic message embedded).

Re: Undocumented 8086 instructions, explained by the microcode

#96

Post by peterfirefly »

rep_lodsb wrote: post #93
userbinator wrote: post #28

Earlier quoted context omitted.

It does on newer physical hardware too.

With the one exception being the 80186, where 'AAM 00h' will result in AH=FFh. It passes the divisor directly to the ALU engine without checking for zero, most likely rationale being that operands other than 0Ah are undocumented :) That was fixed (either in microcode or hardware) on all later generations. And the 8086/88 did the check in the CORD subroutine of course, which is used by both DIV and AAM.

Was the 186 really different from the 286 in that respect?

Re: Undocumented 8086 instructions, explained by the microcode

#97

Post by rep_lodsb »

peterfirefly wrote: post #96
rep_lodsb wrote: post #93

Earlier quoted context omitted.

With the one exception being the 80186, where 'AAM 00h' will result in AH=FFh. It passes the divisor directly to the ALU engine without checking for zero, most likely rationale being that operands other than 0Ah are undocumented :) That was fixed (either in microcode or hardware) on all later generations. And the 8086/88 did the check in the CORD subroutine of course, which is used by both DIV and AAM.

Was the 186 really different from the 286 in that respect?

Yes, the 186 microcode is remarkably similar to that of the original 8086, except for some encoding differences.

Multiply/divide is now assisted by the ALU, so the microcode mainly has to set up the registers and do the check for zero divisor / overflow. There is also a final adjustment to the result, because the hardware uses a non-restoring algorithm that may underflow. And for signed division, the operands are converted to unsigned first and the result possibly negated at the end, using the F1 flag to store the sign like on the 8086.

The 286's instruction decoder and microcode ROM are entirely different: 1536 words of 35 bits, with the entry point determined by a separate PLA.

Re: Undocumented 8086 instructions, explained by the microcode

#99

Post by kens »

rep_lodsb wrote: post #92
peterfirefly wrote: post #85

> An invalid register is used with an otherwise valid opcode (e.g., MOY CS,AX). MOV CS, AX

That paragraph looks like bad OCR copied from some PDF - it also has the letter 'O' replacing the digit '0' in all the hex numbers.

Yes, I cut-and-pasted that paragraph from the 286 manual and clearly I shouldn't have trusted the OCR :-)
Post reply on HN