4KB内存,怎么把人送上月球?阿波罗源码里藏着答案

点击上方蓝字关注我们

1969 年，阿波罗 11 号下降途中，登月舱计算机突然亮起 1202 警报。地面控制中心短暂评估后给出继续着陆的指令。今天回看那段代码，最让人惊讶的不是它有多“复古”，而是它早就想好了：资源不够时，哪些任务必须活下来。

公开在 GitHub 上的 Apollo 11 制导计算机源码，包含指令舱的 Comanche055 和登月舱的 Luminary099。它像一份来自另一种工程世界的现场笔记：没有无限内存，也没有随手更新的补丁，很多设计都得提前算清楚。

01  “4KB”不是噱头，重点是怎么分配

阿波罗制导计算机常被概括为约 4KB 可擦写存储、约 72KB 固定存储。NASA 的资料按机器字统计：约 2K 个 16 位 RAM 字，以及 36K 个磁芯绳存储字。换算成今天熟悉的字节单位，才有了那组广为流传的数字。

放在今天，手机后台随便一个应用都可能超过它。但 AGC 不需要运行所有应用，它只做一件事：在明确的时间约束下，完成导航与控制。设计团队把内存看成稀缺工位，而不是随用随加的仓库。关键不是“少”，而是每一份空间都有明确职责。

02  任务分层，紧急时知道先保谁

源码中能看到调度、定时、输入输出和具体飞行程序等部分。它们并非现代意义上一个个独立服务，而是职责分得很清楚：底层安排任务与时间，上层执行导航、姿态和下降控制等工作。

这套系统不是“所有任务平均分时间”。计算机优先处理时效性强的工作，来不及做的低优先级任务可以暂缓或丢弃。屏幕刷新晚一点，可能只是显示不及时；发动机控制错过窗口，则完全是另一回事。这个优先级判断，直接决定了过载时系统还有没有余地。

03  省内存，不只靠写得短

更聪明的做法，是让不同阶段的任务共用内存。某块空间在这一阶段存临时向量，阶段结束后再交给别的程序使用。前提是：谁能借、什么时候能借、哪些数据不能覆盖，都必须约定清楚。

这与今天常见的“内存不够就扩容”很不一样。它要求工程师提前理解程序之间的生命周期，连变量的出生和退场都规划好。写得短当然有帮助，但真正省下来的，是那些不必要的常驻数据和重复工作。资源约束逼着团队把边界想明白。

04  1202 警报：不是死机，而是系统在取舍

下降过程中，会合雷达开关处于自动位置，计算机反复尝试处理当时并不需要的雷达数据，额外负载触发了 1202、1201 等执行器过载警报。NASA 的记录解释，执行队列出现拥塞，部分任务可能无法运行；当时的软件会重新初始化，并恢复选定的重要任务，而不是把所有工作一股脑重启。地面人员判断风险后，建议飞行员继续下降。

这并不意味着“重启一下就万事大吉”，更不是计算机完全没受影响。重要的是，系统架构预留了过载时的取舍空间：非关键工作可以让路，关键控制尽量维持。可靠性不是永远不出错，而是出错或超载时，系统还能把最重要的事做完。

05  代码从纸上回来，工程精神也留了下来

这份源码并非从某台运行中的飞船直接“导出”。GitHub 项目说明，它来自 MIT Museum 收藏的纸质打印稿，经过拍摄、人工转录，再由 Virtual AGC 项目整理；仓库还注明了汇编器与原始程序版本。

纸上的程序是历史档案，转录后的版本则让更多人能检索、汇编、讨论。打开源码，你会看到程序名、注释、版本记录，也会看到一群工程师如何面对硬件极限。它提醒我们：今天算力充裕，不代表可以不做取舍；能跑起来只是开始，知道什么必须可靠，才是系统设计真正的功课。

如果你也想亲自翻一翻，可以从 GitHub 上的 Apollo-11 仓库和 NASA 的 Apollo 11 Lunar Surface Journal 入手。那不是一段只属于历史课的代码，而是一堂关于优先级、边界和可靠性的工程课。