这是关于 WebAssembly 问题及修复提案的 4 部分迷你系列的最后一部分。

• 系列前文：包含第 1 部分、第 2 部分、第 3 部分。假设读者对虚拟机、编译器和 WebAssembly 有一定了解，必要时会提供相关链接。作者虽爱 WebAssembly，但希望能解决其设计中的问题。
• 引入 Microwasm：是与 WebAssembly 兼容的格式，可被运行时高效消费，也可被像 LLVM 这样的编译器高效生成。目前在Lightbeam 的 Microwasm 分支中实现。主要目标包括：三步实现相对容易、不牺牲安全性和确定性保证、最大化信息传递、优化消费性能、可流式转换 Wasm 为 Microwasm 且性能与直接编译 Wasm 原生代码相同。
• 与 WebAssembly 比较：以 Wasm 规范测试中的简单函数为例，Microwasm 格式的差异有：无本地变量（参数通过栈传递，本地变量通过swap和pick指令模拟）、只有 CFG 控制流（无层次块）、无块返回（通过br.return返回）。还考虑了将环境作为显式参数传递的更改，以减少翻译代码中的特殊情况。生成代码的质量差异明显，如 Lightbeam 在实现 Microwasm 前后的汇编输出对比，控制流更清晰，寄存器使用更好，但仍存在一些问题。与 Firefox 的优化 WebAssembly 编译器生成的汇编相比，大致相同。
• 为何不是普通 MIR：通过保持格式内部，可在不影响 WebAssembly 安全性和沙箱保证的情况下，改进代码生成后端的简单性。待确定如何充分利用该格式后，可让像 LLVM 这样的前端直接生成，提高性能且无需额外工作。
• 为何不在 WebAssembly 中实现：维护一个格式并非易事，且多个浏览器支持两种类似但不同的格式不合理。V8 难以支持这种格式的任意 CFG，IonMonkey 虽有优化但不如 V8 困难。作者认为说服 Chrome 团队改变想法的可能性为零，所以通过实现自己的兼容格式来规避问题，希望能更好地为 WebAssembly 原型化想法。
  总之，这是系列的最后一部分，感谢阅读。若想了解更多，可阅读其他文章或观看 YouTube 视频等。