minivm

> I developed a unique way to write interpreters based on threaded code jumps and basic block versioning when I made MiniVM (https://github.com/FastVM/minivm). It was both larger and more dynamic than WebAssembly. I'd be very interested to read more about this. It looks like you are using "one big function" with computed goto (https://github.com/FastVM/Web49/blob/main/src/interp/interp....). My experience working on this problem led me to the same conclusion as Mike Pall, which is that compilers do not do well with this pattern (particularly when it comes to register allocation): http://lua-users.org/lists/lua-l/2011-02/msg00742.html I'm curious how you worked around the problem of poor register allocation in the compiler. I've come to the conclusion that tail calls are the best solution to this problem: https://blog.reverberate.org/20

I made Web49 because there are not many good tools for WebAssembly out there. WABT is close, but the interpreter is too slow and the tools megabytes in size each. Wasm3 is a bit faster but only contains an interpreter, nothing else. Tooling for WebAssembly is held mostly by the browser vendors. It is such a nice format to work with when one removes all the fluff. WebAssembly tooling should not take seconds to do what should take milliseconds, and it should be able to be used as a library, not just a command line program. I developed a unique way to write interpreters based on threaded code jumps and basic block versioning when I made MiniVM (https://github.com/FastVM/minivm). It was both larger and more dynamic than WebAssembly. Web49 started as a way to compile WebAssembly to MiniVM, but soon pivoted into its own Interpreter and tooling.

Maybe take a look at MiniVM[0]? It was on HN a couple months ago[1], and has gotten a lot better since then (e.g. JIT). [0]: https://github.com/fastvm/minivm [1]: https://news.ycombinator.com/item?id=29850562

Strings appear to be represented as arrays with elements which are 4 bytes in size, with 30 numeric bits for each character: https://github.com/FastVM/minivm/blob/4906256b2dc16e227cad7e... https://github.com/FastVM/minivm/blob/4906256b2dc16e227cad7e...

The disclaimer at the top of the benchmark section - https://github.com/FastVM/minivm#benchmarks - seemed pretty reasonable to me. It's very clear that microbenchmarks don't tell the whole story, and that whole application benchmarks to give more real results will be desirable later. I mean, I agree these benchmarks don't mean that much except for being a useful way to verify that the core code is working and reasonably performant - but they're up front about that fact so calling it 'benchmark-gaming' seems a trifle unfair.