wasm web/wasi target

[giann]

Probable issues:

• Disable mimalloc
• Expose JS regex in place of libpcre
• Disable JIT and FFI
• VM tail call not supported: the VM does not uses a big switch to dispatch opcode but tailcalls, this does not seem to be supported by llvm_stage2 for the wasm64-wasi target
• We can keep 64bit NaN boxing but it might have a performance impact
• We can't use dynamic library loading but we don't really need it: statically link std libs and import does only buzz definition importing
• Disable os specific std libs: fs, io, os, ffi

Resources:

• https://dev.to/sleibrock/webassembly-with-zig-part-1-4onm
• Example of exposing js function to wasm module
• Bring your own os: zig, js
• https://github.com/mitchellh/zig-js

[judah-caruso]

Are there any plans for compiling buzz to wasm directly? Assuming this ticket is to just allow the buzz interpreter to run within wasm?

[giann]

Not sure what you mean? buzz can only run within wasm if built for wasm.

[judah-caruso]

Ah sorry, I meant creating something like a new RunFlavor that compiles buzz to wasm (similar to assemblyscript).

For example:

// main.buzz
import "std";

fun main([str] _) > void {
	print("hello, world");
}

$ buzz -target=wasi_wasm32 -out=main.wasm main.buzz
$ wasmer main.wasm # hello world

This is most likely out of scope for the project, but I was just curious if this is a plan for the future.

[giann]

Yes this is out of scope. That would require buzz to become an AOT compiled language.

[giann]

Reopening because of https://ziglang.org/download/0.12.0/release-notes.html#Bring-Your-Own-OS-API-Layer-Regressed which effectively kills this feature