复现五十年前Apollo-11汇编代码：从交叉汇编到模拟器运行

把一份五十年前的汇编代码跑在现代笔记本上是一种很奇特的体验。项目代号Apollo-11听起来就带着老代码考古的味道它保存的是一台机载制导计算机的完整源代码那台计算机在当年的载人登月任务里承担导航、姿态控制和人机交互。我最初只是好奇一台内存以“K”为计数单位、主频不到百kHz的机器怎么敢接下这么重的活。后来我决定不只满足于看别人的分析文章而是把公开的源码仓库拉下来自己搭起交叉汇编工具链编译出镜像再用开源模拟器把系统跑起来。这篇文章就是这次折腾的完整记录包括我踩过的坑、验证过的细节以及五十年后再看依然觉得厉害的设计思路。如果你对老代码、汇编、模拟器感兴趣或者单纯想知道“没有现代操作系统的时候程序员究竟怎么组织软件”这篇应该合你口味。1. 这份代码到底在解决什么问题任务拆解与工程边界1.1 一台会算数的“飞行员”机载计算机的四个核心任务很多人以为那台计算机是“自动把飞船开到月球”的自动驾驶仪其实它更像一个实时嵌入式控制系统。日常职责可以拆成四块第一块是惯性导航与姿态计算读取陀螺和加速度计的数据维护当前位置、速度和姿态角的数字模型第二块是发动机控制时序什么时候点火、什么时候关机需要按设定程序在精确的毫秒级窗口输出指令第三块是显示与键盘交互让任务成员能查询数据和输入参数第四块是系统监测检测硬件异常并给出报警。对我这种天天接触现代操作系统的人来说最震撼的是这四件事全部跑在同一台不带操作系统、没有文件系统、没有虚拟内存的计算机上一切调度都靠循环和中断。换句话说它没有“进程”概念没有动态分配所有任务的执行时机都是事先编排好的。这不是技术落后而是一种在极端资源约束下的精密设计。1.2 两个版本同时维护指令舱版与登月舱版源码仓库里其实有两套构建目标一套对应指令舱一套对应登月舱。两者的底层模块高度共享导航、时钟、中断服务、显示驱动基本是同一份代码差异集中在任务程序上。打个比方这就像同一套底盘做了两个车型指令舱版要管轨道机动、变轨和返回登月舱版要管下降、着陆和月面停留。这种“公共核心加产品变体”的做法放在今天理所当然但在半个世纪前硬件资源按字节计的时代能把软件架构做得这么清晰相当难得。我复现时没有只挑其中一个而是把两套镜像都编出来方便之后对照两个版本之间到底改了哪些模块。实际对比下来公共部分的改动其实非常少大部分差异都集中在任务程序里这也反过来验证了当初的模块划分是合理的。1.3 我在动手前给自己定的三条验收标准开始之前我就想如果只是把源码编译成功那不算完成得给自己定几条能验收的标准。第一条源码能不能在当前环境下不修改或者只做最小环境适配就成功产出二进制镜像。第二条镜像加载进模拟器后控制面板能不能正常点亮数值显示和按键状态有没有响应。第三条通过面板输入一组指令请求能不能看到系统状态按预期变化而不是只停留在“程序启动了但不知道它在干什么”。这三条标准后来成为我排查问题时的路标。如果你也想做类似的代码考古项目我特别建议先写下类似的可验收目标不然很容易陷进“能跑就行”的错觉里。很多时候程序确实启动了但它到底有没有在干正事只有验收标准能告诉你。2. 从源码到镜像交叉汇编工具链与构建过程复盘2.1 为什么必须“交叉”目标指令集与现代CPU不在一个世界先解释一个基础概念目标机器用的指令集是专门的跟平时用的桌面处理器完全不同。这不是改个编译选项就能编出来的东西必须走交叉汇编。交叉汇编的意思是在本机上运行一个专门的汇编器把源码翻译成目标机器能认识的二进制再由模拟器去加载执行。可以这样理解源码是中文小说你要在一个出版社里把它翻译成英文印刷出来读者读的是英文版出版社就是本机环境英文版就是最终的镜像而模拟器负责“扮演”那些英文读者。搞清楚这条链路后面遇到的报错就能顺藤摸瓜。我当时把链路拆成四段源码、汇编器、镜像文件、模拟器任何一段出问题检查范围都能缩小一大半。2.2 我选定的工具组合与各自的职责工具上没有太多选择余地但组合起来需要各司其职。我最后用的是一套开源组合具体配置如下表环节选型职责说明源码仓库公开历史源码备份仓库提供两套镜像源码和构建脚本汇编器源码仓库自带的历史汇编器把汇编源码翻译为目标机镜像模拟器某开源AGC模拟器模拟目标机CPU、内存、中断与面板外设构建脚本Make脚本与辅助脚本自动完成多次汇编、拼接、校验补充说明一下历史汇编器本身也是老程序第一次在当代系统上编译它时大概率需要修补编译选项或兼容性问题我把这一步单独列出来避免大家以为搭建环境是一路绿灯。我见过很多初学者死磕源码语法结果半天后才发现问题是汇编器根本没编译成功。2.3 构建三步走每一步的意图与潜在问题第一步拉取源码仓库核对文件完整性。老仓库里的文本文件来自几十年前的备份可能在多次转手中混入了奇怪的换行符所以我拉下来第一件事是检查文件数量和关键文件的校验值。这一步看似多余却能避免后面所有“不明原因”的构建失败。第二步编译历史汇编器。我先把汇编器的源码单独拿出来按仓库文档说明的依赖项补齐。这一步我遇到的最典型问题是老代码假设编译器支持某些旧语法在当代工具链里直接报错。处理思路是只做“最小侵入修改”比如替换已经移除的库函数、修正隐式声明而不是重写逻辑。做完之后先让它汇编一段自带的测试样例能通过再进入下一步。第三步执行构建脚本。仓库里其实已经留了构建脚本省了很多事。脚本会依次汇编各个模块最后把生成结果拼接成启动镜像。命令大致是这样make -f Build.a11 # 产出物核心可执行镜像与固定存储镜像后续由模拟器加载我第一次跑的时候脚本在拼接阶段报出长度不一致的错误。检查后发现是某个源文件在文本转换过程中被多塞了几个控制字符导致汇编产出的宽度多了一行。把源文件用二进制模式重新转换后构建顺利结束。这一步能过说明工具链通了。2.4 三个值得记录的坑格式化、编码、路径第一个坑是编辑器自动格式化。老汇编源码非常依赖列对齐操作数和注释的位置都有讲究现代编辑器在打开时常常自动清理尾随空格或者统一缩进。看起来是“好心”实际上直接破坏了源码的列语义汇编器随后报出一堆匪夷所思的错误。我最后用最朴素的等宽编辑器加“禁止自动格式化”配置才解决。建议所有做老代码复现的人第一步先把编辑器的自动保存和格式化关掉。第二个坑是字符编码。仓库里混着一些老的文本控制字符用文件识别命令看部分源码被识别成普通数据而不是文本。我一开始以为是文件损坏后来用二进制查看工具打开才发现是某些块用了一种带控制码的旧编码。处理办法是改成二进制方式读取把多余的控制字节过滤掉再喂给汇编器。这个问题的隐蔽之处在于文件在编辑器里看起来完全正常只有汇编器会在同一个位置反复报错。第三个坑是路径和换行。旧构建脚本是为老目录结构写的在当代系统上经常因为大小写敏感、路径分隔符、换行符差异直接失败。不要手动去改脚本里的路径正确做法是把所有细节都收敛到脚本顶部定义变量然后引用变量。我为此写了几个小脚本辅助差异对比顺带把这些补丁全部做了注释说明。现在回看这些补丁本身也成了复现过程中的一手资料。3. 深入核心它凭什么用那么少的内存完成那么重的任务3.1 资源限制的实感16位字长、2K可擦写内存、85kHz主频先把数字摆出来这台计算机的数据字是15位加符号位固定存储大约36K字可擦写存储只有2K字主频大约在85kHz这个量级。现代一个网页加载时占用的内存动辄就是几百MB相比之下这套系统只有几KB的可用运行内存却要完成导航和姿态控制心里很难没有对比。为了帮你找到体感打个比方如果你把现代操作系统的内核、浏览器、文件系统全都装进几KB的内存剩下的任务是维持飞行器航行你会怎么做制导计算机的做法是代码主体放进只读的固定存储运行时数据放进可擦写存储程序几乎不做动态加载每一个字节都是提前算好占用再布局。这种“存储全静态规划”的思路和我后面在嵌入式项目里看到的裸机程序如出一辙。它之所以有效是因为任务边界是明确且固定的不需要为“未来可能新增的功能”预留弹性空间。3.2 “解释器”是1960年代的虚拟机用空间换结构的巧思整份源码里让我最意外的是这台机器里竟然内置了一个解释器。它会解释执行一套更高层的指令每条解释指令会被翻译成若干条原生指令来执行。为什么在一个资源如此紧张的系统里还要多套一层原因恰恰是省空间如果应用层全部用底层汇编来写重复代码多、可维护性差如果引入常规高级语言光是运行时支持就要吃掉大量内存。解释器做的是在两者之间取平衡用少数原生指令实现一套领域专用指令集让任务程序写得更紧凑。今天很多嵌入式脚本语言、游戏脚本引擎其实还在用同样的设计思路。这套东西放在现在就是“为特定领域定制一个迷你虚拟机”的经典案例。我当时读到解释器那部分代码时反复确认了好几遍因为它实在太像现代虚拟机了解释循环、操作码分派、操作数读取、状态保存每一项都能在现代技术书里找到对应章节。你能感受到设计者并不是没有能力写出更“高级”的结构而是在资源和实时性之间选了最合适的那一种。3.3 时间管理主循环加中断的实时调度实时性是怎么保证的答案不是现代意义上的任务调度器而是一个非常朴素的主循环加中断机制。固定周期产生一次定时中断中断服务函数负责读取传感器、更新导航参数、刷新面板显示主循环则处理按键输入和较低频的日常任务。前台中断保证“关键动作绝不迟到”后台循环保证“日常操作不断档”。现在做实时嵌入式系统的人看到这个结构会很熟悉它本质上是把硬实时任务放在中断上下文把软实时任务放在主循环这种分层处理的思想至今没有过时。我记得自己第一次画出它的执行时序图时心里冒出一句话原来实时系统的教科书五十年前就有人写过了。3.4 在按键和三位显示器上做交互面板交互的设计约束人机交互部分是显示键盘面板十几个数字键、几位数码管、几个状态灯。操作员通过“动词名词”的方式输入指令比如用两个词分别表示“你要做什么操作”和“你要操作哪个对象”。这套交互逻辑其实就是早期命令行界面的雏形只是在硬件上被压缩得非常紧凑。为了在极小空间里保持可用性设计中大量使用了固定编码和默认值没输入数字时按默认参数执行输入错误码时面板直接亮报警灯。这提醒我交互复杂度和硬件能力直接相关今天的UI能做那么多花活底层也是无数类似的小约定堆出来的。当显示区域只有几位数字时你每一条信息都得思考“值不值得占一个显示位”这种约束下的设计决策其实非常适合今天做仪表盘或嵌入式HMI的人参考。4. 模拟运行实测从面板点亮到指令验证4.1 启动流程与面板状态检查安装与初始化到这一步才真正进入“跑起来”环节。我把模拟器和构建出的两个镜像都准备好启动顺序上有个细节先启动模拟器进程再从控制终端加载镜像最后再启动显示面板客户端连接。第一次我只启动了模拟器没确认面板连接端口结果是模拟器在跑但面板上全空我一度以为镜像没写对。后来按文档把启动顺序理清加载镜像、启动面板、观察数码管显示。系统起来后会看到一个自检状态数字显示器上会出现一组特定数值和状态灯这个状态本身就说明内核已经动起来了。这个“灯亮了”的时刻是我整个复现过程中最激动的一瞬间。4.2 按一组指令走通一次标准交互动词加名词的实测我决定实测一组指令组合来验证交互链路。面板上的操作规则是先输入动词数字再输入名词数字然后确认。我在公开命令表里查到了一组用于程序状态查询的常用组合输入后面板应在数码管位置显示当前程序编号或状态信息。这里说明一下具体的数字编码需要以你拿到的命令表为准不同时期版本会有差异我记录的是适合验证启动流程的一组组合。输入完成后面板的反应不是瞬间的系统要经过一次完整扫描周期才会更新大约在一个刷新周期后看到状态变化。看到状态变化后再用同样流程输入一个清除或复位命令确认系统没有卡死。整套过程特别像在没有显示器的老式终端里敲命令反馈只有那几个数字但你能感觉到背后的逻辑正在按你预期的路径执行。4.3 用寄存器监视器验证结果而不只看“能跑”“能跑”不一定等于“跑对”。为了扎实一点我用模拟器自带的寄存器与内存查看功能定位到源码注释里提到的关键地址在操作前后分别读取值作对比。比如某个状态字在操作前是初始值操作后应当被置位到预期值我就盯着那个地址确认变化。这种验证方式值得多说一句如果你做的不是这套系统而是任何模拟器、嵌入式软核相关的项目都应该想办法走到“观察内部状态”这一层而不是只看外部输出。外部输出帮你发现问题内部状态帮你定位问题。我之前做别的复现项目时吃过亏以为外部输出正确就万事大吉结果后面换了输入数据立刻翻车从那以后凡是能看内部寄存器的地方我一定会去看一眼。这套老系统的模拟器在这方面做得相当到位也许是因为维护者自己也是抱着“严谨复现”的目标做的。4.4 崩溃复盘一次按键争抢和一次镜像加载错位过程中还崩过两次。第一次是我在面板上敲数字敲得太快模拟器的按键缓冲积压带动主循环超时整个模拟界面卡住。解决方法不算难停掉面板端进程等模拟器刷新周期过去再重连。这也让我注意到真实面板按键是有限速的快速连点并不符合使用场景。模拟器对连续输入的容忍度比实体设备高很多但你还是能感受到底层循环的被占用状态。第二次崩溃更具迷惑性我加载了两套镜像指令舱版和登月舱版共存于同一个工作目录我随手把登月舱镜像当作指令舱镜像加载结果系统起来后自检状态明显不对面板数值组合在源码注释里对应不到任何合法状态。排查到最后才发现就是镜像错位重新按规范命名工作目录并加上哈希校验问题消失。老流程里的“按文件名区分版本”放到多版本场景下真的不够用。5. 五十年后回看这批老代码里最有含金量的三个设计习惯5.1 “一条指令也不能浪费”的工程节制读这份代码最直接的收获是理解了什么叫资源约束下的工程优先级。由于内存和算力都有限设计者必须放弃一切“锦上添花”的东西每个模块都要回答“它服务哪个核心任务”。这种节制放在今天反而稀缺我们习惯了加抽象、加框架、加运行时经常忘了最基本的目标是什么。我在做嵌入式优化时偶尔会想起这台机器的做法先列出不可让步的硬约束再决定哪些复杂度可以被牺牲。这个顺序一换整个项目的决策都会清爽很多。放在现代业务系统里也一样——先清楚“哪些指标掉链子项目就失败”再去讨论缓存、微服务、可观测性优先级自然就出来了。5.2 用注释记录原因而不只是行为源码里的注释质量出乎意料地高。很多注释不是在解释“这行代码干什么”而是在解释“为什么必须这么干”比如某个限制条件是为应对一次特殊异常而加。这种“原因注释”恰恰是现代工程里最缺的。看多了“给变量赋值”“调用某某函数”这类注释之后再看这些几十年前的老注释会非常感慨。代码考古的价值之一就在这里你能看到前辈程序员如何思考。有一处注释让我印象尤其深它提醒后来者“不要在未确认状态字的情况下修改这段逻辑”短短一句话却至少包含了三个层面的信息这段逻辑很重要、它跟别的模块有隐藏依赖、改它需要先做哪些验证。这种注释放在今天依然值得写进团队的代码规范里。5.3 可复现构建早就该一键化仓库里虽然简陋但构建脚本是完整的文档里甚至记录了应该用什么工具链、按什么顺序构建。这本质上就是在践行“可复现构建”的理念。今天很多项目连一份可以通吃的构建说明都没有反而让人怀念这份五十年前的老仓库。我的体会是构建流程的“文档化”和“自动化”是两码事先做到能把构建步骤写清楚就已经领先很多项目了。等我真正跑通整套流程之后再回头看发现最难的不是某一条命令而是把环境差异、编码转换、路径依赖这些琐碎细节全部理顺。这份老仓库用自己的方式告诉我一个项目能不能被后人理解、复现、继续维护往往不是靠伟大的架构而是靠把基础流程做到位。我跑通整个流程那天晚上盯着模拟器面板上的数字看了很久。一个只有几十kHz主频、几KB内存的系统就把导航、控制和交互安排得明明白白。它教给我的不是怎么造火箭而是怎么在边界里做工程。最后分享一个小技巧如果你也想做类似的老代码复现多准备一个二进制差异对比工具把你重建出的镜像和网上流传的旧镜像逐字节比对。往往一两个字节的差异就能帮你定位工具链版本或者编译器行为的不同这比对着源码一行行去猜要高效得多。