在SIMH中模拟法国Mitra-15小型机：复古计算项目解析

这次我们来看一个比较小众、但非常有复古计算味道的项目在 SIMH 模拟器框架中模拟法国 CII 公司的 Mitra-15 小型机。项目目前处于 Work in Progress 状态也就是说CPU 核心、内存、外设这些模块还在逐步落地不是开箱即用的完整模拟器。但正因为是 WIP对研究模拟器实现、复刻古董机指令集、整理老软件运行环境的开发者来说反倒是一个很好的观察窗口。Mitra-15 不是普通的 8 位教学机它是法国 Compagnie Internationale pour lInformatiqueCII在 1970 年代推出的 16 位小型机面向实时控制、工业自动化、科学计算和数据采集场景。CII 后来并入 Bull 集团所以 Mitra-15 在法国计算机工业史上有一席之地。它支持内存保护、多级中断、硬件陷阱和外部 I/O 通道设计上偏工程控制不是简单的个人电脑路线。这类机器今天很难找到实物能通过 SIMH 在普通 PC 上跑起来价值就在于把一段计算机历史变成可以动手调试的代码。这篇文章会围绕 Mitra-15 和 SIMH 展开先梳理 Mitra-15 的硬件结构和指令集特征再说明 SIMH 模拟器的工程组织方式随后给出本地构建、启动调试、功能验证、自动化批量测试和问题排查的完整思路。如果你对模拟器开发、古董机复原、老操作系统移植感兴趣这篇文章可以收藏备用。1. 项目与核心能力速览能力项说明项目名称French CIIs Mitra-15 in SIMH项目定位在 SIMH 模拟器框架中模拟 Mitra-15 小型机当前状态Work in Progress尚未形成完整可用的最终版本模拟目标CII Mitra-1516 位小型机面向实时控制场景开发语言CSIMH 框架本身为 C 语言实现运行平台可在 Linux、macOS、Windows需本地编译等 SIMH 支持的平台上构建启动方式命令行启动通过 SIMH 控制台交互接口能力主要通过 SIMH 控制台命令和模拟外设文件交互批量能力支持通过 SIMH 脚本命令批量执行测试程序可输出日志用于自动比对显存要求无 GPU 需求纯 CPU 模拟适合人群复古计算爱好者、模拟器开发者、计算史研究者、嵌入式系统教学人员这个表格里的“支持平台”“批量能力”来自 SIMH 框架的通用能力Mitra-15 模拟器本身能跑多少功能要看项目当前的完成度。实机上电之前先把它当一台“正在修复的古董机”看待跑不通某些指令属于常态。2. 背景Mitra-15 是一台什么样的机器Mitra-15 是法国 CII 公司在 1970 年代推出的 16 位小型机主打实时控制和工业自动化。它和同时代的 DEC PDP-11、Data General Nova 在定位上有相似之处但指令系统和系统结构完全是另一套设计。CII 是法国政府推动的“计算计划”下的企业后来和 Honeywell 合作最终并入 Bull 集团。因此 Mitra-15 不只是实验室里的原型机它确实在法国的工业控制、数据采集、过程监控等领域批量部署过。从硬件结构看Mitra-15 有几个关键特征第一字长 16 位基本访存单元是字word不是字节。这意味着内存地址、寄存器、指令格式都围绕 16 位字设计。程序计数器、累加器、索引寄存器等都以字为单位工作。第二具备内存保护机制。Mitra-15 不是裸奔式的小型机它提供了基于上下界或页式的内存保护能力配合实时操作系统使用。这一点在 1970 年代的小型机里是相对高级的设计模拟器实现时不能只做“取指-执行”循环还要把保护检查和异常触发做进去。第三中断系统比较复杂。机器支持多种中断源包括错误中断、外部中断、程序陷阱等。中断发生时CPU 会保存现场跳转到固定向量地址再通过软件分发。模拟器需要精确处理中断优先级、屏蔽状态和上下文保存这是指令模拟之外工作量最大的一块。第四I/O 通过外部设备和 I/O 通道完成。早期 Mitra-15 的常用外设包括高速纸带阅读器、纸带穿孔机、电传终端后期可以挂磁盘和工业 I/O 接口。SIMH 里复刻这些外设时通常会把纸带“文件化”用一个二进制文件或文本文件充当纸带这样既不用真纸带机也能把外设行为模拟到位。Mitra-15 上运行过实时监控程序和实时操作系统部分站点还跑过科学计算和数据处理应用。不过和 PDP-11 的生态相比Mitra-15 的软件存量少、文档散落能拿到的手册和二进制镜像都比较稀缺。这也是模拟器一直处于 WIP 的原因之一硬件结构可以照手册写但缺少充足的测试程序来验证 CPU 行为是否符合原机。模拟 Mitra-15 的价值不在于跑出多高的性能而在于给这段历史留下一个可复现的数字标本。有了 SIMH 模拟器研究者可以随时加载一个 Mitra-15 的内存镜像单步跟踪指令观察中断响应验证操作系统行为。这在实物机器几乎无法存活的今天是难得的资源。3. 适用场景与使用边界先说适合谁。计算史研究者和博物馆策展人会很需要这类模拟器。Mitra-15 的实物如今很难找到即便找到也难以维护。模拟器可以把机器的行为固化下来配合扫描手册、软件镜像形成一套完整的数字档案。从研究角度这比看照片和图纸更有价值。模拟器开发者也可以从中学到很多东西。SIMH 框架有自己的一套设备注册、事件调度、控制台命令机制。给 Mitra-15 编写模拟器需要理解如何把一台真实机器的寄存器、内存、中断、I/O 设备映射到 SIMH 的抽象接口上。这个项目的 WIP 状态意味着代码还不完善但你正好可以看到典型的“先 CPU 后外设、先核心后完整”的推进路径。嵌入式系统教学领域也可以用 Mitra-15 当案例。16 位指令集、内存保护、中断优先级这些概念在现代微控制器里依然存在。学生能在模拟器里设置断点、单步执行、观察寄存器变化理解底层机制比只背 PPT 更有效。再说哪些场景不适合。如果你只是想要一个开箱即用的古董机模拟器现在应该优先跑 SIMH 里已经很成熟的 PDP-8、PDP-11、VAX 等模拟器。Mitra-15 模拟器还处于 WIP启动后可能会有指令未实现、外设不响应、没有完整操作系统镜像等问题不适合当作日常玩具。如果你需要高性能数值计算那也不用考虑它模拟器追求的是行为复刻不是速度。使用边界方面要注意版权。Mitra-15 的老操作系统和应用程序如果还有权利方不能默认随意分发。模拟器本身是新写的代码但加载的固件、操作系统镜像、诊断程序可能存在版权问题。个人研究和教育用途相对宽松公开发布或商用前要确认授权状态。安全层面Mitra-15 模拟器只在本地运行不涉及网络服务。但如果你打算把它接入自动化测试或 CI 流程要注意不要让未经验证的测试程序无限占用 CPU 或写满磁盘。模拟器里跑的“程序”如果行为失控最多影响宿主机性能不会破坏真实硬件不过仍然建议用沙箱目录隔离输入输出。4. 环境准备与前置条件在开始构建和工作之前先确认环境是否满足条件。Mitra-15 模拟器依赖 SIMH 框架而 SIMH 是一个用 C 语言编写的经典模拟器套件构建方式相对传统。操作系统方面Linux 是最顺手的构建环境macOS 和 Windows配合 MinGW 或 WSL也能完成。建议优先选 Ubuntu/Debian 系的 Linux减少编译环境折腾。需要准备的工具有C 编译器例如 GCC 或 Clang。make 或等同的构建工具。Git用于拉取源码和查看项目演进记录。一个支持 ANSI 转义的终端SIMH 控制台交互会更舒服。SIMH 本身不需要图形界面也不需要 GPU对配置的要求很低。但要注意编译模拟器需要能访问源码目录并且建议在一个独立的开发目录里操作不要把输入文件、构建产物和测试输出混在一起。如果之前没有安装编译工具链可以用系统包管理器补齐。下面是一个通用安装示例具体包名以你的发行版为准# Debian/Ubuntu 示例 sudo apt update sudo apt install build-essential git接着拉取 SIMH 源码和 Mitra-15 项目源码。这里以通用命令为例仓库地址和分支需要按项目页实际信息替换# 拉取 SIMH 主框架目录名可自定 git clone https://github.com/simh/simh.git simh # 拉取 Mitra-15 模拟器相关源码 git clone mitra15-repository-url mitra15代码拿到后需要了解项目的文件组织。SIMH 里每个机器模拟器通常包含几个核心文件sim_xxx.c设备模拟包括内存、I/O 设备注册和读写回调。sim_xxx_cp.cCPU 核心实现取指、译码、执行和中断处理。sim_xxx_fp.c浮点单元如果目标机器有。sim_xxx_ds.c控制台显示设备如果目标机器有。Mitra-15 模拟器作为 WIP文件数量和命名可能随项目推进而变化。最稳妥的方式是直接看仓库里的configure脚本、Makefile或CMakeLists.txt确定构建入口。磁盘空间方面SIMH 源码本身很小加上编译产物和测试素材预留 1 GB 完全足够。不需要像大模型那样准备几十 GB 的模型文件。环境准备阶段最容易踩的坑是编译器和 SIMH 框架的版本匹配。SIMH 项目经历了多次重构新代码可能依赖较新的 C 标准或库函数。如果编译报错优先检查是不是编译器太老或者是不是没有先构建 SIMH 的公共库直接编译了设备文件。另一个常见问题是项目可能还在dev分支提交主分支落后拉代码时要注意分支信息。5. 构建流程与启动方式由于 Mitra-15 模拟器处于 WIP启动步骤很可能改动频繁。这里给出一个基于 SIMH 框架通用构建方式的模板实际命令需要按项目当前状态调整。假设源码已经就绪并且项目使用 configure/make 方式构建流程大致如下cd mitra15 # 查看构建说明 ls cat README.md 2/dev/null || cat INSTALL 2/dev/null # 如果存在 configure 脚本 ./configure make如果项目直接提供sim_mitra15或类似的可执行文件名构建完成后先看一眼能否运行./sim_mitra15 -hSIMH 模拟器启动后通常进入一个交互式控制台可以直接输入命令。启动时可以通过命令行参数指定配置文件./sim_mitra15 mitra15.ini配置文件里的内容是一组 SIMH 控制台命令。一个最小配置文件的模板如下具体命令名和参数需要对照项目的sim_mitra15_cp.c和sim_mitra15_sys.c中的注册命令来写; 示例配置文件实际命令需要按项目实现调整 ; 设置内存大小以字为单位 SET CPU 32K ; 挂载纸带阅读器文件 ATTACH PTR program.pt ; 启动模拟器 RUN启动后SIMH 控制台会显示 CPU 状态和提示符通常是sim或类似形式。常见的控制台操作有EXAMINE 地址查看指定内存地址的内容。DEPOSIT 地址 值向指定内存地址写入值。BREAK 地址在指定地址设置断点。TRACE 指令跟踪指令执行。RUN从当前 PC 开始执行。STOP停止执行。QUIT退出模拟器。这些命令属于 SIMH 通用能力只要 Mitra-15 模拟器接入了 SCP就能使用。真正的难点不在命令本身而在于把 CPU 状态、设备寄存器、内存映射和你手里的硬件手册对应起来。启动时如果遇到“命令未实现”或“设备不存在”不需要太紧张WIP 项目里很可能只是功能还没完成。把报错信息记下来去源码注释和 issue 列表里找对应关系。6. 指令集模拟与关键模块实现进入项目源码后建议先看 CPU 核心文件。Mitra-15 的指令集可以描述为“操作码 地址字段”的经典小型机结构16 位字里通常高位是操作码低位是地址或操作数。指令执行过程大致是取指从 PC 指向的内存字取出指令。译码提取操作码和地址信息。访存必要时读内存字。执行根据指令类型修改寄存器、内存或触发 I/O。更新 PC顺序执行指令时 PC 加 1跳转指令则加载目标地址。模拟器里对应的数据结构通常会把这些元素建模为简单变量或数组。例如uint16_t M[32768]; /* 内存按字访问 */ uint16_t PC; /* 程序计数器 */ uint16_t IR; /* 指令寄存器 */ uint16_t A; /* 累加器 A */ uint16_t B; /* 累加器 B */ uint16_t MQ; /* 乘商寄存器如果存在 */ uint16_t X; /* 变址寄存器 X */ uint16_t L; /* 连接/进位寄存器 */ uint16_t R; /* 中断重启地址寄存器 */ uint16_t EP; /* 错误指针寄存器 */ uint8_t MODE; /* 运行模式或状态位 */内存保护在 Mitra-15 里不是摆设。模拟器实现时每一个内存访问都需要检查地址是否落在当前进程允许的范围内。如果越界要触发错误中断并把错误信息记录到状态寄存器。很多 WIP 项目先跑通普通指令内存保护逻辑后补所以测试时要特别关注越界访问场景。中断处理方面Mitra-15 的机制比较复杂。CPU 收到中断请求后会判断优先级和屏蔽状态然后保存现场并跳转到向量地址。模拟器需要在每条指令执行的边界处检查“是否有待处理中断”这和现代 CPU 的中断模型在逻辑上是一致的。如果在模拟器里发现中断没有响应优先检查这几个点中断使能位是否被正确设置。中断向量地址是否被有效代码占用。优先级比较逻辑是“小于”还是“大于”写反了。现场保存时寄存器压栈顺序是否和原机一致。I/O 模块是另一个重点。Mitra-15 的纸带阅读器和穿孔机在模拟器里通常被实现为文件读写设备。纸带阅读器对应一个输入文件每次读取一个字符槽位穿孔机对应一个输出文件每次写入一个字符。SIMH 设备层会提供 attach/detach 命令把宿主文件挂到这个设备上。如果项目里已经实现了外设启动前可以先用空文件测试基本读写。例如# 创建一个空纸带输入文件 touch blank.pt # 在 SIMH 控制台里挂载 ATTACH PTR blank.pt外设实现是否完整通常看设备状态寄存器。Mitra-15 的外设通过状态字报告“忙”“就绪”“错误”等状态CPU 通过轮询或中断方式获取。模拟器里这一套和真实硬件几乎一一对应移植原生诊断程序时基本能对上号。7. 功能测试与效果验证测试一台还处于 WIP 的模拟器核心原则是“从最小可运行的指令组合开始逐步扩大覆盖范围”。不要一上来就跑完整操作系统那样既不好定位问题也容易因为一个外设没实现而卡死。建议按下面的顺序验证。7.1 基础指令执行测试先写一个最简单的测试程序只包含几条顺序执行的指令验证取指、译码、执行、PC 更新是否正确。把程序写入内存设置好 PC然后运行。在 SIMH 控制台里可以用 DEPOSIT 逐个写入内存DEPOSIT 0100 0xC010 DEPOSIT 0101 0x0005 DEPOSIT 0102 0x0000 SET PC 0100 RUN这里的 0xC010 和 0x0005 只是占位值你需要根据 Mitra-15 的真实指令编码替换。判断标准程序执行完PC 停在预期地址累加器或内存值等于预期结果。7.2 内存保护测试Mitra-15 的内存保护功能必须单独测。如果你能拿到原机的手册里面会有“非法访问触发错误中断”的行为描述。测试方式是先设置保护边界然后故意让程序访问越界地址观察是否触发中断、错误寄存器是否被写入预期值。判断成功的标准CPU 没有“静默”跳过越界访问。错误中断被触发。错误寄存器或内存中的错误信息符合手册预期。如果发现越界访问没有触发任何异常说明保护逻辑未实现或条件判断有误。这是 WIP 项目里最需要留意的部分因为普通指令测试很容易全绿保护逻辑测试却不那么容易覆盖。7.3 中断与陷阱测试编写一个打开中断使能、等待外部中断或陷阱的程序。手动触发中断后观察 PC 是否跳转到正确向量地址上下文保存是否完整。如果模拟器支持手动设置中断请求可以通过控制台命令或寄存器写入来触发。注意中断处理完成后R 寄存器重启地址是否正确保存了返回地址这关系到中断返回指令能否恢复现场。7.4 纸带 I/O 测试创建一个只包含少量字节的纸带文件执行读取程序观察数据是否按预期到达内存或累加器。然后再执行穿孔程序检查输出文件是否正确写入。常见失败原因设备状态寄存器没有正确从“忙”切到“就绪”。读取文件时按“字”读还是按“字节”读搞混了。文件结束标志没有触发中断。外设和 CPU 之间缺少握手时序。纸带 I/O 看起来简单但它是整个外设系统的地基。这个测试通过后才有把握继续挂载更复杂的外设。7.5 指令集覆盖测试收集一份 Mitra-15 全部指令的清单可以从手册提取整理成一个测试程序集合逐条执行指令并校验结果。对 WIP 项目来说这个测试集合就是最重要的回归测试资产后续每次代码修改后都应该跑一遍。伪代码模板/* * 通用指令测试程序伪代码 * 每条指令执行后比较预期寄存器和内存值 */ start: load_immediate 0 add_memory operand store result compare result, expected branch_if_not_equal error ... error: /* 记录错误编号停止 */ halt这类测试不用很复杂重点是覆盖每条指令的正常路径和边界条件比如立即数最大值、地址为零、地址为内存边界等。8. 批量测试与自动化脚本模拟器开发到中后期手工在控制台敲命令验证会变得很痛苦。SIMH 支持脚本化执行也就是把命令写进一个文件然后用DO命令一次性执行。这对批量回归测试非常有用。例如你可以为每一条指令写一个独立的 SIMH 脚本; test_ADD.ini ; 装载测试程序 LOAD add_test.bin ; 设置 PC SET PC 0100 ; 运行 RUN ; 输出寄存器状态 EXAMINE A EXAMINE PC ; 停止 STOP QUIT自动化批量执行时可以让终端调用 SIMH 并传参把每个脚本的输出导入日志文件for t in test_*.ini; do echo Running $t ./sim_mitra15 $t log_$(basename $t .ini).txt 21 done然后把日志和预期结果做 difffor f in log_*.txt; do if diff -q $f expected_$f /dev/null; then echo $f PASS else echo $f FAIL fi done更进一步可以用 Python 写一个测试运行器把“执行 SIMH 脚本 - 捕获输出 - 解析寄存器值 - 与期望值比对”做成一个可重复的流程。没有现成的 API 也不影响因为 SIMH 的命令行输出已经足够程序化解析。批量测试要注意的是稳定性。模拟器在批量运行时如果某个测试程序无限循环会导致整个批次卡住。建议给每个测试脚本设置外部超时例如用timeout命令包裹timeout 10 ./sim_mitra15 test_jump.ini log_jump.txt 21这样即使测试程序进入死循环也不会拖垮整个流水线。日志和测试结果建议和分析代码分开目录存放project/ scripts/ run_all_tests.sh tests/ test_ADD.ini test_SUB.ini results/ log_ADD.txt log_SUB.txt expected/ expected_ADD.txt expected_SUB.txt分目录管理的价值在问题定位时体现得最明显日志、输入脚本、预期输出互不干扰跑挂了能快速判断是“测试程序的问题”还是“模拟器的问题”。9. 性能观察与资源占用Mitra-15 模拟器是纯 CPU 模拟对 GPU 没有要求显存占用这种问题可以完全忽略。性能观察重点放在 CPU 占用、内存占用、模拟器执行速度和 I/O 等待上。首先看 CPU 占用。启动模拟器后用系统工具观察进程状态top -p $(pgrep sim_mitra15)或者用更详细的psps -o pid,pcpu,pmem,rss,vsz,etime,cmd -p $(pgrep sim_mitra15)%CPU是 SimH 执行循环的繁忙程度。如果程序在纯计算CPU 占用可能接近单核上限如果程序在等纸带 I/OCPU 占用会降下来因为模拟器在模拟外设时通常需要等待宿主文件操作或模拟 I/O 完成信号。内存占用方面SIMH 模拟器的内存使用量取决于模拟机器的内存配置加上模拟器自身的数据结构。Mitra-15 的内存一般是几千到几万字即使开满配置模拟器的 RSS 也不会很夸张。不过要注意SIMH 的设备缓冲区和日志输出也可能占用额外内存长时间运行后如果发现内存增长异常优先检查日志文件有没有被无限追加。执行速度可以通过 SIMH 自身的指令计数或外部计时来评估。SIMH 通常有SHOW命令可以查看模拟器状态部分模拟器支持统计每秒执行的指令数。如果项目还没实现统计可以用测试程序加时间戳来粗略估算time ./sim_mitra15 benchmark.ini性能瓶颈不一定是 CPU也可能在 I/O 模拟。纸带阅读器如果每次读一个字符都要做一次宿主文件 I/O速度会明显偏慢。如果追求速度可以考虑升级设备实现例如一次读取一块数据并建立缓冲。但要注意设备缓冲逻辑必须保持和真实设备相同的“可见行为”不能在读第一个字符前就把整卷纸带全部预取否则可能会掩盖设备时序上的 bug。降低模拟器开销的方法关闭不必要的指令跟踪TRACE功能会显著拖慢执行速度。减少控制台回显输出SET CONSOLE相关参数可以控制。批量测试时把输出重定向到文件不要持续打印到终端。如果模拟器支持关闭不用的外设减少设备轮询开销。观察资源占用时要区分“模拟器本身的成本”和“目标机器程序的负载”。Mitra-15 程序死循环时模拟器 CPU 会满转这不一定说明模拟器慢跑一个真正密集的算法再对比真实机器的估算速度更能反映模拟器效率。10. 常见问题与排查方法WIP 项目的排查问题和方法和成熟模拟器很不一样。很多报错不是“配置错了”而是“功能还没写完”。下面是一张排查表覆盖构建、启动、运行、外设和自动化流程里的常见问题。问题现象可能原因排查方式解决方案编译报错找不到头文件未先构建 SIMH 公共库或源码目录结构不匹配查看 Makefile确认 include 路径按项目 README 先编译公共库再编译设备文件编译报错函数未定义Mitra-15 设备的回调函数未实现搜索sim_mitra15目录中的函数名补齐设备回调或注释掉未用的设备注册启动后提示“设备不存在”设备尚未在sim_mitra15_sys.c中注册查看源码中的设备表在设备表中添加对应设备条目程序运行后 PC 不变取指或 PC 更新逻辑有误用TRACE跟踪首条指令检查指令译码后是否更新 PC是否存在跳转指令指令执行结果错误操作码或寻址模式译码错误用最小测试程序逐条验证对照手册修正译码表越界访问没有触发中断内存保护逻辑未实现检查M访问前的边界检查在内存读写回调中加入边界检查和错误中断触发中断无响应中断使能位或优先级逻辑有误用EXAMINE查看状态寄存器核对中断屏蔽和优先级比较逻辑纸带阅读器读不到数据文件格式或设备状态错误检查 attach 路径和文件内容确认纸带文件编码检查设备状态寄存器批量测试卡住测试程序死循环用timeout限制外部执行时间增加超时机制标记失败测试日志输出无限增长设备在持续产生输出检查是否有程序循环写穿孔机限制输出大小或写满后停止模拟器无法退出模拟器控制台命令处理异常使用QUIT或外部 kill确认 SIGINT 处理逻辑或强制结束进程遇到问题排查顺序建议是先确认是“模拟器代码问题”还是“测试程序问题”。换一个最简单的指令测试程序试试。再确认是不是“未实现功能”。查看源码里有没有TODO、FIXME、未注册的设备表项。然后用TRACE和EXAMINE缩小范围定位到具体指令或内存地址。最后对照 Mitra-15 手册确认模拟器的行为是否符合预期。不要害怕报错。WIP 项目里报错信息往往比 README 更有价值因为它会直接指向代码里还没完成的部分。把每次报错和修正过程记录下来最终能汇成一份很有分量的项目文档。11. 最佳实践与后续扩展方向如果打算长期跟进这个 WIP 项目建议从第一天开始就建立一套规范的工作流。模拟器开发最怕的就是“改了这里坏了那里”尤其是 CPU 核心这种全局性代码回归测试必须自动化。第一保留一套最小可运行配置。不管项目怎么改动始终维护一个只包含 CPU 和最小内存的启动脚本保证每次构建后能快速确认“取指-执行”链路还活着。这个配置是所有后续测试的地基。第二测试程序分目录管理。把已经跑通的测试用例按模块归类例如指令集测试、内存保护测试、中断测试、外设测试。每次修改模拟器代码后全量跑一遍回归测试及时暴露行为变化。第三记录硬件手册和实现之间的映射。Mitra-15 的寄存器名、中断向量、指令编码最好整理成一张对照表放在仓库文档里。这样后续开发时不用每次翻手册也能让新贡献者快速上手。第四给 CI 流程加入模拟器构建和测试。如果项目托管在 GitHub 等平台可以在 push 时自动跑构建和基础测试发现问题比人工试更快。CI 里的测试脚本要和本地保持一致避免“本地能跑、CI 挂掉”的经典问题。后续扩展方向可以从几个维度考虑完善 CPU 指令覆盖把未实现指令补全尤其是带变址、间接寻址和特殊转移指令。实现更完整的中断控制器支持多优先级和嵌套中断。增加纸带、磁盘等外设的精确时序模拟为运行真实操作系统做准备。移植 Mitra-15 的监控程序或实时操作系统镜像这是模拟器价值兑现的关键一步。增加调试工具例如反汇编器、内存转储比较工具方便定位问题。补充文档把启动步骤、构建方法、测试清单整理成清晰的 README降低其他人参与门槛。如果后续能找到 Mitra-15 的诊断程序或自检程序把这些程序跑通是验证模拟器正确性的最有力手段。诊断程序通常覆盖大量边界条件比手工写的测试更全面也比手工测试更接近原机行为。12. 总结Mitra-15 in SIMH 是一个典型但持续演进的模拟器项目。它用 SIMH 这个成熟框架试图复刻一台 1970 年代的法国 16 位小型机。项目处于 WIP 阶段意味着你可以看到模拟器如何从 CPU 核心开始逐步扩张到内存保护、中断、外设和系统软件支持。相比直接使用一个已经完整可用的模拟器观察这个推进过程反而更有学习价值。如果你对这个项目感兴趣最先应该验证的不是“能不能跑操作系统”而是“指令集模拟是否正确”。从最简单的一条执行指令开始逐步拓宽覆盖再进入中断和内存保护测试。最容易踩的坑是没有建立回归测试就急着加功能结果一个小改动让之前跑通的程序全部失效。把测试脚本、日志、期望输出分目录管理给每类问题建立排查记录慢慢就能形成一套可靠的开发闭环。等到 CPU 核心稳定、外设基本可用再考虑移植 Mitra-15 的监控程序或操作系统镜像那时这个模拟器才真正从“能启动”变成“能跑软件”。这台机器虽然在今天已经毫无性能优势但模拟它的人不是在追逐性能而是在保留一段计算历史上的具体记忆。如果你也喜欢这种“把老硬件从文档里拉回现实”的过程这个项目值得持续关注。