This should make debugging and profiling much better, at little to no
runtime cost.
Also moves off the operator definitions to a separate header, so it
should also improve the editing experience quite a bit.
* wasm: Don't try to print the function results if it traps
* LibWasm: Inline some very hot functions
These are mostly pretty small functions too, and they were about ~10%
of runtime.
* LibWasm+Everywhere: Make the instruction count limit configurable
...and enable it for LibWeb and test-wasm.
Note that `wasm` will not be limited by this.
* LibWasm: Remove a useless use of ScopeGuard
There are no multiple exit paths in that function, so we can just put
the ending logic right at the end of the function instead.
This allows multiply different kinds of interpreters to be used by the
runtime; currently a BytecodeInterpreter and a
DebuggerBytecodeInterpreter is provided.
This should make it easier to implement multiple types of interpreters
on top of a configuration, and also give a small speed boost in not
initialising as many Stack objects.
Doing that was causing a lot of malloc/free traffic, but since there's
no need to have a stable pointer to them, we can just store them by
value.
This makes execution significantly faster :^)
As the parser now flattens out the instructions and inserts synthetic
nesting/structured instructions where needed, we can treat the whole
thing as a simple parsed bytecode stream.
This currently knows how to execute the following instructions:
- unreachable
- nop
- local.get
- local.set
- {i,f}{32,64}.const
- block
- loop
- if/else
- branch / branch_if
- i32_add
- i32_and/or/xor
- i32_ne
This also extends the 'wasm' utility to optionally execute the first
function in the module with optionally user-supplied arguments.
This adds very basic support for module instantiation/allocation, as
well as a stub for an interpreter (and executions APIs).
The 'wasm' utility is further expanded to instantiate, and attempt
executing the first non-imported function in the module.
Note that as the execution is a stub, the expected result is a zero.
Regardless, this will allow future commits to implement the JS
WebAssembly API. :^)
