Reverse-engineering the Intel 8086 processor's HALT circuits

https://www.righto.com/2023/01/reverse-engineering-intel-8086.html

by picture • 3 years ago

96 28 3 years ago

kens3• 3 years ago

A few days ago, monocasa suggested I should look at the 8086's HLT instruction, so here it is. Let me know if you have other comments on what part of the 8086 would be interesting to read about.

https://news.ycombinator.com/item?id=34495317

pwg• 3 years ago

Another suggestion, from the previous thread: https://news.ycombinator.com/item?id=34495797

bonzini2• 3 years ago

Prefixes and (probably related) address generation.

String instructions would be cool, I suspect microcode to have a few features only used by them in collaboration with the decode ROMs. For example REP is probably little more than one of the conditions that the microcode can test.

rep_lodsb2• 3 years ago

For example REP is probably little more than one of the conditions that the microcode can test.

Indeed it is, and the same internal flag set by the REP prefix is also used by the multiplication and division subroutines to keep track of the sign bit. With the prefix, (I)MUL and (I)DIV will return a negated result on the 8086.

The 80186 only does this for IDIV. Mul/div on that processor is already mostly handled by dedicated logic, so the microcode is a lot shorter (and no longer uses any subroutines).

However, MUL and IMUL jump to a common exit point that can put the result into either DX:AX or an arbitrary register (for the three-operand form of IMUL), and again they used the REP flag to keep that extra bit of state. If it is set, the register is selected by the middle ModRM field. The usefulness of that undocumented "feature" is somewhat limited, since that is also part of the opcode, so the only choices for register are AH, CH, SP and BP.

Also, BOUND uses the flag as a 1-bit "loop counter" and will fail to check the upper bound when prefixed with REP.

The 80286 and everything newer either ignore the prefix or handle it similar to 0Fh: each prefixed opcode is now a separate instruction with its own microcode.

monocasa• 3 years ago

I'm just now seeing this; thanks so much for so thoroughly indulging my curiosity! It was a fantastic read.

jchw3• 3 years ago

Question: why were there three HALT opcodes? does it simply fill otherwise unused opcode encodings?

kens3• 3 years ago

That's a good question. I'm completely guessing, but the Datapoint probably used 0x00 and 0xff as HALT opcodes so you ended up in uninitialized or missing memory the processor would halt. Maybe 0x01 was the "intentional" halt instruction.

jchw3• 3 years ago

Ah, that's a really good point. Having 0x00 be a NOP or maybe worse, instruction that actually is valid and does something, would be a hell of a lot worse for debugging, because after the fact it'd be extremely hard to figure out how you got there.

rep_lodsb2• 3 years ago

Maybe 0x01 was the "intentional" halt instruction.

00 would be "increment A", 01 "decrement A". I would guess these weren't supported because of how that register is connected to the ALU?

FF = "load memory from memory", same as the HLT on the 8080.

ok123456• 3 years ago

Probably an artifact of the Datapoint's instruction decoder unit.

flohofwoe3• 3 years ago

Sometimes such 'redundant' instructions happen because of incomplete instruction decoding. For instance the ED-prefixed instruction block on the Z80 has:

- 8x NEG

- 8x RETI/RETN (named differently but same behaviour)

- 4x IM0, 2x IM1 and 2x IM2

- and a whopping 178 opcodes in the ED block decode to a NOP (no operation)

ajross• 3 years ago

On modern CPUs that actually can't run at full speed for thermal reasons, they're critically important (though a complicated dance with MWAIT and a ton of drivers has supplanted HLT on x86 devices).

On microprocessors of the time, they're indeed a little useless. None of the logic was going to disable the internal clock, this was decades before the introduction of gateable power wells, etc...

But on the bigger hardware where DMA was common, a halted CPU could be relied on not to be issuing needless requests to the memory bus and other clients like I/O devices (SMP was in its infancy in the 70's too) would have lower contention and higher throughput. I'm sure that was part of the thinking. The IBM PC itself tended not to contend on its bus much (CGA and MDA had their own framebuffers and floppy DMA was mostly a joke), but maybe there were other 8086 implementations that cared.

anyfoo2• 3 years ago

You get a fun reminder of that if you run MWC's Coherence in a vm today. Coherence's idle loop/task does not issue HLT, so you can happily see the CPU core the vm is running on burning away for no good reason.

pifm_guy• 3 years ago

So why didn't they implement the HLT instruction as simply a 'jump to self' infinite loop?

Then no special logic would be needed, no extra states, etc.

Sure - there would be no power savings, and the memory bus wouldn't be idle, but we're either of those a requirement in 1970?

kens3• 3 years ago

Yes, halt is sort of redundant and processors like the 6502 omitted it. I think the historical popularity of halt was because you could indicate to the operator that the computer was halted, rather than in an infinite loop. Peripheral devices could also detect the halt state.

flohofwoe3• 3 years ago

On Z80 home computers, HALT was often used to synchronise some piece of code with a hardware interrupt like VSYNC for 'race-the-beam' stuff (because an interrupt takes the CPU out of the HALT state).

caf• 3 years ago

I believe by the time the processor has halted, the IP has advanced, so when the interrupt returns it will resume executing after the HLT. An infinite loop would resume executing the loop.

bonzini2• 3 years ago

Yes, and by issuing STI followed by HLT you can ensure that the after the interrupt returns the IP is always pointing past HLT. I think this is a feature that Intel had to patch because they got it wrong in the first steppings.

billforsternz• 3 years ago

1976 not 1970, in 1970 a CPU as advanced as the 8086 was science fiction (things were moving fast back then).

tadfisher• 3 years ago

Yeah, in 1970 the first mass-manufactured integrated circuits were flying to/landing on the Moon. The pace of technology back then was unreal.

rogerbinns• 3 years ago

You mention inheriting little endian from the Datapoint. If that constraint was not there, would a big endian 8086 be materially different in any way? For example could parts be simpler or fewer gates used?

myself248• 3 years ago

Was HLT used much in regular programming, like to say "I've got nothing to do unless an interrupt comes in, might as well just HLT", perhaps?

Or, as I understand other processors of the time might not even bother to include such an instruction, was it sort of optional or rarely used?

blueflow• 3 years ago

In the IBM PC, HLT was used to wait for keyboard input, which came in as hardware interrupt and resumed execution.

flohofwoe3• 3 years ago

Same on Z80 home computers like the Amstrad CPC to synchronise execution with the (video) raster or vsync interrupt.

Reverse-engineering the Intel 8086 processor's HALT circuits

Related Stories