Jump to content

Halt and Catch Fire (computing): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
"less" -> "fewer"
Tag: Reverted
Undid revision 1222769570 by Ugggsw (talk): please see WP:INTDABLINK
 
(23 intermediate revisions by 20 users not shown)
Line 4: Line 4:
{{Use list-defined references|date=June 2022}}
{{Use list-defined references|date=June 2022}}


In computer engineering, '''Halt and Catch Fire''', known by the [[Assembly language#Opcode mnemonics and extended mnemonics|assembly mnemonic]] '''HCF''', is an [[idiom]] referring to a computer [[machine code]] [[Instruction (computer science)|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 architecture|IBM System/360]] computers (introduced in 1964), making a joke about its numerous non-obvious instruction mnemonics.
In computer engineering, '''Halt and Catch Fire''', known by the [[Assembly language#Opcode mnemonics and extended mnemonics|assembly language mnemonic]] '''HCF''', is an [[idiom]] referring to a computer [[machine code]] [[Instruction (computer science)|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 architecture|IBM System/360]] computers (introduced in 1964), making a joke about its numerous non-obvious instruction mnemonics.


With the advent of the [[MC6800]] (introduced in 1974), a design flaw was discovered by programmers. Due to incomplete opcode decoding, two [[illegal opcode]]s, 0x9D and 0xDD, will cause the [[program counter]] on the processor to increment endlessly, which locks the processor until reset. Those codes have been unofficially named HCF. During the design process of the 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.<ref name="Bryan_2021"/><ref name="Daniels_1985"/> 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 [[Multi-user software|system is shared]], a malicious user can execute it to launch a [[denial-of-service attack]].
With the advent of the [[MC6800]] (introduced in 1974), a design flaw was discovered by programmers. Due to incomplete opcode decoding, two [[illegal opcode]]s, 0x9D and 0xDD, will cause the [[program counter]] on the processor to increment endlessly, which locks the processor until reset. Those codes have been unofficially named HCF. During the design process of the 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.<ref name="Bryan_2021" /><ref name="Daniels_1985" /> 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 [[Multi-user software|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.
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.<ref name="Jargon_2012"/>
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.<ref name="Jargon_2012" />


== Origins ==
== Origins ==
The [[Z1 (computer)|Z1]] (1938) and [[Z3 (computer)|Z3]] (1941) computers built by [[Konrad Zuse]] contained illegal sequences of instructions which damaged the hardware if executed by accident.<ref name="Rojas_1997"/>
The [[Z1 (computer)|Z1]] (1938) and [[Z3 (computer)|Z3]] (1941) computers built by [[Konrad Zuse]] contained illegal sequences of instructions which damaged the hardware if executed by accident.<ref name="Rojas_1997" />


Apocryphal stories connect this term with an [[illegal opcode]] in [[IBM System/360 architecture|IBM System/360]]. A processor, upon encountering the instruction, would start switching [[Bus (computing)|bus lines]] very fast, potentially leading to overheating.<ref name="Clements_2006"/><ref name="Kohler_2005"/>
Apocryphal stories connect this term with an [[illegal opcode]] in [[IBM System/360 architecture|IBM System/360]]. A processor, upon encountering the instruction, would start switching [[Bus (computing)|bus lines]] very fast, potentially leading to overheating.<ref name="Clements_2006" /><ref name="Kohler_2005" />


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 [[IBM System/360 architecture|System/360]] computers, along with many other amusing [[three-letter acronym]]s like XPR (Execute Programmer) and CAI (Corrupt Accounting Information),<ref name="Dunlap_2016"/> and similar to other joke mnemonics such as "SDI" for "Self Destruct Immediately"<ref name="Dunlap_2016"/> and "CRN" for "Convert to Roman Numerals".<ref name="Cirsovius_2015"/> A list of such mnemonics, including HCF, shows up as "Overextended Mnemonics" in the April 1980 ''[[Creative Computing]]'' flip-side parody issue.<ref name="CC_1980"/>
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 [[IBM System/360 architecture|System/360]] computers, along with many other amusing [[three-letter acronym]]s like XPR (Execute Programmer) and CAI (Corrupt Accounting Information), and similar to other joke mnemonics such as "SDI" for "Self Destruct Immediately"<ref name="Dunlap_2016" /> and "CRN" for "Convert to Roman Numerals".<ref name="Cirsovius_2015" /> A list of such mnemonics, including HCF, shows up as "Overextended Mnemonics" in the April 1980 ''[[Creative Computing]]'' flip-side parody issue.<ref name="CC_1980" />

The [[IBM System/360 architecture|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),<ref name="IBM360_2012"/> and programmers began creating similarly cryptic, but fictitious, instructions in a humorous vein.<ref name="Korb_2015"/><ref name="Jokes_2016"/>

In a 1990 [[USENET]] discussion, it was claimed that HCF dated back to before 1977.<ref name="IBM360_2017"/><ref name="Folklore_1990"/>

In [[Rick Cook (writer)|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 ''[[TIS-100]]'', a 2015 puzzle video game made by [[Zachtronics]], there is an achievement called HALT_AND_CATCH_FIRE for crashing the machine with a hidden opcode.<ref name="Steam"/>


== In modern CPUs ==
== 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.<ref name="IBM360_2012"/>
CPU designers sometimes incorporate one or more undocumented machine code instructions for testing purposes, such as the IBM System/360 DIAGnose instruction.<ref name="IBM360_2012" />


=== Motorola 6800 ===
=== Motorola 6800 ===
The [[Motorola 6800]] [[microprocessor]] was the first for which an undocumented assembly mnemonic HCF became widely known. The operation codes ([[opcode]]s—the portions of the machine language instructions that specify an operation to be performed) are hexadecimal 9D and DD, and were reported and given the unofficial<ref name="Wheeler_1977"/> mnemonic HCF in an article written by Gerry Wheeler in the December 1977 issue of [[Byte (magazine)|''BYTE'' magazine]] on undocumented opcodes.<ref name="Wheeler_1977"/> 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":
The [[Motorola 6800]] [[microprocessor]] was the first for which an undocumented assembly mnemonic HCF became widely known. The operation codes ([[opcode]]s—the portions of the machine language instructions that specify an operation to be performed) hexadecimal 9D and DD were reported and given the unofficial mnemonic HCF in a December 1977 article by Gerry Wheeler in [[Byte (magazine)|''BYTE'' magazine]] on undocumented opcodes.<ref name="Wheeler_1977" /> 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 described the HCF as a "big surprise", and said of the Catch Fire portion of the moniker, "Well, almost":


{{quotation|1=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.<ref name="Wheeler_1977"/>}}
{{quotation|1=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.<ref name="Wheeler_1977" />}}


Another author wrote in 2002:
The process is reviewed by David Agans, thus:


{{quote|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 [[oscilloscope|scope]]; all of the address and clock lines were nice, cycling square waves.<ref name="Agans_2002"/>}}
{{quote|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.<ref name="Agans_2002" />}}


That is, either opcode made the processor enter a [[CPU modes|mode]], continuously performing [[random-access memory|memory]] read cycles from successive [[memory address|address]]es with no intervening instruction fetches. Hence, the [[address bus]] effectively became a [[Counter (digital)|counter]], allowing the operation of all [[address lines]] to be quickly verified. Once the processor entered this mode, it was not responsive to [[interrupt]]s, 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|date=October 2015}}
The 6800's behavior when encountering HCF was known to Motorola by 1976. When the 6800 encounters the HCF instruction, the processor never finds the end of it, endlessly incrementing its program counter until the CPU is reset.<ref name="MC6800_HCF_Explanation">{{cite journal |last1=Daniels |first1=R. Gary |last2=Bruce |first2=William |title=Built-In Self-Test Trends in Motorola Microprocessors |journal=IEEE Design & Test of Computers |date=April 1985 |volume=2 |issue=2 |page=64 |doi=10.1109/MDT.1985.294865 |s2cid=22719798 |url=https://ieeexplore.ieee.org/document/4069547 |access-date=28 August 2023}}</ref> Hence, the [[address bus]] effectively becomes a [[Counter (digital)|counter]], allowing the operation of all [[address line]]s to be quickly verified. Once the processor entered this mode, it is not responsive to [[interrupt]]s, so normal operation can only be restored by a reset (hence the "Drop Dead" and "Halt and Catch Fire" monikers). These references are thus to the unresponsive behavior of the CPU in this state, and not to any form of erratic behavior.{{citation needed|date=October 2015}}. Motorola kept the HCF behavior in the 6802 variant of the processor (which released in 1977) as an intentional self-test for the 6802's 128 bytes of onboard RAM.


Other HCF-like instructions were found later on the Motorola 6800 when executing undocumented opcodes FD (cycling twice slower than 9D/DD) or CD/ED (cycling at a human-readable very low frequency on a limited number of high-address lines).<ref name="Demeulemeester_2019"/>
Other HCF-like instructions were found later on the Motorola 6800 when executing undocumented opcodes FD (cycling twice slower than 9D/DD) or CD/ED (cycling at a human-readable very low frequency on a limited number of high-address lines).<ref name="Demeulemeester_2019" />


The mnemonic HCF is believed to be the first built-in self-test feature on a Motorola microprocessor.<ref name="Daniels_1985"/>
HCF is believed to be the first built-in self-test feature on a Motorola microprocessor.<ref name="Daniels_1985" />


=== Intel x86 ===
=== Intel x86 ===
{{See also|HLT (x86 instruction)|Pentium F00F bug}}
{{See also|HLT (x86 instruction)|Pentium F00F bug}}


The Intel 8086 and subsequent processors in the x86 series had an [[HLT (x86 instruction)|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.<ref name="Jeschke_2014"/> 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.<ref name="Gortmaker_2003"/>
The Intel 8086 and subsequent processors in the x86 series have an [[HLT (x86 instruction)|HLT]] (halt) instruction, opcode F4, which stops 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 resumes execution, which means the processor can always be restarted.<ref name="Jeschke_2014" /> Some of the early Intel DX4 chips have a problem with the HLT instruction and cannot be restarted after this instruction is used, which disables the computer and turns HLT into more of an HCF instruction. The Linux kernel has a "no-hlt" option telling Linux to run an infinite loop instead of using HLT, which allows users of these broken chips to use Linux.<ref name="Gortmaker_2003" />


The 80286 has the undocumented opcode 0F 04, causing the CPU to hang when executed. The only way out is CPU reset.{{Citation needed|date=August 2017}}<ref name="Sandpile_2004"/>
The 80286 has the undocumented opcode 0F 04, causing the CPU to hang when executed. The only way out is a CPU reset.{{Citation needed|date=August 2017}}<ref name="Sandpile_2004" /> In some implementations, the opcode is emulated through [[BIOS]] as a [[HLT (x86 instruction)|halt]]ing sequence.<ref name="Sandpile_2003" />
In some implementations, the opcode was emulated through [[BIOS]] as a [[HLT (x86 instruction)|halt]]ing sequence.<ref name="Sandpile_2003"/>


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 cycling|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.<ref name="Collins_1998"/><ref name="Intel_1999"/>
Many computers in the Intel Pentium line can be locked up by executing an invalid instruction (F00F C7C8), which causes the computer to lock up. This became known as the [[Pentium F00F bug]]. No compiler creates the instruction, but a malicious programmer can insert it into code to render an afflicted computer inoperable until the machine is [[Power cycling|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.<ref name="Collins_1998" /><ref name="Intel_1999" />


During [[Black Hat Briefings|Black Hat USA 2017]], Christopher Domas showed that he has found a new currently unknown "Halt and Catch Fire" instruction<ref name="Domas_2017_1"/><ref name="Domas_2017_2"/> on a particular x86 processor model using his own x86 processor [[Fuzzing|fuzzer]] called sandsifter.<ref name="Domas_2017_3"/>
During [[Black Hat Briefings|Black Hat USA 2017]], Christopher Domas showed that he found a new "Halt and Catch Fire" instruction<ref name="Domas_2017_1" /><ref name="Domas_2017_2" /> on an [[Responsible disclosure|undisclosed]] x86 processor model using his own x86 processor [[Fuzzing|fuzzer]] called sandsifter.<ref name="Domas_2017_3" />


=== Other CPUs ===
=== Other CPUs ===
The [[NMOS logic|NMOS]] [[MOS Technology 6502]] has 12 invalid instructions which cause the [[program counter]] to fail to fetch the next instruction, locking up the CPU and requiring a processor reset.<ref name="Steil_2016" /><ref name="Offenga_2016" />  The [[Western Design Center|WDC]] version of the [[CMOS]] [[65C02]], as well as the [[65C816]], has the <code>STP</code> (stop, opcode <code>$DB</code>) instruction.  When executed, <code>STP</code> will stop the processor's internal clock, causing all processing to cease—also, the processor will be unresponsive to all inputs except <code>RESB</code> (reset).  The only way to clear the effects of an <code>STP</code> instruction is to toggle <code>RESB</code>.
The [[MOS Technology 6502]] has 12 invalid instructions which will freeze the CPU.<ref name="Steil_2016" /><ref name="Offenga_2016"/>

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 Z80 also supports a non-maskable interrupt.<ref name="SMS_2016"/><ref name="Flammenkamp_2016"/> The /NMI signal is on Pin 17 of the original 40 pin DIP package.<ref name="Z80_2016"/><ref name="Vis_2016"/> 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.
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. However, the non-maskable interrupt signal can be used to break out of this state, making this pair not a true HCF.<ref name="SMS_2016" /><ref name="Flammenkamp_2016" /> The /NMI signal is on Pin 17 of the original 40 pin DIP package.<ref name="Z80_2016" /><ref name="Vis_2016" /> The pair 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.


The SM83 processor{{efn|The SM83 CPU is similar to the Z80, but not directly related.}}<ref name="Gameboy_SM83"/> core in the [[Game Boy]]'s LR35902 system on chip has a similar issue, triggered by two consecutive HALTs with interrupts disabled.{{efn|When interrupts are disabled, the HALT instruction on the Game Boy CPU does not pause the CPU, but, rather, prevents the CPU's program counter from incrementing on the instruction immediately following the HALT, effectively doubling the instruction after the HALT (or, for a multi-byte instruction, doubling the first byte and separating off the original last byte into a new single-byte instruction); if the instruction after the HALT is itself a HALT, then (as HALT is a single-byte instruction) the CPU effectively sees an infinite series of HALTs, causing the system to lock up.}}<ref name="Gameboy_2018"/> The core itself contains no fewer than 11 opcodes that fully lock the CPU when executed.<ref name="Gameboy_2021"/>
The SM83 processor{{efn|The SM83 CPU is similar to the Z80, but not directly related.}}<ref name="Gameboy_SM83" /> core in the [[Game Boy]]'s LR35902 system on chip has a similar issue, triggered by two consecutive HALTs with interrupts disabled.{{efn|When interrupts are disabled, the HALT instruction on the Game Boy CPU does not pause the CPU, but, rather, prevents the CPU's program counter from incrementing on the instruction immediately following the HALT, effectively doubling the instruction after the HALT (or, for a multi-byte instruction, doubling the first byte and separating off the original last byte into a new single-byte instruction); if the instruction after the HALT is itself a HALT, then (as HALT is a single-byte instruction) the CPU effectively sees an infinite series of HALTs, causing the system to lock up.}}<ref name="Gameboy_2018" /> The core itself contains 11 opcodes that fully lock the CPU when executed.<ref name="Gameboy_2021" />


The [[Hitachi]] SC61860 mainly used in [[Sharp Corporation|Sharp]] [[Pocket computer|pocket computers]] in the 1980–1990 also have an undocumented HCF instruction with the opcode 7B.<ref name="ESR_2022"/>
The [[Hitachi]] SC61860, mainly used in [[Sharp Corporation|Sharp]] [[pocket computer]]s in the 1980s and 1990s, has an undocumented HCF instruction with the opcode 7B.<ref name="ESR_2022" />


== See also ==
== See also ==
Line 73: Line 62:
* [[lp0 on fire]]
* [[lp0 on fire]]
* [[Write-only memory (joke)]]
* [[Write-only memory (joke)]]
* [[NOP (code)]]


== Notes ==
== Notes ==
Line 81: Line 71:
<ref name="Dunlap_2016">{{cite web |title=A Proposed Instruction Set |author-last=Dunlap |author-first=Bryan |website=Physics Department, The Ohio State University |url=https://www.physics.ohio-state.edu/~bcd/humor/instruction.set.html |access-date=2016-06-20 |url-status=dead |archive-url=https://web.archive.org/web/20170908154113/https://www.physics.ohio-state.edu/~bcd/humor/instruction.set.html |archive-date=2017-09-08}}</ref>
<ref name="Dunlap_2016">{{cite web |title=A Proposed Instruction Set |author-last=Dunlap |author-first=Bryan |website=Physics Department, The Ohio State University |url=https://www.physics.ohio-state.edu/~bcd/humor/instruction.set.html |access-date=2016-06-20 |url-status=dead |archive-url=https://web.archive.org/web/20170908154113/https://www.physics.ohio-state.edu/~bcd/humor/instruction.set.html |archive-date=2017-09-08}}</ref>
<ref name="IBM360_2012">{{cite book |title=IBM System/360 Principles of Operation |publisher=[[IBM]] |url=http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf |access-date=2014-07-02 |url-status=live |archive-date=2012-02-29 |archive-url=https://web.archive.org/web/20120229200257/http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf}}</ref>
<ref name="IBM360_2012">{{cite book |title=IBM System/360 Principles of Operation |publisher=[[IBM]] |url=http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf |access-date=2014-07-02 |url-status=live |archive-date=2012-02-29 |archive-url=https://web.archive.org/web/20120229200257/http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf}}</ref>
<ref name="Wheeler_1977">{{cite magazine |title=Undocumented M6800 Instructions |author-last=Wheeler |author-first=Gerry |magazine=[[BYTE]] |volume=2 |issue=12 |date=December 1977 |pages=46–47 |url=https://archive.org/details/byte-magazine-1977-12 |quote="The mnemonics are, of course, assigned by me."}}</ref>
<ref name="Wheeler_1977">{{Cite magazine |date=December 1977 |title=Undocumented M6800 Instructions |url=https://archive.org/details/byte-magazine-1977-12/page/n47/mode/2up?view=theater |magazine=[[BYTE]] |volume=2 |issue=12 |pages=46–47 |access-date=2023-11-20 |quote="The mnemonics are, of course, assigned by me." |author-last=Wheeler |author-first=Gerry}}</ref>
<ref name="Daniels_1985">{{Cite journal |title=Built-In Self-Test Trends in Motorola Microprocessors |author-last1=Daniels |author-first1=R. Gary |author-last2=Bruce |author-first2=William |journal=IEEE Design & Test |volume=2 |issue=2 |pages=64–71 |date=April 1985 |doi=10.1109/MDT.1985.294865 |s2cid=22719798 |quote=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 indefinitely. The problem, which was caused by incomplete opcode decoding, 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.}}</ref>
<ref name="Daniels_1985">{{Cite journal |title=Built-In Self-Test Trends in Motorola Microprocessors |author-last1=Daniels |author-first1=R. Gary |author-last2=Bruce |author-first2=William |journal=IEEE Design & Test |volume=2 |issue=2 |pages=64–71 |date=April 1985 |doi=10.1109/MDT.1985.294865 |s2cid=22719798 |quote=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 indefinitely. The problem, which was caused by incomplete opcode decoding, 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.}}</ref>
<ref name="Collins_1998">{{cite web |title=The Pentium F00F Bug: Workarounds for a nasty problem |author-last=Collins |author-first=Robert R. |date=1998-05-01 |publisher=[[Dr. Dobb's Journal]] |url=http://www.ddj.com/architect/184410555 |access-date=2014-08-12 |url-status=live |archive-url=https://web.archive.org/web/20220430005211/https://www.drdobbs.com/embedded-systems/the-pentium-f00f-bug/184410555 |archive-date=2022-04-30}}</ref>
<ref name="Collins_1998">{{cite web |title=The Pentium F00F Bug: Workarounds for a nasty problem |author-last=Collins |author-first=Robert R. |date=1998-05-01 |publisher=[[Dr. Dobb's Journal]] |url=http://www.ddj.com/architect/184410555 |access-date=2014-08-12 |url-status=live |archive-url=https://web.archive.org/web/20220430005211/https://www.drdobbs.com/embedded-systems/the-pentium-f00f-bug/184410555 |archive-date=2022-04-30}}</ref>
Line 91: Line 81:
<ref name="Cirsovius_2015">{{cite web |title=Far out op codes |author-first=Werner |author-last=Cirsovius |url=http://www.cirsovius.de/Firmen/Uni-Chaos/FUN/opcodes.html |access-date=2015-05-28 |url-status=dead |archive-url=https://web.archive.org/web/20160305150047/http://www.cirsovius.de/Firmen/Uni-Chaos/FUN/opcodes.html |archive-date=2016-03-05}}</ref>
<ref name="Cirsovius_2015">{{cite web |title=Far out op codes |author-first=Werner |author-last=Cirsovius |url=http://www.cirsovius.de/Firmen/Uni-Chaos/FUN/opcodes.html |access-date=2015-05-28 |url-status=dead |archive-url=https://web.archive.org/web/20160305150047/http://www.cirsovius.de/Firmen/Uni-Chaos/FUN/opcodes.html |archive-date=2016-03-05}}</ref>
<ref name="CC_1980">{{cite journal |title=Overextended Mnemonics |date=April 1980 |journal=[[Creative Computing]] |volume=6 |issue=4 |pages=17 (hex) (flip–side) |url=https://archive.org/stream/creativecomputing-1980-04/Creative_Computing_v06_n04_1980_Apr#page/n205/mode/2up |access-date=2017-03-12}}</ref>
<ref name="CC_1980">{{cite journal |title=Overextended Mnemonics |date=April 1980 |journal=[[Creative Computing]] |volume=6 |issue=4 |pages=17 (hex) (flip–side) |url=https://archive.org/stream/creativecomputing-1980-04/Creative_Computing_v06_n04_1980_Apr#page/n205/mode/2up |access-date=2017-03-12}}</ref>
<ref name="Korb_2015">{{cite web |title=Kevin Korb's Jokes: Assembler Opcodes that should exist |url=https://www.sanitarium.net/jokes/getjoke.cgi?30 |access-date=2016-12-13 |url-status=live |archive-url=https://web.archive.org/web/20150605050654/http://www.sanitarium.net/jokes/getjoke.cgi?30 |archive-date=2015-06-05}}</ref>
<ref name="Jokes_2016">{{cite web |title=Forgotten Assembly Language Commands |url=http://www.jokes2go.com/lists/list30.html |access-date=2016-12-13 |url-status=live |archive-url=https://web.archive.org/web/20170316064109/http://www.jokes2go.com/lists/list30.html |archive-date=2017-03-16}}</ref>
<ref name="IBM360_2017">[http://www.textfiles.com/humor/COMPUTER/ibm360.jok "Subject: HCF instruction: from Principles of Operation"] {{Webarchive|url=https://web.archive.org/web/20170224215533/http://textfiles.com/humor/COMPUTER/ibm360.jok |date=2017-02-24}}, Archived at textfiles.com</ref>
<ref name="Folklore_1990">[https://groups.google.com/forum/#!topic/alt.folklore.computers/JmHpwEBOn_s "apocryphal opcode mnemonics,long" ] {{Webarchive|url=https://web.archive.org/web/20190531115852/https://groups.google.com/forum/#!topic/alt.folklore.computers/JmHpwEBOn_s |date=2019-05-31}}, 1990-04-23, ''alt.folklore.computers'', (via Google Groups)</ref>
<ref name="Steam">{{cite web |title=Steam Community: TIS-100: Achievements |url=https://steamcommunity.com/stats/370360/achievements |access-date=2021-05-11 |url-status=live |archive-url=https://web.archive.org/web/20210505204442/https://steamcommunity.com/stats/370360/achievements |archive-date=2021-05-05}}</ref>
<ref name="Agans_2002">{{cite book |title=Debugging: the 9 indispensable rules for finding even the most elusive software and hardware problems |author-last=Agans |author-first=David J. |date=2002 |publisher=American Management Association |location=New York, USA |isbn=978-0-81442678-4 |oclc=52043345 |page=77 |url=https://books.google.com/books?id=jynA9ECbBsgC&pg=PA77 |access-date=2016-10-30 |url-status=live |archive-url=https://web.archive.org/web/20140726162952/http://books.google.com/books?id=jynA9ECbBsgC&pg=PA77 |archive-date=2014-07-26}}</ref>
<ref name="Agans_2002">{{cite book |title=Debugging: the 9 indispensable rules for finding even the most elusive software and hardware problems |author-last=Agans |author-first=David J. |date=2002 |publisher=American Management Association |location=New York, USA |isbn=978-0-81442678-4 |oclc=52043345 |page=77 |url=https://books.google.com/books?id=jynA9ECbBsgC&pg=PA77 |access-date=2016-10-30 |url-status=live |archive-url=https://web.archive.org/web/20140726162952/http://books.google.com/books?id=jynA9ECbBsgC&pg=PA77 |archive-date=2014-07-26}}</ref>
<ref name="Demeulemeester_2019">{{cite web |title=Investigating the HCF (Halt & Catch Fire) instruction on Motorola 6800 |author-last=Demeulemeester |author-first=Samuel |date=2019-07-17 |website=X86.FR – Doc TB's R&D Lab |language=en-US |url=https://x86.fr/investigating-the-halt-and-catch-fire-instruction-on-motorola-6800/ |access-date=2022-04-09 |url-status=live |archive-url=https://web.archive.org/web/20220331005900/https://x86.fr/investigating-the-halt-and-catch-fire-instruction-on-motorola-6800/ |archive-date=2022-03-31}}</ref>
<ref name="Demeulemeester_2019">{{cite web |title=Investigating the HCF (Halt & Catch Fire) instruction on Motorola 6800 |author-last=Demeulemeester |author-first=Samuel |date=2019-07-17 |website=X86.FR – Doc TB's R&D Lab |language=en-US |url=https://x86.fr/investigating-the-halt-and-catch-fire-instruction-on-motorola-6800/ |access-date=2022-04-09 |url-status=live |archive-url=https://web.archive.org/web/20220331005900/https://x86.fr/investigating-the-halt-and-catch-fire-instruction-on-motorola-6800/ |archive-date=2022-03-31}}</ref>
Line 109: Line 94:
<ref name="Gameboy_2018">{{cite web |url=http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf#page=21 |title=GameBoy CPU Manual |access-date=2018-06-22 |archive-date=2018-06-23 |archive-url=https://web.archive.org/web/20180623060718/http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf#page=21 |url-status=live}}</ref>
<ref name="Gameboy_2018">{{cite web |url=http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf#page=21 |title=GameBoy CPU Manual |access-date=2018-06-22 |archive-date=2018-06-23 |archive-url=https://web.archive.org/web/20180623060718/http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf#page=21 |url-status=live}}</ref>
<ref name="Gameboy_2021">{{cite web |url=https://gbdev.io/gb-opcodes/optables/ |title=Game Boy CPU instruction set |access-date=2021-03-11 |archive-date=2021-02-09 |archive-url=https://web.archive.org/web/20210209024452/https://gbdev.io/gb-opcodes/optables/ |url-status=live}}</ref>
<ref name="Gameboy_2021">{{cite web |url=https://gbdev.io/gb-opcodes/optables/ |title=Game Boy CPU instruction set |access-date=2021-03-11 |archive-date=2021-02-09 |archive-url=https://web.archive.org/web/20210209024452/https://gbdev.io/gb-opcodes/optables/ |url-status=live}}</ref>
<ref name="Gameboy_SM83">{{cite web |url=https://github.com/Gekkio/gb-research/tree/main/sm83-cpu-core |title=Game Boy SM83 CPU reverse engineering |access-date=2022-11-08 |archive-date=2022-10-29 |archive-url=https://web.archive.org/web/20221029214709/https://github.com/Gekkio/gb-research/tree/main/sm83-cpu-core |url-status=live}}</ref>
<ref name="Gameboy_SM83">{{cite web |url=https://github.com/Gekkio/gb-research/tree/main/sm83-cpu-core |title=Game Boy SM83 CPU reverse engineering |website=[[GitHub]] |access-date=2022-11-08 |archive-date=2022-10-29 |archive-url=https://web.archive.org/web/20221029214709/https://github.com/Gekkio/gb-research/tree/main/sm83-cpu-core |url-status=live}}</ref>
<ref name="SMS_2016">{{cite web |url=http://www.smspower.org/Development/InterruptMechanism |title=Interrupt Mechanism - Development - SMS Power! |access-date=2016-04-25 |archive-date=2016-04-04 |archive-url=https://web.archive.org/web/20160404071536/http://www.smspower.org/Development/InterruptMechanism |url-status=live}}</ref>
<ref name="SMS_2016">{{cite web |url=http://www.smspower.org/Development/InterruptMechanism |title=Interrupt Mechanism - Development - SMS Power! |access-date=2016-04-25 |archive-date=2016-04-04 |archive-url=https://web.archive.org/web/20160404071536/http://www.smspower.org/Development/InterruptMechanism |url-status=live}}</ref>
<ref name="Flammenkamp_2016">{{cite web |url=http://www.z80.info/interrup.htm |title=Interrupt Behaviour of the Z80 CPU |author-first=Achim |author-last=Flammenkamp |access-date=2016-04-25 |archive-date=2016-04-20 |archive-url=https://web.archive.org/web/20160420035105/http://www.z80.info/interrup.htm |url-status=live}}</ref>
<ref name="Flammenkamp_2016">{{cite web |url=http://www.z80.info/interrup.htm |title=Interrupt Behaviour of the Z80 CPU |author-first=Achim |author-last=Flammenkamp |access-date=2016-04-25 |archive-date=2016-04-20 |archive-url=https://web.archive.org/web/20160420035105/http://www.z80.info/interrup.htm |url-status=live}}</ref>

Latest revision as of 18:50, 19 May 2024

For other uses, see Halt and Catch Fire.

In computer engineering, Halt and Catch Fire, known by the assembly language 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 (introduced in 1964), making a joke about its numerous non-obvious instruction mnemonics.

With the advent of the MC6800 (introduced in 1974), a design flaw was discovered by programmers. Due to incomplete opcode decoding, two illegal opcodes, 0x9D and 0xDD, will cause the program counter on the processor to increment endlessly, which locks the processor until reset. Those codes have been unofficially named HCF. During the design process of the 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]

Origins[edit]

The Z1 (1938) and Z3 (1941) computers built by Konrad Zuse contained illegal sequences of instructions which damaged the hardware if executed by accident.[4]

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.[5][6]

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

In modern CPUs[edit]

CPU designers sometimes incorporate one or more undocumented machine code instructions for testing purposes, such as the IBM System/360 DIAGnose instruction.[10]

Motorola 6800[edit]

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 were reported and given the unofficial mnemonic HCF in a December 1977 article by Gerry Wheeler in BYTE magazine on undocumented opcodes.[11] 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 described the HCF as a "big surprise", and said 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.[11]

Another author wrote in 2002:

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

The 6800's behavior when encountering HCF was known to Motorola by 1976. When the 6800 encounters the HCF instruction, the processor never finds the end of it, endlessly incrementing its program counter until the CPU is reset.[13] Hence, the address bus effectively becomes a counter, allowing the operation of all address lines to be quickly verified. Once the processor entered this mode, it is not responsive to interrupts, so normal operation can only be restored by a reset (hence the "Drop Dead" and "Halt and Catch Fire" monikers). These references are thus to the unresponsive behavior of the CPU in this state, and not to any form of erratic behavior.[citation needed]. Motorola kept the HCF behavior in the 6802 variant of the processor (which released in 1977) as an intentional self-test for the 6802's 128 bytes of onboard RAM.

Other HCF-like instructions were found later on the Motorola 6800 when executing undocumented opcodes FD (cycling twice slower than 9D/DD) or CD/ED (cycling at a human-readable very low frequency on a limited number of high-address lines).[14]

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

Intel x86[edit]

See also: HLT (x86 instruction) and Pentium F00F bug

The Intel 8086 and subsequent processors in the x86 series have an HLT (halt) instruction, opcode F4, which stops 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 resumes execution, which means the processor can always be restarted.[15] Some of the early Intel DX4 chips have a problem with the HLT instruction and cannot be restarted after this instruction is used, which disables the computer and turns HLT into more of an HCF instruction. The Linux kernel has a "no-hlt" option telling Linux to run an infinite loop instead of using HLT, which allows users of these broken chips to use Linux.[16]

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

Many computers in the Intel Pentium line can be locked up by executing an invalid instruction (F00F C7C8), which causes the computer to lock up. This became known as the Pentium F00F bug. No compiler creates the instruction, but a malicious programmer can insert it into code to render an afflicted computer inoperable until the machine is 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.[19][20]

During Black Hat USA 2017, Christopher Domas showed that he found a new "Halt and Catch Fire" instruction[21][22] on an undisclosed x86 processor model using his own x86 processor fuzzer called sandsifter.[23]

Other CPUs[edit]

The NMOS MOS Technology 6502 has 12 invalid instructions which cause the program counter to fail to fetch the next instruction, locking up the CPU and requiring a processor reset.[24][25]  The WDC version of the CMOS 65C02, as well as the 65C816, has the STP (stop, opcode $DB) instruction.  When executed, STP will stop the processor's internal clock, causing all processing to cease—also, the processor will be unresponsive to all inputs except RESB (reset).  The only way to clear the effects of an STP instruction is to toggle RESB.

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. However, the non-maskable interrupt signal can be used to break out of this state, making this pair not a true HCF.[26][27] The /NMI signal is on Pin 17 of the original 40 pin DIP package.[28][29] The pair 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.

The SM83 processor[a][30] core in the Game Boy's LR35902 system on chip has a similar issue, triggered by two consecutive HALTs with interrupts disabled.[b][31] The core itself contains 11 opcodes that fully lock the CPU when executed.[32]

The Hitachi SC61860, mainly used in Sharp pocket computers in the 1980s and 1990s, has an undocumented HCF instruction with the opcode 7B.[33]

See also[edit]

Notes[edit]

  1. ^ The SM83 CPU is similar to the Z80, but not directly related.
  2. ^ When interrupts are disabled, the HALT instruction on the Game Boy CPU does not pause the CPU, but, rather, prevents the CPU's program counter from incrementing on the instruction immediately following the HALT, effectively doubling the instruction after the HALT (or, for a multi-byte instruction, doubling the first byte and separating off the original last byte into a new single-byte instruction); if the instruction after the HALT is itself a HALT, then (as HALT is a single-byte instruction) the CPU effectively sees an infinite series of HALTs, causing the system to lock up.

References[edit]

  1. ^ "6800 Instruction Set" (PDF). Bryan's Old Computers. Archived (PDF) from the original on 2021-05-01. Retrieved 2022-04-09.
  2. ^ a b 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. S2CID 22719798. 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 indefinitely. The problem, which was caused by incomplete opcode decoding, 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". Archived from the original on 2012-05-20. Retrieved 2014-05-04.
  4. ^ Rojas, Raúl (April–June 1997). "Konrad Zuse's Legacy: The Architecture of the Z1 and Z3" (PDF). IEEE Annals of the History of Computing. 19 (2): 5–16 [9–10]. doi:10.1109/85.586067. Archived (PDF) from the original on 2022-07-03. Retrieved 2022-07-03. p. 10: There are a lot of details that the engineer designing the "microprogram" must keep in mind, otherwise short circuits can destroy the hardware. The Z1 with its mechanical design was still more sensitive in this respect than the Z3. Even after it was completed, there were sequences of instructions that the programmer had to avoid in order not to damage the hardware. One of those sequences was inadvertently tried at the Berlin Museum of Technology and Transportation, which led to slight damaging of the reconstructed Z1 in 1994. (12 pages)
  5. ^ Clements, Alan (2006-10-28). Embedding Ethics in Computer Architecture. ASEE/IEEE Frontiers in Education Conference (36 ed.). p. 4. Archived from the original on 2022-04-30. Retrieved 2018-03-02.
  6. ^ Kohler, Eddie (2005-04-04). "CS111 - Lecture 1" (PDF). p. 2. Archived (PDF) from the original on 2018-03-02. Retrieved 2018-03-02.
  7. ^ Dunlap, Bryan. "A Proposed Instruction Set". Physics Department, The Ohio State University. Archived from the original on 2017-09-08. Retrieved 2016-06-20.
  8. ^ Cirsovius, Werner. "Far out op codes". Archived from the original on 2016-03-05. Retrieved 2015-05-28.
  9. ^ "Overextended Mnemonics". Creative Computing. 6 (4): 17 (hex) (flip–side). April 1980. Retrieved 2017-03-12.
  10. ^ IBM System/360 Principles of Operation (PDF). IBM. Archived (PDF) from the original on 2012-02-29. Retrieved 2014-07-02.
  11. ^ a b Wheeler, Gerry (December 1977). "Undocumented M6800 Instructions". BYTE. Vol. 2, no. 12. pp. 46–47. Retrieved 2023-11-20. The mnemonics are, of course, assigned by me.
  12. ^ Agans, David J. (2002). Debugging: the 9 indispensable rules for finding even the most elusive software and hardware problems. New York, USA: American Management Association. p. 77. ISBN 978-0-81442678-4. OCLC 52043345. Archived from the original on 2014-07-26. Retrieved 2016-10-30.
  13. ^ Daniels, R. Gary; Bruce, William (April 1985). "Built-In Self-Test Trends in Motorola Microprocessors". IEEE Design & Test of Computers. 2 (2): 64. doi:10.1109/MDT.1985.294865. S2CID 22719798. Retrieved 2023-08-28.
  14. ^ Demeulemeester, Samuel (2019-07-17). "Investigating the HCF (Halt & Catch Fire) instruction on Motorola 6800". X86.FR – Doc TB's R&D Lab. Archived from the original on 2022-03-31. Retrieved 2022-04-09.
  15. ^ "x86 Instruction Set Reference: HLT". Archived from the original on 2014-07-14. Retrieved 2014-07-02.
  16. ^ Gortmaker, Paul (2003-03-21). "The Linux Boot Prompt-How To" (PDF). The Linux Documentation Project. Archived (PDF) from the original on 2015-07-06. Retrieved 2014-07-02.
  17. ^ "Re: Undocumented opcodes (HINT_NOP)". Archived from the original on 2004-11-06. Retrieved 2010-11-07.
  18. ^ "Re: Also some undocumented 0Fh opcodes". Archived from the original on 2003-06-26. Retrieved 2010-11-07.
  19. ^ Collins, Robert R. (1998-05-01). "The Pentium F00F Bug: Workarounds for a nasty problem". Dr. Dobb's Journal. Archived from the original on 2022-04-30. Retrieved 2014-08-12.
  20. ^ Pentium Processor Specification Update (PDF). Intel Corporation. January 1999. pp. 51–52. Order number 242480-041. Archived (PDF) from the original on 2016-03-04. Retrieved 2006-11-02.
  21. ^ "Breaking the x86 ISA (PDF)" (PDF). Christopher Domas. Archived (PDF) from the original on 2018-01-04. Retrieved 2017-12-09.
  22. ^ "Breaking the x86 ISA (video)". Christopher Domas. Archived from the original on 2021-12-21. Retrieved 2017-12-09.
  23. ^ "sandsifter: the x86 processor fuzzer". Christopher Domas. Archived from the original on 2017-10-25. Retrieved 2017-12-09.
  24. ^ Steil, Michael. "How MOS 6502 Illegal Opcodes really work". pagetable.com. Archived from the original on 2016-07-07. Retrieved 2016-08-01.
  25. ^ Offenga, Freddy. "6502 Undocumented Opcodes". NesDev. Archived from the original on 2016-08-08. Retrieved 2016-08-01.
  26. ^ "Interrupt Mechanism - Development - SMS Power!". Archived from the original on 2016-04-04. Retrieved 2016-04-25.
  27. ^ Flammenkamp, Achim. "Interrupt Behaviour of the Z80 CPU". Archived from the original on 2016-04-20. Retrieved 2016-04-25.
  28. ^ "Pinouts - Z80 family". Archived from the original on 2016-05-08. Retrieved 2016-04-25.
  29. ^ Vis, Peter J. "Zilog Z80 Pinout". Archived from the original on 2016-10-11. Retrieved 2016-04-25.
  30. ^ "Game Boy SM83 CPU reverse engineering". GitHub. Archived from the original on 2022-10-29. Retrieved 2022-11-08.
  31. ^ "GameBoy CPU Manual" (PDF). Archived (PDF) from the original on 2018-06-23. Retrieved 2018-06-22.
  32. ^ "Game Boy CPU instruction set". Archived from the original on 2021-02-09. Retrieved 2021-03-11.
  33. ^ "SC61860 (Aka ESR-H) Instruction Set". GitHub. 2022-03-20. Archived from the original on 2022-03-23. Retrieved 2022-03-23.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Halt_and_Catch_Fire_(computing)&oldid=1224667925"