当我们谈论 WebAssembly 的执行模型时，官方文档中 “便携式抽象结构化堆栈机器” 这一描述已经深入人心。然而，深入分析 WASM 的指令语义与 locals 机制的实现细节，我们会发现这幅图景远比表面上看起来复杂得多。事实上，WASM 展现出一种独特的混合特征：它在指令层面表现为堆栈机，但在数据存储层面却更接近寄存器机，而且是一种缺乏 liveness 分析的寄存器机。这种设计上的微妙差异对编译器优化和运行时性能产生了深远影响，理解这一点对于构建高效的 WASM 工具链至关重要。
堆栈机与寄存器机的本质差异
要理解 WASM 的执行模型，首先需要明确堆栈机与寄存器机的根本区别。在传统的堆栈机中，所有操作都隐式地从操作数堆栈中获取数据。例如，一个加法指令会从堆栈顶部弹出两个值，相加后将结果压回堆栈。这种设计的优势在于指令编码极为紧凑 —— 操作码本身不需要指定操作数的位置，因为它们总是来自堆栈的预定位置。此外，堆栈机的 liveness 分析变得 trivial：一旦一个值被用作某个操作的参数，它在该操作执行完成后就立即变为死值，不需要额外的复杂分析。
相比之下，寄存器机拥有固定数量的具名存储位置，每个指令明确指定读取和写入哪些寄存器。典型的三地址指令格式如 add %0, %1, %2 表示将寄存器 %1 和 %2 的值相加，结果存入寄存器 %0。寄存器机的优势在于可以更直接地映射到真实硬件的寄存器文件，但代价是需要进行复杂的 liveness 分析 —— 编译器必须精确计算每个寄存器在程序每一点的生存状态，才能安全地复用寄存器空间。这种分析在流式编译场景中尤其困难，因为编译器无法预读整个函数甚至整个模块的代码。
WASM 的双重面孔：指令层的堆栈机
从指令层面观察，WASM 确实表现出堆栈机的典型特征。以 i32.add 指令为例，它从操作数堆栈中弹出两个 i32 值，将它们相加，然后将结果推回堆栈。所有算术、逻辑和内存访问指令都遵循这一模式。这种设计的直接好处是指令高度可移植 —— 不同平台上的 WASM 运行时不需要关心寄存器分配问题，只需要正确维护一个值堆栈即可。指令验证也因此变得简单直接：验证器只需要跟踪每条指令执行前后堆栈的深度和类型是否匹配。
这种堆栈语义还天然地与 SSA 形式兼容。在真正的堆栈机中，堆栈上的每个值在用作操作数之后就立即死亡，不存在跨指令的数据依赖。这意味着理论上可以将任何堆栈机代码 trivially 转换为 SSA 形式，而不需要复杂的数据流分析。即使是 pick 这类复制堆栈元素的指令，只要其参数是编译时常量，也可以通过引用计数的方式高效实现。这意味着一个理想的 WASM 运行时应该能够生成非常高效的机器代码，因为它可以充分利用这种固有的 SSA 性质。
locals 机制：隐藏在堆栈机表象下的寄存器机
然而，WASM 引入了 locals 机制 —— 通过 get_local、set_local 和 tee_local 指令访问的具名存储位置。这改变了整个图景。Locals 在函数入口处分配，在函数退出时释放，它们在整个函数生命周期内存在。与堆栈值不同，locals 可以被多次读写，而不需要每次都通过堆栈传递。这种设计本意是让编译器能够将频繁使用的值保持在 “寄存器” 中，避免反复压栈出栈的开销。
但这恰恰是问题的根源。Locals 是可变的，这意味着它们无法直接转换为 SSA 形式。在 SSA 形式中，每个变量只能被赋值一次，而 locals 可以被多次赋值。更糟糕的是，locals 在整个函数范围内都是活跃的 ——WASM 的语义没有提供任何方式来表达 “这个 local 在某个点之后不再使用”。这意味着即使一个 local 在函数的后半部分从未被访问，运行时仍然必须为它保留存储空间，因为它无法知道这个 local 何时不再需要。
考虑一个具体的例子：当编译一个包含循环的函数时，循环计数器通常被实现为 local。传统上，编译器可以分析出循环计数器在循环最后一次迭代之后就不再使用，从而释放相应的寄存器。但在 WASM 中，由于 local 必须在整个函数生命周期内保持分配，运行时无法进行这种优化。这导致了一个看似荒谬的结果：一个从未使用过的函数参数仍然会永久占用一个 “寄存器” 位置，即使运行时代码明确知道这个参数在函数的后续部分不会被访问。
对编译器优化的深层影响
这种设计对优化编译器产生了多方面的负面影响。首先，也是最显然的，流式编译器（如 Firefox 的 baseline 编译器）无法在没有完整函数视图的情况下进行有效的寄存器分配。在理想的堆栈机中，编译器只需要跟踪堆栈深度，不需要关心寄存器的分配和释放。但 WASM 的 locals 机制要求编译器进行额外的 liveness 分析，而这种分析在流式编译场景中是不可行的。
其次，即使对于能够进行完整分析的后端编译器，WASM 也强制它们重新计算本应已经由前端计算过的信息。当一个语言编译器（如 Rust、Cargo 或 Emscripten）生成 WASM 代码时，它已经完成了自己版本的 liveness 分析和寄存器分配。然而，这些信息在转换为 WASM 的过程中丢失了 ——WASM 的 locals 机制无法表达 “此变量在第 N 行之后死亡” 这样的精细信息。结果是，后端运行时不得不重复这些计算，造成了计算资源的浪费。
第三，这种设计还影响了代码验证和安全性。在严格的堆栈机中，访问未初始化变量在语义上是不可能的 —— 如果尝试使用一个从未被推送的值，堆栈会下溢，验证器会拒绝该模块。但在 WASM 中，locals 默认值为零，验证器只能通过静态分析来检查 local 是否在每次读取前都被写入。这种分析在存在控制流分支时会变得非常复杂，而且一旦分析失败，运行时就会执行包含未定义值的代码，这可能引发安全问题和难以调试的 bug。
运行时设计的挑战与应对
对于 WASM 运行时的实现者来说，理解这种混合模型至关重要。现代 WASM 运行时（如 Wasmtime、Wasmer）通常采用分层编译策略：先进行快速的 baseline 编译以实现短启动时间，然后根据实际执行情况进行优化 JIT 编译。在 baseline 阶段，由于缺乏完整的 liveness 信息，编译器必须采取保守策略，为每个 local 保留独立的存储位置，这导致了更高的内存占用和更多的内存访问次数。
优化 JIT 编译器需要投入额外的编译时开销来进行数据流分析，以恢复丢失的 liveness 信息。一些先进的运行时采用了 “记录 - 重放” 策略：在 baseline 执行阶段记录 local 的实际使用模式，然后在优化编译阶段利用这些信息进行更精准的寄存器分配。这种方法虽然有效，但增加了实现的复杂性和运行时的内存开销。
另一个值得关注的趋势是 multi-value 提案的采用。该提案允许函数和代码块接受参数并返回多个值，这与传统堆栈机的块参数机制更为接近。如果完全采用这种设计，理论上可以消除对 locals 的依赖：函数参数可以通过块参数传递，循环计数器可以作为循环头的参数，局部变量也可以通过临时性的块参数替代。这样一来，WASM 将真正成为一个具有 SSA 形式的堆栈机，编译器可以生成更高效的代码，验证器可以更容易地确保内存安全，运行时也可以更简单地实现优化。
总结
WebAssembly 的执行模型代表了在一个特定历史背景下做出的工程折中。最初被设计为 asm.js 的二进制表示，后来演变为独立的虚拟机指令集，WASM 继承了来自多个设计阶段的概念遗产。指令层面的堆栈语义提供了可移植性和简洁的验证规则，但 locals 机制的存在使其在数据存储层面表现为一个缺乏 liveness 分析的寄存器机。这种双重性质导致了优化编译器必须重新计算本应已经知道的信息，流式编译器难以生成高效代码，以及运行时必须投入额外资源进行保守的资源分配。
理解这些底层细节对于 WASM 工具链的开发者和使用者都有重要价值。对于工具链开发者，它揭示了当前设计的局限性以及潜在改进方向。对于应用开发者，它帮助理解为什么某些看似简单的 WASM 代码可能在性能上不如预期，以及如何编写更友好的 WASM 代码。随着 multi-value 等提案的逐步成熟和采用，WASM 有望向更纯粹的堆栈机模型演进，从而释放更大的性能潜力。