3 ms·

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

by jchw 4y ago

kens 4y 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.
- rep_lodsb 4y 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.
- jchw 4y 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.
  - pcwalton 4y ago
    It's also bad for security. IIRC code execution is easier on MIPS because 0x0 is a NOP.
    - jchw 4y ago
      Definitely. Lot easier to heap spray when most of the memory is a free nopslide.
    - anyfoo 4y ago
      It's worth nothing though, that that likely wasn't much of a consideration at all at the time. Networks for one were barely a thing, at least on systems so tiny that they'd use an 8086. And even when they were, they tended to be extremely trusting until way into the 90s.
- deleted 4y ago
  [deleted]
ok123456 4y ago
Probably an artifact of the Datapoint's instruction decoder unit.
deleted 4y ago
[deleted]
flohofwoe 4y 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 4y 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.
- anyfoo 4y 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.

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

by jchw 4y ago

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

kens 4y 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.

rep_lodsb 4y 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.
jchw 4y 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.
- pcwalton 4y ago
  It's also bad for security. IIRC code execution is easier on MIPS because 0x0 is a NOP.
  - jchw 4y ago
    Definitely. Lot easier to heap spray when most of the memory is a free nopslide.
  - anyfoo 4y ago
    It's worth nothing though, that that likely wasn't much of a consideration at all at the time. Networks for one were barely a thing, at least on systems so tiny that they'd use an 8086. And even when they were, they tended to be extremely trusting until way into the 90s.
deleted 4y ago
[deleted]

ok123456 4y ago

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

deleted 4y ago

[deleted]

flohofwoe 4y 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 4y 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.

anyfoo 4y 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.