Halt and Catch Fire

Halt and Catch Fire, known by the mnemonic HCF, was originally a fictitious computer machine code instruction claimed to be under development at IBM for use in their System/360 computers, along with many other amusing instructions such as "Execute Operator".

In modern practice, HCF denotes an undocumented machine code instruction with unusual side-effects, included in the processor for test purposes. The old "Halt and Catch Fire" instruction and HCF mnemonic were appropriated by users who discovered 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, while nevertheless appearing quite busy. The expression "catch fire" is strictly metaphorical.

One apocryphal story goes back to the late 1960's, 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 "Halt and Catch Fire".

A real life HCF

The Motorola 6800 microprocessor was the first for which an HCF opcode became widely known. The origin of the 6800 HCF opcode (0xDD or 0xD9) came from an article written by Gerry Wheeler (1952–2006) in the December 1977 issue of "BYTE" magazine on undocumented opcodes.cite journal | last = Wheeler | first = Gerry | title = Undocumented M6800 Instructions | journal = BYTE | volume =2 | issue =12 | pages = 46–47 | date = December 1977] The instruction makes the processor enter a mode intended for manufacturing testing, in which it continuously performs memory read cycles from successive addresses, with no intervening instruction fetches. Effectively the address bus becomes a counter, allowing the operation of all address lines to be quickly verified. Once the processor has entered this test mode, it is not responsive to interrupts, so normal operation can only be restored by a reset.

Potential damage

There are apocryphal reports of damage resulting from the use of such instructions, but there is no documented evidence of such an instruction actually causing damage to a computer. Obviously special instructions designed into a processor for use in manufacturing tests would not be designed in such a manner as to cause damage to that processor.

However, in an embedded system the unintended execution of an HCF instruction could easily cause problems in the system being controlled. For instance, the system could fail to stop a machine when the closure of a limit switch occurs. This problem is not specific to an HCF instruction, and could occur if the software crashes for any reason. Properly designed systems have hardware interlocks and watchdog timers to prevent such occurrences or limit their consequences.

Additionally, there are cases of hardware suffering damage due to manipulation by program code. See Killer poke for examples.

pecific processors with HCF opcode

*6502, and in general the NMOS 650x and 651x series processors [cite web
url=http://linux.cis.monroeccc.edu/~paulrsm/6502/AAL/AAL8103.TXT
title=Apple Assembly Line Volume 1 Issue 6
accessdate=2008-05-09]
*6800
*6809fact|date=February 2008
*MIPS-X: processor supported by the Defense Advanced Research Projects Agency, the Programmer's Manual describes an HSC (Halt and Spontaneously Combust) instruction in -NSA version of the processor [ftp://reports.stanford.edu/pub/cstr/reports/csl/tr/86/289/CSL-TR-86-289.pdf]

ee also

*Killer poke
*Cyrix coma bug
*SEX
*f00f
*Printer on fire

References