Open Virtual Machine Project

Overview

Recent technologies such as Java and CLR present an interesting concept to a programmer - the ability to compiler your code once and run it "anywhere". This is an appealing notion indeed, but to take advantage of these technologies you have to succumb to some major drawbacks:

• Closed Virtual Machine The virtual machine in both cases is proprietary and can be changed at the whim of their respective owners. Furthermore, if a bug is found in the virtual machine, you must work around it, without source code to guide you.
• Big Library On its face, this may seem like a Good Thing™, but what it does is tie you to a particular methodology for your programming. Furthermore, if the library has a design flaw in it, like Java 1's insistence on doing all of the multithread synchronization for you, badly, you're stuck with it.
• Language Non-Neutrality Java is the biggest offender here; to write software for the Java VM, you must write your software in Java. For CLR, you must use C# or a bunch of extensions to C++ that tie you to the CLR.

What is needed is a virtual machine that fights against all three of these drawbacks. Enter the Open Virtual Machine (OVM) Project. Our intent is to provide the premiere portable virtual machine, supporting as many compilers (and therefore programming languages) and platforms as possible.

Project Goals

• Open Source Virtual Machine If you don't get the benefits of this, then you don't belong here. Au revoire! 'nuf said.
• No (or extremely minimal) Library The virtual machine should provide just enough of a library that it can support porting of as many other libraries as possible.
  To the naysayers who think a virtual machine will not succeed without some library, you're right. We just think that libraries should be separate projects. In fact, we envision a series of sister projects whose goals are to port the plethora of existing open source libraries to run on OVM or to support the porting of proprietary libraries.
• Language Neutrality Instead of requiring that you write your OVM software in a special OVM high-level language, the OVM project intends to provide an Application Binary Interface that compilers can target. In this way, any number of compilers can be modified to target OVM. As a sister project, we intend to provide a machine description so that GCC can compile OVM binaries.

Project Objectives

• Virtual Machine Specification Need to write a technical document explaining the instruction set that we intend for the virtual machine to implement, along with its register description, memory model, etc.
• Virtual Machine Reference Implementation The following features will be necessary to claim a 1.0 version:
  • Standard integer and floating-point math operations
  • Function call support At the VM code level, this could simply be the ability to set a return address in a register and then jump to the function address. Or it could be an x86-like call instruction. I don't care. I just know that it'll be really difficult to port existing compilers if you can't generate a function call of some form.
  • Interrupt and/or Exception Support (Maybe) If it's necessary to support
  • Console style I/O. Note that this mechanism should not be, e.g., an implementation of printf, but rather closer to the concept of a terminal on UNIX or the low-level console API's on Win32. ("move cursor to X,Y... copy n characters from memory to the screen... fill this rectangle on the screen with character x").
  • Minimal GUI interaction on appropriate platforms. I.e., the ability to ask for screen real-estate and draw to it using a (very) few well-chosen primitives, and the ability to ask for the occurrence of a (very) few well-chosen events. ("Create a window... Call this function when the pointer moves over the window... Call this function when a key is pressed...")
  • Minimal file system interaction. The equivalent of fopen, fread,fwrite,fclose,and fseek, but not fputs, fprintf, etc.
  • Spawn and synchronize threads. Not an enforced mechanism, as in Java 1.0, but a mechanism where the programmer has control over when locks are acquired and released.
  • Dynamic loading of additional VM modules.
  • Bind to native dynamically-loaded modules. This similar to the JNI.

Support

• The project page is hosted by ResPower, Inc.
  If you have a need for a render farm, or for any custom remote parallel processing solution, check them out! ResPower Render Farm