Wasm on chai2010 的博客

2023: WASM 原生时代已经扑面而来

Sun, 15 Jan 2023 00:00:00 +0000

作者在2018年写作《WebAssembly 标准入门》，当时有幸邀请到CSDN和极客帮的创始人蒋涛先生为该书作序，当时蒋涛先生就对WebAssembly的技术做出了高度评价。2022年我们针对WebAssembly开源凹语言，CSDN平台也在第一时间提供了报道。在此一并感谢蒋涛先生和CSDN平台！

这是我今年写的2022年技术盘点的最后一篇（前两篇分别是：CSDN首发的“Go2正式落地，中国 Gopher 踏上新征程！”和InfoQ首发的“2022 国产编程语言盘点”）。WebAssembly 作为一种新兴的网页虚拟机标准，它的设计目标包括：高可移植性、高安全性、高效率。2018 年 WebAssembly 第一个规范草案诞生，2019 年成为 W3C 第四个标准语言。到了 2022 年底，WebAssembly 现在怎么样了…

0. WASM 原生和 Ending 定律

0.1 什么是 WASM 原生

WASM 原生可以类比云原生的定义：就是天生就是为 WebAssembly 平台设计的程序和语言。比如专门为 WebAssembly 设计的 AssemblyScript 语言和凹语言就是 WASM 原生的编程语言。如果一个应用天生就是考虑了 WebAssembly 的生态支持，那么就是 WASM 原生的应用。

现在 Docker 已经开始支持 WASM 程序，因此 WASM 原生软件天然也是云原生的软件，但是反之则不能成立。因为云原生受限于云的环境、导致其应用的场景和领域有较大的限制，比如云原生应用强依赖网络因此无法在很多单片机环境、甚至是本地环境运行。但是 WASM 原生的程序则可以轻松在 Arduino 等受限环境、本地台式机机环境、个人智能手机环境和 Kubernetes 等云原生环境执行。可以说 WASM 原生因为其比云原生更多的限制，换来了更普适的执行环境和更大的生态。

可以预期随着 WebAssembly 的普及，WASM 原生的应用将会越来越多，同时影响面也会越来越大。

0.2 什么是 Ending 定律

Ending’s law: “Any application that can be compiled to WebAssembly, will be compiled to WebAssembly eventually.”

Ending 定律：“一切可编译为 WebAssembly 的，终将被编译为 WebAssembly。”

Ending 定律也称为终结者定律，它是 Ending 在 2016 年 Emscripten 技术交流会上针对 WebAssembly 技术给出的断言。Ending定律的威力不仅仅在语言层面。WebAssembly是第一个虚拟机世界标准，以后将人手至少一个 WASM 虚拟机。不过和之前被大家鄙视的JavaScript语言大举入侵各个领域的情况不同，这次 Python、Ruby 这些语言将彻底拥抱 WebAssembly 技术，因为它是一个更底层、也更加开放的新兴生态平台。

1. WebAssembly 发展简史

WebAssembly（简称 WASM）是W3C定义的第4个标准，是Web的第四种语言。说WebAssembly是一门编程语言，但实际上它更像一个编译器，其实它是一个虚拟机，它还包含了一门低级汇编语言和对应的虚拟机体系结构，而WebAssembly这个名字从字面理解就说明了一切：“Web的汇编语言”。简而言之、WebAssembly是一种新兴的网页虚拟机标准，它的设计目标包括：高可移植性、高安全性、高效率（包括载入效率和运行效率）、尽可能小的程序体积。

1.1 Emscripten 项目

WebAssembly的前身是Mozilla的创建的Emscripten项目（2010年）——通过将C/C++通过LLVM编译到JavaScript的asm.js子集来提速！JavaScript作为弱类型语言，由于其变量类型不固定，使用变量前需要先判断其类型，这样无疑增加了运算的复杂度、降低了执行效能。因为asm.js仅包含可以预判变量类型的数值运算，有效的避免了JavaScript弱类型变量语法带来的执行效能低下的顽疴。根据测试，针对asm.js优化的引擎执行速度和C/C++原生应用在一个数量级。

2015年6月Mozilla在asm.js的基础上发布WebAssembly项目，随后Google、Microsoft、Apple等各大主流的浏览器厂商均大力支持。WebAssembly不仅拥有比asm.js更高的执行效能，由于使用了二进制编码等一系列技术，WebAssembly编写的模块有更小的体积和更高的解析速度。目前不仅C/C++语言编写的程序可以编译为WebAssembly模块，Go、Kotlin、Rust、Python、Ruby、Node.js、AssemblyScript、凹语言等新兴的编程语言都开始对WebAssembly提供支持。

1.2 WebAssembly 1.0草案

WebAssembly技术自诞生之日就进入高速发展阶段。在2018年7月WebAssembly 1.0草案正式发布，在2019年12月正式成为W3C国际标准，成为与HTML、CSS和JavaScript并列的唯四前端技术。2019年同样诞生了WASI（WebAssembly System Interafce）规范，用于将基本的系统调用带入到WASM生态。2022年Docker对WASM提供支持，目前WebAssembly已经是一个独立的生态。

1.3 WebAssembly 生态大图

下面是 “WebAssembly将引领下一代计算范式” 展示的生态大图：

可以看到从工具链、基础设施、到应有和Web3均有涉及，生态已经非常丰富。

3. WASM社区22年的变化

2022年，自媒体社区对 WebAssembly 的评价态度可谓是完美遵循了欲扬先抑的剧本。先是有热文爆大佬 WebAssembly 创业失败引发质疑，然后是传出社区分裂、应用争议再引发炒错的方向争论，然后随着 Docker 对 WASM 支持的预览版发布带来风向转变，年底就又变成各种赞美和畅想。其实 WebAssembly 真正的从业人员始终在稳步推进，完全没有自媒体这种过山车的变化。

3.1 WebAssembly 2.0 草案

4 月 20 日，W3C 公布了 WebAssembly 2.0 的第一批公共工作草案。主要包含向量类型、引用类型、多返回值、多Table支持和Table和内存指令增强等。向量类型的支持可以用于优化纯计算类型的并发程序、引用类型可以用于和外部的浏览器DOM对象等更好的交互、多返回值可以可以简化某些程序的表示（比如凹语言后端依赖该特性）、多Table支持可能用于灵活支持多模块连接等。可以说 WebAssembly 标准是该生态的统一基准平面，而且这些特性的实现已经相对普及，可以作为实验特性试试用。

完整文档参考：https://www.w3.org/TR/wasm-core-2/

3.2 Docker 支持 WebAssembly

2019 年，Docker 创始人 Solomon Hykes 发布了一条推文，他说如果 2008 年就诞生 WebAssembly 和 WASI 的话，Docker 就没有必要诞生了。

其实《WebAssembly标准入门》作者在2018年 WebAssembly 草案刚刚诞生的时候也得出过类似的结论：我们觉得 WebAssembly 更大的生命力在浏览器之外，如果配合文件系统、网络系统将得到一个更为迷你的操作系统无关的运行平台。也正是基于这个判断，在2018年底正式启动了国产凹语言项目（专门针对WebAssembly设计的通用语言）。

Docker 与 WasmEdge 合作创建了一个 containerd shim，此 shim 从 OCI 工件中提取 Wasm 模块并使用 WasmEdge 运行时运行。Docker 现在添加了对声明 Wasm 运行时的支持，这将允许开发者使用这个新的 shim。

Docker 执行 wasm 需要指定一些额外参数：

$ docker run -dp 8080:8080 \
  --name=wasm-example \
  --runtime=io.containerd.wasmedge.v1 \
  --platform=wasi/wasm32 \
  michaelirwin244/wasm-example

首先runtime参数指定wasmedge运行时，然后platform指定采用wasi/wasm32规范（指定有哪些宿主api）。

完整的信息可以参考 Docker 的官方文档：https://docs.docker.com/desktop/wasm/

