I have never watched the AMC show Halt and Catch Fire, and for a long time I only knew the title, but nothing about the show. Something about it always reminded me of programmer humor: somewhat dramatic, a little absurd, and weirdly precise. Turns out, the show really is about the computer industry in the 1980s and 1990s, but the phrase itself is much older than the show, and it started as some engineering humor.
What it means
In the context of computers, Halt and Catch Fire (shortened to HCF) has been generalized to describe machine-code that causes the CPU to stop doing anything useful, forcing you to only recover by resetting (or power-cycling) the machine. In a pretty literal sense, it "halts" the machine. Sure, the "catch fire" part is a joke, but it's not as far-fetched as it might seem. Take the IBM System/360 for example. Apparently when this system would encounter a certain invalid opcode, it would constantly access a specific location in the magnetic core memory, which caused it to get very hot and even catch on fire.
Over time, HCF also became a catch-all label for undocumented or invalid opcodes that lock up the processor, intentional test modes that look like a hang, and real hardware bugs (you might even recall that some early Pentium-class chips could be locked up with a carefully chosen illegal instruction, known as the F00F bug - more on that later).
The phrase was created, in part, because of the standard of using three-letter assembly mnemonics: ADD, CMP, JMP, etc. The joke spread in various publications, including HCF alongside some other personal favorites of mine:
EPI: Execute Programmer ImmediatelyDC: Divide and ConquerCRN: Convert to Roman Numerals
The Motorola 6800
So HCF was mostly just a joke, until it wasn't.
The Motorola 6800 has 256 single-byte opcodes, but not every bit pattern corresponds to a documented instruction. Hit the wrong one and the chip does whatever the silicon "decodes" into — sometimes nothing much, sometimes something significant.
Gerry Wheeler's BYTE piece "Undocumented M6800 Instructions" ran in December 1977, volume 2 number 12, in the Technical Forum on pages 46–47. He starts from Motorola's own docs: 197 documented opcodes, which leaves 59 bit patterns unaccounted for in the official story. Some of those behave like NOPs, some change the condition-code register in patterns Wheeler said were still "undeciphered" at the time, and two bytes — $9D and $DD — share one especially nasty outcome he chose to call Halt and Catch Fire. He is explicit that "The mnemonics are, of course, assigned by me."
What actually happens, in hardware terms, is that the part stops behaving like a normal fetch–decode–execute engine: the program counter keeps advancing and the chip issues reads while the address lines march through memory like a hardware counter. Interrupts will not stop you from your path of self-destruction - you only get out of the loop with a reset or power cycle. Wheeler's own description is worth reading in the original, rather than paraphrasing:
When this instruction is run the only way to see what it is doing is with an oscilloscope. From the user's point of view the machine halts and defies most attempts to get it restarted. Those persons with indicator lamps on the address bus will see that the processor begins to read all of the memory, sequentially, very quickly. In effect, the address bus turns into a 16 bit counter. However, the processor takes no notice of what it is reading... it just reads.
On the "catch fire" half of the phrase, he adds, "Well, almost." While the IBM system did catch fire in cases, it seems that the Motorola 6800 did not.
Outside BYTE, the same opcode family picked up other nicknames. David J. Agans, in Debugging (2002), remembers DD as what his team called the "Drop Dead" instruction—same bus-walking trick, different name—and notes that engineers used it deliberately because "all of the address and clock lines were nice, cycling square waves" on a scope.
Most machines only feel like they hang. On at least one early 6800 microcomputer with finicky memory-mapped video, the pattern can show up as visible "snow". Ben Z's Sphere News article is a great rabbit hole to go down (video RAM arbitration, timing, CRT artifacts).
Years later, Motorola engineers wrote more about this same issue. In IEEE Design & Test (1985), Daniels and Bruce describe an illegal opcode that customers found on the MC6800, internally nicknamed HACOF, where the program counter could increment forever until reset. They also tell of a detail that's almost hard to believe: product engineering wanted a fast way to scan RAM during bring-up, recognized this behavior already did something like that, and basically kept it instead of paying to remove it. So, in the words of Bob Ross, this turned out to be a "happy accident".
More recently, someone actually put a real MC6800 on hardware and actually measured the thing instead of just trusting scans of old magazines and Wikipedia pages. Doc TB's lab write-up notes an interesting detail: after the opcode is fetched, there is a delay on the order of tens of milliseconds before the address lines settle into the famous fast counting pattern, and there are other undocumented opcodes that look like slower or glitchier versions of the same idea.
Beyond Motorola
Motorola wasn't the only modern processor with this issue: illegal 6502 opcodes that lock the CPU, the Pentium F00F bug (if you remember that era), pairs of instructions on some architectures that wait forever for an interrupt that cannot arrive, and modern x86 fuzzing talks where people still turn up invalid states in huge processors.
Basically, with fuzzing they're trying to set random or unexpected data to the processor to help identify vulnerabilities or bugs in the processor. Unsurpisingly, it's a pretty effective strategy, and not just for processors, but for all kinds of software as well.
Halt and end post
This was a fun bit of history to research - and there turned out to be much more to it than I expected, even regarding the "catch fire" part. As a lot of software moves up the stack, it's easy to lose sight of the hardware from our 10,000 foot view. In the end, it's just a bunch of silicon wired together in a way that can sometimes go wrong.
All I know is that this phrase is too good to not use - expect a future project (or company) to use the "HCF" acronym.
Sources and more info
To keep you busy, here are some links to the sources and more info: