Thanks! The goal was readability and ease of use, so that's probably why it's slow :P

Not sure I understand. What would it do differently?

Edit: Hang on, so I should generate C or asm? or something?

I think that the method you use is "Token Threaded Code" [1]. It's one good way of implementing a VM.

I only added the blog link in case you were interested in extending the VM to use Just In Time compiling. Using a JIT would mean generating assembly.

I like your VM - there is no need to change it. Thanks for sharing.

[1] http://realityforge.org/code/virtual-machines/2011/05/19/int...

Thanks for the info! :)

You'd essentially be generating machine code on the fly and letting the cpu execute it, instead of interpreting anything yourself.

Interesting. Is that significantly harder?

It does make it more complex since you now have another layer to deal with. I wouldn't roll by own JIT compiler though, otherwise it would definitely be a crap ton harder. Using something like libjit or llvm's JIT compiler are two good options.

It's nice having a normal, interpreted VM then building a JIT compiler later on for extra speed. A recent Rust project called `js.rs`[0] started out with a simple interpreter and swapped it for a JIT compiler using libjit.

The biggest difference being you now have to interface with the actual CPU and such.

[0] https://github.com/TomBebbington/js.rs

if you're already writing in C, no. Just write some functions to convert those instructions into asm, and write an assembler (or use one of the many out there) to output them to bytes. Then use mprotect(), tadah!

Interesting.