Halt and Catch Fire

From HandWiki
Revision as of 19:14, 1 August 2022 by imported>WikiGary (correction)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

In computer engineering, Halt and Catch Fire, known by the assembly mnemonic HCF, is an idiom 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. It originally referred to a fictitious instruction in IBM System/360 computers, making a joke about its numerous non-obvious instruction mnemonics.

With the advent of the MC6800, a design flaw was discovered by the programmers. Due to incomplete opcode decoding, two illegal opcodes, 0x9D and 0xDD, will cause the program counter on the processor to increment endlessly, which renders the processor useless. Those codes have been unofficially named HCF. During the design process of MC6802, engineers originally planned to remove this instruction, but kept it as-is for testing purposes. As a result, HCF was officially recognized as a real instruction.[1][2] Later, HCF became a humorous catch-all term for instructions that may freeze a processor, including intentional instructions for testing purposes, and unintentional illegal instructions. Some are considered hardware defects, and if the system is shared, a malicious user can execute it to launch a denial-of-service attack.

In the case of real instructions, the implication of this expression is that, whereas in most cases in which a CPU executes an unintended instruction (a bug in the code) the computer may still be able to recover, 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" is a facetious exaggeration of the speed with which the CPU chip would be switching some bus circuits, causing them to overheat and burn.[3]

Etymology

Apocryphal stories connect this term with an illegal opcode in IBM System/360. A processor, upon encountering the instruction, would start switching bus lines very fast, potentially leading to overheating.[4][5]

Assembly language mnemonics

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),[6] and similar to other joke mnemonics such as "SDI" for "Self Destruct Immediately"[6] and "CRN" for Convert to Roman Numerals.[7] A list of such mnemonics, including HCF, shows up as "Overextended Mnemonics" in the April 1980 Creative Computing flip-side parody issue.[8]

The IBM System/360 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),[9] and programmers began creating similarly cryptic, but fictitious, instructions in a humorous vein.[10][11]

In a 1990 USENET discussion, it was claimed that HCF dated back to before 1977.[12][13]

In Rick Cook's science fiction/fantasy novel, The Wizardry Compiled, about programmers transported to a universe where magic could be programmed, one of them refers to the command as HMCF, for "Halt, Melt and Catch Fire".

In modern CPUs

CPU designers sometimes incorporate one or more undocumented machine code instructions for testing purposes, such as the IBM System/360 DIAGnose instruction.[9] These instructions are not intended to be executed during normal operation of the CPU; when they are actually executed by a program during normal operation, they can have unusual side-effects.[citation needed] The "Halt and Catch Fire" (HCF) instruction and 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.[citation needed]

Motorola 6800

The Motorola 6800 microprocessor was the first for which an undocumented assembly mnemonic HCF became widely known. The operation codes (opcodes—the portions of the machine language instructions that specify an operation to be performed)—hexadecimal 9D and DD, and were reported and given the unofficial[14] mnemonic HCF in an article written by Gerry Wheeler in the December 1977 issue of BYTE magazine on undocumented opcodes.[14] Wheeler noted that Motorola reported 197 valid operation codes for the M6800 processor, and so inferred that with 256 possible 8 bit combinations, there must be 59 "invalid instructions." He goes on to describe the HCF as a "big surprise," and saying of the Catch Fire portion of the moniker, "Well, almost.":

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.[14]

The process is reviewed by David Agans, thus: "In the old days of the Motorola 6800 microprocessor, instruction code DD caused the processor to go into an endless loop, reading from each memory address in order. (Other engineers referred to this as the 'Halt and Catch Fire' (HCF) instruction, but we remembered the code by calling it the 'Drop Dead' instruction.) Drop Dead mode was wonderful for spotting hardware timing and address logic problems with a scope; all of the address and clock lines were nice, cycling square waves."[15]

That is, either opcode made the processor enter a mode, continuously performing memory read cycles from successive addresses with no intervening instruction fetches. Hence, the address bus effectively became a counter, allowing the operation of all address lines to be quickly verified. Once the processor entered this mode, it was not responsive to interrupts, so normal operation could only be restored by a reset (hence the "Drop Dead" and "Halt and Catch Fire" monikers). These references were thus to the unresponsive behavior of the CPU in this state, and not to any form of erratic behavior.[citation needed]

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

Intel x86

