手写 EVEX 字节前，先建立汇编与反汇编的闭环

JIT 示例最危险的一行，有时是根本没有执行的函数调用，后面却打印“安全返回”。另一个常见问题是复制一串 EVEX 前缀后不验证 map、操作码与寄存器字段。机器码不会根据注释猜作者想写哪条指令。

Intel 指令手册第二卷给出了 VFMADD213PS 等指令的编码与语义。手册中的 opcode map 是编码的一部分，不是可省略的装饰。实际工程宜先让汇编器生成，再反汇编核对；独立实现编码器后，再用同样流程做差分测试。

助记符、汇编器、字节和反汇编组成检查闭环，页权限另行验证。

先用不会执行的模型检验内存页状态

以下 Rust 程序只验证 JIT 页的状态转换策略：写入只能发生在 Writable 状态，发布后只读。它没有创建可执行内存，更没有发出 AVX-512。保存为jit_state.rs，使用标准rustc --edition=2021编译运行。

#[derive(PartialEq, Debug)] enum State { Writable, Executable } struct Page { state: State, bytes: Vec<u8> } impl Page { fn write(&mut self, b: u8) -> Result<(), &'static str> { if self.state != State::Writable { return Err("page is sealed"); } self.bytes.push(b); Ok(()) } fn seal(&mut self) { self.state = State::Executable; } } fn main() { let mut p=Page { state: State::Writable, bytes: Vec::new() }; p.write(0xc3).unwrap(); p.seal(); assert!(p.write(0x90).is_err()); assert_eq!(p.bytes, vec![0xc3]); println!("JIT state model rejects post-seal writes"); }

真正执行还需要更长的合同

真实实现必须检查映射与保护切换是否成功，遵守平台的可写可执行限制，并在需要时处理指令缓存一致性。函数指针类型、调用约定、栈对齐和寄存器保存也必须匹配。macOS 的 JIT 权限与 x86 Linux 的mmap示例不能互相替代。

指令集支持应在调用前检查，错误路径不能回到未经验证的机器码。代码内存的释放还需等待所有执行者退出；Rust 的普通Vec<u8>不会自动赋予可执行权限，也不会解决跨线程执行生命周期。

编码器可以怎样做差分检查

先固定一条明确的助记符、寄存器组合和操作数形式，让成熟汇编器生成字节，再让自己的编码器生成同样输入。比较字节时要区分等价编码与错误编码；之后再用独立反汇编器检查每个字段。寄存器从低编号换成高编号、改变向量宽度与掩码，能帮助覆盖前缀中最容易漏掉的位。

反汇编吻合仍不等于执行正确。浮点指令的操作数顺序、读写目标与舍入选项，也可能与作者预期不同。真正执行测试需要给各个输入寄存器放入可区分的数据，再逐元素比较输出。把所有输入都设为零，会让多种错误编码得到同样结果。

权限状态机也需要现实接口支撑。例子中的 seal 只修改枚举，实际实现必须确认操作系统已经完成相应保护切换，并处理失败。若失败以后仍把地址转成函数指针，类型系统中的状态便与真实页面权限脱节。可以让成功转换返回一个新类型，使可执行入口只存在于成功路径。

最后是卸载。生成的函数可能被多个线程持有，释放代码页之前必须知道没有任何调用还在进行，也不会再开始。缓存驱逐和动态更新都可能触碰这个边界。JIT 的生命周期问题与普通函数不同，不能因为测试函数已经返回，就假定整份代码缓存都可以回收。

验证记录最好分别保存助记符输入、生成字节、反汇编结果与执行输出，避免把注释当成唯一证据。某条指令没有在当前架构执行，就只报告编码层检查。对于尚无目标设备的分支，保留明确未测状态，比用一行成功打印替它完成验收更可靠。

本文没有实际执行字节码，也不声称纳秒生成或微秒编译。可靠的 JIT 验证应逐层记录：编码正确、反汇编吻合、ABI 正确、执行输出正确、错误路径可靠。任何一层缺证据，都应保留这个缺口。