The VM Goals
Mon, 5 May 1997 21:10:01 -0500
| From: John Wood <firstname.lastname@example.org>
| 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
| but this optimisation would be offered natively and so would not suffer
| degradation in efficiency. Effectively, the VM would be a foundation for
| optimisations for every language, and extended through a controlled
| (ie. the extensions would have to be reviewed before being published, and
| implementation would have to be offered in terms of the base VM if not
| 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
| 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
| and (b) the underlying VM would be flexible enough to support the LISP VM
| future of massively diverse requirements.
I find your comments quite interesting, if a bit frustrating -- tell me
>From these comments I have the impression that your idea of the common VM
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
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.