I don't actually know about this stuff, so I'll suggest an obviously stupid machine design and you can tell me what's wrong with it and fix it. At least this will get some progressive conversation started on this.
The machine shall have the following:
- A stack, for passing parameters to functions
- $N registers, each of is some data - what should N be?
- named functions
- some instructions, which should probably be as simple as possible.
I would suggest the following instructions:
- push $REG, to push the contents of a register onto the stack
- pop $REG, to pop the contents of the stack into a register
- copy $IN $OUT, to copy the contents of one register to another
- call $FUNC, to call a function
- return, to return from a function. Something with the stacks should allow a number to be returned.
- alloc $REG $SIZE, to make $REG point to $SIZE bytes.
- free $REG, to get rid of the data behind $REG
The following functions should be built in:
- print $REG
- read $REG
The reason for including alloc and free stuff is that I think it would be neat to have all the machinery for complex data types inside the VM. From my meagre bit of knowledge, it seems that that would make it simpler to write compilers to target the machine.
So, everyone, what's missing? What's wrong? Make comments and corrections!
This original rubbish written by IainMcCoy, because he doesn't like seeing things go nowhere fast.
How about having two levels of bytecode -- the "high level" representation with operations like callfunc and deffunc (for example) and then the "low level" virtual machine that implemented everything else (e.g. callfunc would be transformed into lower level operations that saved the contents of the registers, called a named function [transformed in a jump] and then restored the registers for the caller). I think that basing the VM off of the basic design of an existing processor like the mips32 with all of the non-usermode stuff removed and maybe a few extras added. Or really, the high level library could be a set of macros for the assembler (although it would be advantageous to make the high level operations available to all users of the VM, even if they simply write the raw bytecode without using an assembler). -- ClintonEbadi
Can you perhaps specify what there would be after your proposed changes to mips32? I've just downloaded an instruction set document and discovered that the list of instructions in the contents runs for 2 and a half pages, so I'm not much inclined to go through the thing. Anyway, just approximations are fine at this point.
I'm reading the MIPS Architecture documents that I found at http://segfault.net/~scut/cpu/mips/ right now so I'll try to post a modified mips32 instruction set in the next day or so. Basically, I think that it would be useful to use mips32 usermode instruction set mostly unmodified. -- ClintonEbadi
Has anybody ever attempted to create a minimal virtual machine, with the smallest possible specification to be able to do anything? I reached five or six instructions and two registers. Not really related, but I think that a simple virtual machine is better than a complex virtual machine.
Perhaps it does not really apply to VMs but has anyone read about OISC (One Instruction Set Computer). That means you could theorically build a VM with one instruction only: http://www.wikipedia.org/wiki/OISC -- FrancoisDenisGonthier
I like the comment about creating a minimum virtual machine. I think that a virtual machine is supposed to be like a machine. That means that it should imitate an actual hardware device that you could build. I feel that if our VM manages objects then it will be severely limited in the types of programming languages that it can support. If you want garbage collection and objects, then just write an interpreter - not a VM.
I suggest that we make a virtual stack machine. Each stack element will be a 32-bit number. Instructions will be available to do basic arithmetic and comparisons. A static-sized memory block will be available to the program for storing data. I suggest that we keep it very simple - only 3 memory instructions:
* get size of memory block * store 32-bit number from stack into memory location * retrieve 32-bit number from memory
I wrote a simple stack VM for a freshman class that does not implement any parsing or lexical techniques. I think it had 5 "memory locations" and around 12 instructions... Oh, written in C++. Send me an e-mail if you want the source (kmonihen at fast dot net). I also have a generic parser and lexical analyzer that I wrote for an extra credit assignment (talk about easy E.C.) - KeithMonihen
Most VMs or architectures you see are either stack or register-based, and use jmps etc.. How about something where all you can do is modify registers, but that fulfills actions? For example, there is an addition register, and after each instruction, that register adds itself to the data register. For example, to display "Hello, World!" you would maybe do something like this:
; put string adress on stack push string ; load top of stack into output register ldout ; exit halt ; the string string: dd "Hello, World!", 0x13, 0x00
-- rk
If it's simple stack machines you're interested in, you can find information and real life examples here: http://www.ultratechnology.com/chips.htm