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

这次我们来看一个比较小众、但非常有复古计算味道的项目：在 SIMH 模拟器框架中模拟法国 CII 公司的 Mitra-15 小型机。项目目前处于 Work in Progress 状态，也就是说，CPU 核心、内存、外设这些模块还在逐步落地，不是开箱即用的完整模拟器。但正因为是 WIP，对研究模拟器实现、复刻古董机指令集、整理老软件运行环境的开发者来说，反倒是一个很好的观察窗口。

Mitra-15 不是普通的 8 位教学机，它是法国 Compagnie Internationale pour l'Informatique（CII）在 1970 年代推出的 16 位小型机，面向实时控制、工业自动化、科学计算和数据采集场景。CII 后来并入 Bull 集团，所以 Mitra-15 在法国计算机工业史上有一席之地。它支持内存保护、多级中断、硬件陷阱和外部 I/O 通道，设计上偏工程控制，不是简单的个人电脑路线。这类机器今天很难找到实物，能通过 SIMH 在普通 PC 上跑起来，价值就在于把一段计算机历史变成可以动手调试的代码。

这篇文章会围绕 Mitra-15 和 SIMH 展开，先梳理 Mitra-15 的硬件结构和指令集特征，再说明 SIMH 模拟器的工程组织方式，随后给出本地构建、启动调试、功能验证、自动化批量测试和问题排查的完整思路。如果你对模拟器开发、古董机复原、老操作系统移植感兴趣，这篇文章可以收藏备用。

1. 项目与核心能力速览

这个表格里的“支持平台”“批量能力”来自 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.c：CPU 核心，实现取指、译码、执行和中断处理。
• 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 -h

SIMH 模拟器启动后，通常进入一个交互式控制台，可以直接输入命令。启动时可以通过命令行参数指定配置文件：

./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" 2>&1 done

然后把日志和预期结果做 diff：

for 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 2>&1

这样即使测试程序进入死循环，也不会拖垮整个流水线。

日志和测试结果建议和分析代码分开目录存放：

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)

或者用更详细的ps：

ps -o pid,pcpu,pmem,rss,vsz,etime,cmd -p $(pgrep sim_mitra15)

%CPU是 SimH 执行循环的繁忙程度。如果程序在纯计算，CPU 占用可能接近单核上限；如果程序在等纸带 I/O，CPU 占用会降下来，因为模拟器在模拟外设时通常需要等待宿主文件操作或模拟 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 项目的排查问题和方法，和成熟模拟器很不一样。很多报错不是“配置错了”，而是“功能还没写完”。下面是一张排查表，覆盖构建、启动、运行、外设和自动化流程里的常见问题。

遇到问题，排查顺序建议是：

1. 先确认是“模拟器代码问题”还是“测试程序问题”。换一个最简单的指令测试程序试试。
2. 再确认是不是“未实现功能”。查看源码里有没有TODO、FIXME、未注册的设备表项。
3. 然后用TRACE和EXAMINE缩小范围，定位到具体指令或内存地址。
4. 最后对照 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 的监控程序或操作系统镜像，那时这个模拟器才真正从“能启动”变成“能跑软件”。

这台机器虽然在今天已经毫无性能优势，但模拟它的人不是在追逐性能，而是在保留一段计算历史上的具体记忆。如果你也喜欢这种“把老硬件从文档里拉回现实”的过程，这个项目值得持续关注。