Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implementing a Virtual Machine in C

blog.felixangell.com

Post reply on HN
Print view View original

31–40 of 54 posts

Re: Implementing a Virtual Machine in C

#31

Post by earlz »

I'm pretty sure everyone has wrote their own toy VMs, but I'll go ahead and throw mine out there. (well, 1 of the 3 I've wrote that I like best). It's called LightVM and is intended to be capable of running on tiny microcontrollers.

The most cool thing I like about it is the opcodes and registers are extremely general purpose. So, to do a branch, you do `mov IP, label`, or even a "push.mv" instruction which when used against IP is basically the same as the usual "call" instruction, but can also be used with data registers to save a register to the stack and then set it to a value.

I've found the hardest thing about making a VM isn't making a VM, but rather making the infrastructure around it (assembler, debugger, compilers, etc)

https://bitbucket.org/earlz/lightvm/overview

Re: Implementing a Virtual Machine in C

#32

Post by dkersten »

earlz wrote: post #31

I'm pretty sure everyone has wrote their own toy VMs, but I'll go ahead and throw mine out there. (well, 1 of the 3 I've wrote that I like best). It's called LightVM and is intended to be capable of running on tiny microcontrollers. The most cool thing I like about it is the opcodes and registers are extremely general purpose. So, to do a branch, you do `mov IP, label`, or even a "push.mv" instruction which when used…

So, to do a branch, you do `mov IP, label`, or even a "push.mv" instruction which when used against IP is basically the same as the usual "call" instruction

I wrote something a little like this once too - there was a register stack and call, jump, branch were all implemented by pushing or popping the register stack.

Re: Implementing a Virtual Machine in C

#33

Post by jCanvas »

I think the title is very misleading. This is not a virtual machine but an interpreter for a made up assembly language. There is nothing wrong with that and I am sure a beginner would find it very useful. But reading the title I was expecting something quite different.

Re: Implementing a Virtual Machine in C

#34

Post by dalke »

jCanvas wrote: post #33

I think the title is very misleading. This is not a virtual machine but an interpreter for a made up assembly language. There is nothing wrong with that and I am sure a beginner would find it very useful. But reading the title I was expecting something quite different.

Virtual machines include "interpreters for a made up assembly language." Quoting from http://en.wikipedia.org/wiki/Virtual_machine#Process_virtual... :

> A process VM, sometimes called an application virtual machine, or Managed Runtime Environment (MRE), runs as a normal application inside a host OS and supports a single process. ... Process VMs are implemented using an interpreter; performance comparable to compiled programming languages is achieved by the use of just-in-time compilation.

It points to several examples of process VMs. One is Parrot. Quoting from http://en.wikipedia.org/wiki/Parrot_virtual_machine :

> Parrot is a register-based process virtual machine designed to run dynamic languages efficiently. It is possible to compile Parrot assembly language and PIR (an intermediate language) to Parrot bytecode and execute it.

(I quoted that one over Java and Python virtual machines because it uses the phase "assembly language" in the context of the VM.)

Re: Implementing a Virtual Machine in C

#35

Post by vbezhenar »

For those who want to implement a VM as an exercise, I recommend to implement a simple JIT-compiler after that. You'll probably be impressed at performance improvements and it's funny exercise to do. I used GNU lightning to generate machine code.

Re: Implementing a Virtual Machine in C

#36

Post by maguirre »

tptacek wrote: post #18
maguirre wrote: post #16

Earlier quoted context omitted.

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"

It's an instruction set, with an instruction dispatcher, a stack, and a register file. Why would it surprise you that someone would call it a VM? Are you maybe getting your signals crossed between the kind of VM this article is talking about (in the p-code sense of a VM) and virtualization systems?

I was not surprised that it was called a VM. I was surprised that I didn't know that!

Re: Implementing a Virtual Machine in C

#37

Post by userbinator »

tptacek wrote: post #20
jcoffland wrote: post #9

I'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

In interpreted environments, registers are stored in memory anyways, so the advantage of simulating them isn't as great

...unless the interpreter maps VM registers directly onto machine registers. With some VMs it's possible, and then you can get very good performance.

Re: Implementing a Virtual Machine in C

#38

Post by gsg »

userbinator wrote: post #37
tptacek wrote: post #20

Earlier 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

In interpreted environments, registers are stored in memory anyways, so the advantage of simulating them isn't as great ...unless the interpreter maps VM registers directly onto machine registers. With some VMs it's possible, and then you can get very good performance.

That would be very inefficient, because registers cannot be indexed. The dispatch you have to introduce to jump to code that references the right physical regs would murder you with mispredictions.

Also, register VMs typically have three operands. Specialising each instruction for each possible register for three operands would result in a ridiculous volume of code.

Special purpose instructions that access fixed registers would be fine, but general purpose operand references cannot be sanely implemented in this way. Existing register VMs use memory because it's faster.

Re: Implementing a Virtual Machine in C

#39

Post by becausecomputer »

tylermac1 wrote: post #28
ternaryoperator wrote: post #15

I 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.

Thank you for raising this. My faith in humanity has been restored.

Re: Implementing a Virtual Machine in C

#40

Post by rdc12 »

tptacek wrote: post #20
jcoffland wrote: post #9

I'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

This paper [1] (thou it is a tad old now) shows that the register machine approach does still outperform the stack machine by a fair margin. Largely from the reduction of needed instructions.

Wonder which is a better source represntation for a JIT thou.

[1] https://www.usenix.org/legacy/events/vee05/full_papers/p153-...

Post reply on HN