停下来并着火
一句话看懂：“Halt and Catch Fire”（HCF）是一起源于上世纪七十年代的计算机工程幽默，专指那些让 CPU 停止一切正常指令执行、只能通过重置才能恢复的非法操作码。它从一句玩笑变成了真实硬件缺陷与测试模式的代名词，影响至今仍在嵌入式开发和低层调试领域被反复提及。
事件核心：发生了什么
在一篇发表于 1977 年 12 月《BYTE》杂志的文章中，Gerry Wheeler 正式将 Motorola 6800 芯片上两个未定义的字节——$9D 和 $DD——赋予了“Halt and Catch Fire”这个引人注目的名称。这两个非法操作码会触发一种特殊行为：程序计数器不停递增，地址总线像计数器一样对全部内存进行顺序读取，但 CPU 不理睬读取到的任何内容，也不执行任何有用指令，且中断无法打断这一过程，唯一的恢复方法是硬件重置或断电重启。值得注意的是，Wheeler 本人明确表示“这个助记符是我分配的”。后来，这种特性被产品工程团队故意保留，因为它可以在硬件启动时快速扫描 RAM，成了一个“快乐的意外”。类似的故事在其他硬件平台也有上演，例如 IBM System/360 在遭遇无效操作码时会持续访问特定磁芯内存位置导致过热甚至起火，以及早期 Pentium 系列芯片中著名的 F00F 错误。
为什么重要
HCF 的历史展示了计算机工业从工程幽默到真实 bug 的典型演化路径。在汇编语言以三个字母助记符为标准（ADD、CMP、JMP）的背景下，HCF 的创造本身就是一种内部玩笑。但随后的实践表明，那些未被文档记录的非法操作码并非都可忽略——有些被有意用于硬件测试，有些则是掩藏在晶圆设计中的真实缺陷。Motorola 6800 的案例特别值得关注，因为工程师最终选择保留这一“缺陷”作为加速 RAM 检测的手段，体现了硬件调试中实用主义与容错性的结合。这一概念在今天仍有现实意义：嵌入式开发、芯片验证、低层系统调试中，工程师仍然会主动寻找或设计类似的“坏指令”作为诊断工具。
对用户/开发者/创作者的影响
对普通用户而言，HCF 的直接影响几乎为零，它属于芯片工程师和内核开发者的知识遗产。但对从事嵌入式开发、固件调试以及操作系统底层工作的开发者来说，理解 HCF 意味着能够预判硬件在遭遇非法指令时的行为边界。在实际开发中，当 CPU 表现出异常的“全内存扫描”行为而不响应中断时，这既可能是未文档化操作码导致的锁定，也可能是有意设计的测试模式。对创作过“计算机历史”主题内容的作者或开发者来说，HCF 是低成本硬件回溯的绝佳案例——有人已经用真实的 MC6800 芯片在硬件上复现了这一现象，而不再只是翻阅旧杂志的扫描件。
值得关注的后续
第一，HCF 行为在更现代处理器（如 ARM、RISC-V 的某些内部测试模式）中是否存在对应实现，尚待确认；第二，随着芯片逆向工程和开源硬件工具链的普及，更多历史芯片的“隐藏指令”可能被公开；第三，若未来有公司因未文档化操作码导致设备在苛刻环境下不可恢复卡死，可能会推动硬件厂商在指令集规范中明确标注所有可能的非法行为。
