4984
Joined 4 years ago
Karma
125
Submissions
10
Member since
Jan 8
Recent submissions
Comment · 3 years ago
Comment · 3 years ago
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. I could not be happier with it in its current form and am excited to see what else It can do, with more work.
Comment · 3 years ago
The interview in question, for those interested:
https://odin-lang.org/news/newsletter-2022-12/#interview-wit...
Comment · 4 years ago
I have looked into Meta Machines. They are not what I want.
Meta Machines can be almost as fast, but i just prefer the cache locality of local functions.
Wasm3 is slower than MiniVM when you don't count the GC. Wasm3 is very cool!
Comment · 4 years ago
There is no roadmap. There are no written long term goals. This project came out of need for a faster virtual machine for my Paka language. There is an api to emit vm bytecode, but it's not in C, it is from Paka.
Roadmap could go like this tho: More Core Opcodes (Bit Ops, Closures), Split overloaded opcodes. More frontends. Optimizer, Dynamic Compiler and JIT.
Comment · 4 years ago
MiniVM uses coroutines already, every 1000 branches the vm will return to the scheduler. The Build system can accept CFLAGS+=-DVM_BRANCH_DEFER which makes MiniVM able to run part of bytecode up-to N instructions.
It is not exposed on the insruction level yet tho. Would be quite easy to add.
Comment · 4 years ago
Author here, Tail calls can be implemented in MiniVM bytecode. There was once an instruction that performed a tail call, It bit-rotted due to not being used.
MiniVM is moving very quickly currently. A lot still needs to be done, like JIT and optimizers.
Eventually a formal specification of MiniVM should happen, just not yet as things are changing too fast.
Comment · 4 years ago
Thank you for having a look.
The reason MiniVM is so benchmark-oriented in its presentation is that MiniVM is ver benchmark-oriented in my workflow.
I have tried to find a faster interpreter without JIT. It is hard to find benchmarks that don't just say that MiniVM is 2-10x faster than the interpreted languages.
Comment · 4 years ago
MiniVM will JIT eventually. Right now the biggest barrier is the VM snapshots. Currently MiniVM its own stack and heap and can snapshot them from any point in the program.
One thing to note about MiniVM is that it has very strong types. V8 has many steps to go through when it needs to perform something like addition (weak typing). MiniVM supports only 4 basic types.
MiniVM's reference frontend Paka is fully self hosted, It is currently the only large MiniVM program.
And as to why the rest are faster, I spent much time optimizing the interpreter and learning what the best way to write interpreters is. Its mostly jump threading and Mixed Data.