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

1–10 of 104 posts

Re: Undocumented 8086 instructions, explained by the microcode

#2

Post by colejohnson66 »

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 processors do. What's the advantage of matching on undefined byte sequences?

Also, SALC is still technically undocumented by Intel (AMD documents it, though). It doesn't have a dedicated section in the SDM (would be in Volume 2, Chapter 4), and in the opcode map (Volume 2, Appendix A), there's a blank there. One actually has to go to Volume 3, Chapter 23 "Architecture Compatibility", Section 15 "Undefined Opcodes" (of version 080 from June) to see it mentioned. It's weird. They even call it out as SALC "when not in 64-bit mode" and that it performs "IF (CF=1), AL=FF, ELSE, AL=0", but refuse to officially document it.

Re: Undocumented 8086 instructions, explained by the microcode

#3

Post by kens »

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…

There's a reason why every 8086 opcode matches something. If an instruction didn't match anything, I think the microcode engine would spin idle and the instruction would never terminate. (You need a RNI micro-instruction to end microcode processing.) Having your processor lock up due to a bad opcode is something that the designers presumably explicitly avoided.

The 6502 on the other hand, didn't take such precautions. There are opcodes that cause the internal timing state machine to sort of fall off the end, causing the CPU to lock up and even an interrupt won't rescue you. You need a RESET signal.

Re: Undocumented 8086 instructions, explained by the microcode

#5

Post by greenyoda »

kens wrote: post #3
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…

There's a reason why every 8086 opcode matches something. If an instruction didn't match anything, I think the microcode engine would spin idle and the instruction would never terminate. (You need a RNI micro-instruction to end microcode processing.) Having your processor lock up due to a bad opcode is something that the designers presumably explicitly avoided. The 6502 on the other hand, didn't take such precautions…

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 process of the MC6802, engineers originally planned to remove this instruction, but kept it as-is for testing purposes. As a result, HCF was officially recognized as a real instruction.

https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing...

Re: Undocumented 8086 instructions, explained by the microcode

#6

Post by unnouinceput »

quickthrower2 wrote: post #4

Aside: If you are writing stuff this good (and this niche) I would say ditch the ads. They really will turn off the audience you want to attract. Or at least use one of the developer-focused ad networks that just inline ads not pop them up.

What ads? Didn't seen any ads when visiting the page. Are you browsing the web without uBlock Origin by any chance?

Re: Undocumented 8086 instructions, explained by the microcode

#7

Post by lloydatkinson »

unnouinceput wrote: post #6
quickthrower2 wrote: post #4

Aside: If you are writing stuff this good (and this niche) I would say ditch the ads. They really will turn off the audience you want to attract. Or at least use one of the developer-focused ad networks that just inline ads not pop them up.

What ads? Didn't seen any ads when visiting the page. Are you browsing the web without uBlock Origin by any chance?

I am always amazed how many tech orientated people don't use any kind of ad blocking

Re: Undocumented 8086 instructions, explained by the microcode

#8

Post by djmips »

quickthrower2 wrote: post #4

Aside: If you are writing stuff this good (and this niche) I would say ditch the ads. They really will turn off the audience you want to attract. Or at least use one of the developer-focused ad networks that just inline ads not pop them up.

Data point: I browsed without an adblocker on phone in Chrome and didn't see any ads.
Post reply on HN