3.3 SQLite3 官方支持 WebAssembly

SQLite3 作为一个纯粹的 C 语言库，其实在 WebAssembly 标准诞生之前就可以通过 Emscripten 技术将 C 代码编译为 asm.js。因此，网上很早就有在浏览器的 JS 版本、甚至直接通过 Emscripten 输出 WebAssembly。不过这次是 SQLite3 官方提供了对 WebAssembly 的支持，这表示 WebAssembly 在 SQLite 社区完全进入工业级应用阶段！

根据官网介绍，主要有 4 个目标：

绑定一个低级的 sqlite3 API，在使用方面尽可能接近原生 API。
更高级别的面向对象风格 API，类似于 sql.js 和 node.js 样式的实现。
基于 Worker 的 API，以支持多线程环境更容易使用 SQLite 功能。
基于 Worker API 的 Promise 包装，对用户完全隐藏了跨线程通信方面复杂性

而不在此列的特性包括不支持UTF16、和清除老旧特性等。简而言之，在提供底层 API 能力的同时，针对面向对象、多线程等环节提供简单易用的 API。完整的介绍请参考：https://sqlite.org/wasm

3.4 Ruby 3.2 支持 WebAssembly

12 月发布的 Ruby 3.2 也增加了基于 WASI 的 WebAssembly 支持。使得 CRuby 二进制内容可用于浏览器、Serverless Edge、以及其他 WebAssembly/WASI 嵌入环境。目前，此功能已通过除 Thread API 之外的 basic 和 bootstrap 测试套件。

虽然目前基于安全原因，还缺少一些功能来实现纤程、异常和垃圾回收的特性，但是这已经让用户可以在浏览器中尝试原生的 CRuby：https://try.ruby-lang.org/playground/

3.5 Python 3.11 支持 WebAssembly

和 Ruby 社区的目标类似，Python 社区也在 4 月启动在 Python 3.11 增加对 WebAssembly 的支持。Python 3.11 对 wasm32-emscripten 和 wasm32-wasi 提供了支持，从而也实现了在浏览器执行 Python 的梦想。

具体细节可参考以下文档：

因为有了 WebAssembly 魔法加持，Ruby 个 Python 等脚本语言也终于可以在浏览器玩耍了。

3.6 为 WebAssembly 而生的凹语言

WebAssembly 草案刚刚发布不久，国外就诞生了专门为其设计的 AssemblyScript 语言。在2022年7月，国内 Gopher 也发起了针对 WebAssembly 平台的凹语言。目前凹语言不仅仅提供了在线的Playground，还上线了用凹语言开发的贪吃蛇小游戏。希望新兴的语言可以为 WebAssembly 注入更多的活力。

凹语言主页：https://wa-lang.org/
凹语言仓库：https://github.com/wa-lang/wa
凹语言开发的贪吃蛇：https://wa-lang.org/wa/snake/

4. WASM虚拟机实现

对于 JavaScript 用户，直接通过浏览器内置的 WebAssembly 模块即可，或者是通过 Node.js 提供的模块 API。我们这里简要介绍的是浏览器环境之外的WASM虚拟机实现，这里介绍的主要有C/C++、Rust和Go语言几类实现。总体来说，大家完全不需要担心WASM虚拟机的选择和切换代价，只要遵循WASM标准原则切换虚拟机就和换个鼠标一样容易。

4.1 C/C++ 语言 - WasmEdge 和 wasm3

WasmEdge 和 wasm3 是 C/C++ 语言实现的具有代表性的两个 WebAssembly 虚拟机（没有包含 V8 的虚拟机）。

WasmEdge 可以说是目前最受关注的 WebAssembly 虚拟机实现，因为它不仅仅是 CNCF 推荐的 WASM 虚拟机，更是 Docker 内置的 WebAssembly 虚拟机。WasmEdge 是由美国的袁钧涛（Michael Juntao Yuan）发起，是由 CNCF 托管的云原生 WebAssembly runtime。它广泛应用于边缘计算、汽车、Jamstack、Serverless、SaaS、服务网格，乃至区块链应用。 WasmEdge 可以进行 AOT （提前编译）编译器优化，是当今市场上最快的 WebAssembly runtime 之一。可以预计，随着 Docker Wasm 的普及，WasmEdge 将成为最流行的 WASM 虚拟机实现之一。

WasmEdge：https://wasmedge.org
袁钧涛（Michael Juntao Yuan）：https://github.com/juntao
开源中国高手问答：“WebAssembly 将会取代 Docker”，但还有后半句：https://www.oschina.net/question/5324949_2323880

wasm3 是 C 实现的 WebAssembly 引擎，可运行在嵌入式设备上。因为需要的资源比较少，目前可以运行在Arduino和树莓派环境。wasm3 仓库：https://github.com/wasm3/wasm3

4.2 Rust 语言 - wasmer 和 wasmtime

wasmer 和 wasmtime 是 Rust 实现的两个流行的 WebAssembly 虚拟机。根据 2022 年 7 月的的调查报告（300人提交问卷），来自字节码联盟的 wasmtime 最流行、其次为 wasmer。不过从长期看，作者推测 WasmEdge 将随着 Docker/wasm 成为浏览器外最流行的 Wasm 虚拟机实现。

wasmtime 仓库：https://github.com/bytecodealliance/wasmtime
wasmer 仓库：https://github.com/wasmerio

4.3 Go 语言 - WaZero

WaZero 是纯 Go 语言实现的 WebAssembly 虚拟机，因此不需要依赖 CGO 特性。目前凹语言内置的就是 WaZero 虚拟机。仓库地址：https://github.com/tetratelabs/wazero

另外，国内张秀宏著的《WebAssembly原理与核心技术》讨论了用Go语言如何实现 WebAssembly 虚拟机，感兴趣的读者可以参考。

5. 支持WASM的编程语言

WebAssembly 允许开发者用几十语言（包括 AssemblyScript、C/C++、Rust、Golang、JavaScript和凹语言等）。支持WASM的编程语言主要分为3类：首先是专门为 WebAssembly 设计的新语言，比如 AssemblyScript 和凹语言等；其次是将语言编译到 WebAssembly 目标平台，比如 C/C++、Rust、Golang 这类语言（和第一类有一定重叠）；最后是将语言的虚拟机或解释器编译到 WebAssembly 平台，比如 Lua、JavaScript、Ruby和Python这些。除此之外，还有一些其它的领域语言也在支持 WebAssembly 平台。

支持 WebAssembly 的语言列表：https://github.com/appcypher/awesome-wasm-langs

5.1 JavaScript —— WebAssembly 替换的目标

JavaScript 开始其实是 WebAssembly 要替换的目标。但是随着 WasmEdge 等引擎支持 QuickJS 的解释器，JavaScript 逐渐变成了 WebAssembly 平台之上的最流行的编程语言。这里除了有 JavaScript 语言用户比较多的因素，同时 JavaScript 的单线程模型也非常契合 WebAssembly 的单线程模型。JavaScript 和 WebAssembly 无限套娃的事情真在切实发生，同时 JavaScript 也失去了浏览器中的霸主地位降级为普通公民。

5.2 AssemblyScript —— 为 WebAssembly 而生

AssemblyScript 是一个把 TypeScript 语法搬到 WebAssembly 的编译器。它目前是 WebAssembly 环境非常受欢迎的一个语言。AssemblyScript 只允许 TypeScript 的有限功能子集，因此不需要花太多时间就可以上手。同时它与 JavaScript 非常相似，所以 AssemblyScript 使 Web 开发人员可以轻松地将 WebAssembly 整合到他们的网站中，而不必使用完全不同的语言。

下面是一个 AssemblyScript 程序，和 TypeScript 几乎是一样的：

export function add(a: i32, b: i32): i32 {
  return a + b;
}

