The wasm architecture currently uses a special CallImport assembler instruction to call function imports. This approach is quite inflexible and only compatible with the ABI used by wasm_exec.js.
The WebAssembly ecosystem is converging on using WASI (WebAssembly System Interface) as a standardized interface between the WebAssembly binary and its host (similar to system calls). I am working on adding support for WASI to Go. As a first step, Go needs to be able to use function imports with the ABI used by WASI.
For this reason I propose to replace CallImport with a new compiler directive go:wasmimport. It can be used like this:
By default go:wasmimport will use the ABI used by WASI. An optional parameter can be used for backwards compatibility with wasm_exec.js. This parameter is called abi0 because wasm_exec.js is reading the parameters form memory with Go's normal ABI0 layout:
//go:wasmimport wasmExit go runtime.wasmExit abi0
func wasmExit(code int32)
I do not plan to add other ABIs. On the contrary, the abi0 mode is supposed to go away once WASI can be used as the primary interface (it is still missing certain features).
The go:wasmimport directive will not be covered by Go's compatibility promise as long as the wasm architecture itself is not considered stable.
The wasm architecture currently uses a special
CallImportassembler instruction to call function imports. This approach is quite inflexible and only compatible with the ABI used by wasm_exec.js.The WebAssembly ecosystem is converging on using WASI (WebAssembly System Interface) as a standardized interface between the WebAssembly binary and its host (similar to system calls). I am working on adding support for WASI to Go. As a first step, Go needs to be able to use function imports with the ABI used by WASI.
For this reason I propose to replace
CallImportwith a new compiler directivego:wasmimport. It can be used like this:By default
go:wasmimportwill use the ABI used by WASI. An optional parameter can be used for backwards compatibility withwasm_exec.js. This parameter is calledabi0becausewasm_exec.jsis reading the parameters form memory with Go's normal ABI0 layout:I do not plan to add other ABIs. On the contrary, the
abi0mode is supposed to go away once WASI can be used as the primary interface (it is still missing certain features).The
go:wasmimportdirective will not be covered by Go's compatibility promise as long as the wasm architecture itself is not considered stable.