Details of Optimisation Table VM
Tue, 6 May 97 22:12:23 UT
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
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
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
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
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