★ FEATURED ARTICLE 1. 从“Apollo-11”这个名字说起它到底指什么第一次看到“Apollo-11”这个标题很多人脑子里蹦出来的第一反应是阿波罗登月计划。没错这个命名确实借用了那段人类探索史里最有辨识度的符号但在技术圈子里它更多时候指向的是一份被反复引用的开源代码仓库——一份把当年登月导航计算机里跑的核心飞行软件源码公开出来的资料集。我第一次接触它是在翻一份关于嵌入式系统历史演进的资料时当时以为只是扫描件合集结果打开一看里面是完整的汇编源码、注释、任务分段说明甚至还有当年工程师手写的笔记扫描。那种感觉就像你以为只是去看一张老照片结果推开门发现是一整间保存完好的工作室。这份资料的核心价值不在于“怀旧”而在于它是一份极其罕见的、真实运行过的、在极端约束条件下写出来的高可靠系统样本。当年的导航计算机主频不到1MHz内存以KB计却要完成载人飞行、导航、制导、控制等一整套任务。今天我们在动辄几十GB内存、多核并行的环境里写代码很多工程直觉已经退化了——比如对内存布局的敏感度、对指令周期的敬畏、对“每一行代码都必须有存在理由”的执念。Apollo-11这份源码恰好把这些东西原封不动地摆在你面前。它适合谁看如果你是嵌入式开发、实时系统、高可靠性软件方向的从业者这份资料值得你花几个晚上逐段读。如果你只是对计算机历史感兴趣它也能给你提供一个非常具体的切入点而不是停留在“当年很厉害”这种模糊印象上。我写这篇东西的目的就是把这份资料里最值得挖的几个层面拆开结合我自己读代码和做嵌入式项目的经验讲清楚它为什么在几十年后依然有参考价值以及你可以怎么用它来校准自己的工程判断。2. 这份源码的物理形态它到底长什么样2.1 文件组织与命名逻辑打开这份资料最先看到的是一堆以任务阶段命名的文件。当年的软件不是按“模块”来切的而是按飞行阶段来切的——比如助推段、入轨段、奔月段、着陆段、上升段、返回段。每个阶段有独立的代码段段与段之间的切换由任务序列控制。这种组织方式在今天看来很“反模块化”但它背后的逻辑非常清晰每个阶段对实时性、内存占用、中断响应的要求完全不同混在一起反而会增加验证难度。文件命名里大量出现“BURN”“COAST”“LAND”这类动词而不是“ModuleA”“ServiceB”这种抽象命名。我一开始觉得这只是时代习惯后来意识到这其实是一种极强的语义约束——你看到文件名就知道这段代码在飞行流程里的位置不需要额外查文档。今天很多项目用一堆缩写命名模块新人进来第一周全在猜名字对比之下这种“动词阶段”的命名反而更高效。2.2 汇编语言的选择不是保守而是必然很多人看到通篇汇编会觉得“当年没办法”。但如果你仔细看代码结构会发现他们并不是在“将就”而是在主动利用汇编的特性。比如有一段处理雷达数据的代码他们手动安排了累加器的使用顺序让连续几条指令共享同一个寄存器省掉了中间存储。这种优化在编译器生成的代码里几乎不可能出现因为编译器不会知道“这个值在接下来三个周期内不会被覆盖”。我做过一个粗略的对比同样一段定点数乘法累加逻辑用当年这种手写汇编的方式指令数比用早期高级语言编译器生成的版本少将近四成。在内存只有几KB的环境里四成的指令数差距直接决定了你能不能把整个任务塞进去。所以这不是“没办法才用汇编”而是在那个约束条件下汇编是唯一能同时满足功能和资源限制的选择。2.3 注释密度与注释风格这份源码的注释密度高得惊人。有一段我数过平均每三行代码就有一行注释而且注释不是重复代码在做什么而是在解释“为什么这样做”。比如有一处注释写着“此处不能使用中断因为中断服务程序会修改累加器而当前值在下一个周期还要用”。这种注释在今天很多项目里已经绝迹了——大家更习惯写“计算速度”“更新状态”这种废话注释。我后来在自己的嵌入式项目里试着模仿这种注释风格要求自己每写一个非直观的操作必须写清楚“如果换成另一种写法会出什么问题”。坚持了两个月之后代码 review 的效率明显提升因为 reviewer 不需要反复问“这里为什么不用更简单的写法”。这个习惯就是从读 Apollo-11 源码里学来的。3. 任务分段与优先级设计实时系统的原始教科书3.1 为什么按任务阶段切代码前面提到文件按飞行阶段组织但更值得看的是每个阶段内部的执行结构。当年的导航计算机没有现代意义上的操作系统任务调度是靠一套固定的执行序列加上中断来完成的。每个阶段有一个主循环循环里按固定顺序调用各个处理块中断只处理最紧急的事件比如姿态偏差超限。这种设计的核心思想是确定性优先于吞吐量。主循环每一轮执行的时间是固定的因为每个处理块的执行路径和指令数都是预先算好的。今天很多实时系统追求“平均响应时间”但在载人飞行里平均没有意义最坏情况才有意义。你必须在设计阶段就知道“最坏情况下从传感器读到数据到输出控制指令需要多少个周期”然后确保这个数字小于安全阈值。我在做一个工业控制项目时借鉴了这个思路。当时团队在争论要不要用动态任务队列我坚持改成了固定顺序轮询加中断。上线后最坏响应时间从原来的不确定变成了可计算的固定值虽然平均响应时间变长了一点但系统稳定性上了一个台阶。这个决策的直接来源就是 Apollo-11 的任务分段结构。3.2 优先级不是“重要程度”而是“错过代价”这份资料里有一个非常清晰的优先级划分逻辑不是按“这个任务重不重要”来排而是按“如果这个任务晚执行一个周期后果是什么”来排。姿态控制相关的任务优先级最高因为姿态偏差如果不及时修正会迅速累积成不可逆的轨道偏差。而一些遥测数据的打包和发送优先级很低因为晚几个周期发送不影响飞行安全。这个思路听起来简单但实际做项目时很容易跑偏。我自己就犯过一个错误在一个数据采集项目里把“数据完整性校验”的优先级设得比“传感器读取”还高理由是“数据不完整后面全白做”。结果在高负载情况下校验任务挤占了传感器读取的时间窗口导致采样周期抖动反而让数据质量更差。后来重新按“错过代价”来排把传感器读取放到最高优先级校验放到空闲时间做问题才解决。3.3 中断服务程序的极简原则源码里的中断服务程序短得令人发指。有一段处理时钟中断的代码总共不到二十条指令只做三件事更新计时器、设置一个标志位、返回。所有复杂的处理都放到主循环里根据标志位来做。这种“中断只做最少的事”的原则在今天很多嵌入式教程里也会提但真正执行到位的不多。我见过不少项目在中断里做浮点运算、做内存分配、甚至做日志打印。这些操作在中断上下文里要么耗时不可控要么可能引发重入问题。Apollo-11 的写法是中断里只碰最少的全局变量而且这些变量在主循环里的访问顺序是经过设计的确保不会出现竞态。这种严谨程度在今天看来依然有很强的参考意义。4. 内存与算力约束下的工程取舍4.1 定点数运算的全面采用这份源码里几乎看不到浮点数运算。所有涉及小数的地方都用定点数表示小数点位置由工程师手动维护。比如计算轨道参数时他们会把角度值放大一定倍数存成整数运算完再缩小回去。这样做的好处是运算速度快、内存占用小、结果完全确定。今天很多嵌入式芯片已经带硬件浮点单元了所以很多人默认“浮点随便用”。但我在实际项目里发现即使有硬件浮点定点数在某些场景下依然有优势。比如在一个电机控制项目里用定点数做PID运算响应时间比浮点版本稳定得多因为定点运算的周期数是固定的而浮点运算在某些边界条件下会触发异常处理导致周期数跳变。这个经验让我重新理解了 Apollo-11 当年全面采用定点数的决策——不只是因为硬件不支持浮点更是因为定点数提供了更好的时间确定性。4.2 内存复用的极致操作源码里有一段处理导航数据的代码同一个内存区域在不同阶段被赋予完全不同的含义。在奔月段这块区域存的是速度增量在着陆段同一块区域被重新解释为高度变化率。这种“一块内存多种用途”的做法在今天看来很危险但在当年内存以KB计的环境里这是必须的。我并不是建议你在现代项目里也这么干但理解这种做法的思路是有价值的内存不是“越多越好”而是“每一字节都要有明确的生命周期”。我在做一个资源受限的物联网设备固件时借鉴了这个思路把几个不同状态下的配置参数合并到一个联合体里省下了将近30%的RAM。当然我加了严格的编译期检查来确保不会同时访问两个互斥的字段这是现代工具能提供的安全保障当年没有。4.3 指令周期的手工计算资料里有一些工程师手写的周期计算表列出了一段代码在最坏情况下的执行周期数。这种手工计算在今天几乎绝迹了因为编译器会帮你做指令调度处理器有流水线和缓存精确计算周期变得非常困难。但在当年这种计算是必须的因为整个系统的实时性保证就建立在这些数字上。我并不是说你要回到手工计算周期的时代但有一个习惯值得保留对你系统里最关键的几条路径心里要有一个时间预算。比如在一个通信协议栈里从收到数据包到发出应答中间经过哪些处理每个处理大概耗时多少最坏情况是多少。你不需要精确到周期但需要有一个量级上的把握。我在做一个低延迟通信项目时就是靠这种“量级预算”发现了协议栈里一个不必要的内存拷贝去掉之后延迟直接降了一半。5. 从源码里能学到的验证与测试思路5.1 边界条件的显式处理源码里大量出现对边界条件的显式判断。比如计算角度时会先判断是否接近0度或360度然后走不同的处理分支。这种写法在今天看来很啰嗦因为现代语言和库通常会帮你处理这些边界。但在当年这种显式处理是保证正确性的唯一方式。我在做金融计算相关项目时重新理解了这种做法的价值。浮点数在接近零的时候精度会急剧下降如果你不显式处理结果可能完全错误。Apollo-11 的工程师们没有浮点库可以依赖所以他们养成了“每个计算都要考虑边界”的习惯。这个习惯在今天依然值得保持尤其是当你处理的是钱、是安全、是不可逆的操作时。5.2 冗余校验与交叉验证资料里有一段关于导航数据校验的代码同一个物理量用两种不同的方式计算然后比较结果。如果偏差超过阈值就触发告警并切换到备用方案。这种“交叉验证”的思路在今天的高可靠性系统里依然是标准做法但很多普通项目里很少见。我在做一个数据采集系统时借鉴了这个思路关键传感器数据同时用两种滤波算法处理如果两个结果偏差过大就标记该数据点为可疑。这个机制后来真的帮我们抓到了一个传感器间歇性故障——单看一种算法的输出完全正常但两种算法结果一对比就露馅了。5.3 故障注入与恢复路径源码里有一些看起来“多余”的分支处理的是各种传感器失效、数据超限、计算溢出的情况。这些分支在正常飞行中几乎不会被执行但它们的存在保证了即使出现异常系统也能进入一个安全状态。这种“为不会发生的情况写代码”的做法在今天很多追求快速迭代的项目里被牺牲掉了。我自己的体会是故障处理代码的价值不在于它被执行的频率而在于它被执行时能不能真的把系统带回安全状态。我在一个自动化测试项目里专门花了两天时间写各种异常恢复逻辑当时团队觉得浪费时间。后来在一次长时间压力测试中一个不常见的资源竞争条件触发了异常正是那段“浪费时间”的恢复代码让系统自动回到了正常状态没有导致测试中断。从那以后团队里再没人质疑故障处理代码的必要性了。6. 把 Apollo-11 的思路用到现代项目里的具体做法6.1 先定时间预算再写代码当年工程师是先算周期再写代码今天很多人是先写代码再测性能。这两种顺序带来的结果完全不同。我现在的习惯是在动手写一个关键模块之前先在一张纸上列出这个模块的时间预算——从入口到出口最多允许花多少时间中间每个步骤大概分配多少。写代码的时候时刻对照这个预算如果某个步骤超了就重新设计。这个习惯的直接来源就是 Apollo-11 源码里的那些周期计算表。虽然我不用精确到指令周期但“先有预算再有实现”这个顺序帮我避免了很多后期优化的麻烦。6.2 中断里只做三件事受源码启发我给自己定了一个规矩中断服务程序里只做三件事——更新一个状态变量、设置一个标志位、清除中断源。所有其他处理都放到主循环里根据标志位来做。这个规矩执行下来系统的响应抖动明显减小而且调试变得容易很多因为中断上下文里的代码少到几乎不会出错。6.3 每个非直观操作都要写“为什么”源码里的注释风格我前面提过这里再强调一下具体做法每当你写了一个“看起来可以更简单但你没那么写”的地方立刻在注释里写清楚原因。比如“这里不用循环是因为循环变量的内存地址和中断服务程序冲突”“这里手动展开是因为编译器生成的代码会多一次内存访问”。这种注释在代码 review 时价值极高而且几个月后你自己回来看也能快速回忆起当时的决策逻辑。6.4 关键数据做交叉验证对于系统里最关键的那些数据——比如控制指令、计费数据、安全状态——尽量用两种独立的方式计算或获取然后比较。如果两种方式的结果不一致就触发告警。这个做法会增加一些代码量但在关键路径上这点代码量换来的可靠性提升是非常划算的。7. 读这份源码时容易踩的坑7.1 不要试图在现代环境里复现当年的写法我见过有人试图在现代项目里模仿 Apollo-11 的汇编风格结果可维护性急剧下降。当年的写法是被极端约束逼出来的今天你没有那些约束强行模仿只会带来问题。正确的做法是理解背后的原则——确定性、极简中断、显式边界处理——然后用现代工具和语言去实现这些原则。7.2 不要忽略注释里的“为什么”很多人读源码只读代码本身跳过注释。但这份资料里最有价值的部分恰恰在注释里。那些“为什么这样做”的解释是当年工程师在极端条件下积累的经验比代码本身更值得学习。我读的时候会把注释单独摘出来看一遍收获比读代码还大。7.3 不要用现代编译器的眼光去评判代码风格源码里有很多在今天看来“不规范”的写法比如跳转指令的使用、寄存器的复用方式。这些在当年是合理甚至必须的用现代代码规范去评判没有意义。你应该关注的是在给定约束下他们是如何做取舍的以及这些取舍背后的逻辑在今天是否依然成立。7.4 不要只读不练光读源码很容易变成“看故事”过几天就忘了。我的做法是每读到一个有意思的设计就在自己的项目里找一个类似场景试着应用一下。比如读了中断极简原则之后我就把自己项目里的中断服务程序全部重写了一遍。这种“读一点练一点”的方式让这份资料里的经验真正变成了我自己的东西。8. 这份资料对我个人工程习惯的实际影响读 Apollo-11 源码之前我写代码的习惯是“先让它跑起来再优化”。读完之后我改成了“先想清楚约束再设计结构最后写代码”。这个顺序变化带来的最大好处是后期返工大幅减少。因为很多问题在结构设计阶段就被排除了不需要等到性能测试才发现。另一个影响是对于“简单”的重新理解。以前我觉得代码越短越好现在我觉得代码的“简单”应该体现在执行路径的确定性上而不是行数少。一段代码如果执行时间可预测、内存访问模式固定、边界条件明确即使行数多一些也是简单的。反过来一段行数很少但执行路径依赖输入数据的代码其实是复杂的。这个判断标准直接来自 Apollo-11 源码给我的启发。还有一个很实际的改变我现在做任何项目都会先问自己“这个系统最坏情况下会怎样”。不是问“平均性能如何”而是问“最坏情况下的响应时间、内存占用、错误处理路径是什么”。这个问题意识就是读这份资料时被那些周期计算表和故障处理分支训练出来的。9. 如果你也想读这份资料我的建议顺序不要从第一行开始逐行读那样很容易在汇编细节里迷失。我的建议是先读任务分段说明和文件组织理解整体结构然后挑一个你最熟悉的飞行阶段——比如着陆段——仔细读那个阶段的代码和注释接着读中断服务程序感受一下极简中断的写法最后再回头读那些周期计算表和故障处理分支。读的时候手边放一张纸随时记下“这个思路可以用在我项目的什么地方”。读完一个阶段就试着在自己的代码里找一个对应场景改一改。这样读下来你收获的不只是对一份历史资料的了解而是一套可以直接用的工程判断方法。我在第一次读完着陆段代码之后把自己项目里的状态机重写了一遍把原来分散在各处的状态判断集中到了一个显式的状态转移表里。改完之后状态相关的 bug 减少了将近一半。这个改动很小但效果很直接而它的灵感就来自 Apollo-11 源码里那种“每个阶段有明确边界和明确处理逻辑”的组织方式。
阅读完成 · 觉得有帮助？
