与其他架构比较
https://ewasm.readthedocs.io/en/mkdocs/comparison/#good_2
WASM
优点：
- 有限的非决定论（limited well defined non-determinism）
- 性能良好
- 可移植
- 前景广泛
- AST字节码使计量与虚拟机分离变得容易
缺点：
- 还不稳定
LLVM IR
优点：
- 久经考验
- 庞大的社区
- 被谷歌的PNACL使用
- 广泛应用
缺点：
- 不可移植
- 不稳定
- 虚拟机实现者必须应对ISA
Derek Schuff（PNACL工程师之一），Wasm和LLVM的对比
我猜你对PNACL不熟悉。这或多或少是PNACL采用的方法；例如使用LLVM作为连线格式的起点。事实证明，llvm ir/bitcode本身既不可移植，也不稳定，不足以用于此目的，而且它是为编译器优化而设计的，它有一个巨大的表面积，远远超过了此目的所需的表面积。PNACL通过定义一个可移植的三元组（一个称为“LE32”的体系结构，而不是i386或ARM）、LLVM IR的一个子集和基于LLVM bitcode的稳定线格式来解决这些问题。所以这种方法（虽然不像“直接使用llvm-ir”那么简单）确实有效。然而，llvm的ir和bitcode格式（分别）被设计成用作编译器的ir和用于链接时间优化的临时文件序列化。它们不是为我们的目标而设计的，特别是压缩分发格式和快速解码场景。我们认为，通过从PNACL获得的经验，我们可以为WASM做得更好。
LLVM IR旨在使编译器优化易于实现，并代表C、C++和其他语言在各种操作系统和体系结构中所需的构造和语义。这意味着，默认情况下，IR是不可移植的（同一个程序对于不同的体系结构具有不同的表示形式）或稳定的（随着优化和语言需求的变化，它会随着时间而变化）。它对各种各样的信息都有表示，这些信息对于实现中级编译器优化很有用，但对于代码生成却没有用（但对于代码生成实现者来说，这是一个很大的表面积）。它还具有未定义的行为（基本上类似于C和C++），这使得某些类的优化是可行的或更强大的，但这可能导致在运行时不可预测的行为。LLVM的二进制格式（bitcode）是为临时磁盘上的IR序列化而设计的，用于链路时间优化，而不是为了稳定性或可压缩性（尽管这两种格式都有一些特性）。
这些问题都不是不可克服的。例如，pnacl设计了一个小的可移植的IR子集，删除了那些未定义的行为，以及一个稳定的比特码编码版本。它还采用了几种技术来提高启动性能。但是，每个定制、解决方案和特殊解决方案都意味着从公共基础设施中获益较少。
CLI/ECMA-335
优点：
- 内核运行时和CIL子集，这是我们所需要的。（我们可以只使用CIL中间语言子集，但这会切断我们与更大生态系统的联系。）
- 内核似乎可以安全和确定的使用。我没有太多的分析，但保险和安全是设计目标。
- 2000年以来国际标准稳定。
- 稳定的.NET和开源Mono实现。
- 成熟的工具和语言支持，庞大的用户群，开源（甚至来自微软）。
缺点：
- 缺少标准SIMD支持。（Mono和.NET都在使用它，所以它最终应该是标准的。）
- 缺少了WASM的一些更好的特性——堆栈机，不那么紧凑，不基于AST等等。
- 可能比WASM占用更大的运行时间。
- 微软。
- 我提到微软了吗？
RISCV
RISCV不是纯粹的硬件规格吗？
JVM
放弃。Oracle所有权和知识产权问题。
EVM1
优点：
- 自主可控
- 我们引导其发展方向
- 与其他项目的协调是可选的
- 我们有这方面的工程人才
- 我们可以适当地结合WASM和其他技术
缺点：
- 我们完全控制
- 我们需要维护和构建自己的开发人员和用户社区。（这可能是专业人士。）
- EVM的设计有些笨重，妨碍了性能和良性的发展。
