Halt and Catch Fire

From Wikipedia, the free encyclopedia
Jump to: navigation, search
For the television series, see Halt and Catch Fire (TV series).

In computer engineering, Halt and Catch Fire, known by the assembly mnemonic HCF, is a euphemism referring to a computer machine code instruction that causes the computer's central processing unit (CPU) to cease meaningful operation, typically requiring a restart of the computer. This originally referred to a fictitious instruction in IBM System/360 computers, but later computer developers who saw the joke created real versions of this instruction for some machines. In the case of real instructions the implication of this expression is that, whereas in most cases when a CPU executes an unintended instruction (a bug in the code) the computer may still be able to recover, but in the case of an HCF instruction there is, by definition, no way for the system to recover without a restart.

The expression "catch fire" in this context is normally facetious, rather than literal - referring to a total loss of CPU functionality during the current session, not physical damage.

Other euphemisms are often used such as "SDI" for "Self Destruct Immediate" and also for other joke operations, such as "CRN" for Convert to Roman Numerals.[1]

In early CPUs[edit]

In a computer's assembly language, mnemonics are used that are directly equivalent to machine code instructions. The mnemonics are frequently three letters long, such as ADD, CMP (to compare two numbers), and JMP (jump to a different location in the program). The HCF instruction was originally a fictitious assembly language instruction, said to be under development at IBM for use in their System/360 computers, along with many other amusing three-letter acronyms like XPR (Execute Programmer) and CAI (Corrupt Accounting Information).[2] The S/360 instruction set already included numerous non-obvious mnemonics like ZAP (Zero and Add Packed), EDMK (EDit and MarK), TRT (TRanslate and Test), and Read Backward (an I/O channel command),[3] and programmers began creating similarly cryptic, but fictitious, instructions in a humorous vein.[citation needed]

One apocryphal story about the HCF instruction goes back to the late 1960s, when computers used magnetic core memory. The story goes that in order to speed up the core memory on their next model the engineers increased the read/write currents in the very fine wires that were threaded through the cores. This worked fine when the computer was executing normal programs, since memory accesses were spread throughout memory. However, the HALT instruction was implemented as a "Jump to self". This meant that the same core memory location was repeatedly accessed, and the very fine wires became so hot that they started to smoke — hence the instruction was labeled "Halt and Catch Fire".[4]

In modern CPUs[edit]

CPU designers sometimes incorporate one or more undocumented machine code instructions for testing purposes[citation needed]. These instructions are not intended to be executed during normal operation of the CPU and when they are actually executed by a program, they often have unusual side-effects.

The old "Halt and Catch Fire" instruction and HCF mnemonic are sometimes appropriated by users who discover these instructions as a humorous way of expressing that the unintended execution of such an instruction causes the system to fail to perform its normal functions.

Motorola 6800[edit]

The Motorola 6800 microprocessor was the first for which an undocumented assembly mnemonic HCF became widely known. The opcodes for the mnemonic HCF are $9D and $DD and were reported in an article written by Gerry Wheeler in the December 1977 issue of BYTE magazine on undocumented opcodes.[5][6]

Either opcode makes the processor enter a mode in which it continuously performs memory read cycles from successive addresses, with no intervening instruction fetches. The address bus effectively becomes a counter, allowing the operation of all address lines to be quickly verified. Once the processor has entered this mode, it is not responsive to interrupts, so normal operation can only be restored by a reset. Some engineers began referring to the operation as "Halt and Catch Fire".[7] It has been claimed that in some hardware configurations, the unrelenting driving of the address lines caused them to smoke or burn.[8] It is likely that the term "catch fire" is intended more as a metaphor for the unresponsive behavior of the CPU when placed in this state; there are no known examples of erratic behavior.

The mnemonic HCF is believed to be the first built-in self-test feature on a Motorola microprocessor.[9]

Intel x86[edit]

See also: HLT and Pentium F00F bug

The Intel 8086 and subsequent processors in the x86 series had an HLT (halt) instruction, op code F4, which stopped instruction execution and placed the processor in a HALT state. An enabled interrupt, a debug exception, the BINIT signal, the INIT signal, or the RESET signal resumed execution, which meant the processor could always be restarted.[10] Some of the early Intel DX4 chips had a problem with the HLT instruction and could not be restarted after this instruction was used, which disabled the computer and turned HLT into more of an HCF instruction. The Linux kernel added a "no-hlt" option telling Linux to run an infinite loop instead of using HLT, which allowed users of these broken chips to use Linux.[11]

Many computers in the Intel Pentium line could be locked up by executing an invalid instruction (F00F C7C8), which caused the computer to try to execute the invalid F00F instruction and then lock up. This became known as the Pentium F00F bug. No compiler would create the instruction, but a malicious programmer could insert it into code to render an afflicted computer inoperable until the machine was power-cycled. Since its discovery, workarounds have been developed to prevent it from locking the computer, and the bug has been eliminated in subsequent Intel processors.[12][13]

In popular culture[edit]

References to the Halt and Catch Fire instruction have been made in various forms of media.


Video games[edit]

A hidden instruction HCF is programmed into the game. Upon execution of the instruction the game will simulate a CRT display rebooting, and then bring the user to the main menu.[14]

See also[edit]


  1. ^ Far out op codes, Werner Cirsovius, retrieved 2015-05-28 
  2. ^ A Proposed Instruction Set, The Ohio State University, retrieved 2014-07-02 
  3. ^ IBM System/360 Principles of Operation (PDF), IBM, retrieved 2014-07-02 
  4. ^ http://catless.ncl.ac.uk/Risks/5.6.html#subj2.4 | RISKS Digest: Hardware vs Software Battles (from Usenet)
  5. ^ Wheeler, Gerry (December 1977). "Undocumented M6800 Instructions". BYTE 2 (12): 46–47. 
  6. ^ Banks, Walter. "Mailing list entry". Retrieved 2014-06-08. 
  7. ^ Agans, David J. (2002). Debugging: the 9 indispensable rules for finding even the most elusive software and hardware problems. New York: American Management Association. p. 77. ISBN 9780814426784. OCLC 52043345. Retrieved 10 July 2014. 
  8. ^ "The Jargon File, v 3.1.0". 15 October 1994. Retrieved 2010-07-08. 
  9. ^ Daniels, R. Gary; Bruce, William (April 1985). "Built-In Self-Test Trends in Motorola Microprocessors". IEEE Design & Test 2 (2): pp. 64–71. doi:10.1109/MDT.1985.294865.  "HACOF thus became the first intentional built-in self-test feature on a Motorola microprocessor."
  10. ^ "x86 Instruction Set Reference: HLT". Retrieved 2014-07-02. 
  11. ^ Gortmaker, Paul (21 March 2003). "The Linux Boot Prompt-How To" (PDF). The Linux Documentation Project. Retrieved 2014-07-02. 
  12. ^ Collins, Robert R. (1 May 1998). "The Pentium F00F Bug: Workarounds for a nasty problem". Dr. Dobb's Journal. 
  13. ^ Pentium Processor Specification Update (PDF). Intel Corporation. January 1999. pp. 51–52. order number 242480-041. Retrieved 2006-11-02. 
  14. ^ "Undocumented Instructions - TIS-100 - Steam Community". Retrieved June 27, 2015. 

External links[edit]