Repository files navigation

• simple.vm
• Compilation
• Implementation Notes
• Embedding
• Instructions
  • Simple Example
• Fuzz Testing
• See Also

This repository contains the implementation for asimple virtual-machine, along with a driver which will read a program from a file and execute it via that virtual machine.

In addition to the virtual machine interpreter you'll also find:

• A simple compiler, written in perl.
  • This will translate from assembly-source into binary-opcodes.
• A simple decompiler, written in perl.
  • This will translate in the other direction.
• Severalexample programs written in our custom assembly-language.
• An example ofembedding the virtual machine in a C host program.
  • Along with the definition of a custom-opcode handler.

This particular virtual machine is intentionally simple, but despite that it is hopefully implemented in a readable fashion. ("Simplicity" here means that we support only a small number of instructions, and the registers the virtual CPU possesses can store strings and integers, but not floating-point values.)This particular virtual machine is register-based, having ten registers which can be used to store strings or integer values.

Because the compiler and decompiler are written in Perl they need no specialtreatment.

The interpretter, written in C, can be built like so:

$ make

This will generatesimple-vm andembedded from the contents ofsrc/.

Implementing a basic virtual machine, like this one, is a pretty well-understood problem:

• Load the bytecode that is to be interpreted into a buffer.
• Fetch an instruction from from the buffer.
  • Decode the instruction, usually via a longcase statement.
  • Advance the index such that the next instruction is ready to be interpreted.
  • Continue until you hit ahalt, orexit instruction.
• Cleanup.

The main complications of writing a virtual machine are:

• Writing a compiler to convert readable source into the binary opcodes which will be actually executed.
  • Users want to write "goto repeat" not "0x10 0x03 0x00".
• Writing a disassembler for debugging purposes.
• Implementing a useful range of operations/opcodes.
  • For example "add", "dec", "inc", etc.

This particular virtual machine contains only a few primitives, but it does include the support for labels, looping, conditional jumps, calls and returns. There is also a stack which can be used for storing temporary values, and used forcall/ret handling.

The handling of labels in this implementation is perhaps worthy of note, because many simple/demonstration virtual machines don't handle them at all.

In order to support jumping to labels which haven't necessarily been defined yet our compiler keeps a running list of all labels (i.e. possible jump destinations) and when it encounters a jump instruction, or something else that refers to a label, it outputs a placeholder-address, such as:

• JUMP 0x000
  • In our bytecode that is the three-byte sequence0x10 0x00 0x00 as the JUMP instruction is defined as0x10.

After compilation is complete all the targets should have been discovered and the compiler is free to update the generated bytecodes to fill in the appropriate destinations.

NOTE: In our virtual machines all jumps are absolute, so they might look like "JUMP 0x0123" rather than "JUMP -4" or "JUMP +30".

NOTE: The same thing applies for other instructions which handle labels, such as storing the address of a label, making a call, etc.

This virtual machine is designed primarily as a learning experience, but it is built with the idea of embedding in mind.

The standardsimple-vm binary, which will read opcodes from a file and interpret them, is less than 40k in size.

Because the processing of binary opcodes is handled via a dispatch-table it is trivially possible for you to add your own application-specific opcodes to the system which would allow you to execute tiny compiled, and efficient, programs which can call back into your application when they wish.

There is an example of defining a custom opcode in the filesrc/embedded.c. This example defines a custom opcode0xCD, and executes a small program which uses that opcode for demonstration purposes:

 $ ./embedded [stdout] Register R01 => 16962 [Hex:4242] Custom Handling Here     Our bytecode is 8 bytes long

There are several instruction-types implemented:

• Storing string/int values into a given register.
• Mathematical operations:
  • add, and, sub, multiply, divide, incr, dec, or, & xor.
• Output the contents of a given register. (string/int).
• Jumping instructions.
  • Conditional and unconditional
• Comparison of register contents.
  • Against registers, or string/int constants.
• String to integer conversion, and vice-versa.
• Stack operations
  • PUSH/POP/CALL/RETURN

The instructions are pretty basic, as this is just a toy, but adding new ones isn't difficult and the available primitives are reasonably useful as-is.

The following are examples of all instructions:

