The VM Goals

[Dwight Hughes]

| From: John Wood <tenshon@msn.com>
|
| Just to publicize my ideas...
| 
| >> In a general VM it would be necessary to re-implement
| those LISP constructs, and LISP structures (stack frames, dynamic
| binding, etc), on the top of the VM, thus not optimizing as much as a
| LISP-dedicated VM. <<
| 
| As I said, the optimisation *would* have to be built on top of the base
VM, 
| but this optimisation would be offered natively and so would not suffer
and 
| degradation in efficiency.  Effectively, the VM would be a foundation for

| optimisations for every language, and extended through a controlled
manner 
| (ie. the extensions would have to be reviewed before being published, and
its 
| implementation would have to be offered in terms of the base VM if not
offered 
| natively to satisfy its declaration of being platform neutral).
| 
| >> And I think that's much more demanding to build a generic VM than a 
| LISP-dedicated one. <<
| 
| The same work would have to be done, with the added work of writing the
base 
| VM - which I feel is a worthwhile project in the sense that (a) the LISP 
| implementation would provide a good marketing vehicle for the underlying
VM 
| and (b) the underlying VM would be flexible enough to support the LISP VM
in a 
| future of massively diverse requirements.

I find your comments quite interesting, if a bit frustrating -- tell me
more!
>From these comments I have the impression that your idea of the common VM
could
be characterized as "mid-level" (as opposed to high-level (ASTs or S-exps)
or low-level (assembly-level code for some "ideal" stack-based VM)). Could 
your VM code be efficiently interpreted? (By efficiently, I mean much
better than a standard JavaVM.) This is a downside of the AST-based VM
notion - the intermediate code is not really appropriate for
interpretation.
One would almost *have* to translate the AST to native code to reap any
real benefits from it, making initial porting to a new processor and/or
architecture slow and complex.

-- Dwight