The VM Goals

[John Wood]

>> Could your VM code be efficiently interpreted? (By efficiently, I mean much
better than a standard JavaVM.) <<

In the sense that the reduction process involves taking the individual 
references to the optimisation table and dereferencing them to collate the 
native representation, it would lend itself more to efficient compilation, or 
more specifically JIT compilation.

For example, a standard (non-LISP) instruction:

n = 1;

...will involve an optimisation table dereference in order to collate its 
native code representation.  On some platforms, the dereference will be 
offered natively at the highest possible level - eg.

n = 1;
..will reduce directly to a machine code instruction of something like..
load [n], 1

On other platforms the native dereference may not be offered. In this case, 
the optimisation table holds a one-level-lower implementation, which will be 
defined in terms of other optimisation table entries.  eg.

put address of n into register
put 1 on the stack
store stack content in register-indirect

...and it will be mandatory for the optimisation table to hold these 
statements' references as native code. That wasn't a good example of code, but 
at least gives you an idea of the process.

If the dereference does not resolve (because the optimisation table does not 
include that op-code / location) then this will be picked up during an initial 
parse - and the source-provider of the code will be required to provide the 
necessary optimisation table extensions.

With this model in particular, the difference between a compiler and 
interpreter VM becomes blurred.  The reduction process leaves you with some 
native code to execute - either you execute the native code when you get it - 
or you store it so that you can execute it at the end of the compilation 
process.  

Fundamentally (ie. on a fresh platform) you will have (a) the base VM and (b) 
the LISP extensions to the optimisation table.  At this time, the reduced code 
will be un-optimised (ie. will always be in terms of the base VM code) and 
thus will probably be slower than any other LISP interpreter/compiler.  
However, when (b) is met with a native implementation of each 
optimisation-table entry - then we have optimised code and the potential for 
far more efficient execution.

John