不过 AssemblyScript 只有 WebAssembly 支持的基本类型，而复杂的类型通过内置库实现。同时为了提供灵活的扩展能力，AssemblyScript 编译器提供了扩展能力。

AssemblyScript主页：https://www.assemblyscript.org/

5.3 C/C++ —— WebAssembly 为其而生

C/C++ 是 WebAssembly 该技术前身 Emscripten 诞生时的初始目标。Emscripten项目，尝试通过LLVM工具链将C/C++语言编写的程序转译为JavaScript代码，在此过程中创建了JavaScript子集asm.js，asm.js仅包含可以预判变量类型的数值运算，有效的避免了JavaScript弱类型变量语法带来的执行效能低下的顽疴。其中的核心魔法使 WebAssembly 和 C/C++ 采用相似的线性内存模型，提供为 JIT 提供了转化为相似代码的可能。

5.4 Rust 语言 —— 基于 LLVM 的输出 WebAssembly 能力

Rust 和 Emscripten 诞生于 Mozilla 公司，因此目前 WebAssembly 社区和 Rust 社区有着很大的重叠部分。很多 Rust 实现的 WebAssembly 虚拟机，同时 Rust 编译器借助 LLVM 的能力输出 WebAssembly 模块。可以说 Rust 技术的发展和抱住 WebAssembly 这个大腿有极大的关系。当然，因为 Rust 兼容 C/C++ 内存模型同时又无 GC 依赖，使得 Rust 可以构造出非常轻量高效的 WASM 模块。不过 Rust 本身的技术门槛也为初学者带来了极大的挑战。

5.5 Go 语言 —— 独立的 WebAssembly 后端

Go语言作为云计算等领域的主流语言，从Go1.11开始，WebAssembly开始作为一个标准平台被官方支持，这说明了Go语言官方团队也认可了WebAssembly平台的重要性和巨大潜力。目前Go语言社区已经有众多与WebAssembly相关的开源项目，比如有很多开源的WebAssembly虚拟机就是采用Go语言实现的。不过Go语言对WebAssembly被诟病的一个方面是官方生成的WASM文件不是wasi规范，同时因为GC等特性导致WASM体积比较大。

社区有个针对嵌入式环境等 TinyGo 变种，后端同样借助 LLVM 的能力输出 WebAssembly 模块。不过因为 LLVM 的依赖非常重，导致 TinyGo 的命令行将近 100MB、同时无法方便在浏览器环境使用。可以说 TinyGo 本身并不 Tiny，只是其目标平台是针对 Tiny 的单片机和 WASM 等平台。

5.6 凹语言 —— 为 WebAssembly 而生的国产语言

凹语言是为 WebAssembly 而设计的新语言，是国内 Gopher 发起的纯社区构建的开源国产编程语言项目。同时凹语言也是国内第一个实现纯浏览器内编译、执行全链路的自研静态类型的编译型通用编程语言。凹语言不仅仅点亮了 Arduino Nano 33 开发板，同时也通过实现了 BrainFuck 虚拟机证明了其图灵完备的能力，最近还验证了通过凹语言开发 Web 版本贪吃蛇的能力。

凹语言主页：https://wa-lang.org/

5.7 KCL —— 向 WebAssembly 迁移的领域语言

Kusion 配置语言（KCL）是由来自蚂蚁的徐鹏飞负责设计的、基于约束的记录及函数语言。作为领域语言，KCL 目前也是基于 LLVM 的能力输出 WebAssembly 模块。此外，KCL团队还在设计面向 Web3 领域的合约编程语言，也是天生就选择支持 WebAssembly 平台。

KCL 语言的主页：https://kcl-lang.io/

6. WASM的一些场景

6.1 Web 应用

随着 WebAssembly 的成熟，Web 应用不在是 JavaScript 的天下。比如之前就有国外大牛基于 WASM 技术将 Windows 2000 搬到了浏览器中。而像 AutoCAD 和谷歌地球这些重量级的应用均通过 WebAssembly 支持了浏览器。

当然，不仅仅是重量级的 Web 应用，随着 WASM 原生编程语言的成熟，可以预期会有更多的其他语言开发的 Web 应用。比如，下面是采用凹语言开发的贪吃蛇小游戏就是基于 WebAssembly：

贪吃蛇游戏在线地址：https://wa-lang.org/wa/snake/

6.2 Web3 和元宇宙应用

随着 Web3 和元宇宙概念的兴起，WebAssembly 也将作为其中的关键技术，甚至是基石技术。目前 Web3 相关的区块链行业有大量的技术基于 WebAssembly 构建，甚至专门定制 EWASM 技术标准。而元宇宙作为数字化和现实完全融合的新社会生态，其底层的软件系统更是非常依赖纯开源软件和平台无关的通用技术，因此作者推测GPL开源协议和 WebAssembly 技术将会是元宇宙的两大关键支柱。

6.3 Serverless 应用

Serverless 强依赖高度优化的冷启动，Wasm非常适合作为下一代无服务器平台运行时。SecondState、Cloudflare、Netlify和Vercel等公司都支持通过其边缘运行时部署WebAssembly功能。

下图是 AWS Lambda 中的 WebAssembly Serverless 函数工作原理：

具体细节可以参考这个文章：https://www.cncf.io/blog/2021/08/25/webassembly-serverless-functions-in-aws-lambda/

6.4 插件系统应用

得益于 WASM 的跨平台的特性，很多系统和框架在考虑通过 WASM 开发插件系统。比如基于 eBPF 和 Wasm 技术实现给 Linux 打动态的补丁。比如蚂蚁开源的MOSN（Modular Open Smart Network），是一款主要使用 Go 语言开发的云原生网络代理平台。MSON 就支持通过 WASM 插件来扩展其能力。下图是 MOSN 插件的工作原理图：

MOSN 插件的细节可参考：https://mosn.io/blog/posts/mosn-wasm-framework/

6.5 单片机应用

Wasm 不仅仅应用在浏览器、云计算等行业，在边缘计算等嵌入式领域也有应用场景。比如 wasm3 虚拟机就针对 arduino 提供的更精简的虚拟机，用户可以通过 wasm 技术为不同的单片机开发应用。

比如可以通过凹语言结合 wasm3-arduino 来开发 arduino 的例子，下图是本地模拟环境代码和执行效果图：

wasm3-arduino 仓库：https://github.com/wasm3/wasm3-arduino

7. WASM 教程推荐

WebAssembly 属于这个新生态的根技术、而目前正是处于根技术生态的构建阶段。因此，这类推荐的更多是偏向WebAssembly 规范、原理和实现的教程。我们希望当 WebAssembly 技术正在普及之后，用户可以通过流行的编程语言直接开发 WebAssembly 应用而不需要关系根技术的细节。

7.1 《WebAssembly 规范》—— 2022

WebAssembly 规范 1.0 草案在 2018 年发布，现在最新的 WebAssembly 2.0 在 2022 年发布。WebAssembly 规范是市面上所有该技术的实现和实践的参与源头。任何希望追根溯源、获取最前沿的 WebAssembly 发展方向的同学不仅仅推荐精读该规范，甚至还建议跟踪规范的讨论和诞生的过程。

该文档并非正式出版的图书，目前规范只有在线电子版，建议自行打印。

7.2 《WebAssembly 标准入门》—— 2018

本书是本文作者和前同事于 2018 年合著，主要讲解了WebAssembly的基础知识，其内容涵盖了WASM的历史背景、WASM中汇编语言和虚拟机指令、浏览器对WASM的支持、其它高级语言对WASM的支持等。

本书适合想要掌握WebAssembly技术、构建对应虚拟机工具、编程语言或希望了解底层细节的用户学习。

7.3 《WebAssembly: The Definitive Guide》—— 2021

这是 Oreilly 出版的相对较新的 WebAssembly 专著，不仅仅覆盖了规范本身同时结合了主流编程语言的案例。

