Acorn 在 1983 年启动 RISC Machine 项目时，团队中没有任何成员有过处理器设计经验。他们读到加州大学伯克利分校的 RISC 架构论文后，意识到芯片设计并非遥不可及。两年后，ARM（Acorn RISC Machine）处理器问世，定义了 Archimedes 产品线。这枚 32 位处理器后来演变为今日智能手机和 Apple 芯片生态的基石 —— 尽管 Acorn 本身从未能在家庭市场复制 BBC Micro 的辉煌。
理解这段历史的技术遗产，对于今天的跨平台编译器设计和模拟器兼容性工作具有直接的参考价值。
后端重定向的工程约束
PipeDream 的移植路径提供了一个教科书级别的后端重定向案例。该软件最初运行于 Cambridge Z88（基于 Zilog Z80 的便携设备），其核心设计围绕字符型布局引擎构建。当 Mark Colton 将开发环境转向 C 语言时，为 Archimedes 进行移植变得相对直接 —— 只要处理好 ARM2 与 Z80 在指令集层面的差异。
ARM2 采用加载 / 存储架构，所有运算操作仅能作用于寄存器，而非直接操作内存地址。这一约束意味着：Z80 代码中常见的 LD A,(HL) 这类内存直接寻址操作，在 ARM2 上必须分解为独立的加载指令和运算指令。对于一个以电子表格和数据库为核心功能的应用，这种指令粒度的变化直接影响了内存访问模式的效率。
更关键的约束来自寻址模式。Z80 的间接寻址能力相对有限，但 ARM2 的流水线设计对指令的立即数编码有严格限制 —— 每条指令的立即数域仅能编码 8 位旋转值，这意味着超过 256 的常量在汇编层面需要多次指令才能构建。移植时，需要识别代码中的大块常量，将其预置到数据段或使用文字池（Literal Pool）技术。
RISC OS 与模拟器的硬件抽象层
Acorn 在开发 ARX（计划中的抢占式多任务操作系统）期间遭遇延期，最终决定在原有的 Arthur 操作系统基础上继续演进，演变为 RISC OS。这个权宜之计催生了一个独特的 GUI 环境：无菜单栏（右键菜单在指针位置弹出）、三键鼠标（Select/Menu/Adjust）、拖放作为核心文件操作隐喻。
对于现代模拟器开发者而言，理解 RISC OS 的硬件抽象层至关重要。以 RPCEmu 为例，该模拟器实际模拟的是 Acorn 后期的 Risc PC 而非原始 Archimedes 硬件。关键在于：RISC OS 本身对硬件层进行了大量抽象，使得应用层代码在两种硬件配置间能够平滑过渡。
这种兼容性取决于几个参数配置：
- MEMC（内存控制器）模拟：Risc PC 使用 MEMC1a，而 Archimedes 早期型号使用 MEMC1，两者对页面映射和缓存策略的处理存在差异
- 中断控制器：ARM2 的标准中断机制在模拟器中需要精确时序才能保证多任务调度的正确性
- 视频帧缓冲：原始 Archimedes 的视频系统支持特定的分辨率和色彩深度组合，模拟器需要提供等效的显示输出能力
对于想在 x86 或其他现代架构上运行 RISC OS 应用的开发者，最实用的建议是采用预构建镜像。RPCEmu 的预配置版本通常包含了 OS、必要的驱动以及常用的应用程序，能够在数分钟内完成部署。手动配置则需要处理键盘映射（如 | 键在不同键盘布局下的处理）和文件系统的挂载路径等细节。
指令级兼容性与性能权衡
在评估模拟器性能时，需要区分两个不同的层次：硬件指令级兼容和操作系统 API 级兼容。
硬件级兼容涉及 ARM2 指令集的实际模拟。对于需要精确时序的工作（如性能基准测试或依赖特定指令执行时间的代码），必须逐条模拟每条 ARM 指令。这种方法的开销巨大 —— 典型的模拟器每条 guest 指令需要数十条 host 指令来完成模拟。
操作系统 API 级兼容则采用不同的策略。RISC OS 提供了一组相对稳定的系统调用接口，模拟器可以拦截这些调用并转换为宿主系统的原生实现。例如，文件操作 osgbpb 系列调用在模拟器环境下会被重定向到宿主文件系统的对应路径，而无需逐条模拟底层的 ARM 指令流。
实测表明，采用 API 级兼容的模拟器在大多数应用场景下能够达到宿主系统 70%–85% 的性能水平。对于 PipeDream 这类办公应用而言，这个性能差几乎不可感知 —— 真正的瓶颈更可能来自模拟器中的图形渲染效率，而非处理器模拟部分。
移植参数与可配置阈值
对于计划进行类似移植的开发者，以下参数值得重点关注：
寄存器分配策略方面，ARM2 拥有 16 个通用寄存器（r0–r15），其中 r13 传统上用作栈指针，r14 作为链接寄存器。移植代码时应避免直接操作这些保留寄存器，或确保调用约定与此一致。
调用约定方面，ARM 架构使用 r0–r3 传递前四个参数，多余参数压栈返回。函数返回值通过 r0 传递。这种约定与 x86 的栈传递模式完全不同，需要在 ABI 层面进行适配。
内存对齐方面，ARM2 要求 32 位数据按 4 字节边界对齐，16 位数据按 2 字节对齐。未对齐访问会触发数据中止异常，模拟器需要正确处理这类边界情况。
浮点运算方面，原始 Archimedes 可选配 FPA（浮点加速器）协处理器，但模拟器通常不模拟该组件，软件会回退到软件浮点库，性能下降约 10–20 倍。
历史遗产的开源延续
Mark Colton 在 1995 年的一场赛车事故中丧生，他的父亲 Richard 在 2014 年将 PipeDream 和 Fireworkz 开源，使其延续至今。目前由 Stewart Swales 维护，他曾是 Acorn 的工程师，参与过 Arthur 操作系统的开发，如今在 RISC OS 生态中继续着这项工作。
Fireworkz 作为原生 Win32 应用在 Windows 11 和 macOS Wine 环境下均可正常运行，体积仅 2.5MB。这种跨时代的兼容性证明了一个朴素的真理：当年在架构设计时多花的心思，最终会以意想不到的方式获得回报。
对于今天的开发者而言，Acorn Archimedes 的故事提醒我们：硬件选择固然重要，但软件层面的抽象能力 —— 无论是通过操作系统还是模拟器 —— 往往决定了技术路线的最终寿命。
资料来源：Stone Tools 博客 "PipeDream on the Acorn Archimedes"，2026 年 5 月发布。
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。