Halt and Catch Fire: '不正なオペコード'の歴史
今日、多くの人々がHalt and Catch Fireをパーソナルコンピュータ革命を描いたAMCの高く評価されたドラマシリーズとして知っていますが、このフレーズは、エンジニアリングのユーモアとハードウェアの不安定さに由来する、もっと古い伝統から生まれています。コンピューティングの初期において、「Halt and Catch Fire」（HCF）は、CPUが有用な作業を停止し、オペレーターがマシンの電源を入れ直す（power-cycle）以外に選択肢がなくなるようなマシンコードの略称となりました。
'不正なオペコード'の解剖学
HCFの本質は、プロセッサが未定義または無効なオペコード（ハードウェアがどのように処理すべきかを知らないビットパターン）に遭遇した状態を指します。完璧に設計されたシステムであれば、無効なオペコードは例外（exception）を発生させるか、制御された停止を引き起こすべきです。しかし、初期のシリコンにおいては、命令セット内のこれらの「穴」が、しばしば予測不可能な動作につながりました。
歴史的に、このフレーズは標準的な3文字のアセンブリ言語のニーモニック（ADD、CMP、またはJMPなど）にかけた言葉遊びでもありました。それは、当時流行していた以下のようなプログラマーのジョークと並んで存在していました：
EPI: Execute Programmer ImmediatelyDC: Divide and ConquerCRN: Convert to Roman Numerals
Motorola 6800と'バス・ウォーキング'のバグ
Motorola 6800において、HCFはジョークから文書化されたハードウェアの癖へと変化しました。このチップは256個の単一バイトのオペコードを備えていましたが、公式に文書化されていたのは197個のみでした。これにより、シリコンが未定義の方法でデコードしてしまう59個のビットパターンが残されました。
1977年のBYTE magazineの記事において、Gerry Wheelerは、壊滅的な失敗を引き起こす2つの特定のバイト、$9Dと$DDを特定しました。これらのオペコードが実行されると、プロセッサはフェッチ・デコード・実行エンジンとしての動作を停止します。その代わりに、プログラムカウンタが無限にインクリメントされ、チップはアドレスバスを通じて継続的なリードリクエストを発行し続けます。
Wheelerが説明した内容は以下の通りです：
この命令が実行されると、何が起きているかを確認する唯一の方法はオシロスコープを使用することです。ユーザーの視点からは、マシンは停止し、再起動の試みの大半を拒否します。アドレスバスにインジケーターランプを備えている人は、プロセッサがメモリの全領域を非常に高速に、順次的に読み取り始めるのを目にするでしょう。事実上、アドレスバスは16ビットのカウンタへと変貌します。
興味深いことに、この動作は必ずしも欠陥として見なされていなかったわけではありません。Motorolaのエンジニアは後にIEEE Design & Test (1985) において、この状態の内部的なニックネームがHACOFであったことを明らかにしました。この「バス・ウォーキング」動作は事実上RAMをスキャンすることになるため、製品エンジニアリング部門は、バグを取り除くためにリソースを費やすよりも、立ち上げプロセス（bring-up process）中のメモリテストを高速に行うための方法として、これを維持することに決定しました。
コアメモリから現代のファジングへ
フレーズの「catch fire」（火を吹く）の部分は、しばしば誇張と見なされますが、物理的な現実に根ざしています。ある記録によれば、IBM System/360では、特定の無効なオペコードがシステムを磁気コアメモリの特定の位置に非常に高速にアクセスさせることで、ハードウェアが過熱し、物理的に火を吹くことがあったと示唆されています。一部の懐疑論者はこれを都市伝説と見なしていますが、ソフトウェアエラーによるハードウェア故障のリスクは、初期のコンピューティングにおける現実的な問題でした。
他の同様の失敗は、さまざまなアーキテクチャに現れています：
- The 6502: CPUをロックさせる可能性がある不正なオペコードを備えていました。
- The Pentium F00F Bug: 特定のバイト列がプロセッサをロックアップさせる有名な欠陥です。
- CRT Burn-in: Commodore PET 4032では、不適切な
POKEコマンドによってCRTのラスタースキャンが停止し、電子ビームが一点に留まり続けることで、数分で画面のホスファーを焼き付けてしまうことがありました。
今日、この遺産はファジング（fuzzing）という形で生き続けています。現代のセキュリティ研究者は、ファジングを使用して、プロセッサにランダムまたは予期しないデータを入力して、無効な状態、脆弱性、またはハードウェアのバグを特定します。これは、本質的に、次のHCF命令を探索するためのハイテク版と言えます。
ハードウェア時代の考察
HCFへの関心は、ソフトウェアとハードウェアの境界が曖昧であった時代を反映しています。ある観察者が指摘したように、80年代と90年代は、開発者が「ハードウェアに直接触れ、ハードウェアとソフトウェアが何を行っているのかを大部分的に理解できる」という驚異を感じられる時代でした。
高レベルの抽象化とクラウドコンピューティングの時代において、すべてのコードの行は、最終的にシリコンを通じて移動する電気信号へと変換されることを忘れがちです。