世界を動かす技術を、日本語で。

ハルト・アンド・キャッチ・ファイア

概要

Halt and Catch Fire(HCF) は、コンピュータ業界の ジョーク から生まれた用語。 本来はCPUを 強制停止 させるマシンコードを指す。 Motorola 6800 など特定ハードウェアで実際に類似現象が発生。 現代でも プロセッサのバグや脆弱性発見 に関連する話題。 用語の由来や歴史、実際の事例を 多角的に解説

Halt and Catch Fire(HCF)とは何か

  • Halt and Catch Fire(HCF) は、CPUを強制的に停止させ、リセットや電源再投入以外で復旧できなくする マシンコード の総称。
  • “Catch Fire” は冗談めいた表現だが、IBM System/360のように本当に 発熱・発火 した事例も存在。
  • 三文字のアセンブリニーモニック(ADD、CMP、JMPなど) の命名規則に沿った技術者ユーモア。
  • EPI(Execute Programmer Immediately)DC(Divide and Conquer) など他のジョーク命令も出版物で紹介。
  • HCFは次第に 未定義命令やバグ、テストモードなどCPUがハングアップする状況全般を指す用語に拡大。

Motorola 6800とHCF命令

  • Motorola 6800 では、256通りの1バイト命令のうち、59個が 未定義 として残された。
  • BYTE誌(1977年12月号) でGerry Wheelerが未定義命令の挙動を調査。
    • $9Dおよび$DD命令が Halt and Catch Fire と命名される。
    • 実行時、プログラムカウンタが暴走し、メモリ全域を高速で読み続ける “バスウォーク”現象 が発生。
    • 外部割り込みでも復帰不可、リセット必須。
  • Wheelerの観測:「オシロスコープでしか動作を確認できない」「メモリ全域を高速で読み漁る」。
  • “Catch Fire” は6800では実際の発火は起きなかったが、IBM System/360では 本当に発火 した例あり。
  • “Drop Dead”命令 など、他にも同様の未定義命令に別名が付与された事例。
  • 製品エンジニアリング部門 がRAMスキャン用途としてこの挙動を温存したエピソードも。

他プロセッサでの類似現象と現代への影響

  • 6502や初期Pentium (F00Fバグ)など、他のCPUでも 未定義命令によるフリーズ や脆弱性が存在。
  • 現代のx86プロセッサ でも、 ファジング による脆弱性調査で同様の現象が発見される例。
  • ファジングは、 予期しないデータや命令 を投入し、バグや脆弱性を効率的に発見する手法。
  • ハードウェアバグ・未定義動作 は、ソフトウェア層が進化しても依然として根本的なリスク。

HCF用語の文化的側面と今後

  • HCF はプログラマやエンジニアの間で、 技術的ユーモアや教訓 として親しまれている。
  • ハードウェアの本質的な脆弱性 や、設計上の“偶然の産物”を象徴する存在。
  • 今後も プロジェクト名や企業名 など、象徴的な使い方が続く可能性。

参考文献・さらなる情報

  • Gerry Wheeler, "Undocumented M6800 Instructions," BYTE Dec 1977
  • David J. Agans, Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems(AMA, 2002)
  • Ben Z, "Sphere News: Halt and Catch Fire!" RetroComputing SE #15289
  • Doc TB, "Investigating the HCF instruction on Motorola 6800"
  • Wikipedia: Halt and Catch Fire (computing)

Hackerたちの意見

楽しいショーだったよ。80年代と90年代のコンピュータ業界をフィクションで振り返る感じで、めっちゃ楽しめた。

最初から強烈に始まるね。最初の数話は最高だった。

同じショーランナーが今の『ザ・テラー』のシーズンを担当してるよ(俺のレビューでは「北極のクマショー」って呼んでるけど;あの第一シーズンは素晴らしかった)。

そうそう。大手石油会社とテキサスの企業、そしてコンピュータがカリフォルニアに移っていく様子が描かれてる。メインフレームやパソコン(C64)から、ベージュのPCが台頭してくるのも見れる。イントロも素晴らしいよね:https://youtu.be/yD_kCKiSkoI

実際にはニッチなショーなのが残念。特にリー・ペイスとマッケンジー・デイヴィスの演技は4シーズン通して素晴らしい。機会があれば毎回おすすめしてるけど、見る人は少ないんだよね。みんな『シリコンバレー』を選ぶことが多い。

うん、最後まで本当に素晴らしいショーだった。今までの中で一番好きかも。

まだどこかにダウンロードしてあるから、もう一度見たかったんだ。めっちゃ良かったよ。

