★ FEATURED ARTICLE 1. 从“Apollo-11”这个名字说起它到底指什么第一次看到“Apollo-11”这个标题很多人脑子里蹦出来的第一反应是上世纪的登月计划。但在技术圈子里尤其是做嵌入式和开源项目的圈子里这个名字指向的是另一件东西——一份被反复引用、被无数工程师当作“教科书级范本”的制导计算机源码。它的正式身份是阿波罗制导计算机AGC的飞行软件而“Apollo-11”特指那个把人类送上月球表面的特定任务版本。我最初接触它是因为一个很实际的问题手头在做一个资源极度受限的实时控制系统MCU主频只有几十兆RAM按KB算任务调度、中断响应、优先级抢占这些概念在常规RTOS里讲得头头是道但真到了这种“每一字节都要抠”的场景很多教科书方案直接失效。有人跟我说你去翻翻AGC的源码那玩意儿用不到40KB的ROM和2KB的RAM跑完了从发射到登月的全套制导逻辑。我当时的第一反应是“不可能”第二反应是“得看看”。这份源码后来被整理成了公开仓库核心是一个叫“Luminary”的版本系列其中Apollo-11对应的编号是Luminary099。整个代码库用汇编语言写成注释密度极高几乎每一行都有解释。它解决的核心问题不是“怎么算轨道”而是“在算力、内存、可靠性三重极限约束下怎么让一套软件在生死攸关的场景里稳定跑完”。这跟今天大多数开发者面对的环境完全不同——我们现在习惯了几百兆的内存、几吉赫兹的主频、动辄几十层的抽象栈而AGC的软件架构逼着你回到最原始的状态每个字节都要有存在的理由每个跳转都要有明确的时序保证。适合读这份源码的人我总结下来是三类。第一类是嵌入式/实时系统开发者想看看在没有MMU、没有虚拟内存、甚至没有像样的堆栈保护的年代软件是怎么组织的。第二类是对可靠性工程感兴趣的人想知道“一次失败就全盘皆输”的系统里冗余和容错是怎么落到代码层面的。第三类是纯粹的技术考古爱好者想亲眼看看人类第一次登月时背后跑的那几千行汇编到底长什么样。不管你属于哪一类读它的收获都不会停留在“知道了一个历史故事”这个层面而是会实实在在影响你对自己代码的审视方式。2. 为什么一份五十多年前的汇编代码今天还值得逐行读2.1 资源约束下的架构选择没有操作系统只有“执行器”AGC的软件里没有我们今天理解的“操作系统”这个概念。没有进程调度器没有文件系统没有内存管理单元。它有的是一套叫“Executive”的执行框架加上一组“Job”和“Task”的调度逻辑。你可以把它理解成一个极简的协作式调度器但它的设计目标不是“公平”或“吞吐”而是“在确定的时间窗口内保证最高优先级的任务一定被执行”。具体来说AGC的调度单位叫“Job”每个Job有一个优先级范围从0到7。数字越小优先级越高。最高优先级的那一类Job一旦被触发会直接抢占当前正在执行的低优先级Job。这听起来像今天RTOS里的抢占式调度但关键区别在于AGC没有“上下文切换”这个概念。它不保存寄存器现场不切换堆栈指针而是通过一种叫“Bank switching”的机制在不同的内存分区之间跳转。每个Job有自己的“工作区”切换时只是把当前执行位置和少量状态存到固定地址然后跳到新Job的入口。这种设计的好处是切换开销极小几乎可以忽略不计。代价是编程模型极其受限你不能随便定义局部变量不能递归不能动态分配内存。所有东西都必须是静态确定的。我一开始觉得这太原始了但后来想明白了一件事在登月这种场景里“确定性”比“灵活性”重要一万倍。你宁可代码写起来麻烦十倍也不能接受运行时出现一个不可预测的延迟。2.2 2KB RAM怎么用内存布局本身就是一门学问AGC的RAM只有2048个16位字也就是4KB字节。听起来少得可怜但更让人头疼的是这2KB还要分成好几个区域有专门给“Executive”用的有给“Waitlist”用的有给各个Job的工作区用的还有给“Downlink”数据打包用的。每个区域的大小都是硬编码的不能动态调整。我印象最深的是它的“VAC”区域——Vector Accumulator用来存中断向量和关键状态。这个区域只有几十个字但里面塞了所有中断处理程序的入口地址、当前正在执行的Job编号、以及一些标志位。每次中断发生硬件会直接跳到VAC里的固定地址然后由软件决定下一步去哪。这种“硬件软件”紧耦合的设计在今天看来很不优雅但它把中断响应时间压到了最低。还有一个细节AGC的RAM里有一块区域叫“Erasable Memory”字面意思是“可擦除内存”其实就是我们今天说的“可写内存”。但它的“擦除”不是指断电丢失而是指“可以被程序修改”。与之对应的是“Fixed Memory”也就是ROM里面存的是不可变的代码和常量。这种命名方式反映了当时硬件工程师的思维习惯内存不是“读写”的而是“固定”和“可擦除”的。这种二分法直接影响了软件架构——所有需要修改的数据都必须放在Erasable区而Erasable区只有2KB所以你必须极其谨慎地决定哪些数据值得“占用”这个宝贵空间。2.3 中断处理为什么“快”不是唯一目标AGC的中断系统有一个今天看来很反直觉的设计它不区分“中断优先级”。所有中断在硬件层面是平等的谁先来谁先处理。但软件层面通过“Interrupt Vector”表给每个中断源分配了一个处理程序入口。当多个中断同时发生时硬件会按固定顺序依次跳转软件在处理程序里再决定要不要“排队”或者“丢弃”。这种设计的原因是AGC的中断源非常有限主要是雷达、光学瞄准器、手动输入这些外部设备。它们的触发频率和时序关系是已知的不会出现今天PC上那种“网卡中断风暴”的情况。所以硬件不需要复杂的优先级仲裁软件也不需要嵌套中断处理。每个中断处理程序都写得极短通常就是设置一个标志位然后立刻返回。真正的处理逻辑放在主循环里由“Executive”根据标志位决定什么时候执行。我一开始觉得这太简陋了但后来在做一个电机控制项目时遇到了类似问题中断服务程序里如果做太多事会导致其他中断被延迟进而影响控制精度。AGC的做法给了我一个很好的参考——把中断处理拆成“标记”和“执行”两个阶段中断里只做最紧急的事剩下的交给主循环。这个思路在今天依然有效尤其是在那些对实时性要求极高的场景里。3. 拆开Luminary099代码结构里的工程智慧3.1 模块划分不是“高内聚低耦合”而是“按硬件边界切”AGC的源码没有今天意义上的“模块”概念但它的文件组织方式很能说明问题。整个Luminary099被分成若干个“Section”每个Section对应一个功能块比如“Executive”、“Waitlist”、“Downlink”、“IMU”、“Radar”等等。这些Section之间的边界不是按“业务逻辑”划的而是按“硬件接口”划的。举个例子“IMU”这个Section负责处理惯性测量单元的数据。它不关心这些数据是用来算轨道还是用来调姿态它只负责从硬件端口读取原始数据做初步的滤波和标定然后把结果放到一个固定的内存地址里。至于谁去读这个地址、怎么用这些数据那是其他Section的事。这种“只做一件事并且做到极致”的风格让每个Section的代码量都很小通常几百行汇编逻辑清晰到可以逐行验证。我在实际项目里试过模仿这种划分方式。当时做一个多传感器融合的小系统一开始按“功能”划分模块结果发现传感器驱动和数据处理逻辑纠缠在一起改一个地方要动好几个文件。后来改成按“硬件接口”划分每个传感器一个独立模块只负责“读原始数据做最基础的转换”上层逻辑再单独写。改完之后代码的可测试性明显提升——每个传感器模块可以单独用模拟数据验证不需要跑整个系统。3.2 注释密度为什么“写给自己看”和“写给未来的人看”是两回事Luminary099的注释密度高到令人发指。几乎每一行汇编指令后面都跟着一段英文解释说明这行代码在做什么、为什么这么做、以及如果改动了会有什么后果。有些注释甚至包含了数学推导比如某个滤波系数的来源、某个角度计算的近似方法。我一开始以为这是“历史文物”特有的待遇——因为大家都知道这份代码重要所以后人整理时加了很多注释。但后来查资料发现这些注释大部分是当年写代码的工程师自己加的。他们的理由很简单这套代码要运行在生死攸关的场景里任何一个改动都必须被严格审查。如果注释不够详细审查者看不懂就可能漏掉一个致命的错误。这个习惯在今天依然值得学习。我见过太多项目代码写得飞快注释寥寥无几结果半年后自己都看不懂了。更糟糕的是有些关键逻辑的“为什么”只存在于某个人的脑子里一旦这个人离开代码就变成了黑盒。AGC的做法提醒我注释不是“额外工作”而是“代码的一部分”。尤其是那些“看起来可以简化但实际不能简化”的地方必须写清楚原因。3.3 错误处理没有“异常”只有“报警”和“重启”AGC的软件里没有“异常”这个概念。没有try-catch没有错误码返回没有日志系统。它处理错误的方式只有两种要么设置一个“报警”标志让宇航员看到要么直接触发“重启”把系统恢复到已知状态。听起来很粗暴但仔细想想在登月场景里这可能是唯一合理的选择。如果某个传感器读数异常软件没有能力“修复”它也没有时间去做复杂的错误恢复。它能做的是告诉宇航员“这个数据不可信”然后继续用其他传感器的数据维持基本控制。如果错误严重到影响核心功能那就重启——AGC的“重启”不是重新加载整个系统而是跳到一个固定的入口地址重新初始化关键状态然后继续执行。整个过程只需要几毫秒。我在做一个工业控制项目时遇到过类似情况某个通信接口偶尔会丢包一开始想写复杂的重传和恢复逻辑后来发现根本没必要。因为上层控制算法本身就有一定的容错能力丢一两个包不会导致系统失控。于是改成“检测到丢包就标记数据无效让上层用上一次的有效值”代码量减少了一大半稳定性反而提升了。AGC的思路给了我很大启发不是所有错误都需要“处理”有些错误只需要“标记”和“绕过”。4. 从AGC源码里能抄到的“作业”几个可以直接用的思路4.1 固定优先级调度简单但有效AGC的“Executive”用的是一个固定优先级调度器优先级只有8级每个Job的优先级在编译时就确定了。运行时不做任何动态调整。这种设计的好处是调度行为完全可预测不会出现“优先级反转”或者“饥饿”问题。我在一个小型数据采集系统里试过这个方案。系统有四个任务传感器读取、数据滤波、通信发送、状态指示。按重要性排优先级传感器读取最高状态指示最低。每个任务都是一个无限循环里面调用“等待下一次执行”的函数。调度器就是一个简单的优先级数组每次从高到低扫描找到第一个“就绪”的任务就执行。代码不到50行跑起来非常稳定。当然这种方案有局限性如果高优先级任务一直“就绪”低优先级任务就永远得不到执行。AGC的解决办法是高优先级任务在执行完关键操作后会主动“让出”CPU把自己标记为“未就绪”直到下一次触发条件满足。这种“协作式”的让出机制在今天很多RTOS里也有对应实现但AGC把它做到了极简。4.2 双缓冲Downlink数据打包的经典模式AGC需要把遥测数据发送回地面但通信带宽极低而且不能中断关键任务。它的做法是在RAM里开辟两块缓冲区一块用于“当前正在填充”的数据另一块用于“正在发送”的数据。当填充缓冲区满了就交换两块缓冲区的指针然后通知通信模块发送。这个过程不需要复制数据只需要改一个指针。这个模式在今天依然广泛使用尤其是在音频、视频、网络通信这些领域。我在做一个无线传感器节点时直接照搬了这个思路传感器数据先写入缓冲区A写满后切换到缓冲区B同时把缓冲区A的数据通过无线模块发出去。整个过程没有内存拷贝没有动态分配代码简单到可以一眼看懂。4.3 自检与冗余不是“备份”而是“交叉验证”AGC的软件里有很多“自检”代码但它的自检不是简单地“读一个寄存器看对不对”而是“用两种不同的方法算同一个结果然后比较”。比如计算某个角度时它会同时用“三角函数近似”和“查表插值”两种方法如果结果差异超过阈值就触发报警。这种“交叉验证”的思路在今天的可靠性工程里依然有效。我在做一个电机位置检测时用了两个独立的传感器一个霍尔传感器一个光电编码器。两个传感器的读数在正常范围内应该一致如果偏差超过一定值就说明其中一个出了问题。软件不需要知道“哪个坏了”只需要知道“数据不可信”然后切换到安全模式。这种设计比单纯“加一个备份传感器”更可靠因为它能检测出“传感器还在工作但数据已经漂移”的情况。5. 读这份源码时我踩过的几个坑5.1 别用现代编程思维去“优化”它我一开始读的时候看到很多“冗余”的指令比如连续两次加载同一个地址、或者用两条指令完成一条指令就能做的事。我的第一反应是“这可以优化”。但后来查资料发现这些“冗余”往往是有意为之要么是为了保证时序某些指令的执行时间不同需要凑够固定的周期数要么是为了防止单点故障如果一条指令因为硬件问题没执行另一条还能兜底。这个教训让我意识到在资源受限且可靠性要求极高的系统里“效率”不是第一优先级“确定性”才是。你宁可多花几个周期也不能让执行时间变得不可预测。这个思路在我后来做实时控制时帮了大忙——我不再追求“最短代码”而是追求“最可预测的代码”。5.2 汇编里的“宏”和现代语言的“宏”不是一回事AGC的汇编器支持一种叫“Macro”的机制但它跟今天C语言里的宏完全不同。AGC的宏是在汇编阶段展开的展开后的代码会直接插入到调用位置。这意味着宏的参数不能是“表达式”只能是“符号”或“常量”。而且宏展开后的代码会占用ROM空间所以不能滥用。我一开始想用宏来“简化”一些重复逻辑结果发现展开后的代码量暴涨ROM直接不够用了。后来改成用“子程序调用”虽然多了一次跳转开销但ROM占用小了很多。这个经验告诉我在资源受限的环境里“抽象”是有代价的而且代价往往比你想象的大。5.3 别忽略“注释里的数学”Luminary099的注释里有很多数学公式尤其是关于轨道计算和姿态控制的。我一开始跳过了这些觉得“反正我不做航天”。但后来发现这些数学里包含了很多“近似方法”和“数值技巧”在今天的嵌入式开发里依然有用。比如它用“查表线性插值”来算三角函数精度足够且速度极快。我在一个需要实时计算角度的项目里直接用了这个方法比调用标准库的sin/cos快了将近十倍。6. 如果你也想读这份源码我的建议路线6.1 先看“Executive”和“Waitlist”这两个部分是整个系统的骨架。Executive负责调度Waitlist负责管理“等待某个事件”的任务。看懂这两个你就理解了AGC软件的基本运行逻辑。不要一上来就去看“IMU”或者“Radar”这些具体功能模块那样很容易迷失在细节里。6.2 用“模拟器”跑一遍网上有开源的AGC模拟器可以在PC上运行Luminary099。我建议你至少跑一次“Apollo-11”的完整任务流程看看各个模块是怎么协同工作的。模拟器通常会提供一个“调试视图”可以单步执行、查看内存、设置断点。这比单纯读代码直观得多。6.3 带着问题去读不要“从头到尾”读那样效率很低。更好的方式是先想一个你当前项目里遇到的问题比如“怎么在2KB内存里管理多个任务的状态”然后去AGC源码里找对应的解决方案。这种“问题驱动”的阅读方式能让你更快地抓住重点也更容易把学到的东西用到实际工作里。6.4 注意“版本差异”Luminary有多个版本Apollo-11对应的是Luminary099但还有其他版本对应不同的任务。不同版本之间的代码差异往往能反映出“需求变化”和“工程取舍”。比如某个版本增加了一个新的传感器接口代码里就会多出一组“读取-滤波-标定”的逻辑。对比这些差异能让你更深刻地理解“为什么这么设计”。7. 这份源码对我实际工作的影响最直接的影响是我现在写代码时会下意识地问自己“这段逻辑在极端情况下会怎样”。比如一个循环如果输入数据异常会不会死循环一个中断处理如果硬件连续触发会不会导致堆栈溢出这些问题在AGC的代码里都有明确的答案因为它的设计目标就是“在任何情况下都不能崩溃”。另一个影响是我开始重视“代码的可审查性”。AGC的代码之所以能被后人整理、分析、验证很大程度上是因为它的结构清晰、注释完整、逻辑确定。我现在写代码时会刻意让每个函数只做一件事每个变量都有明确的含义每个“为什么”都写在注释里。这样做短期内会增加工作量但长期来看它让代码变得“可维护”和“可信任”。还有一个不太直接但很重要的影响我对“资源”的敬畏心增强了。AGC用2KB RAM跑完了登月任务而我们现在动辄用几百兆内存跑一个“Hello World”。当然时代不同了不能简单对比。但AGC提醒我资源永远是有限的不管你有多少都应该珍惜。这种心态让我在做架构设计时会更谨慎地评估“这个功能真的需要吗”、“这个抽象真的值得吗”。8. 最后分享几个读源码时的小技巧第一准备一个“符号表”。AGC的汇编里用了大量符号名比如“T6RUPT”表示“时间6中断”“PIP”表示“程序中断点”。这些符号在源码里有定义但分散在各个文件里。我建议你先把常用的符号整理成一个表读代码时随时查阅能省很多时间。第二用“颜色标记”区分不同类型的代码。比如用红色标出所有“中断处理”用蓝色标出所有“内存访问”用绿色标出所有“跳转指令”。这样你一眼就能看出某个模块的“中断密度”和“内存访问模式”对理解它的设计意图很有帮助。第三不要怕“跳过”。AGC的源码有几千行不可能每一行都读懂。遇到实在看不懂的地方先标记下来继续往后读。很多时候后面的代码会给你提供上下文让你回头再看时豁然开朗。第四找一个“同伴”一起读。我当时是和一个做嵌入式的朋友一起读的我们每周讨论一次各自分享自己看懂的部分和没看懂的部分。这种“互相教”的方式比一个人闷头读效率高得多。第五把学到的思路“立刻用起来”。不要等“读完再说”而是每读到一个觉得有用的设计就想想能不能用到当前项目里。哪怕只是改一个调度策略、换一种缓冲区管理方式都能让你对这份源码的理解更深一层。
阅读完成 · 觉得有帮助？
