rdunnington / bytebox Goto Github PK

Currently the order of args is: bytebox <FILE> [WASM_ARGS]... [OPTION].... However, wasmtime (and other runtimes) put their option args before the wasm file like so: wasmtime [OPTION]... <FILE> [WASM_ARGS].... Bytebox should match this ordering to make it easier to run as a drop-in replacement, or at the very least to make it easier to compare runtimes.

To do this, in the file run/main.zig, parseCmdOpts() will need to be updated to account for the reordering.

By convention, init() never returns errors and just initializes the struct. We should follow this convention.

The current implementation of the wasi functions are not threadsafe, as wasi file descriptors are backed by an internal data structure that isn't threadsafe, nor wrapped by any locks. This is fine for simple programs, but more complex programs that embed bytebox may invoke wasm functions from different threads. Ideally the solution will also allow compiling thread safety out if it isn't needed to avoid the overhead in single-threaded environments.

Stack-based VMs have inherent performance limitations that are not present in register-based VMs. To reach or surpass performance of other WASM VMs, bytebox will need to implement a register-based VM. To do this, we will need to:

1. Translate WASM bytecode into a sea-of-nodes IR format.
2. Run optimization passes eliding unnecessary loads/stores as there will be many of these coming from the stack-based VM.
3. Lower the IR to a register-based bytecode.
4. Write a new VM capable of interpreting the new bytecode format.
   This approach will optionally allow implementation of a secondary pipeline that can JIT the IR to native asm in the future.

A quickly-hacked together powershell script is doing the work here, but only works on windows. A zig program would be portable and could call out to either a checked-in binary or require WABT on the system if one doesn't exist for the OS.

Depends on #2 to avoid writing shell script for each platform.

this would allow applications that require this mode to be ported to wasm, such as htop, MC, alsamixer and others (in fact, 95% of the software uses ncurses doing it).
(i found this in c. termios.h functions: tcsetattr tcgetattr)

wasm3 allows you to supply a wasm file and invoke a specific function, supplying it with parameteres like so:
wasm3 [options] <file> [args...]
The run exe should do the same, and utilities should be provided to autoconvert string parameters into the proper Val types the wasm function expects, if possible.

To allow for easier integration with other projects, bytebox should provide a C wrapper around the public API. Ideally this is tested with an actual integration in another project, such as wasm4.

• Official spec seems to be here: https://github.com/WebAssembly/memory64
• Needed to support Orca's desired memory model

As of this writing, wasi-testsuite does not have full coverage of the functions in preview1, and as a result the untested functions have not been implemented. To reach parity with other runtimes, bytebox still needs to implement:

• fd_datasync
• fd_sync
• path_link
• path_readlink
• path_rename
• poll_oneoff
• sched_yield
• sock_accept
• sock_recv
• sock_send
• sock_shutdown

The current testsuite mirror is using an old version, it should be updated since the newer suite has some extra test cases and fixes for bugs in the tests.

Currently zig build test runs the wasm test suite, and you have to manually invoke zig test to run unit tests. Running wasi tests is even more of a pain where you have to manually run a python command. Ideally we have a uniform interface for running all the tests from zig build:

• zig build test: runs everything
• zig build test-unit: only unit tests
• zig build test-wasm: only wasm test suite
• zig build test-wasi: only wasi test suite

zig build test-cffi should build a C file that loads a wasm file and invokes a function in it, link it with bytebox.lib, and run the exe, expecting no errors. This will ensure the FFI code paths remain exercised in CI.

Currently the wasi_rights arg is essentially ignored for most wasi calls. To be compliant with the spec, the bytebox wasi runtime should return NOTCAPABLE when functions are called for file descriptors that don't have the particular rights. Special attention should be given to preopen rights and inheriting rights.