The VM Goals
Tue, 6 May 97 08:04:58 UT
>> 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
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.