1. 项目缘起与整体设计思路1.1 为什么一个五十多年前的导航计算机值得今天重新拆解我第一次在资料里翻到阿波罗导航计算机Apollo Guidance Computer简称AGC的指令集手册时脑子里冒出的第一个念头是这东西的算力还不如现在一颗电子表芯片凭什么把人送上月球再带回来后来花了两周时间把它的架构、指令集、内存模型和那套著名的“绳存储器”机制啃了一遍才明白它真正的价值不在算力而在于在极端资源约束下做工程取舍的思路。这套思路放到今天的嵌入式开发、边缘计算、甚至一些资源受限的实时系统里依然有很强的参考意义。这个项目我把它命名为“Apollo-11”不是要复刻整个登月任务而是以AGC为核心做一次完整的逆向拆解与仿真复现把它的指令集、内存组织、中断机制、执行周期用现代工具重新实现一遍最后跑通几个经典的制导计算片段。说白了就是拿它当教材学的是“怎么在只有几KB内存、几微秒周期预算的条件下把一件极其复杂的事情做对”。适合谁来参考三类人。第一类是对计算机体系结构、嵌入式底层感兴趣想找一个有历史厚度又不失技术深度的练手项目的人第二类是做实时系统、航天软件、高可靠性嵌入式开发的工程师想看看前辈在没有现代工具链的情况下怎么保证正确性第三类是对“极限优化”这件事本身着迷的人比如做竞赛编程、做单片机性能压榨的开发者。哪怕你只是好奇“登月计算机到底长什么样”这篇内容也能让你从代码层面把它看个通透。1.2 整体方案选型为什么用软件仿真而不是硬件复刻摆在面前的路其实有三条。第一条是找原版AGC硬件或者用FPGA做门级复刻第二条是直接读原始汇编源码做静态分析第三条是用现代语言写一个指令级仿真器把AGC的每条指令、每个寄存器、每个存储周期都模拟出来。我最终选了第三条理由有三个。第一硬件复刻的成本和门槛太高。原版AGC用的是双极性集成电路绳存储器更是需要专门的绕线工艺个人开发者几乎不可能在合理成本内完成。FPGA门级复刻虽然可行但需要先有完整的网表或者逆向出的电路结构工作量极大而且一旦出错很难定位是电路问题还是逻辑问题。第二纯静态分析只能看懂“写了什么”看不出“跑起来是什么样”。AGC的很多设计精髓藏在时序里比如它的内存周期与指令执行周期是重叠的取指和取操作数有特定的节拍安排这些只有动态仿真才能体现出来。第三指令级仿真器有一个巨大的好处可观测、可调试、可修改。我可以在每条指令执行前后打印寄存器状态可以单步跟踪中断响应可以人为注入故障看系统怎么处理。这种可控性是硬件复刻给不了的。而且用现代语言写仿真器代码本身就是一份可执行的文档比任何文字描述都精确。提示如果你也想做类似的历史计算机仿真项目建议先从指令集手册入手把指令格式、寻址模式、周期数整理成表格再动手写代码。跳过这一步直接看源码很容易在细节里迷路。1.3 核心架构拆解AGC到底特别在哪里AGC的架构用今天的眼光看非常“反直觉”但每一条设计都有明确的工程理由。我把它最关键的几个特征列出来后面会逐一展开。特征具体表现设计动机字长15位数据 1位奇偶校验在可靠性和复杂度之间取平衡内存约36K字ROM绳存储器 2K字RAMROM存固定程序RAM存变量和临时数据指令集约30条基本指令精简到极致减少译码复杂度时钟约2MHz但指令周期约12微秒内存访问速度是瓶颈中断向量中断优先级固定保证关键任务及时响应冗余指令级奇偶校验 关键数据双份存储太空环境不能靠人工重启这里最值得说的是15位字长加1位奇偶校验这个选择。为什么不是16位因为多一位校验位意味着每个存储字要多一个存储单元在绳存储器那种手工绕线的工艺下成本是成倍增加的。而15位数据位已经足够表示大部分导航计算所需的精度配合定点运算和精心设计的缩放因子完全可以满足任务需求。奇偶校验位则用于检测存储和传输过程中的位翻转这在宇宙射线环境下是刚需。另一个容易被忽略的点是指令周期远大于时钟周期。2MHz的时钟听起来还行但一条指令要花12微秒相当于24个时钟周期。原因在于内存访问速度跟不上AGC的存储器是磁芯存储器读写速度有限所以CPU大部分时间在等内存。这个特征直接影响了程序优化策略减少内存访问次数比减少指令条数更重要。这一点和今天做嵌入式优化时“cache友好”的思路异曲同工。2. 核心细节解析与实操要点2.1 指令集逆向从手册到可执行模型AGC的指令集手册是我见过的最“抠门”的指令集之一总共就三十来条指令但每条都物尽其用。我把它分成四类来理解数据传输类、算术运算类、逻辑运算类、控制转移类。每类挑几个典型指令说明。数据传输类里最核心的是TCTransfer Control和CCSCount, Compare, and Skip。TC看起来像跳转但它同时会把返回地址存到指定位置实际上承担了子程序调用的角色。CCS更巧妙它根据累加器的值做四件事如果为正加一后跳过下一条如果为零跳过两条如果为负取绝对值后跳过三条。这一条指令就实现了“根据数值范围分派不同处理逻辑”的功能省掉了大量比较和跳转指令。算术运算类只有加法和减法没有乘除法。乘法和除法都是通过子程序实现的用移位和加法迭代完成。这听起来很慢但考虑到导航计算的实时性要求并不需要每秒钟做几万次乘法这个取舍是合理的。我在仿真器里实现乘法子程序时特意统计了执行周期一次16位乘法大约需要200到300微秒取决于操作数的位模式。这个数字在今天看来慢得离谱但在当时完全够用。逻辑运算类包括与、或、异或和移位。移位指令支持左移、右移、循环移位而且可以指定移位数。这里有个细节AGC的移位是通过内存访问实现的也就是说移位操作实际上是把数据写到特定地址触发硬件移位然后再读回来。这个设计在仿真时需要注意不能简单地用现代语言的移位运算符替代必须模拟那个“写地址触发”的过程。控制转移类除了TC还有条件跳转和中断返回。条件跳转依赖前面指令设置的标志位比如溢出标志、进位标志等。中断返回指令会恢复被中断时的现场包括累加器和返回地址。注意实现指令集仿真时最容易出错的地方是标志位的更新时机。有些指令在执行过程中会临时改变标志位但最终结果又把它覆盖掉。必须严格按照手册里的时序描述来写不能想当然。2.2 内存模型绳存储器与磁芯存储器的仿真策略AGC的内存分两部分ROM和RAM。ROM是绳存储器内容在制造时就已经固定相当于今天的固件。RAM是磁芯存储器可以读写但断电后内容丢失。在仿真器里我用两个数组来模拟一个只读数组存ROM内容一个可读写数组存RAM内容。绳存储器的仿真有个特殊之处它的读取是非破坏性的但写入是不可能的。所以在仿真器里任何试图写ROM的指令都应该触发一个错误或者被忽略。我选择让它触发一个可配置的异常这样在调试程序时可以及时发现非法的写操作。磁芯存储器的仿真更复杂一些。真实的磁芯存储器在读取时是破坏性的读完之后内容会变成零需要立即回写。AGC的硬件设计里有一个读后自动回写的机制对程序员透明。但在仿真器里如果我不模拟这个回写过程程序跑起来就会出错。我的做法是在每次读RAM之后立即把原值写回去同时记录一次“回写周期”。这样虽然增加了仿真器的复杂度但能更真实地反映时序。内存地址空间的组织也很有意思。AGC的地址是12位但实际可寻址范围是经过分页的。每个页有固定的用途比如某些页专门放中断向量某些页放常用子程序。这种设计是为了让指令中的地址字段尽可能短减少指令长度。在仿真器里我需要实现一个地址译码逻辑把12位地址映射到具体的存储体。地址范围用途仿真处理方式0x000-0x3FF固定程序区只读写操作触发异常0x400-0x7FF可切换程序区根据bank寄存器选择实际存储体0x800-0xBFF变量区可读写模拟磁芯回写0xC00-0xFFF中断向量与特殊功能读写触发特定行为2.3 中断机制优先级与现场保护AGC的中断系统是它可靠性的重要保障。中断源包括定时器溢出、键盘输入、雷达数据就绪、发动机状态变化等。每个中断源有固定的优先级高优先级中断可以打断低优先级中断的处理。中断响应的过程分几步首先硬件把当前指令执行完不是立即打断而是等当前指令结束然后把当前程序计数器和累加器保存到特定的“中断保存区”接着根据中断向量跳转到对应的处理程序最后处理程序结束时用中断返回指令恢复现场。这里有个关键细节中断保存区是固定的几个地址不是栈。这意味着如果高优先级中断打断了低优先级中断的处理低优先级中断已经保存的现场会被覆盖。AGC的解决办法是高优先级中断使用不同的保存区而且中断处理程序在允许嵌套之前会先把现场转移到安全的地方。这个机制在仿真器里必须精确模拟否则嵌套中断的行为就会出错。我在实现中断仿真时专门写了一个测试用例模拟一个低优先级中断正在处理时高优先级中断到来检查现场是否正确保存和恢复。第一次跑的时候发现累加器值不对排查了半天才发现是保存区的地址映射写错了。这种错误在真实硬件上可能直接导致任务失败在仿真器里却能通过单步调试抓出来这也是做仿真项目的价值之一。提示中断优先级的仿真不要用简单的if-else堆叠建议用一个优先级队列或者位掩码来管理。AGC的中断优先级是固定的但中断使能状态是动态的用位掩码可以同时表示“哪些中断被使能”和“哪些中断正在挂起”。3. 实操过程与核心环节实现3.1 环境搭建与工具链选择我用的开发环境很朴素一台普通笔记本电脑操作系统是常见的桌面系统编程语言选了Python和C混合。Python用来写高层控制、测试脚本和可视化C用来写仿真核心因为指令级仿真对性能有一定要求纯Python跑大规模测试会太慢。为什么不全用C因为调试和快速迭代阶段Python的开发效率高得多。我的做法是先用Python写一个原型仿真器把指令集和内存模型跑通验证逻辑正确性然后把核心循环用C重写通过Python的扩展接口调用。这样既保证了开发速度又保证了最终性能。工具链方面我用了几个现成的库pybind11做Python和C的绑定pytest做单元测试matplotlib做执行轨迹的可视化。版本控制用Git每实现一条指令就提交一次方便回滚和对比。注意不要一上来就追求高性能实现。仿真器的第一目标是正确第二目标才是快。我见过不少人直接用C写结果在调试指令语义时浪费了大量时间因为C的调试周期比Python长得多。3.2 指令译码与执行的实现细节AGC的指令格式是固定的高3位是操作码低12位是地址或操作数。译码逻辑就是根据高3位查表找到对应的处理函数。听起来简单但有几个坑。第一个坑是操作码的编码不是连续的。有些操作码对应多条指令具体是哪条取决于地址字段的某些位。比如某条指令在地址字段的最高位为0时是“读”为1时是“写”。这种设计是为了在有限的编码空间里塞进更多功能。实现时必须先判断这些特殊位再决定执行哪条指令。第二个坑是指令执行过程中的临时状态。有些指令在执行到一半时会修改程序计数器但最终又改回来。如果仿真器在指令执行中途检查PC会得到错误的值。我的做法是每条指令的执行函数返回一个“下一条指令地址”而不是直接修改全局PC。这样指令执行过程中PC保持不变只有执行结束后才更新。第三个坑是周期计数。AGC的每条指令有固定的周期数但有些指令的周期数取决于是否发生了跳转、是否访问了内存等。我在仿真器里为每条指令维护一个周期计数器执行时累加。这个计数器不仅用于性能统计还用于模拟定时器中断——当周期数达到某个阈值时触发中断。# 指令执行框架的伪代码示意 def execute_instruction(cpu, instruction): opcode (instruction 12) 0x7 address instruction 0xFFF handler OPCODE_TABLE[opcode] cycles handler(cpu, address) cpu.cycle_count cycles check_timer_interrupt(cpu) return cpu.next_pc3.3 制导计算片段的复现与验证光跑通指令集还不够得用真实的计算任务来验证。我选了三个经典的制导计算片段位置矢量更新、速度矢量更新、姿态角计算。这些计算在原始任务中由不同的子程序完成我根据公开的算法描述用AGC指令重新实现了一遍。位置矢量更新涉及大量的乘法和加法。AGC没有硬件乘法所以乘法是用移位加法子程序实现的。我实现的乘法子程序接受两个16位定点数返回32位结果的高16位。这里有个精度问题定点数的缩放因子必须仔细选择否则中间结果会溢出或者精度不够。我参考了原始文档里的缩放策略把位置矢量的每个分量都缩放到合适的范围。速度矢量更新更复杂一些因为它涉及重力加速度的计算。重力加速度是位置的函数所以每次更新速度之前要先算重力。这个计算链在AGC上是通过一系列子程序调用完成的每个子程序都有严格的周期预算。我在仿真器里加了周期统计发现一次完整的更新大约需要2毫秒和原始文档里的描述基本吻合。姿态角计算涉及三角函数。AGC没有三角函数指令而是用查表加插值的方法。我实现了一个256项的查表配合线性插值精度可以满足任务需求。这里有个经验查表法的精度不仅取决于表的密度还取决于插值方法。线性插值在表项之间误差较大改用二次插值后精度明显提升但计算量也增加了。最终我选择了折中方案在关键区域加密表项其他区域用线性插值。计算任务主要指令平均周期数仿真耗时现代CPU位置更新乘法子程序 加法约4000约0.1毫秒速度更新重力计算 乘法 加法约8000约0.2毫秒姿态计算查表 插值 乘法约6000约0.15毫秒提示验证仿真器正确性的一个好方法是交叉验证。我用现代浮点运算实现了同样的算法然后把AGC定点运算的结果和浮点结果对比。误差在允许范围内就说明仿真器基本正确。如果误差突然变大往往是某条指令的语义实现错了。4. 常见问题与排查技巧实录4.1 指令语义实现中的典型错误做这个项目的过程中我踩过的坑主要集中在指令语义的细节上。下面整理几个最有代表性的问题。问题一溢出标志的更新时机不对。AGC的加法指令在结果溢出时会设置溢出标志但这个标志是在加法完成后立即设置还是在写回结果后设置手册里的描述比较模糊。我一开始按“写回后设置”实现结果发现某些条件跳转的行为和预期不符。后来仔细对照时序图发现溢出标志是在加法器输出稳定后就设置的早于写回。修正后问题解决。问题二移位指令的位数处理。AGC的移位指令可以指定移位数但移位数是存在地址字段里的而且有特殊的编码方式。比如移位数0表示不移位移位数1表示移1位但移位数15表示移16位因为编码空间有限用了循环表示。我一开始没注意到这个细节导致移位结果总是差一位。问题三中断返回时的现场恢复顺序。中断返回指令会恢复累加器和程序计数器但恢复顺序有讲究。如果先恢复PC再恢复累加器那么在恢复PC和恢复累加器之间如果发生新的中断累加器的值就是旧的。AGC的设计是先恢复累加器再恢复PC而且恢复PC的那一步会暂时禁止中断。这个细节在仿真器里必须精确模拟否则嵌套中断的测试会失败。4.2 性能瓶颈与优化取舍仿真器跑起来之后我发现性能瓶颈不在指令译码而在内存访问的模拟。因为每次读RAM都要模拟磁芯回写这个操作在真实硬件上是并行的但在仿真器里是串行的导致速度很慢。优化方案有几个。第一个是批量回写把多个读操作攒起来最后一次性回写。但这会改变时序影响中断触发的时机所以只适合在不需要精确时序的场景下使用。第二个是缓存常用地址把频繁访问的RAM地址的值缓存在CPU寄存器里减少数组访问次数。这个方案对时序影响小但实现复杂度高。第三个是用更高效的数据结构把RAM数组换成更紧凑的类型减少内存占用和缓存未命中。我最终选了第二个方案因为它在保持时序精确性的同时能带来明显的性能提升。具体做法是在CPU结构体里加一个小的直接映射缓存缓存最近访问的16个RAM地址。每次读RAM先查缓存命中就直接返回未命中再访问数组并更新缓存。写RAM时同时更新缓存和数组。实测下来仿真速度提升了大约40%。注意缓存一致性是个容易出错的地方。如果某个地址被写入了新值但缓存里还是旧值后续读取就会出错。我的做法是写操作时立即更新缓存确保缓存和数组始终一致。另外中断处理程序可能会修改任意地址所以中断发生时我会清空缓存避免脏数据。4.3 常见问题速查表现象可能原因排查方法解决方案程序跑飞指令译码错误单步跟踪打印每条指令的PC和操作码对照手册检查译码表计算结果偏差大定点缩放因子错误用浮点交叉验证重新计算缩放因子中断不触发中断使能位未设置检查中断控制寄存器的值在初始化代码中设置使能位嵌套中断现场丢失保存区地址冲突打印中断保存区的读写记录为不同优先级分配不同保存区仿真速度慢内存访问模拟开销大用性能分析工具定位热点加缓存或批量回写奇偶校验频繁报错仿真器未正确模拟校验位检查校验位的生成和验证逻辑修正校验位计算4.4 独家避坑经验最后分享几条我在这个项目里总结出来的经验都是文档里不会写的。第一条先写测试再写实现。每实现一条指令先写一个测试用例覆盖正常情况和边界情况。比如加法指令要测试正数加正数、正数加负数、溢出、零加零等。测试通过了再继续下一条。这样虽然前期慢但后期调试省下的时间远超投入。第二条保留执行日志。仿真器运行时把每条指令的PC、操作码、操作数、执行结果都写到日志文件里。一旦出错可以回放日志定位问题。日志文件会很大但可以按需开启比如只在出错前后开启。第三条不要迷信手册。手册里的描述有时不够精确或者有印刷错误。遇到和预期不符的地方先怀疑手册再怀疑自己的实现。我的做法是如果某个行为在手册里找不到明确描述就去查原始的工程笔记或者相关的技术报告往往能找到更详细的说明。第四条分阶段验证。不要等整个仿真器写完再测试。先实现最基本的指令子集跑通一个简单的循环程序然后逐步增加指令每增加一批就回归测试一次。这样能保证问题尽早暴露定位范围也小。这个项目后续还可以这样扩展把仿真器和现代可视化工具结合做一个交互式的AGC教学演示或者把仿真器移植到嵌入式平台上做一个实体的“复古计算机”装置再或者把AGC的调度算法提取出来应用到现代实时系统的任务调度优化中。我个人最感兴趣的是最后一个方向因为AGC在资源极度受限的情况下实现的调度策略对今天的边缘计算场景依然有启发。