翻译原理

是一个进程，不是一台机器

Champollion 只做用户态。客户程序不是被模拟出来的机器，它就是宿主进程本身。rvrun 加载 ELF， 把各个段映射进预留的客户地址空间，然后从入口点开始执行。当程序发起系统调用时，由运行时负责 处理——能直接实现的用 Rust 实现，无法实现的则翻译给宿主。

从文件到第一条指令

加载器解析 ELF，把各个段映射进客户内存（预留 256 GiB；在 macOS 上客户地址是相对该区域的固定 偏移，在 arm64 Linux 上客户地址就是宿主地址），构建初始的 Linux 栈，并为静态 PIE 映像做重 定位。程序若是动态链接的，它的 PT_INTERP——musl 的 ld-musl-riscv64.so.1——会先运行， 从 -L 指定的 sysroot 中解析。

两个引擎，一个基准

解释器逐条取指、译码、执行，它是永久的基准：其他引擎均以它为准进行比对，而不是反过来被信任。快速引擎 维护解码块缓存，块与它最后两个后继链接在一起，另有每线程的软件 TLB，覆盖客户内存的 4 KiB 页面。 内存映射发生变化或客户执行 fence.i 时，缓存会被丢弃。

riscv-tests 测试套件会让快速引擎和 JIT 与解释器逐例比对，要求每个用例结束时状态完全一致。

JIT

基本块由手写的编码器翻译成 arm64，它的输出在测试中与汇编器逐字节核对。生成的代码把客户地址 掩码进预留区域，并通过跳转缓存找到已翻译的后继块。翻译结果按可执行文件保存在持久化代码缓存中 （默认在 ~/Library/Caches/champollion），因此程序第二次运行时就已经是翻译好的； RVRUN_CACHE=0 可以关掉，RVRUN_JIT=0 则退回解释器。

系统调用与信号

客户程序的系统调用遵循 Linux ABI。一部分由运行时自己处理（mmap、brk 等）；其余的通过 一层极薄的 HostOs 接口过界。它的 macOS 后端负责翻译差异——open 的标志位、errno 取值、 信号、flock；它的 Linux 后端则把调用直接传给内核，内存布局为恒等映射。两种情况下错误都以 Linux errno 返回，并由一个宿主线程向客户程序投递信号。