目前国内还没有中文版本，大家可以阅读英文版本。

7.4 《WebAssembly原理与核心技术》—— 2021

这是国内虚拟机实现专家张秀宏写的一本讲述如何实现 WebAssembly 虚拟机的专著。它不仅对WebAssembly的工作原理、核心技术和规范进行了全面的剖析和解读，而且给出了实现WebAssembly解释器和AOT编译器的思路和代码。

对于希望尝试自己实现 WebAssembly 的同学建议阅读本书。

8. 2023年展望

对于 WebAssembly 来说，2022年是真正润物细无声开始落地的过程：从新的2.0标准到Ruby、Python两大主流脚本语言开始官方支持，从SQLite3开始官方支持、从Docker开始官方支持等，到为其而生的凹语言等，到真正的商业应用都有巨大的发展（而完全不是因为某个大佬的项目黄了就断言WASM要凉的节奏）。在商业应用上，Figma 基于WebAssembly打造在浏览器中的高性能应用，后被 Adobe 以 200亿美元收购，而Adobe也在项浏览器迁移。此外，WebAssembly 也是云厂商、边缘计算和Serverless 的候选人。

随着 WebAssembly 的普及，有一些相关技术流行趋势也日趋明朗化。作者做2个小小的趋势预测：首先是WasmEdge将成为浏览器外最流行的运行时；其次是JavaScript将成为WebAssembly平台上最流行的编程语言。不过这只是5年内的短期预测，更长的发展趋势还需要看 WebAssembly 生态其他的基础设施和编程语言发展状态。

尽管目前 WebAssembly 发展喜人，但百废待兴仍有许多工作要做。我们希望大家更多的是参与到 WebAssembly 建设中去，而不是仅仅作为围观者。作为凹语言作者我们希望在2023年真正解决语言的可用性和易用性的问题，让WebAssembly应用构建更加简单。WebAssembly 作为一个新兴的赛道，作为一个基础设施必将带来更大的生态洗牌，这是一个值得关注和投入的方向，让我们携手共建 WASM 原生时代。

SQLite3 官方支持 WebAssembly！

Mon, 31 Oct 2022 00:00:00 +0000

SQLite 官方的 wasm 项目终于来了！这表示 WebAssembly 在 SQLite 社区完全进入工业级应用阶段！

1. WASM 是什么

WebAssembly，又名 WASM，是一种标准，它定义了一种低级编程语言，适合 (A) 作为与许多其他语言交叉编译的目标，以及 (B) 通过浏览器中的虚拟机运行。它在设计时考虑了通过 JavaScript 编写脚本，它提供了一种将 C 代码（以及其他代码）编译为 WASM 并通过 JavaScript 编写脚本的方法，尽管 JavaScript 和 C 之间还存在巨大的编程模型差异，但它为不同语言和 JS 的交互带来了标准桥梁。

根据 Ending 定律：“所有可以用WebAssembly实现的终将会用WebAssembly实现”。SQLite 官方支持 WASM 只是再次证明和强化了定律有效性。实际上，在很早之前网上就有很多基于 LLVM 或 Emscripten 构建的 SQLite 库，它们最终可以被包装为 JS 库。

扩展阅读：WASM 作为 W3C 的第 4 个标准，已经在不同的领域取得巨大的进展。比如 Docker 发布集成 WebAssembly 的首个技术预览版。同时大量编程语言已经开始支持 WASM 平台（完整列表可参考 https://wasmlang.org/ ），国内的 Go+、凹语言、KCL 配置语言等都把对 WASM 的支持作为较高的优先级。关于 WASM 的更多信息可以关注《WebAssembly标准入门》。

2. SQLite 官方支持 WebAssembly

https://sqlite.org/wasm/doc/ckout/index.md

其实早在 2022 年 9 月，Google 的 Chrome 开发团队宣布与 SQLite 开发团队合作，并开发了 SQLite 的 WebAssembly 版本，作为替代的 Web SQL 数据库 API。WebAssembly 起源于 SQLite 开发团队的努力。

3. 在浏览器体验 SQLite

打开网址 https://sqlite.org/fiddle/

4. 项目的具体目标

根据官网介绍，主要有 4 个目标：

绑定一个低级的 sqlite3 API，在使用方面尽可能接近原生 API。
更高级别的面向对象风格 API，类似于 sql.js 和 node.js 样式的实现。
基于 Worker 的 API，以支持多线程环境更容易使用 SQLite 功能。
基于 Worker API 的 Promise 包装，对用户完全隐藏了跨线程通信方面复杂性

不在此列的特性：

WASM 作为 Web 标准，我们只认 UTF8 一种编码格式，UTF16 支持暂无计划
WASM 虽然不局限于 Web 环境，但是 WASM 版本的 SQLite 依然是聚焦 Web 环境的场景
WASM 只支持较新的特性，老旧特性将被乘机清除掉

简而言之，在提供底层 API 能力的同时，针对面向对象、多线程等环节提供简单易用的 API。

WebAssembly将引领下一代计算范式[翻译]

Sun, 23 Oct 2022 00:00:00 +0000

WebAssembly 是一种新兴的网页虚拟机标准，它的设计目标包括：高可移植性、高安全性、高效率（包括载入效率和运行效率）、尽可能小的程序体积。2018 年 WebAssembly 第一个规范草案诞生，2019 年成为 W3C 第四个标准语言。到了 2022 年底，WebAssembly 现在怎么样了…

作者：Anders Ranum, Justin Liu, David Carter
译者：柴树杉，凹语言作者，2本WASM图书作者，WASM布道者，目前在蚂蚁从事 KusionStack 和 KCL 开发。
时间：Thought Leadership / October 18, 2022
原文：https://sapphireventures.com/blog/whats-up-with-webassembly-computes-next-paradigm-shift/

WebAssembly（简称Wasm）是一个自诞生之日起就充满潜力的技术，从 “JavaScript杀手 “到 “云计算的下一个前沿方向”几乎覆盖了全部新兴领域。同时在从云计算项边缘计算渗透，Wasm已经远远超出了起作为第四种Web标准语言的角色。甚至重新定义了应用软件的开发模式，正逐渐接近其“一次编写，随处运行”的愿景。

在Wasm从诞生到现在的几年间，我们见证了从最开始的Wasm应用演示到为数十亿的头部技术产品提供基础设施支持。在同整个Wasm社区交谈过程中，我们也发现虽然很多人很看好Wasm未来发展前景，但是也存在争议和讨论。

不过在Sapphire，依然对围绕Wasm的快速发展和Wasm开始为更广泛的计算世界带来的新的可能性感到非常兴奋。在本文中我们将探讨什么是Wasm，为什么它很重要、今天它是如何被使用的、以及对这个生态系统的繁荣有什么期待。我们不会详细展开讨论Wasm的历史，但如果你对这些感到好奇可以看看Lin Clark 的精彩系列文章。

一、什么是Wasm？

WebAssembly正在沿着其名字中Web和Assembly两个领域之外的方向发展，因此这是一个极其有误导性的名字。

首先它不完全是汇编语言。Wasm是一种类似汇编字节码的指令格式标准，它更像LLVM-IR那种比汇编语言更高一些抽象的中间语言（比如其中函数的参数和返回值定义更像高级语言）。开发人员也不需要完全手写Wasm；相反人们一般选择使用其他高级语言（如C、C++、Rust、Go、凹语言等）将他们的代码编译为Wasm。
另外它不再只是Web网络。虽然Wasm最初被设计为Web浏览器的编译目标，但它的影响并没有停止。今天，使用与Wasm兼容的运行时，Wasm文件可以在客户端和服务器端执行，将使用范围扩大到浏览器之外——稍后将进一步探讨这些例子。

二、为什么Wasm很重要？

Wasm有几个关键的设计目标使其出生开始就自带令人亮眼的关注：

2.1 首先Wasm是可移植的