同意だね。これはシーズンを通してストーリーがかなり進んだ数少ないショーの一つだったし、ジャンプ・ザ・シャークすることもなかった。

なんでそんなに評価されてるのか分からない。みんなコンピュータの発展について言ってるけど、私が得たのは背景にコンピュータがある恋愛ストーリーだけだった。まるで、SFが家族ドラマの背景に過ぎないようなSF番組と同じだね。

IBM 360が違法なオペコードで火が出たって話は都市伝説だと思う。

データセンターはいつも火事になるからね。無限ループが電力を増やして火事を引き起こすのも納得できる。ただ、実際には機械自体が燃えるわけじゃなくて、建物や配線が燃えるってことだよね。

Commodore PET 4032のビデオシステムは、6545(6845相当)の陰極線管コントローラーによって生成されていて、ビデオバッファのアドレスや水平・垂直同期パルスを作り出してたんだ。これがメモリマップされてて、POKEコマンドを使うときに気をつけないと、CRTのラスタースキャンを止めちゃって、ビームが画面の真ん中に留まっちゃうことがあるんだよね。そうなると、その部分の蛍光体が数分で焼き切れちゃう。HCFとは言えないけど、似たような感じかな。(PETには独自のモニターがあって、当時の一般的なコンポジットモニターとは違って、同期信号が消えたらスキャンを続けなかったらしいよ。)

1978年に6800マイクロプロセッサと6845を使ってシングルボードコンピュータを作ったんだ。それにキーボードも作ったし、ちゃんと動いたんだよ。でも、引っ越しを繰り返すうちに消えちゃったけど、回路図はまだ持ってる。なんか、億万長者になるチャンスを逃しちゃったな!

IBM MDAも6845を使ってたし、非常にシンプルな設計の固定周波数モニターを駆動してたから、標準のタイミングから外れると、フライバックトランスの魔法の煙が出ちゃうこともあったんだ。https://marc.info/?l=classiccmp&m=119637265107100

それは絶対にモニターの欠陥で、プログラマーの重大なミスじゃないよ。壊れたモニターは、そのデザインを承認した人が責任を持つべきだし、オールインワンコンピュータに統合されているモニターでも、外すことを想定してないはず。リンクを提供してくれたuserbinatorが言ってたIBMのMDAモニターのように、ひどいデザインのモニターも見たことがあるけど、私が見たテレビは、同期パルスがないと自由に振動してしまうけど、必要なスキャン周波数に同期するためには「同期」パルスが必要だった。同期パルスがないとラスタースキャンを駆動するリラクゼーションオシレーターやPLLを持たないことでコスト削減を図るのは、昔のブラウン管テレビの時代でも、コンピュータモニターの時代でも、常に無視できるほどのものだった。物理的な安全装置を排除するのは、コスト削減のための受け入れられない方法だよ、特にこのケースのように節約がほんのわずかしかない時にはね。

6845でより起こりやすいリスクは、モニターのフレームフライバックトランスが故障する原因になる、規格外の垂直同期を作り出すことだね。ただ、PETモニターのビームが「パーク」されているという説明は、実際には同じ効果を示唆しているかも。

AIのコメントがめっちゃ多いね。どの投稿にもスパムみたいに湧いてる。しかも、ブログが1年未満のAIアカウントばっかりで、3~6個のつまらないプログラミングプロジェクトを持ってる。マジで何なんだよ。

削除されたのかな?今は主に確立されたアカウントからのコメントしか見ないね。

完全なシリーズがiTunes/Apple TVで過去最低の14.99ドルだよ: https://www.cheapcharts.com/us/itunes/seasons/1745389594

このショーは、80年代と90年代のコンピュータに対する懐かしさをたくさん感じさせてくれる。ハードウェアに触れられて、ハードウェアやソフトウェアが何をしているのか大体理解できた。コンピュータは主にツールとして使っていて、コマンドを受け付けるだけで、決定やワークフローに影響を与えようとはしなかった(もちろん、クリッピーはいたけど)。コンピュータの性能、メモリ、ストレージの進化は、日常のユーザーにとってもっと影響力があった。驚きがあって、生活全体を支配することはなかった。何よりも、まだコンピュータの奴隷にはなっていなかったし、注意を引くためにあらゆる手段を使って作られたデバイスでもなかったんだ。

「それは、物事を物事に導くものだ。」

古い車をいじるときも同じ気持ちになる。

コンピュータに奴隷になってるわけじゃないよ。自分の行動を操るような悪いサービスは使わない方がいい。まだまだ本当に面白いコンテンツがある昔ながらのインターネットが残ってるし。IPv8と、その(最終的には必須になる)デバイス認証がプロトコルレベルで導入されると、こういう擬似匿名の自由な情報交換は終わっちゃうだろうね。良かったのはその時だけだった。