The Intel 8086 and subsequent processors in the x86 series had an HLT (halt) instruction, opcode 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.[16] 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.[17]

The 80286 has the undocumented opcode 0F 04, causing the CPU to hang when executed. The only way out is CPU reset.[citation needed] [18] In some implementations, the opcode was emulated through BIOS as a halting sequence.[19]

Many computers in the Intel Pentium line could be locked up by executing an invalid instruction (F00F C7C8), which caused the computer to 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.[20][21]

During Black Hat USA 2017, Christopher Domas showed that he has found a new currently unknown "Halt and Catch Fire" instruction[22][23] on a particular x86 processor model using his own x86 processor fuzzer called sandsifter.[24] (As of December 2017), the affected instruction, processor and manufacturer have not yet been revealed due to responsible disclosure guidelines.[citation needed]

Other CPUs

The MOS Technology 6502 has 12 invalid instructions which will freeze the CPU.[25][26]

On the Zilog Z80, executing DI (disable interrupts) followed by HALT (wait for an interrupt) results in the CPU staying frozen indefinitely, waiting for an interrupt that cannot happen. The similar processor found in the Game Boy, the LR35902, contained a partial fix allowing it to recover from one HALT, but it would become frozen with three consecutive HALTs with interrupts disabled.[27] The LR35902 itself contains no less than 11 opcodes that fully lock the CPU when executed.[28]

The Z80 also supports a non-maskable interrupt.[29][30] The /NMI signal is on Pin 17 of the original 40 pin DIP package.[31][32] Since a non-maskable interrupt will regain control of the CPU even after executing the instruction sequence DI / HALT, that pair does not represent a true HCF. It will only result in a HCF condition if either the /NMI pin is connected directly to the +5V rail, making the generation of that signal impossible, or if the interrupt routine that services /NMI ends with a return, placing it back in the HALT state.

See also

