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

61–70 of 104 posts

Re: Undocumented 8086 instructions, explained by the microcode

#61

Post by kens »

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.

Re: Undocumented 8086 instructions, explained by the microcode

#62

Post by kiwidrew »

colejohnson66 wrote: post #2

A lot of the undocumented instruction "match" bits make sense, such as POP CS at [0F]. However, it's clear that the authors of the microcode deliberately made every opcode match to some routine, as evidenced by Jcc being mirrored into the [60..6F] region, LOCK into [F1], group 2 /6 into /7, etc. It wouldn't've "cost" anything extra to make Jcc only match on its documented [70..7F] region (and others) like later proce…

When implementing the decoding in silicon, each bit you want to compare requires one or more transistors; but no transistors are required for the "don't care" bits.

Re: Undocumented 8086 instructions, explained by the microcode

#64

Post by SomeRndName11 »

sedatk wrote: post #57
greenyoda wrote: post #5

Earlier quoted context omitted.

Also the 6800, with its famous HCF (Halt and Catch Fire) instruction: > With the advent of the MC6800 (introduced in 1974), a design flaw was discovered by programmers. Due to incomplete opcode decoding, two illegal opcodes, 0x9D and 0xDD, will cause the program counter on the processor to increment endlessly, which locks the processor until reset. Those codes have been unofficially named HCF. During the design proce…

Also a fantastic TV series about the personal computing era of the 80's. https://www.imdb.com/title/tt2543312/

The show is mediocre, lots of technical inaccuracies.

Re: Undocumented 8086 instructions, explained by the microcode

#65

Post by kens »

kiwidrew wrote: post #62
colejohnson66 wrote: post #2

A lot of the undocumented instruction "match" bits make sense, such as POP CS at [0F]. However, it's clear that the authors of the microcode deliberately made every opcode match to some routine, as evidenced by Jcc being mirrored into the [60..6F] region, LOCK into [F1], group 2 /6 into /7, etc. It wouldn't've "cost" anything extra to make Jcc only match on its documented [70..7F] region (and others) like later proce…

When implementing the decoding in silicon, each bit you want to compare requires one or more transistors; but no transistors are required for the "don't care" bits.

Since the decoder is implemented in a PLA-style matrix, you don't save any space by omitting transistors. So that's not a motivation.

Random thing: chip transistor counts usually count "transistor sites" rather than physical transistors, so the omitted transistors still show up in the transistor counts.

Re: Undocumented 8086 instructions, explained by the microcode

#66

Post by Max-q »

I love this blog series that just goes on and on. Keep up the good work!

One thing I'm thinking about: I grew up writing 6502 assembly on the VIC20 and C64. We hated the 8086 back then, as kids do with hardware. When growing up I saw that we were partly right. The 6502 performed very well compared to the IBM PC on practical tasks. But the 6502 is a dirt simple, while the 8086 is surprisingly complex. Was the PC slow due to 8088 and not 8086?

I can of course just Google it or check the op code table. But always fun to talk about old technology :)

Re: Undocumented 8086 instructions, explained by the microcode

#67

Post by peterfirefly »

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.

> Looking at the microcode, the subopcode bits are ignored, so I think your analysis is correct.

That's what Andrew Jenner's emulator code does.

https://github.com/reenigne/reenigne/blob/master/8088/xtce/x...

Line 3049.

Re: Undocumented 8086 instructions, explained by the microcode

#68

Post by watersb »

_ugfj wrote: post #15

> The undocumented C9 opcode is identical to the documented CB, far return instruction. I remember this. Once ... gosh, it's hard to believe how long ago that was now, but once I knew the entire Z80 opcode table off head. I could read the Z80 machine code and disassemble it. High school crowded that stuff out of my head, I went to a special math school, it was very very hard. Except... C9 was RET (and the Z80 is an e…

Somewhere around here, I've got a notebook, it's pages of hex dump written with a pencil in a child's handwriting.

I couldn't afford a printer.

Re: Undocumented 8086 instructions, explained by the microcode

#69

Post by peterfirefly »

quotemstr wrote: post #52

I can only imagine the nail-biting at Intel when repurposing the 8086's undocumented but instruction aliases for new 80[123]86's instructions. Intel had no way of knowing whether someone, somewhere, had written software using these aliases.

My guess is that they didn't care much when they made the 186/286 because it wasn't yet clear how big the PC would get -- and those chips did a lot to weed out bad programs (the once they didn't use caused INT 6) so they felt perfectly safe when they made the 386.

Re: Undocumented 8086 instructions, explained by the microcode

#70

Post by peterfirefly »

pwg wrote: post #47
bruce343434 wrote: post #11

Where can one learn more about microcode, how it's implemented in silicon? As I understand it most machine code is actually "VM bytecode", and the "real" cpu is the microcode processor?

> Where can one learn more about microcode, Provided you can find a copy, the book "Computer Organization", 2nd ed, by V. Car Hamacher, Zvonko G. Vranesic and Safwat G. Zary, published by McGraw Hill, contains a very understandable chapter of microcode control. Depending on your background, you may want to read some of the prior chapters first before starting on the microcode one, to get some foundational knowledge.…

Amazon has some used copies.
Post reply on HN