New concepts are introduced at a satisfying pace. Each bit of code is explained thoroughly. Nice writeup.
Implementing a Virtual Machine in C
21–30 of 54 posts
Re: Implementing a Virtual Machine in C
#22For people looking for less "toy" implementations, I've written two emulators, an 8086 one and a Z80 one.
There's libz80 (https://github.com/ggambetta/libz80) which is (AFAIK) quite complete and correct but just a library, and the 8086 one (https://github.com/ggambetta/emulator-backed-remakes) which is incomplete and buggy but serves a much more interesting purpose :)
Re: Implementing a Virtual Machine in C
#23I find these kinds of very basic intro articles frustrating. They till the same ground over and over: a tiny instruction set implemented with a switch statement. None of the more difficult issues are addressed: exception handling, linking to libraries or other programs written for the same VM, portability of programs across architectures, accessing the OS for services like file I/O, time, etc.-- All the things that m…
That's a little ungenerous of you. The toy VM has presented an aha! moment to all of us at one time - or more than once, when you learn about Turing equivalence and the rabbit hole that leads from that.
Skip the articles beneath your skill level and move along.
Re: Implementing a Virtual Machine in C
#24I'd like to see such an article on a register based VM. Pawn and Lua are nice examples. Most VMs are stack based but this is mainly because they are conceptually easier to understand. Register based machines have some real advantages, like requiring far fewer instructions inside tight loops.
Not an article, but this is a register-based VM that should be simple and straight-forward to understand. Also comes with an assembler, disassembler and debugger.
Re: Implementing a Virtual Machine in C
#25I'd like to see such an article on a register based VM. Pawn and Lua are nice examples. Most VMs are stack based but this is mainly because they are conceptually easier to understand. Register based machines have some real advantages, like requiring far fewer instructions inside tight loops.
Stack VMs aren't used just because they're easier to understand: * In interpreted environments, registers are stored in memory anyways, so the advantage of simulating them isn't as great * It is easier to generate code for stack machines, because you don't need to run register allocation * There's a tradeoff in instruction complexity versus number of instructions between stack and register machines
Registers are stored in memory, but ideally "memory" means L1 cache, and it seems to me like register VMs would have better cache locality. This might be why they're getting more popular relative to stack VMs as the speed advantage of cache increases.
Re: Implementing a Virtual Machine in C
#26Earlier quoted context omitted.
Stack VMs aren't used just because they're easier to understand: * In interpreted environments, registers are stored in memory anyways, so the advantage of simulating them isn't as great * It is easier to generate code for stack machines, because you don't need to run register allocation * There's a tradeoff in instruction complexity versus number of instructions between stack and register machines
Registers are stored in memory, but ideally "memory" means L1 cache, and it seems to me like register VMs would have better cache locality. This might be why they're getting more popular relative to stack VMs as the speed advantage of cache increases.
Stack machines are constantly using the same absolute offsets into the stack when evaluating in a loop, or evaluating different branches of a big expression. In fact, one of the simplest register allocators you can use in an expression code generator is a stack; pop to allocate, push to deallocate, and spill if you run out. On a CPU, this will have benefits, but in a VM, it's just a relabeling scheme for the same memory slots a stack VM would use.
What you potentially gain with a register VM is reduced accounting overhead; a stack machine will be constantly adjusting the stack pointer on every operation. It's a tradeoff for less complexity at codegen time. It's swings and roundabouts in the lowlands of performance, though; no loop and switch VM will be super-fast.
Re: Implementing a Virtual Machine in C
#27I find these kinds of very basic intro articles frustrating. They till the same ground over and over: a tiny instruction set implemented with a switch statement. None of the more difficult issues are addressed: exception handling, linking to libraries or other programs written for the same VM, portability of programs across architectures, accessing the OS for services like file I/O, time, etc.-- All the things that m…
I feel the same way. I went to read the post expecting a lot more than what I found and came away feeling both more knowledgeable than I thought I was and more ignorant for not knowing that I could get away with calling what a saw a "Virtual Machine"
"Virtual machine" here means "abstract machine" as in JVM or CLR, not "multiplexed hardware".
Re: Implementing a Virtual Machine in C
#28I find these kinds of very basic intro articles frustrating. They till the same ground over and over: a tiny instruction set implemented with a switch statement. None of the more difficult issues are addressed: exception handling, linking to libraries or other programs written for the same VM, portability of programs across architectures, accessing the OS for services like file I/O, time, etc.-- All the things that m…
Considering the author is 16, I think it's a great write up/exercise.
Re: Implementing a Virtual Machine in C
#29C is not my thing so a few years ago trying to sort out how a VM works, I created a VM in Ruby.
Practical? Not in the least. But, it was a good weekend's worth of fun.
Re: Implementing a Virtual Machine in C
#30Contrary to the naysayers, I like seeing stuff like this. Why? Because it's a simple, gentle introduction. It's easily digestible for the newcomer. And it might be easy enough to encourage a newcomer to start building their own VM that goes on to be something real. For those that criticize it and find faults with it -- I'm sure the author would consider pull requests. Or you could provide your own fork with all the i…
Calling people who criticize that blog post "naysayers" is childish, at best. Once something is out there on the web it's going to get some criticism, that's normal.There is nothing wrong with that.