虽然Wasm最初是为Web设计的，而且今天所有主要的浏览器都提供对Wasm的支持。同时它也被设计为针对低级虚拟机架构，其指令由物理机单独翻译成机器代码。这意味着Wasm二进制文件最终可以在各种操作系统和芯片架构上运行——无论是在运行X86笔记本电脑的浏览器中，还是在内部或云端的服务器上，在移动设备、物联网设备上等等。

2.2 其次Wasm是多语言之下的一个标准

因为Wasm是一个编译目标，用于编程模块的具体语言并不重要，重要的是是否有支持将该语言编译到Wasm。开发人员可以灵活地使用多种语言（如C、C++、Rust、凹语言等）来构建二进制文件，并享受Wasm带来的复利。这意味着不需要考虑诸多组件和库链接等狗屁问题，只要他们都被编译到Wasm可以用于支持一个单一的应用。

2.3 最后Wasm是轻量和高效的

作为一个低级别的二进制指令格式，只需要较少的操作来将Wasm翻译成优化的机器代码。例如比如和Javascript进行比较（感兴趣的话可以参考 Lin Clark 的一些分析文章）。Javascript作为解释型语言，必须在运行时用即时编译（JIT）进行编译，并且必须经过获取/解析/编译/优化，最后才能执行和垃圾回收等步骤。

虽然JavaScript也可以被解析并转换为字节码，但Wasm已经是原生的字节码。另外Wasm也是静态类型的，这使得大多数优化在其初始编译时就已完成。最后JavaScript是动态类型的，需要在运行时进行优化和再优化，这共同导致了较难预测的性能。

这些优势也体现在浏览器之外，特别是Wasm模块的大小对于冷启动有极大的优势。目前，Serverless 的一个有问题是冷启动缓慢。虽然Serverless为开发者节省了管理后台基础设施和资源分配的时间，但如果该功能在冷态下被调用，就必须启动新的资源从而带来执行时间增加的额外成本。因为Wasm模块是非常轻量级的，和库调用类似方式使得启动时间可以大大减少（低至毫秒）。

2.4 Wasm是默认安全的

Wasm 目标之一是安全，它在一个沙盒环境中执行，对主机运行时没有初始可见性。这意味着对系统资源（如文件系统，硬件等）的访问是受限制的，除非明确导入了对应的函数以支持。因此Wasm极大限制了攻击面，实现了多租户环境中不受信任的代码安全受限地执行。这种安全模式是一个关键的促成因素，允许开发人员使用插件和用户提交的代码来扩展现有的应用程序，我们将在下面进一步探讨这一使用情况。

三、Wasm现在是如何使用的？

3.1 客户端使用案例

3.1.1 浏览器中的多语言支持

开发客户端的流行语言不多，大部分都是Javascript构建的。应用程序的语言在历史上是有限的，今天大多数现代网络应用程序是用Javascript构建的。而浏览器和前端框架对Wasm的支持已经开始打开闸门，使开发者更容易在浏览器中编译和执行其他流行语言。现在开发者可以选择在浏览器中直接运行C、C++、Rust、和Go等语言。此外，像Zig这样的新兴系统语言已经为Wasm增加了很好的支持。而其他专门从Wasm设计的语言也已经出现，包括AssemblyScript、Grain、Motoko和凹语言等。

3.1.2 高性能的网络应用

已经有一些公司使用Wasm来显著提高他们的网络应用程序的性能。例如，Figma（刚刚被Adobe以200亿美元收购），一个基于浏览器的协作界面设计工具，使用C++构建其渲染引擎，最初将其代码交叉编译到称为asm.js的Javascript子集。在之前因为面临Javascript固有的优化限制，在改用Wasm后Figma的加载时间快了3倍，无论正在加载的文档大小如何。

其他价值数十亿美元的公司也已经在产品采用了Wasm。比如Adobe的Photoshop、Autodesk的AutoCAD。重新利用现有的代码库，用Wasm将整个桌面应用移植到网络上已经是真实发生的事情。其他有趣的例子包括移植成熟的视频游戏和项目，如完全在浏览器中运行的Doom3和Angrybots，Unity明确地将其WebGL构建的编译目标转换为Wasm。

除了移植已有的应用，我们还看到一些公司利用Wasm建立新的功能，这些功能在以前会受到性能限制的制约。一些例子包括Runway，这是一个下一代内容创作套件，使用Wasm来支持其视频编解码器和媒体操作，以及StackBlitz，使用Wasm来支持纯Web的IDE开发环境，这比以前伪在线IDE外挂一个远程服务器拖油瓶的方式有着更好的安全性和性能优势。

3.1.3 浏览器内的数据库和分析

我们已经开始看到数据库的出现，它们利用Wasm的执行性能，使以前的服务器端分析工作负载更接近数据的存在。这里的例子包括DuckDB-Wasm，它使用Wasm为浏览器的中分析SQL数据库提供动力。以及SQL.js，它允许开发人员完全在浏览器中创建和查询SQLite数据库。

3.2 WASI：突破浏览器的桎梏

鉴于Wasm模块在默认情况下不能访问被明确授权的功能，纯WASM其实只能实现一些纯运算的功能。在上面的例子中，浏览器本身代表Wasm模块对系统资源的访问控制界面（例如，文件系统、I/O、时钟、全局变量等）。然而当我们在浏览器之外使用Wasm时需要什么呢？

在实践中，运行时实如何提供对系统资源的访问方面有很大的不同。这就是WebAssembly系统接口（WASI）出现的地方。WASI是W3C的一个项目，是一个供应商中立的、模块化的标准化API集合，正如其名称所示，它作为Wasm模块和操作系统之间的接口，促进与主机运行时的通信，并以一致的方式使用选定的系统资源。

当然，WASI是扩大Wasm可能的范围的关键促成因素之一，包括像下面即将提到的服务器端应用程序。

3.3 服务器端场景

虽然已经有很多例子证明了Wasm在客户端的优势和价值，但我们对Wasm在服务器端的想象空间更加兴奋。Wasm的每一个设计原则（速度、安全和可移植性）都能使下一波服务器端的工作负载成为可能。

3.3.1 Serverless计算

Serverless强依赖高度优化的冷启动，Wasm运行时（如WasmEdge）非常适合为下一代无服务器平台提供动力。SecondState、Cloudflare、Netlify和Vercel等公司都支持通过其边缘运行时部署WebAssembly功能。其他公司如Grafbase正在使用Wasm，使开发者能够在边缘用他们选择的语言编写和部署GraphQL解析器。同时，Fermyon提供了一个类似于FaaS的自助式开发平台，用Wasm合成和运行基于云的应用程序。

3.3.2 边缘的数据分析和机器学习

Wasm的效率和可移植性使其独特地适合于支持边缘的机器学习工作负载，部署在外形和计算能力差异很大的设备上。我们相信，实时ML用例将推动计算越来越接近数据产生的地方，无论是运行在网络边缘（如CDN）还是设备边缘（如IoT）。Wasi-nn（神经网络）是一个API规格，旨在将服务器端的Wasm程序与运行在主机上的流行ML框架（如Tensorflow、PyTorch、OpenVINO）连接起来。今天利用Wasm的ML场景的公司包括Edge Impulse和Hammer of the Gods，前者提供一个低代码开发平台，将TinyML模型设计和部署到Wasm模块中，在嵌入式设备上运行；后者使开发者能够创建超便携容器，通过其开源项目Rune，使用Rust和Wasm在边缘运行ML的工作负载。

3.3.3 插件和扩展

Wasm的多语言支持和沙盒隔离技术使其成为产品的有力的候选技术，产品开发者希望在现有的应用程序上提供一个可扩展的模型和执行第三方（可信或不可信）代码的能力。例如，Shopify在其Shopify Scripts框架背后使用了WebAssembly，为商家提供了以更有效的方式定制客户体验中对性能敏感的方面（如购物车、结账）的能力。 Suborbital提供了一个扩展引擎，使SaaS供应商能够安全、独立地运行 “终端用户开发者 “提供的代码。 Dynaboard使开发者能够在其低代码网络应用程序开发平台之上运行用户提供的代码，包括客户端和服务器端。

SingleStore和ScyllaDB已经开始利用Wasm，用用户定义的函数（UDF）引擎来扩展他们的数据库，允许开发人员重新使用现有的库，并将计算转移到数据库本身（例如，规避了将数据导出到另一个应用程序进行处理的限制）。

同时，RedPanda和Infinyon允许用户使用Wasm对流媒体数据进行实时内联转换。代理服务器领域也开始接受Wasm，Tetrate（Sapphire Portfolio公司）等服务网格供应商正在开发func-e等工具，以帮助团队快速构建Wasm模块，扩展开源的Envoy。

Profian是Enarx的监护人，这是一个开源项目，使用Wasmtime运行时间在可信执行环境（TEE）内执行Wasm二进制文件——这是Wasm的硬件可移植性的另一个场景。虽然Wasm的安全模型保护主机免受不受信任的代码影响，但Profian将这一好处翻转过来，在TEE内使用Wasm二进制文件，以保护应用程序免受不受信任的主机影响。这使企业能够将其敏感的应用程序和数据部署到云端或内部，并获得加密保证。

3.3.4 Web3应用开发和智能合约

Wasm天然适合以加密为中心的场景：首先Wasm的可移植性使运行不同硬件集的节点网络具有可靠性；其次Wasm的性能在这些网络中转化为更广泛的效率。

Ewasm是一个关键的例子，并被视为以太坊第二阶段升级的一个关键组成部分。Ewasm将取代以太坊虚拟机（EVM），EVM虚拟机目前为交易提供动力并维护以太坊的网络状态，但没有针对不同的硬件平台进行优化，因此效率不高。Ewasm（连同分片和转向股权证明）代表了改善整体网络性能，并提供了一个更具扩展性的底层，为希望建立去中心化应用程序的开发人员扩大了对Solidity以外的语言支持。

Wasm也被用来支持其他网络和可互操作区块链的计算。例如，Parity是Substrate的开发者，这是一个开源框架，使用Wasm作为Polkadot生态系统的骨干。同时，CosmWasm是一个为Cosmos生态系统建立的多链智能合约平台，运行Wasm字节码。 Fluence实验室提供Marine，这是一个通用的Wasm运行时，与他们的专用编程语言Aqua相结合，使分散的应用程序和协议能够在他们的点对点网络上运行。目前利用Wasm的其他协议包括NEAR、Dfinity、EOS等。

四、Wasm的应用和基础大图

我们已经列出了一些公司和组织，他们主要分为两类：一类是使用Wasm来支持他们自己的产品和平台；另一类是提供所需的基础工具和基础设施，使开发人员能够自己建立Wasm。

五、最后总结

5.1 Wasm的未来

虽然我们看到许多初创企业和科技巨头采用Wasm技术，但生态系统的一些关键技术只是在最近才逐渐发展起来。今天，Wasm带来增量效益往往被使用一个低级技术和一个不成熟的工具链所带来的额外成本所抵销。

我们认为在推动Wasm的未来应用中有四个方面是最重要的。

无缝的开发者体验。在最初阶段，开发人员在企业级利用Wasm所需的环境一直是比较复杂的。Wasm的开发者体验并不舒适（例如，调试Wasm仍然是众所周知的困难），在整个开发生命周期中，在编译到Wasm和以实际方式利用Wasm方面，有大量的空间可以提供更好的工具。同时大多数开发人员不具备低级语言和技术的专业知识，因此，通过抽象来提高可用性对促进更多的人的采用是非常重要的。我们已经开始看到第一波明确致力于为开发者配备这些工具的公司，包括Fermyon、Second State、Suborbital、Wasmer和Cosmonic。
标准的继续推进。虽然社区有一些分裂意见（例如，见AssemblyScript决定放弃对WASI的支持），但是Wasm标准的活力依然重要。除了蓬勃发展的创业生态系统，微软、亚马逊、谷歌、Fastly、Cloudflare、Mozilla等科技巨头也开始认识到Wasm是支持下一代云工作负载的有效底层，他们正在积极为标准机构和非营利组织（如W3C和字节码联盟）做出贡献，以推动这个社区的发展。CNCF也在发挥重要作用，接受wasmCloud和WasmEdge作为沙盒项目。仍有重要的工作要做；像文档，如垃圾收集、本地DOM访问、套接字、线程、组件模型等，都在激烈讨论中。标准的总体目标是使Wasm更适用于更多的目标，并适用于更多的使用案例。
编程语言支持。虽然Wasm最常被吹捧的好处之一是多语言支持，但目前支持的现实状态是介于两者之间。像C++、Go（包括TinyGo）和Rust这样的语言已经接受了Wasm，但一些最常见的语言，如Python、Java和PHP还在努力实现一等公民的地位。为了真正实现主流采用，Wasm的支持必须继续扩展到一些更复杂的语言，如C++和Rust，并向最广泛采用的语言扩展。对于那些有兴趣跟踪这方面进展的人来说，Fermyon团队已经做了一项伟大的工作，即跟踪Wasm在RedMonk的前20种编程语言中的支持情况。中国的Gopher创建的凹语言则将支持WASM作为第一目的，其语言命名正是Wasm图标基于中国汉字的变形。
理念、传播和社区。正如我们在容器和协调引擎（如Kubernetes）的案例中看到的那样，开发者对Wasm的采用可以通过布道者和更广泛的、成熟的倡导者社区来进一步推动。像云原生计算基金会（CNCF）和字节码联盟这样的组织已经走在了吸引开发者的前列，以促进对Wasm相关项目、活动和倡议的参与。除了开发者受众，其他利益相关者对Wasm的认识可以通过阐述二阶价值主张来推动，例如在云和Serverless环境中使用Wasm可能带来的成本节约。

5.2 Wasm会取代容器吗？

随着时间的推移，我们相信Wasm运行时将作为containerd、microVMs（Firecracker）和其他流行的容器结构的合法替代品 - 特别是随着WASI等标准的进一步扩展。这并不是说Wasm将全盘取代容器；在可预见的未来，它们将并肩存在，而利用每种容器的决定是由特定工作负载的特点所驱动的。

与传统的基于管理程序的虚拟机相比，Docker风格的容器提供了显著的改进，而Wasm已经能够将这些相同的效率提高到 “下一个水平”。凭借其亚毫秒级的冷启动，Wasm容器非常适合寿命较短的无服务器和边缘工作负载（除了现有的客户端用例之外）。同时，传统的Docker式工作负载非常适用于需要大量I/O或需要访问网络套接字的长期运行的服务（如缓存服务器）。

我们渴望看到像Kubernetes这样的协调引擎如何随着时间的推移与Wasm进行整合。尽管还很早，但像Krustlet（kubelet代理的替代品）、runwasi、Containerd Wasm Shims和crun的Wasm处理程序等项目和扩展都旨在将Wasm提升为容器环境中的一等公民，将其作为一个新的运行时类，可以由K8s进行相应的调度和管理。

5.3 谁会赢？

云厂商和Serverless是这里的明显候选人。但在Sapphire依然期望保持对Wasm生态每一个新兴技术保持近距离的关注依然。

随着任何新兴技术的出现，需要使其能够被主流采用。我们已经开始看到了许多真实的案例。然而，尽管今天正在推进的标准和正在开发的框架和运行时为实现Wasm的潜力奠定了基础，但百废待兴仍有许多工作要做。从以Wasm为中心的应用开发到开发人员生产力工具，到监控和安全解决方案，我们很高兴支持那些建立基础设施和工具的人，为每个人释放Wasm的优势，从个人开发者到全球企业。

如果你正在为Wasm生态系统做出贡献，或者正在使用Wasm为你的基础设施提供动力，请联系 anders@sapphireventures.com, liu@sapphireventures.com 或 carter@sapphireventures.com - 我们很乐意听到你的意见！

特别感谢Michael Yuan、Matt Butcher、Liam Randall、Connor Hicks和Alexander Gallego的宝贵观点和反馈。

《WebAssembly 标准入门》开始预售了，欢迎关注!

Fri, 07 Dec 2018 00:00:00 +0000

WebAssembly 是一种新兴的网页虚拟机标准，它的设计目标包括高可移植性、高安全性、高效率（包括载入效率和运行效率）、尽可能小的程序体积。本书详尽介绍了 WebAssembly 程序在 JavaScript 环境下的使用方法、WebAssembly 汇编语言和二进制格式，给出了大量简单易懂的示例，同时以 C/C++和 Go 语言开发环境为例，介绍了如何使用其他高级语言开发 WebAssembly 模块。

序

某一天，有朋友向我推荐了一项新技术——WebAssembly。我认为这是一项值得关注的技术。

说WebAssembly是一门编程语言，但它更像一个编译器。实际上它是一个虚拟机，包含了一门低级汇编语言和对应的虚拟机体系结构，而WebAssembly这个名字从字面理解就说明了一切——Web的汇编语言。它的优点是文件小、加载快、执行效率非常高，可以实现更复杂的逻辑。

其实，我觉得出现这样的技术并不令人意外，而只是顺应了潮流，App的封闭系统必然会被新一代Web OS取代。但现有的Web开发技术，如JavaScript，前端执行效率和解决各种复杂问题的能力还不足，而WebAssembly的编译执行功能恰恰能弥补这些不足。WebAssembly标准是在谋智（Mozilla）、谷歌（Google）、微软（Microsoft）、苹果（Apple）等各大厂商的大力推进下诞生的，目前包括Chrome、Firefox、Safari、Opera、Edge在内的大部分主流浏览器均已支持WebAssembly。这使得WebAssembly前景非常好。

WebAssembly是Web前端技术，具有很强的可移植性，技术的潜在受益者不局限于传统的前端开发人员，随着技术的推进，越来越多的其他语言的开发者也将从中受益。如果开发者愿意，他们可以使用C/C++、Go、Rust、Kotlin、C#等开发语言来写代码，然后编译为WebAssembly，并在Web上执行，这是不是很酷？它能让我们很容易将用其他编程语言编写的程序移植到Web上，对于企业级应用和工业级应用都是巨大利好。

WebAssembly的应用场景也相当丰富，如Google Earth，2017年10月Google Earth开始在Firefox上运行，其中的关键就是使用了WebAssembly；再如网页游戏，WebAssembly能让HTML5游戏引擎速度大幅提高，国内一家公司使用WebAssembly后引擎效率提高了300%。

WebAssembly作为一种新兴的技术，为开发者提供了一种崭新的思路和工作方式，未来是很有可能大放光彩的，不过目前其相关的资料和社区还不够丰富，尽管已经有一些社区开始出现了相关技术文章，CSDN上也有较多的文章，但像本书这样全面系统地介绍WebAssembly技术的还不多，甚至没有。本书的两位作者都是有10多年经验的一线开发者，他们从WebAssembly概念诞生之初就开始密切关注该技术的发展，其中柴树杉是Emscripten（WebAssembly的技术前身之一）的首批实践者，丁尔男是国内首批工程化使用WebAssembly的开发者。

2018年7月，WebAssembly社区工作组发布了WebAssembly 1.0标准。现在，我在第一时间就向国内开发者介绍和推荐本书，是希望开发者能迅速地了解和学习新技术，探索新技术的价值。

——蒋涛 CSDN创始人、总裁，极客帮创始合伙人

Go中的wasm汇编语言

Wed, 03 Oct 2018 00:00:00 +0000

Go1.11已经正式发布，最大的一个亮点是增加了对WebAssembly的实验性支持。对于Go汇编语言爱好者来说，WebAssembly平台是一个新的挑战。本文尝试从最简单的memclr函数入手，简要了解WebAssembly汇编语言。

runtime·memclrNoHeapPointers 函数

改函数源文件在：

https://github.com/golang/go/blob/master/src/runtime/memclr_wasm.s

函数的实现如下：

// func memclrNoHeapPointers(ptr unsafe.Pointer, n uintptr)
TEXT runtime·memclrNoHeapPointers(SB), NOSPLIT, $0-16
	MOVD ptr+0(FP), R0
	MOVD n+8(FP), R1

loop:
	Loop
		Get R1
		I64Eqz
		If
			RET
		End

		Get R0
		I32WrapI64
		I64Const $0
		I64Store8 $0

		Get R0
		I64Const $1
		I64Add
		Set R0

		Get R1
		I64Const $1
		I64Sub
		Set R1

		Br loop
	End
	UNDEF

函数签名

函数的签名如下：

func memclrNoHeapPointers(ptr unsafe.Pointer, n uintptr)

对应C语言的签名如下：

void memclrNoHeapPointers(int32_t ptr, int32_t n);

对应WebAssembly的函数签名如下：

(func $memclrNoHeapPointers (param $ptr i32) (param $n i32)
	...
)

读取函数参数

因为Go语言是动态栈，和WebAssembly的内存模型并不一样。我们先忽略这些问题的细节，看看如何读取参数的：

	MOVD ptr+0(FP), R0
	MOVD n+8(FP), R1

熟悉Go汇编语言的同学肯定很容易理解上述代码。其中第一行指令是将Go函数的第一个参数加载到R0寄存器，第二行指令是将第二个参数加载到R1寄存器。FP是伪寄存器，表示当前函数调用的帧寄存器，每个参数分别使用参数名作为前缀+参数相对于FP的地址偏移量确定。

不过WebAssembly是基于栈式的虚拟机结构，并不存在寄存器的概念。不过我们可以将R0和R1看作是函数的局部变量。因此在memclrNoHeapPointers函数的定义中再增加2个局部变量：

(func $memclrNoHeapPointers (param $ptr i32) (param $n i32)
	(local i32) (local f32) ;; R0 R1 寄存器
	...
)

WebAssembly汇编语言

现在将函数的主体指令改为WebAssembly汇编语言，大概是如下的写法：

(func $memclrNoHeapPointers (param $ptr i32) (param $n i32)
	(local i32) (local f32) ;; R0 R1 寄存器

loop:
	Loop
		Get R1
		I64Eqz
		If
			RET
		End

		Get R0
		I32WrapI64
		I64Const $0
		I64Store8 $0

		Get R0
		I64Const $1
		I64Add
		Set R0

		Get R1
		I64Const $1
		I64Sub
		Set R1

		Br loop
	End
	UNDEF
)

具体的算法类似以下的Go语言代码：

func memclrNoHeapPointers(ptr, n int32) {
	R0 := ptr
	R1 := n

	loop: for {
		if R1 == 0 {
			return
		}

		Memort[R0] = 0
		R0++
		R1--

		continue loop
	}
}

在循环中，第一组指令是R1表示的未清0的元素个数是否未0，如果未0则返回。对应代码如下：

		Get R1
		I64Eqz
		If
			RET
		End

其中Get对应WebAssembly的get_local指令，用于根据局部变量的索引标号获取一个值，放到栈中。I64Eqz对应i64.eqz指令，从栈中取出一个值，判断是否为0，并将结果从新放入栈中。而If则对应br_if控制流指令，首先从栈取出一个值，如果非0则执行分支内的指令。RET返回函数，和WebAssembly的return指令不一定完全等价。

第二组指令是强R0表示的内存地址对应的空间清0：

		Get R0
		I32WrapI64
		I64Const $0
		I64Store8 $0

Get对应get_local指令，取出一个i64类型的值。I32WrapI64对应i32.wrap/i64指令，将i64类型强制转型为i32类型，重新入栈。I64Const则是生成一个常数0，入栈。I64Store8对应i32.store8指令，从栈取出内存地址，第二个参数是0表示地址采用默认的对其方式。简而言之就是将R0对应的地址设置为0。

第三组是将R0加一后存回R0局部变量：

		Get R0
		I64Const $1
		I64Add
		Set R0

第四组是将R1减一后存回R1局部变量：

		Get R1
		I64Const $1
		I64Sub
		Set R1

循环内的最后一个Br loop指令是继续从loop标号开始的循环。

函数最后的UNDEF并不是WebAssembly汇编指令。

总结

因为Go语言序言支持栈的分裂，Go语言对WebAssembly的汇编语言是一个变异的版本。Go语言使用局部或者是全局变量来模拟寄存器，在函数的内部在依然基于WebAssembly栈虚拟机的方式工作。

因为WebAssembly也是刚刚支持的平台，很多技术细节还需要进一步确认。想深入了解WebAssembly汇编语言的同学，本人写的《Go语言高级编程》和《WebAssembly标准入门》中的汇编语言章节部分的内容。

《C++面向wasm编程》开源！[转]

Tue, 25 Sep 2018 00:00:00 +0000

目前支持WebAssembly的各种高级语言中，与WebAssembly匹配度最高的无疑是C/C++，为此，我们将开源编写《C++面向wasm编程》一书。本书将围绕“如何开发对WebAssembly友好的C/C++程序”这一中心，从Emscripten工具链的使用、C/C++与JavaScript互操作、一般性的设计原则等多方面介绍相关知识，并分享作者在实际工程应用中总结出的诸多经验。

原文：https://mp.weixin.qq.com/s/o4NIuc67eV3U_FGODT0ufA

第0章 WebAssembly简介
第1章 Emscripten快速入门
- 1.1 安装Emscripten
- 1.2 你好，世界！
- 1.3 胶水代码初探
- 1.4 编译目标及编译流程
第2章 C与JavaScript互操作
- 2.1 JavaScript调用C函数
- 2.2 JavaScript函数注入C
- 2.3 单向透明的内存模型
- 2.4 JavaScript与C交换数据
- 2.5 EM_ASM宏
- 2.6 emscripten_run_script函数
第3章 Emscripten运行时
- 3.1 main函数与生命周期
- 3.2 消息循环
- 3.3 文件系统
- 3.4 内存管理
- 3.5 Module定制
第4章 WebAssembly友好的一般性方法
- 4.1 消息循环分离
- 4.2 数据对齐
- 4.3 使用C接口导出C++对象
- 4.4 C++对象生命周期控制
- 4.5 使用C接口注入JavaScript对象
- 4.6 小心int64
- 4.7 忘掉文件系统
第5章网络IO
- 5.1 websocket
- 5.2 ajax
- 5.3 fetch
- 5.4 一个通用的网络IO小框架
第6章多线程
- 6.1 JavaScript中的多线模型
- 6.2 一个例子
- 6.3 一个通用的多线程小框架
第7章 GUI及交互
- 7.1 canvas
- 7.2 鼠标事件
- 7.3 键盘事件
- 7.4 触屏事件
第8章工程管理
- 8.1 使用Makefile
- 8.2 静态库

项目地址：

https://github.com/3dgen/cppwasm-book

欢迎围观。加星可以鼓励作者尽快更新哦！

Ending定律即将生效!

Sun, 16 Sep 2018 00:00:00 +0000

WebAssembly草案1.0终于在2018年7月正式诞生，Ending定律即将生效！

Ending’s law: “Any application that can be compiled to WebAssembly, will be compiled to WebAssembly eventually.”

Ending定律也称为终结者定律，它是Ending在2016年Emscripten技术交流会上给出的断言：所有可以用WebAssembly实现的终将会用WebAssembly实现。

在2018年7月，WebAssembly的第一份标准草案终于诞生，一切准备就绪。终于到了Ending定律生效的时刻了！

WebAssembly也叫wasm，是最新的Web汇编语言标准，同时涵盖了一个虚拟机标准，可以用于浏览器或者其它嵌入式环境。WebAssembly被刻意设计为便携式的抽象语法树结构，用于提供比JavaScript更快速的编译和运行。2018年，Firefox、Chrome、Microsoft Edge、Safari等主流的浏览器已经充分支持WebAssembly特性。

我们知道在JavaScript领域有个木头定律，但是木头定律不适用于WebAssembly！因为WebAssembly是为了性能而诞生，再用JavaScript模拟的WebAssembly性能将是一坨屎，没有任何价值！但是WebAssembly之上却很有可能再跑一个v8引擎。

Ending定律的威力不仅仅在语言层面。WebAssembly是第一个虚拟机世界标准，以后将人手至少一个wasm虚拟机。曾被大家鄙视的JavaScript语言大举入侵各个领域的情况将再次重演，Lua、Java、Python等语言首当其冲，它们的虚拟机统统将面临被WebAssembly蚕食的境况！

星辰大海的入口已经打开，let’s dive!

Go1.11和WebAssembly

Sat, 25 Aug 2018 00:00:00 +0000

Go1.11已经正式发布，最大的一个亮点是增加了对WebAssembly的实验性支持。这也再一次验证了Ending定律的预言：所有可以编译到WebAssembly平台的软件终将会被编译到WebAssembly平台。

在上一周，qemu的作者bellard大神将Windows 2000搬到浏览器到新闻彻底引爆了WebAssembly技术，这也证明了WebAssembly的强大的性能优势。

感兴趣的同学可以查看bellard大神到网站，网站提供了在浏览器Linux和Windows等多种系统等运行链接：https://bellard.org/jslinux/

不过本文我们将重点和大家分享如何在Go语言中使用WebAssembly。先安装好Go1.11+版本的Go语言环境。然后创建hello.go文件：

package main

import "fmt"

func main() {
	fmt.Println("你好，WebAssembly！")
}

为了不了解Go语言的同学便于理解，让我们简单介绍一下程序。第一句表示当前的包名字为main，同时包中有一个main函数，而main包的main函数就是Go语言程序的入口。在main函数中通过导入的fmt包内的Println方法输出了一个字符串。然后在命令行中直接输入go run hello.go来运行程序。如果一切正常的话。应该可以在命令行看到输出”你好，WebAssembly！”的结果。

Go1.11开始支持WebAssembly，对应的操作系统名为js，对应的CPU类型为wasm。目前还无法通过go run的方式直接运行输出的wasm文件，因此我们需要通过go build的方式生成wasm目标文件，然后通过Node环境执行。需要注意的是更新的Node版本对wasm的支持会更好，作者推进使用v10以上的版本。

通过以下命令将hello.go编译为a.out.wasm：

$ GOARCH=wasm GOOS=js go build -o a.out.wasm hello.go

生成的a.out.wasm文件体积可能超过2MB大小。而且生成等a.out.wasm还无法直接运行，需要初始化Go语言必须的运行时环境。

对运行时初始化是一个相对复杂的工作，因此Go语言提供了一个$(GOROOT)/misc/wasm/wasm_exec.js文件用于初始化和运行的工作。同时提供了一个基于node包装的$(GOROOT)/misc/wasm/go_js_wasm_exec脚本文件，用于执行Go语言生成的wasm文件。

参考go_js_wasm_exec脚本的实现，我们可以直接使用wasm_exec.js来运行wasm模块。我们可以先将wasm_exec.js文件复制到当前目录，然后通过以下命令运行wasm模块：

$ node wasm_exec.js a.out.wasm
你好，WebAssembly

现在终于可以正常运行Go语言生成wasm程序了。因此以后可以使用Go语言来开发Web应用了。

如果对WebAssembly技术感兴趣，可以关注Github上的WebAssembly(wasm)资源精选项目：

https://github.com/chai2010/awesome-wasm-zh