年々面白いなと思うのは、人々がシステムを悪用する(キーアクティベーション、Netflixアカウントの共有、VPN、トレントなど)と、これが深刻な犯罪と見なされるのに対して、企業がシステムを公然と悪用する(解約の迷路、依存、詐欺など)はあまり問題視されないこと。これ、逆であるべきだよね。そうしない限り、システムは常に人々を支配しようとして、人々は良くも悪くも適応していくことになる。

コンピュータは昔と全く同じこと、つまりオペコードを読み取ってバイナリ計算をするだけなんだよね。それだけ。ユーザーにとって敵対的な形でそれをマネタイズする方法を見つけたのは人間と企業なんだ。でも、時間が経てばこれも過ぎ去ると思うし、コンピュータはずっと同じことをし続けるよ。小さなPCBを設計したり、マイクロコントローラーを使ったり、楽しいものを作るのは今でも楽しめるからね。

その奴隷状態に対して何か効果的なことをする時間がなくなってきてるけど、電子的な奴隷状態を「治す」ためにできる非常に効果的なこともある(EMPや他の災害など)んだ。でも、要するに、効果的なことをしたいなら、新しい世代に古い技術を教えなきゃいけない。技術は古くならないけど、ユーザーは年を取るからね。ただ、ユーザーが年を取ると「この事実について気分が良くなる」ことが多いんだけど、新しい技術にアップグレードすることでそれを無視しちゃう。消費主義のこの滑りやすい車輪には、オペレーティングシステムのベンダーによって多くの罠が仕掛けられてるんだ。解決策は、できるだけ若い世代に古い技術を使って素晴らしくて新しい面白いことをするアイデアをすぐに広めることだよ。 >「日常のユーザー」 はい、ほとんどの普通のユーザーは、仕事をするためにこんな後ろ向きな考え方は必要ないです。これは、特に子供たちのためのことなんだ。10年後にもハッカーがまだいることを確実にしなきゃ。

コンピュータサイエンスを勉強していた時、教授が1980年代にアメリカ軍が自己破壊機能を持つチップを持っていたと言ってたんだ。具体的な話は確認できなかったけど、後にDARPAのプログラムがあって、軍用の自己破壊電子機器を目指してたみたい。この話を聞くと、教授の話は偶然のオペコードに基づいた都市伝説かもしれないなって思う。

若い頃は「ジュニアオペレーター」としてたくさんの仕事をしてたんだ。それは他のオペレーターの手伝いをするってこと。私たちが操作していたコンピュータルームにはハロンシステムがあって、ある日、特に大きなログでキャリッジリターンのバイトと一緒にラインフィードバイトを追加するのを忘れちゃって、すごいことになったんだ。IBMのラインプリンターが、必要なログのハードコピーを印刷するために隅に置いてあったんだけど、数メガバイトのログのすべての文字を、同じ紙の位置にできるだけ早く印刷し続けて、数分後には火が出ちゃった。マスクをつけたままオペレーターの椅子に座って、すごく怒ってる上司にcr/lfの印刷ジョブとcrだけのジョブの違いを説明しなきゃいけなかった。二日後、別の上司も同じことをやらかしたから、ちょっとは気が楽になったけど、ランダムなタイプミスで火事になるかもしれないって知ってるのは本当に楽しくなかったよ(報告書の「tr」を正しい場所に入れなかったんだ、ああ!)

これについて面白いのは、古いコンパイラが踏み込まなかった場所があること。例えば6502では、$A2やLDX #immを除いて、2で終わるオペコードは全てJAM命令になるんだ。CPUはその時点で止まっちゃう。後のCMOSバージョンでも大体の$x2命令はそうだったけど、一部はNOPに変換されたんだ。だから、FPGAで6502を実装して、スタック相対アドレッシングを追加したいなら、通常のオペコードと絶対に競合しないオペコードのセットがあるから安心だよ。6502がそれを発行したらすぐに停止するからね(でも燃えたりはしない)。

投稿を読んで、すぐに80年代や90年代のPCにあったビッグレッドボタンを思い出したよ。ハードリセットが唯一の解決策になる状態になることが多かったからね。もちろん、そんな状態でもそれが効かないことも稀にあって、その時は電源を切るしかなかった。あれから何年も、いや、数十年もその状況には遭遇してないけど、遭遇したときはハードウェアの故障だったんだ。昔のようなソフトウェアの故障じゃなかった。