Halt and Catch Fire

# 停止并着火（Halt and Catch Fire） 来源：https://unstack.io/halt-and-catch-fire 我从未看过AMC的电视剧《停止并着火》，很长一段时间里我只知道这个剧名，对剧情一无所知。剧名总让我想起程序员的幽默：有点戏剧化、有点荒谬，又莫名精准。结果发现，这部剧确实讲的是20世纪80年代和90年代的计算机行业，但这个短语本身比剧集古老得多，而且最初是一种工程幽默。 ## 含义 在计算机语境中，**停止并着火**（缩写为**HCF**）已被泛化，指代导致CPU停止执行任何有用操作的机器码，迫使你只能通过重置（或重新上电）机器来恢复。从相当字面的意义上说，它“停止”了机器。当然，“着火”部分是玩笑，但并非像看上去那么牵强。以IBM System/360为例。显然，当该系统遇到某个无效操作码时，它会不断访问磁芯存储器中的特定位置，导致其变得非常热，甚至着火。 随着时间的推移，**HCF**也成为一个总括性标签，指代锁定处理器的未记录或无效操作码、看似死机的有意测试模式，以及真正的硬件错误（你可能还记得，早期一些奔腾级的芯片可以通过精心选择的非法指令被锁定，即著名的F00F漏洞——稍后会详细介绍）。 这个短语的产生，部分是因为使用三个字母的汇编助记符的标准：`ADD`、`CMP`、`JMP`等。这个玩笑在各种出版物中流传，**HCF**连同其他一些我个人偏爱的助记符一起出现： - `EPI`: 立即执行程序员（Execute Programmer Immediately） - `DC`: 分而治之（Divide and Conquer） - `CRN`: 转换为罗马数字（Convert to Roman Numerals） ## 摩托罗拉6800 因此，**HCF**基本上只是一个玩笑，直到它变得不再只是玩笑。 摩托罗拉6800有256个单字节操作码，但并非每个位模式都对应一个已记录的指令。如果命中了错误的模式，芯片会执行硅片“解码”出的任何动作——有时没什么大不了的，有时则意义重大。 格里·惠勒（Gerry Wheeler）在《BYTE》杂志上发表的文章**“未记录的M6800指令”**刊登于**1977年12月**，第**2**卷第**12**期，**技术论坛**栏目，**第46–47页**。他首先引用摩托罗拉自己的文档：**197**个已记录的操作码，这意味着官方描述中还有**59**个位模式未被说明。其中一些行为类似于NOP，一些以惠勒当时表示仍“未破解”的模式更改条件码寄存器，而两个字节——`$9D`和`$DD`——具有一个特别严重的结果，他选择称之为**停止并着火**。他明确表示：“当然，这些助记符是由我所分配的。” 从硬件角度看，实际发生的情况是，该部分不再像正常的取指-译码-执行引擎那样工作：程序计数器继续递增，芯片发出*读*操作，同时地址线像硬件计数器一样遍历内存。中断无法阻止你走向自我毁灭之路——你只能通过复位或重新上电才能摆脱循环。惠勒自己的描述值得阅读原文，而不是转述： > 执行该指令时，唯一能看到它在做什么的方法是用示波器。从用户的角度来看，机器停止了，并且无法通过大多数尝试让它重新启动。那些在地址总线上有指示灯的会看到处理器开始依次快速读取所有内存。实际上，地址总线变成了一个16位计数器。然而，处理器对其读取的内容毫不在意……它只是读取。 关于短语中的“着火”部分，他补充道：“嗯，几乎。”虽然IBM系统确实在某些情况下着火了，但摩托罗拉6800似乎没有。 在《BYTE》之外，相同的操作码系列还有别的绰号。大卫·J·阿甘斯（David J. Agans）在《调试》（2002年）中将**`DD`**记为他团队所称的“*Drop Dead*”指令——相同的总线行走技巧，不同名称——并指出工程师们故意使用它，因为“在示波器上，所有地址线和时钟线都是漂亮、循环的方波”。 大多数机器只是*感觉*像死机了。在一台早期内存映射视频有问题的6800微型计算机上，这种模式可能以可见的“雪花”现象出现。Ben Z在Sphere News上的文章（https://sphere.computer/news/2025-04-04-halt-and-catch-fire.html）是一个值得深入探索的兔子洞（视频RAM仲裁、时序、CRT伪影）。 多年后，摩托罗拉的工程师们撰写了更多关于同一问题的文章。在《IEEE设计与测试》（1985年）中，丹尼尔斯和布鲁斯描述了客户在MC6800上发现的一个非法操作码，内部昵称**HACOF**，其程序计数器可能永远递增直到复位。他们还讲述了一个几乎难以置信的细节：产品工程部门希望在启动期间快速扫描RAM，意识到这种行为已经做到了类似的事情，基本上保留了它而不是花钱移除它。因此，用鲍勃·罗斯的话来说，这变成了一场“美丽的意外”。 最近，有人真的将真实的MC6800放在硬件上进行了实际测量，而不是仅仅相信旧杂志和维基百科页面的扫描件。Doc TB的实验室报告（https://x86.fr/investigating-the-halt-and-catch-fire-instruction-on-motorola-6800/）指出了一个有趣的细节：在获取操作码后，地址线需要几十毫秒的延迟才能稳定到著名的快速计数模式，还有其他未记录的操作码看起来像是相同思想的较慢或故障较多版本。 ## 超越摩托罗拉 摩托罗拉并非唯一出现此问题的现代处理器：锁定CPU的6502非法操作码、奔腾F00F漏洞（https://en.wikipedia.org/wiki/Pentium_F00F_bug）（如果你记得那个时代的话）、在某些架构上永远等待无法到达的中断的指令对，以及现代x86模糊测试中人们仍然在大型处理器中发现无效状态的话题。 基本上，通过模糊测试，他们试图向处理器提供随机或意外数据，以帮助识别处理器中的漏洞或错误。不出所料，这是一种相当有效的策略，不仅适用于处理器，也适用于各种软件。 ## 停止并结束帖子 这是一段有趣的历史研究——结果发现其中的内容比我想象的要多得多，即使是关于“着火”部分也是如此。随着大量软件在堆栈上移，从我们一万英尺的视角很容易忽视硬件。归根结底，它只是一堆硅片以某种方式连接在一起，有时候会出现问题。 我所知道的是，这个短语太好用了，不能不用——期待未来的某个项目（或公司）使用“HCF”这个缩写。 --- ## 来源与更多信息 为了让你有东西可看，以下是一些来源和更多信息的链接： - Gerry Wheeler, "Undocumented M6800 Instructions," *BYTE* Dec 1977 (https://archive.org/details/byte-magazine-1977-12/page/n47/mode/2up) - David J. Agans, *Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems* (AMA, 2002), p. 77 - Ben Z, "Sphere News: Halt and Catch Fire!" (https://sphere.computer/news/2025-04-04-halt-and-catch-fire.html) - RetroComputing SE #15289 (https://retrocomputing.stackexchange.com/questions/15289/behavior-of-lesser-known-illegal-m6800-opcodes) - Doc TB, "Investigating the HCF instruction on Motorola 6800" (https://x86.fr/investigating-the-halt-and-catch-fire-instruction-on-motorola-6800/) - Wikipedia: Halt and Catch Fire (computing) (https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing))