如果看過官網的文件,會發現目前釋出的WebAssembly版本,被稱作MVP版本,也就是「最小可實行」的版本。這個版本的目的是提出一個可運作的版本,讓開發者可以先使用,未來再根據真正的需求來擴充他的規格。
其實在研究WebAssembly的功能跟語法時就有發現,有些功能是在語法上可能,但是尚未支援的。例如Linear Memory,在WebAssembly中宣告時,可以加上Identifier:
(memory $mem1 (import "js" "buf1") 1 10)
可以加上$mem1
這個identifier,表示應該可以透過不同的identifier來參考到不同的Memory,也就是說在程式內應該可以有不只一個的Linear Memory可以使用。例如,想用三個Memory來當作stdin/stdout/stderr:
(module
(memory $input (import "js" "buf") 1)
(memory $output (export "output") 1)
(memory $error (export "error") 1)
)
其實在Memory區段的語法上是合法的,但是用wabt編譯時會說:
test018.wat:3:3: error: only one memory block allowed
(memory $output (export "output") 1)
^^^^^^
另外一個例子是Table。目前只能放anyfunc
這一種元素,然後用call_indirect
來呼叫索引所參考到的函數。但是文件中也有提到,未來可能會加入更多種元素類型。例如可能把物件的參考透過Table傳進來等等。
不過即使是目前功能有一些限制的MVP版本,也已經可以有相當多的應用。有許多是透過Emscripten把現有的一些以C/C++的程式轉成WebAssembly來跑...例如現在很紅(或是很讓人厭惡)的CoinHive,他運算的部份就是在Worker中跑WebAssembly或ASM.js。把東西嵌入到網站以後,上這個網站時,瀏覽器就會幫這個網站挖礦。(核心的運算部份,是從C寫的程式透過Emscripten轉成ASM.js或是WebAssembly來跑。他會偵測瀏覽器可以支援功能,來看是要跑哪個)因為是在Worker跑,所以瀏覽網頁並不會卡,但是CPU會拉高,因為有Worker在背景做運算。
在WebAssembly官網的WebAssembly High-Level Goals文件中,有提到除了目前已經實現的MVP版本,後續還會專注在幾個新的功能:
執行緒的部份,看起來會以SharedArrayBuffer為中心,實做出執行緒共享的記憶體以及Atomic的操作。
ECMA已經把SIMD打回票(因為太複雜),不過看起來WebAssembly有打算要支援。所以未來可能會加入新的SIMD型別及指令。我猜使用起來會有點像:https://developer.mozilla.org/en-US/docs/Web/JavaScript/SIMD_types ,可以同時計算幾個同型別的資料。
在WebAssembly官網的Features to add after the MVP文件中,有討論許多未來可能擴充的方向。不過真的有點多,而且有很多只是「討論」,我就不一一舉出來了。
比較有方向的大概是在Tracking Issues列出來的:
這裡面大部分在高階目標已經有提出。Bulk memory operation主要是增加一些記憶體操作的指令,例如move_memory等。高階目標已經有提到Same Origin Policy,這裡更進一步把規則整合到Web Content Security Policy。至於ECMAScript module的整合,看起來是希望可以直接透過script標籤、Worker建構函數以及在Worker中透過importScripts函數的方式載入WebAssembly,並且把import/export語法在Javascript端及WebAssembly端整合。
大致上回顧了一下文件,把目前WebAssembly規格的發展狀況整理一下。明天,先來看一下怎麼在node.js裡面使用WebAssembly。