:test:labelgoto  0x44ff      # Jump to the given addressgoto  label       # Jump to the given labeljmpnz label       # Jump to label if Zero-Flag is not setjmpz  label       # Jump to label if Zero-Flag is setstore #1, 33      # store 33 in register 1store #2, "Steve" # Store the string "Steve" in register 1.store #1, #3      # register1 is set to the contents of register #3.exit              # Stop processing.nop               # Do nothingprint_int #3      # Print the (integer) contents of register 3print_str #3      # Print the (string) contents of register 3system #3         # Call the (string) command stored in register 3add #1, #2, #3    # Add register 2 + register 3 contents, store in reg 1sub #1, #2, #3    # sub register 2 + register 3 contents, store in reg 1mul #1, #2, #3    # multiply register 2 + register 3 contents, store in reg 1concat #1, #2,#3  # store concatenated strings from reg2 + reg3 in reg1.dec #2            # Decrement the integer in register 2inc #2            # Increment the integer in register 2string2int #3     # Change register 3 to have a string from an intis_integer #3     # Does the given register have an integer content?int2string #3     # Change register 3 to have an int from a stringis_string  #3     # Does the given register have a string-content?cmp #3, #4        # Compare contents of reg 3 & 4, set the Z-flag.cmp #3, 42        # Compare contents of reg 3 with the constant 42.  sets z.cmp #3, "Moi"     # Compare contents of reg 3 with the constant string "Moi".  sets z.peek #1, #4       # Load register 1 with the contents of the address in #4.poke #1, #4       # Set the address stored in register4 with the contents of reg1.random #2         # Store a random integer in register #2.push #1           # Store the contents of register #1 in the stackpop  #1           # Load register #1 with the contents of the stack.call 0xFFEE       # Call the given address.call my_label     # Call the defined labelret               # Return from a called-routine.

The following program will just endlessly output a string:

 :start      store #1, "I like loops"      print_str #1      goto start

This program first stores the string "I like loops" in register 1, then prints that register, before jumping back to the start of the program.

To actually compile this program into bytecode run:

  $ ./compiler ./examples/simple.in

This will produce an output file full of binary-opcodes in the filesimple.raw:

  $ od -t x1 -An ./examples/simple.raw  01 01 0c 49 20 6c 69 6b 65 20 6c 6f 6f 70 73 03  01 06 00 00

Now we can execute that series of opcodes:

  ./simple-vm ./examples/simple.raw

If you wish to debug the execution then run:

  DEBUG=1 ./simple-vm ./examples/simple.raw

There are more examples stored beneath theexamples/ subdirectory in this repository. The fileexamples/quine.in provides a good example of various features - it outputs its own opcodes.

If you wish to fuzz-test withafl you should find that pretty straight-forward:

• Installafl itself, as per the instructions.
• Compile this project, settingCC=afl-gcc in theMakefile.
• Generate some sample-programs, as starting point, then run the fuzzer.

You can compile each of our bundled samples like so:

 cd examples/ for i in *.in; do ../compiler $i; done cd ..

This will compileexamples/*.in intoexamples/*.raw. Place those in a directory, and start your fuzzer:

 mkdir samples/ cp examples/*.raw samples/

Now you have./samples/ containing only compiled programs. You can then mutate/permute those examples under the control of the fuzzer with a command-line like this:

 export FUZZ=1 afl-fuzz -i ./samples/ -o results/ ./simple-vm @@ 16384

NOTE: Here we cap each run to executing no more than 16384 instructions. This will ensure that programs don't have infinite loops in them.

We set the environmental variableFUZZ to contain1 solely to disable the use of thesystem() function. Which might accidentally remove your home-directory, format your drive, orsend me a donation!

A golang port of the virtual-machine compiler and interpreter is available from the following repository:

• https://github.com/skx/go.vm

In addition to that you can find areal virtual-machine inside the embedded scripting engine I wrote, also for golang. In that case a scripting language is parsed and converted into a series of bytecode instructions, which are executed by a virtual machine. Similar to this project, but the bytecode operations are more complex and high-level:

• https://github.com/skx/evalfilter

If you're interested in compilers, and interpreters, generally you might enjoy these other projects too:

• https://github.com/skx/gobasic
  • A simple BASIC interpreter
• https://github.com/skx/foth
  • An interpreter for a FORTH-like language.
• https://github.com/skx/critical
  • An interpreter for a TCL-like language.
• https://github.com/skx/bfcc
  • Abrainfuck compiler
• https://github.com/skx/math-compiler
  • A simple compiler for mathematical expressions.