References

  1. ↑ http://bytecollector.com/archive/digital_group/documentation/hardware/dg_systems/system_cards/6800_cpu_card/6800_Instruction_Set.PDF MC6800 Instruction Set
  2. ↑ 2.0 2.1 Daniels, R. Gary; Bruce, William (April 1985). "Built-In Self-Test Trends in Motorola Microprocessors". IEEE Design & Test 2 (2): 64–71. doi:10.1109/MDT.1985.294865. "To add insult to injury, we discovered that we had an illegal HACOF, an instruction that our customers found on the MC6800. It was an unused opcode-an illegal instruction. When executed inadvertently, the program counter would increment in- definitely. The problem, which was caused by incomplete opcode decod- ing, was a nuisance because Reset was the only means of terminating the instruction. [...] During the design process, we figured out how to eliminate the HACOF instruction. About that time, the product engineers came to us with an idea. They said, "You know what we'd really like? Some way to quickly test the RAM. If we could somehow point the program counter at the first RAM address and then just increment through the RAM, we could test it a lot faster." Since the HACOF "instruction" did precisely that-and we really didn't want to invest the effort needed to remove it-we replied, "Have we got a deal for you!" HACOF thus became the first intentional built-in self-test feature on a Motorola microprocessor.". 
  3. ↑ Jargon File entry for the HCF assembly mnemonic
  4. ↑ Clements, Alan (28 October 2006). "Embedding Ethics in Computer Architecture" (PDF). ASEE/IEEE Frontiers in Education Conference (36 ed.). p. 4. https://www.researchgate.net/publication/224061061. Retrieved 2 March 2018. 
  5. ↑ Kohler, Eddie (4 April 2005). "CS111 - Lecture 1". p. 2. http://www.read.seas.harvard.edu/~kohler/class/cs111-s05/notes/notes1.pdf. Retrieved 2 March 2018. 
  6. ↑ 6.0 6.1 Dunlap, Bryan. "A Proposed Instruction Set". https://www.physics.ohio-state.edu/~bcd/humor/instruction.set.html. 
  7. ↑ Far out op codes, Werner Cirsovius, http://www.cirsovius.de/Firmen/Uni-Chaos/FUN/opcodes.html, retrieved 2015-05-28 
  8. ↑ "Overextended Mnemonics", Creative Computing 6 (4): 17 (hex) (flip–side), April 1980, https://archive.org/stream/creativecomputing-1980-04/Creative_Computing_v06_n04_1980_Apr#page/n205/mode/2up, retrieved 2017-03-12 
  9. ↑ 9.0 9.1 IBM System/360 Principles of Operation, IBM, http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf, retrieved 2014-07-02 
  10. ↑ "Kevin Korb's Jokes: Assembler Opcodes that should exist". https://www.sanitarium.net/jokes/getjoke.cgi?30. Retrieved December 13, 2016. 
  11. ↑ "Forgotten Assembly Language Commands". http://www.jokes2go.com/lists/list30.html. Retrieved December 13, 2016. 
  12. ↑ "Subject: HCF instruction: from Principles of Operation", Archived at textfiles.com
  13. ↑ "apocryphal opcode mnemonics,long" , 23/04/1990, alt.folklore.computers, (via Google Groups)
  14. ↑ 14.0 14.1 14.2 Wheeler, Gerry (December 1977). "Undocumented M6800 Instructions". BYTE 2 (12): 46–47. https://archive.org/details/byte-magazine-1977-12. ""The mnemonics are, of course, assigned by me."". 
  15. ↑ 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. https://books.google.com/books?id=jynA9ECbBsgC&pg=PA77. Retrieved 10 July 2014. 
  16. ↑ "x86 Instruction Set Reference: HLT". http://x86.renejeschke.de/html/file_module_x86_id_134.html. Retrieved 2014-07-02. 
  17. ↑ Gortmaker, Paul (21 March 2003). "The Linux Boot Prompt-How To". The Linux Documentation Project. http://www.tldp.org/HOWTO/pdf/BootPrompt-HOWTO.pdf. Retrieved 2014-07-02. 
  18. ↑ "Re: Undocumented opcodes (HINT_NOP)". Archived from the original. Error: If you specify |archiveurl=, you must also specify |archivedate=. https://web.archive.org/web/20041106070621/http://www.sandpile.org/post/msgs/20004129.htm. Retrieved 2010-11-07. 
  19. ↑ "Re: Also some undocumented 0Fh opcodes". Archived from the original. Error: If you specify |archiveurl=, you must also specify |archivedate=. https://web.archive.org/web/20030626044017/http://www.sandpile.org/post/msgs/20003986.htm. Retrieved 2010-11-07. 
  20. ↑ Collins, Robert R. (1 May 1998). "The Pentium F00F Bug: Workarounds for a nasty problem". Dr. Dobb's Journal. http://www.ddj.com/architect/184410555. 
  21. ↑ Pentium Processor Specification Update. Intel Corporation. January 1999. pp. 51–52. order number 242480-041. http://download.intel.com/support/processors/pentium/sb/242480.pdf. Retrieved 2006-11-02. 
  22. ↑ "Breaking the x86 ISA (PDF)". Christopher Domas. https://www.blackhat.com/docs/us-17/thursday/us-17-Domas-Breaking-The-x86-ISA.pdf. Retrieved December 9, 2017. 
  23. ↑ "Breaking the x86 ISA (video)". Christopher Domas. https://www.youtube.com/watch?v=KrksBdWcZgQ. Retrieved December 9, 2017. 
  24. ↑ "sandsifter: the x86 processor fuzzer". Christopher Domas. https://github.com/xoreaxeaxeax/sandsifter. Retrieved December 9, 2017. 
  25. ↑ Steil, Michael. "How MOS 6502 Illegal Opcodes really work". http://www.pagetable.com/?p=39. 
  26. ↑ Offenga, Freddy. "6502 Undocumented Opcodes". http://nesdev.com/undocumented_opcodes.txt. 
  27. ↑ "GameBoy CPU Manual". http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf#page=21. 
  28. ↑ "Game Boy CPU (LR35902) instruction set". https://max-m.github.io/gb-docs/optables/classic. 
  29. ↑ "Interrupt Mechanism - Development - SMS Power!". http://www.smspower.org/Development/InterruptMechanism. 
  30. ↑ Flammenkamp, Achim. "Interrupt Behaviour of the Z80 CPU". http://www.z80.info/interrup.htm. 
  31. ↑ "Pinouts - Z80 family". http://www.cpu-world.com/info/Pinouts/Z80.html. 
  32. ↑ Vis, Peter J.. "Zilog Z80 Pinout". http://www.petervis.com/electronics/CPU_Processors/Zilog_Z80A/Z80A_CPU_Features.html. 

External links




Retrieved from "https://handwiki.org/wiki/index.php?title=Halt_and_Catch_Fire&oldid=46902"