与其他架构比较
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的设计有些笨重,妨碍了性能和良性的发展。