Details of Optimisation Table VM

[John Wood]

Let me take a step back and explain the whole thing..

Currently, it's quite normal to have a VM which mimicks the architecture of 
common processors - that is, we have some registers and some set operation 
commands which deal with IO, register content manipulation and memory access.

There's a good reason why hardware processors use this architecture - hardware 
is not a very dynamic beast.  As software is very dynamic, I believe we should 
look at some new VM designs which make use of the flexibility of software, 
rather than be dictated by the constraints of hardware.

SO.. I'm going to put forward my ideas on a more dynamic VM.  These aren't 
totally original ideas - in fact the fundamental idea is under patent by 
Microsoft - but that doesn't mean we can't successfully derive from the 
concept and put it into a context where it could be really useful.

The foundation is based on the single statement " capabilities grow with time 
". Considering processor instructions reflect quite accurately the basic 
capabilities of a processor, then we can only know that over time the actual 
requirements laid on a set of processor instructions will change.  New and 
diverse language models especially place new and diverse requirements on a 
processor - the hardware will become obsolete simply because of its lack of 
flexibility.  The software, however, does not have to become obsolete.

There is a potential for a software driven VM to simulate a processor with a 
*dynamic* instruction set - that is, an instruction set which can change over 
time - to meet different requirements and solve different problems.  

In terms of implementation, this "dynamic instruction set" has to be 
controlled.  It has to be controlled in terms of its morphability especially.  
I'm sure you could imagine what would happen if this was not controlled.

The foundation for the "dynamic instruction set" (which I will refer to as 
DIS) will be a small set of fundamental instructions, following a RISC model.  
These instructions will merely allow for the invocation of a method on an 
object, including several instructions to manipulate parameters and execute 
functions conditionally.

By separating the object model from the VM, the capability arises for us to be 
independent from any particular API or OS.  This, in itself, counteracts many 
of the causes which are attributed to obsolete systems.  The object model will 
provide all the functionality for display and OS interaction - for example, 
the display object model could be the W3C's dynamic HTML object model - or 
perhaps even AWT or an implementation of IFC or AFC. Or indeed it may not even 
have a display object model - perhaps we just want the VM to run some code in 
our washing machines ;)

The fundamental instruction set (which I'll call FIS) will have associated 
native implementations.  HOWEVER - the FIS will never (or rarely) be referred 
to directly.  At this point I will introduce the "Optimisation Table" (which 
I'll refer to as the OT).

The FIS never grows.  The dynamics are a feature of the OT:  It is the OT that 
grows. The OT reflects higher-level commands.  The level of the commands is 
not dictated or constrained in any way by the VM.  In actual fact, it could 
include a command which had the intention " draw a blue circle on the screen 
".

The OT is the instruction set, or more accurately - a collection of 
instruction sets.  Ultimately we have a number of OT based instruction sets, 
and the higher level instruction sets are based on the lower level instruction 
sets.

This may sound like it could be painfully slow - but it isn't called an 
Optimisation Table for nothing.  Usually a number of the optimisation tables 
will not only have each instruction defined in terms of references to other OT 
instructions (which will always redice to either native implementation or 
FIS), but will also offer an implementation of that specific instruction 
*natively*.  

It will be a feature of the VM implementation to use pre-defined system 
objects from the "object model" to locate missing OTs.  If, for example, a 
program is parsed by the VM only to find that it references an OT which is not 
resident - the program's source will have to be able to provide the OT.  This 
will then be downloaded (giving platform information).  If the native OT is 
not available, then the basic OT which comprises of calls to other OTs will be 
used.  The program may run slower - but it will run.

It would also be possible to have a dynamic instruction code format.  It is 
simply a matter of relating a stream of data to different parts of an OT.  
This way, we could have, for example, a JVM compatible instruction code format 
at the same time as having a instruction code format optimised for a Lisp 
model.

We still need to work out the FIS and the extensions required to make Lisp 
compile more efficiently - but as a fundamental basic of a VM, what do you all 
think?

John