Details of Optimisation Table VM -Reply

[Bill House]

Somone wrote:
>
> [snip]
> 
> If the generic nature of the VM is a primary goal from the outset, I believe
> it can work.  If it is a secondary goal, i.e.,  try to keep it open enough so
> others could work within it if their model is close enough to what is
> designed for Lisp, then it will come out smelling like the JVM -- too biased
> for any language besides close relatives to put any stock in.  As mostly
> an outsider to Lisp, I am not trying to say that one or the other is the
> correct strategy.  Only that a properly-executed generic VM would really
> interest me, and I would like to be able to choose languages besides
> Java.
> 
There is no law that says the LispVM has to compromise the languages it
supports. Well, in the case of C/C++, I think that's not true, but for many
languages, I believe it.

The tradeoff will be the disk and memory footprints of the result, not
necessarily the execution speed (given that even JIT costs something).  If an
efficient internal architecture that can swap personalities on the run can be
developed, and it seems that it can, then the rest is just defining the special
instructions that each particular language needs. Oh, and supporting them <g>
-- a non-trivial task, but one that could be done by sub-project groups.
Vendors with successful HLLs could caucus with their users to create the
VB/PB/Delphi/Whatever special bits for their favorite language. Researchers can
develop new languages, or create ML/Haskell/Dylan/etc. mappings.

Language Egalitarianism -- just what we need, another "ism". <g>

In this case, we also need the following:

1. A really clear idea of how this swapping architecture will work, so we can
look at available starting code and see what (if anything) is useful.  From a
work-fast perspective, I'd like to use Kaffe as a template -- it seems pretty
well-made and already has a JVM-compatible JIT for free.  However, I'm
reserving judgement on this until my compiler guru gets back.

2. The base VM instruction set and a JIT for same. This is a critical piece, as
translation from these codes to native are how this beast is supposed to
achieve cross-platform performance. There is an issue here, as we may need to
extend the set to have low-level support for various programming models -- we
have to decide what those extended instructions (if any) might be. 

My original leaning was to simply write compilers for Lisp->VM, Scheme->VM and
Java->VM, but that notion does not encompass the OTVM concept, which is that
new languages could somehow carry their specialized instruction sets with them,
installing optimizations for themselves on the fly. Hmm... 

3. The mapping for our first hosted language. For the sake of simplicity, I
would suggest Scheme -- it's small and useful. The Java mapping will hopefully
be salvaged from the Kaffe codebase. I'm sure a Lisp mapping would also be
among the first to be done. If someone wants to concurrently produce a VB
mapping, that's also just fine.

The more, the merrier.

4. The Rules of the Road for hosted languages. There are certain things we
can't support and be a generic binary VM standard. Raw memory pointers come to
mind. In all these cases, I think the appropriate thing to do is simply let
interested parties develop any kind of language mapping they want, as long as
they follow the Rules of the Road. This will encourage language designers and
those who want a familar syntax, even at the cost of some features (a
safe-pointer version of C??).

Perhaps the easiest way to enforce this is to restrict the VM instructions that
programs can execute, unless they are trusted.  Trusted programs would get
access to the instruction that allows calls outside the sandbox -- others would
get a runtime error for that.

BTW, please be sure to send replies to 

	lispvm@math.gatech.edu

Otherwise, they're not visible to others.

Bill House
--
http://www.dazsi.com
The views expressed are mine alone,
unless you agree with me.