does the host provide? (what can be imported?) • What functions should the module expose? (what should be exported?) • WASM modules are sandboxed ◦ do not have access to stdout ◦ nothing runs until called upon • Commonly used ◦ Emscripten (POSIX-like) => wasm32-unknown-emscripten ◦ WASI (WebAssembly System Interface, capability based) => wasm32-wasi ▪ Officially supported since Rust 1.36
WASM runtime • We can write our own Rust program that will run WASM code fn main() -> error::Result<()> { let wasm_bytes = include_bytes!("my-module.wasm"); let import_object = imports! {}; let instance = instantiate(wasm_bytes, &import_object)?; instance.call("my_function", &[])?; Ok(()) }
Compiling wasmer-test v0.1.0 (/code/wasmer-test) Finished dev [unoptimized + debuginfo] target(s) in 2.60s Running `target/debug/wasmer-test` environ_sizes_get fd_prestat_get wasi_fd_write fd=1 byte_len=11 bytes= hello world • It’s printing to stdout via a call into a host-provided fd_write() function • WASI syscalls allow modules to access restricted resources
• Via a JavaScript interpreter compiled to WASM • Running on top of the V8 engine • https://webassembly.sh/?run-command=quickjs Let’s take a look at QuickJS on webassembly.sh
stable • Rust has full WASI support built into the toolchain • The inner workings of WASM/WASI are quite simple • Rust x WASI has many interesting cross-platform use cases @TaigaMerlin