Loading article…
コンピュータ工学において、アセンブリ言語ニーモニックHCFで知られるHalt and Catch Fire は、コンピュータの中央処理装置(CPU)に意味のある操作を停止させ、通常はコンピュータの再起動を必要とするコンピュータマシンコード命令を指す慣用句です。これはもともと、 IBM System/360コンピュータ (1964 年に導入)の架空の命令を指し、多数のわかりにくい命令ニーモニックに関するジョークでした。
MC6800 （1974年発売）の登場により、プログラマーによって設計上の欠陥が発見されました。オペコードのデコードが不完全なため、2つの不正なオペコード0x9Dと0xDDによって、プロセッサのプログラムカウンターが際限なく増加し、リセットされるまでプロセッサがロックされます。これらのコードは非公式にHCFと名付けられています。MC6802の設計プロセス中に、エンジニアは当初この命令を削除する予定でしたが、テスト目的でそのまま残しました。その結果、HCFは正式な命令として認識されました。[1] [2]その後、HCFは、テスト目的の意図的な命令や意図しない不正な命令など、プロセッサをフリーズさせる可能性のある命令に対するユーモラスな包括的な用語になりました。一部はハードウェアの欠陥と見なされ、システムを共有している場合は、悪意のあるユーザーがそれらを実行してサービス拒否攻撃を開始できます。
実際の命令の場合、この表現の意味は、CPU が意図しない命令 (コード内のバグ) を実行した場合でも、ほとんどの場合はコンピューターは回復できる可能性があるのに対し、HCF 命令の場合は、定義上、再起動せずにシステムを回復する方法がないということです。
「発火する」という表現は、CPUチップがバス回路を切り替える速度を誇張して冗談めかして表現したもので、その結果、バス回路が過熱して燃えてしまうというものである。[3]
起源
コンラート・ツーゼが製造したZ1（1938年）とZ3（1941年）コンピュータには、誤って実行するとハードウェアに損傷を与える不正な命令シーケンスが含まれていました。[4]
伝説によると、この用語はIBM System/360の不正な命令コードと関連しているという。プロセッサは、この命令に遭遇すると、バスラインを非常に高速に切り替え始め、過熱を引き起こす可能性がある。[5] [6]
コンピュータのアセンブリ言語では、マシンコード命令と直接同等のニーモニックが使用される。ニーモニックは、ADD、CMP（2つの数値を比較する）、JMP（プログラム内の別の場所にジャンプする）など、多くの場合3文字である。HCF命令は、もともと架空のアセンブリ言語命令であり、 XPR（Execute Programmer）やCAI（Corrupt Accounting Information）など、他の多くの面白い3文字の頭字語とともに、 System/360コンピュータで使用するためにIBMで開発中であると言われた。また、"Self Destruct Immediately"の"SDI" [7]や"Convert to Roman Numerals"の"CRN" [8]などの他のジョークニーモニックにも似ている。HCFを含むそのようなニーモニックのリストは、1980年4月のCreative Computingの裏表紙のパロディ号に「Overextended Mnemonics」として掲載されている。 [9]
現代のCPUでは
CPU設計者は、IBM System/360 DIAGnose命令など、テスト目的で文書化されていないマシンコード命令を1つ以上組み込むことがあります。[10]
モトローラ 6800
モトローラ6800 マイクロプロセッサは、文書化されていないアセンブリ ニーモニック HCF が広く知られるようになった最初のマイクロプロセッサでした。オペレーション コード (オペコード- 実行する操作を指定するマシン言語命令の部分) の 16 進数 9D と DD が報告され、非公式のニーモニック HCF が与えられたのは、1977 年 12 月のBYTEマガジンに掲載された、文書化されていないオペコードに関するジェリー ウィーラーの記事でした。[11]ウィーラーは、モトローラが M6800 プロセッサに対して 197 の有効なオペレーション コードを報告したことを指摘し、8 ビットの組み合わせが 256 通りあるため、59 の無効な命令があるはずだと推測しました。彼は HCF を「大きな驚き」と表現し、ニックネームの Catch Fire の部分については「まあ、ほぼ」と述べました。
この命令が実行されると、それが何をしているかを見る唯一の方法はオシロスコープを使うことです。ユーザーの観点から見ると、マシンは停止し、再起動を試みてもほとんど効果がありません。アドレスバスにインジケータランプが付いている人は、プロセッサがメモリ全体を非常に高速に順番に読み取り始めるのがわかります。実際には、アドレスバスは 16 ビットのカウンタになります。ただし、プロセッサは読み取っている内容には注意を払いません。単に読み取るだけです。[11]
別の著者は2002年にこう書いています。
Motorola 6800 マイクロプロセッサの昔、命令コード DD はプロセッサを無限ループに陥らせ、各メモリ アドレスを順番に読み取りました。(他のエンジニアはこれを「Halt and Catch Fire」[HCF] 命令と呼んでいましたが、私たちはこのコードを「Drop Dead」命令と呼んで覚えていました。) Drop Dead モードは、スコープでハードウェアのタイミングとアドレス ロジックの問題を見つけるのに最適でした。すべてのアドレス ラインとクロック ラインは良好で、矩形波を循環していました。[12]
HCF に遭遇したときの 6800 の動作は、1976 年までにモトローラに知られていました。6800 が HCF 命令に遭遇すると、プロセッサは命令の終わりを見つけることがなく、CPU がリセットされるまでプログラム カウンタを際限なく増加させます。[13]したがって、アドレス バスは事実上カウンタになり、すべてのアドレス ラインの動作を迅速に検証できます。プロセッサがこのモードに入ると、割り込みに応答しなくなるため、通常の動作を復元するにはリセットするしかありません (「Drop Dead」や「Halt and Catch Fire」という呼び名が由来)。したがって、これらの言及は、この状態での CPU の応答しない動作を指しており、何らかの異常な動作を指しているわけではありません。[要出典]。モトローラは、6802 の 128 バイトのオンボード RAM の意図的なセルフテストとして、プロセッサの 6802 バリアント (1977 年にリリース) に HCF の動作を残しました。
その他のHCFに似た命令は、後にモトローラ6800で、文書化されていないオペコードFD（9D/DDの2倍の速度で循環）またはCD/ED（限られた数の高アドレス行で人間が読める非常に低い周波数で循環）を実行するときに発見されました。[14]
HCFはモトローラのマイクロプロセッサに初めて組み込まれたセルフテスト機能であると考えられています。[2]
インテル x86
Intel 8086 およびそれ以降の x86 シリーズのプロセッサには、命令の実行を停止し、プロセッサを HALT 状態にするHLT (停止) 命令 (オペコード F4) があります。有効な割り込み、デバッグ例外、BINIT 信号、INIT 信号、または RESET 信号によって実行が再開されるため、プロセッサはいつでも再起動できます。[15]初期の Intel DX4 チップの一部には HLT 命令に問題があり、この命令を使用した後は再起動できず、コンピュータが無効になり、HLT が HCF 命令に近くなります。Linux カーネルには、Linux に HLT を使用する代わりに無限ループを実行するように指示する "no-hlt" オプションがあり、これにより、これらの壊れたチップのユーザーが Linux を使用できます。[16]
80286には文書化されていないオペコード0F 04があり、実行するとCPUがハングアップする。唯一の解決策はCPUをリセットすることだ。[要出典] [17]一部の実装では、オペコードは停止シーケンスとしてBIOSを通じてエミュレートされる。[18]
Intel Pentium シリーズの多くのコンピュータは、無効な命令 (F00F C7C8) を実行するとロックアップし、コンピュータがロックアップすることがある。これはPentium F00F バグとして知られるようになった。この命令を作成するコンパイラはないが、悪意のあるプログラマがコードにこの命令を挿入すると、マシンの電源を入れ直すまでコンピュータが動作不能になる。このバグが発見されて以来、コンピュータがロックアップするのを防ぐ回避策が開発され、その後の Intel プロセッサではこのバグは解消された。[19] [20]
Black Hat USA 2017で、クリストファー・ドーマスは、独自のx86プロセッサファザー「sandsifter」を使用して、非公開のx86プロセッサモデル上で新しい「Halt and Catch Fire」命令[21] [22]を発見したことを示しました。[23]
その他のCPU
NMOS MOS Technology 6502には、プログラムカウンタが次の命令をフェッチできず、CPU がロックアップしてプロセッサのリセットが必要になる無効な命令が 12 個あります。[ 24 ] [25] CMOS 65C02のWDC バージョンと65C816には、 (stop, opcode ) 命令があります。これを実行すると、プロセッサの内部クロックが停止し、すべての処理が停止します。また、プロセッサは (reset) 以外のすべての入力に応答しなくなります。命令の効果をクリアする唯一の方法は、 を切り替えることです。
STP$DBSTPRESBSTPRESB
Zilog Z80では、 DI (割り込みを無効にする) を実行してから HALT (割り込みを待つ) を実行すると、CPU は発生し得ない割り込みを待ちながら無期限にフリーズしたままになります。ただし、マスク不可能割り込み信号を使用してこの状態から抜け出すことができるため、このペアは真の HCF ではありません。[26] [27] /NMI 信号は、オリジナルの 40 ピン DIP パッケージのピン 17 にあります。[28] [29] /NMI ピンが +5V レールに直接接続されていてその信号の生成が不可能になっている場合、または /NMI を処理する割り込みルーチンがリターンで終了して HALT 状態に戻っている場合にのみ、このペアは HCF 状態になります。
ゲームボーイのLR35902システムオンチップのSM83プロセッサ[a] [30]コアにも同様の問題がある。割り込みが無効になっている状態でHALTが2回連続して発生すると、この問題が発生する。 [b] [31]コア自体には、実行時にCPUを完全にロックする11個のオペコードが含まれている。[32]
1980年代から1990年代にかけてシャープのポケットコンピュータで主に使用されていた日立SC61860には、オペコード7Bを持つ文書化されていないHCF命令があります。[33]
参照
注記
- ^ SM83 CPU は Z80 に似ていますが、直接の関係はありません。
- ^ 割り込みが無効になっている場合、ゲームボーイ CPU の HALT 命令は CPU を一時停止しませんが、HALT の直後の命令で CPU のプログラム カウンターが増分するのを防ぎ、HALT の後の命令を実質的に 2 倍にします (または、マルチバイト命令の場合は、最初のバイトを 2 倍にして、元の最後のバイトを新しい 1 バイト命令に分離します)。HALT の後の命令自体が HALT である場合、(HALT は 1 バイト命令であるため) CPU は実質的に無限の HALT の連続を認識し、システムがロックアップします。
参考文献
- ^ 「6800 命令セット」(PDF)。Bryan 's Old Computers。2021 年 5 月 1 日時点のオリジナルよりアーカイブ(PDF) 。2022 年 4 月 9 日閲覧。
- ^ ab Daniels, R. Gary; Bruce, William (1985 年 4 月). 「Motorola マイクロプロセッサの組み込みセルフテストの動向」. IEEE Design & Test . 2 (2): 64–71. doi :10.1109/MDT.1985.294865. S2CID 22719798.
さらに悪いことに、MC6800 でお客様が見つけた命令である HACOF が不正であることが判明しました。これは未使用の命令コードであり、不正な命令でした。誤って実行すると、プログラム カウンタが無限に増加します。不完全な命令コードのデコードによって発生したこの問題は、リセットが命令を終了する唯一の手段であったため、厄介な問題でした。... 設計プロセス中に、HACOF 命令を削除する方法を見つけました。その頃、製品エンジニアがアイデアを持ってやって来ました。彼らはこう言いました。「私たちが本当に欲しいのは、RAM をすばやくテストする方法です。プログラム カウンタを最初の RAM アドレスにポイントし、RAM をインクリメントすることができれば、はるかに高速にテストできます。」HACOF「命令」はまさにそれを実行するため、そして私たちはそれを削除するのに必要な労力を本当に費やしたくなかったので、「いい取引がありますよ!」と答えました。こうして、HACOF は Motorola マイクロプロセッサに意図的に組み込まれた最初の自己テスト機能となりました。
- ^ 「HCF アセンブリ ニーモニックの Jargon ファイル エントリ」。2012 年 5 月 20 日時点のオリジナルよりアーカイブ。2014 年 5 月 4 日に取得。
- ^ Rojas, Raúl (1997年4月～6月). 「Konrad Zuseの遺産: Z1とZ3のアーキテクチャ」(PDF) . IEEE Annals of the History of Computing . 19 (2): 5–16 [9–10]. doi :10.1109/85.586067. 2022年7月3日にオリジナルからアーカイブ(PDF) . 2022年7月3日に取得。p. 10:
「マイクロプログラム」を設計するエンジニアが留意しなければならない細部がたくさんあります。そうでないと、短絡によりハードウェアが破壊される可能性があります。機械設計の
Z1は、この点で
Z3
よりもさらに敏感でした
。完成した後でも、ハードウェアを損傷しないようにプログラマーが回避しなければならない命令シーケンスがありました。それらのシーケンスの 1 つが
ベルリン技術交通博物館
で誤って試行され
、1994 年に再建された Z1 に軽微な損傷が発生しました。
（12ページ）
- ^ Clements, Alan (2006-10-28). Embedding Ethics in Computer Architecture. ASEE/IEEE Frontiers in Education Conference (36 ed.). p. 4. 2022-04-30時点のオリジナルよりアーカイブ。2018-03-02に閲覧。
- ^ Kohler, Eddie (2005-04-04). 「CS111 - Lecture 1」(PDF) . p. 2. 2018-03-02 時点のオリジナルよりアーカイブ(PDF) . 2018-03-02閲覧。
- ^ Dunlap, Bryan. 「提案された命令セット」。オハイオ州立大学物理学部。2017年9月8日時点のオリジナルよりアーカイブ。2016年6月20日閲覧。
- ^ Cirsovius, Werner. 「Far out op codes」。2016年3月5日時点のオリジナルよりアーカイブ。2015年5月28日閲覧。
- ^ 「Overextended Mnemonics」. Creative Computing . 6 (4): 17 (hex) (flip–side). 1980年4月. 2017年3月12日閲覧。
- ^ IBM System/360 Principles of Operation (PDF) . IBM . 2012-02-29 のオリジナルからアーカイブ(PDF) . 2014-07-02に取得。
- ^ ab Wheeler, Gerry (1977 年 12 月). 「Undocumented M6800 命令」. BYTE . 第 2 巻、第 12 号。pp. 46–47 . 2023 年 11 月 20 日閲覧。
ニーモニックは、もちろん私が割り当てたものです。
- ^ Agans, David J. (2002). デバッグ: 最も見つけにくいソフトウェアとハードウェアの問題を見つけるための 9 つの必須ルール。米国ニューヨーク: American Management Association。p. 77。ISBN 978-0-81442678-4. OCLC 52043345. 2014年7月26日時点のオリジナルよりアーカイブ。2016年10月30日閲覧。
- ^ Daniels, R. Gary ; Bruce, William (1985 年 4 月)。「Motorola マイクロプロセッサの組み込みセルフテストの動向」。IEEE Design & Test of Computers。2 ( 2): 64。doi : 10.1109 /MDT.1985.294865。S2CID 22719798。2023年 8 月 28 日 に閲覧。
- ^ Demeulemeester, Samuel (2019-07-17). 「Motorola 6800 の HCF (Halt & Catch Fire) 命令の調査」X86.FR – Doc TB's R&D Lab。 2022-03-31 時点のオリジナルよりアーカイブ。2022-04-09に取得。
- ^ 「x86 命令セットリファレンス: HLT」。2014 年 7 月 14 日時点のオリジナルよりアーカイブ。2014 年 7 月 2 日閲覧。
- ^ Gortmaker, Paul (2003-03-21). 「Linux ブートプロンプトの使い方」(PDF) . Linux ドキュメンテーション プロジェクト。2015-07-06にオリジナルからアーカイブ(PDF)されました。2014-07-02に取得。
- ^ 「Re: 文書化されていないオペコード (HINT_NOP)」。2004 年 11 月 6 日時点のオリジナルよりアーカイブ。2010 年 11 月 7 日閲覧。
- ^ 「Re: 文書化されていない 0Fh オペコードもいくつかあります」。2003 年 6 月 26 日時点のオリジナルよりアーカイブ。2010 年 11 月 7 日閲覧。
- ^ Collins, Robert R. (1998-05-01). 「Pentium F00F バグ: 厄介な問題の回避策」. Dr. Dobb's Journal . 2022-04-30 時点のオリジナルよりアーカイブ。2014-08-12に取得。
- ^ Pentium プロセッサ仕様アップデート(PDF)。Intel Corporation。1999 年 1 月。pp. 51–52。注文番号 242480-041。2016年 3 月 4 日のオリジナルからアーカイブ(PDF) 。2006年 11 月 2 日に取得。
- ^ 「Breaking the x86 ISA (PDF)」(PDF)。Christopher Domas。2018年1月4日時点のオリジナルよりアーカイブ(PDF) 。 2017年12月9日閲覧。
- ^ 「x86 ISAの破壊（ビデオ）」Christopher Domas。2017年8月31日。2021年12月21日時点のオリジナルよりアーカイブ。2017年12月9日閲覧。
- ^ 「sandsifter: x86 プロセッサ ファザー」。Christopher Domas。2017 年 10 月 25 日時点のオリジナルよりアーカイブ。2017年 12 月 9 日閲覧。
- ^ Steil, Michael. 「MOS 6502 不正オペコードの実際の動作方法」pagetable.com。2016年 7 月 7 日のオリジナルからアーカイブ。2016年 8 月 1 日に取得。
- ^ Offenga, Freddy. 「6502 文書化されていないオペコード」。NesDev。 2016 年 8 月 8 日時点のオリジナルよりアーカイブ。2016 年 8 月 1 日閲覧。
- ^ 「割り込みメカニズム - 開発 - SMS Power!」。2016年4月4日時点のオリジナルよりアーカイブ。2016年4月25日閲覧。
- ^ Flammenkamp, Achim. 「Z80 CPU の割り込み動作」。2016 年 4 月 20 日時点のオリジナルよりアーカイブ。2016年 4 月 25 日閲覧。
- ^ 「ピン配置 - Z80 ファミリー」。2016 年 5 月 8 日時点のオリジナルよりアーカイブ。2016 年 4 月 25 日閲覧。
- ^ Vis, Peter J. 「Zilog Z80 Pinout」。2016年10月11日時点のオリジナルよりアーカイブ。2016年4月25日閲覧。
- ^ “Game Boy SM83 CPUリバースエンジニアリング”. GitHub . 2022年10月29日時点のオリジナルよりアーカイブ。2022年11月8日閲覧。
- ^ 「GameBoy CPU マニュアル」(PDF) 。2018年 6 月 23 日のオリジナルからアーカイブ(PDF) 。2018 年 6 月 22 日閲覧。
- ^ “Game Boy CPU instruction set”. 2021年2月9日時点のオリジナルよりアーカイブ。2021年3月11日閲覧。
- ^ “SC61860 (別名 ESR-H) 命令セット”. GitHub . 2022-03-20. 2022-03-23 時点のオリジナルよりアーカイブ。 2022-03-23取得。