thinking about virtual machines

[Fare Rideau]

[Note: again, I've been cross-posting between
lispos@math.gatech.edu and tunes-lll@ens.fr]

On lispos@math.gatech.edu, Richard Coleman (coleman@l.g.e) said:
> [assuming we tried to develop a LVM standard]

> Now, a big problem is the process of developing a "standard".
> We all know this is a long and frustrating process.  Once you are
> done, this is no guarantee that anyone will be interested in the
> results.
If people are interested, that may be worse:
you'll end-up with a stubborn low-level standard,
that will grow a large legacy base a la MS-DOS,
so you cannot fix the design.
   Solution:
* keep the VM design *high-level* and extensible/versioned;
* make it simple enough with clean formal specs,
 so that recycling/autotranslating legacy code is doable.
Isn't some kind of Scheme a good VM?

> While waiting on this standard to develop, this project would
> lose its momentum.  People need to see progress (i.e. running code)
> to stay interested.  So how could we do this and keep the momentum up?
Don't care about what the others do. Do it yourself.
[well, I admit Tunes has no running code yet :( :(]

> Maybe a two tier attack, where one group develops the LVM standard
> and layers it on some hardware (using Flux toolkit for example) and
> the second group starts with a chosen lisp implementation and start
> adding all the system applications that a stand-alone lispOS would
> require.
Kind of the Tunes HLL/LLL project separation, eh?


> 1) Where to start?
I like the OCaml virtual machine, Scheme, Turing Machines,
<choose-a-set-of-greek-letters>-calculus.
But their fitness to our purposes depends on our purposes, ain't it?
So again, what are the goals of the virtual machine?

What family of front-end languages does it aim to efficiently implement?
  what about languages with a rich static type system, like ML, Haskell, etc?
  what about dirty languages (C, asm, FORTRAN)? (just joking, or am I not?)?
  what about parallel languages?
  what about some kind of ILU (interlanguage unification)?
  what about the n+2345th differently modeled object system?
What general back-end architecture models does it aim to emulate?
  what about changes in fixnum/address sizes (16/20/32/64/128/n bits)?
  what about local vs world-wide unique object identifiers?
  what about parallel architectures? multiprocessors? shared memory?
  what about dynamic code migration between heterogeneous architectures?
  what about real-time constraints?
  what about fast access to low-level bit/pixmaps?
  what about precision control in bignums and floats?
What kind of optimizations/safety-checks/program-transformations
  do we intend to structurally favorize in the back-end?
  What about supporting/enforcing the usual features for a clean language?
    what about strong type checking? static vs dynamic scoping?
    pure functions and read-only objects? explicit references a la ML?
  What about GC?
    Local/Distributed? Persistent/Transient? Moving or in place?
    Got Finalizers? What/how?
  What about downward extensibility?
    access to the hardware bits?
    interfacing with lower-level languages?
  What about support for compiler optimization hints?
    generic transformations?
    partial evaluation, RTCG?
    prefetching/optimistic evaluation/models of the future?
  What about support for multiple underlying architectures?
    precompiled native-code alternatives? evolution of VM versions?
    negociation of precise object format? fallback strategy?
  What about objects, packages, environments?
    first class environments? modules?
    first class classes/types? meta-objects?
    versioning? unification of different packages?
  What about security?
    cryptographical certificates?
    formal proofs of programs?

  etc...

Are we to allow/disallow/leave room for some or any of the suggestions?
Why/Why not?
What is the definition of an OS to you? How must generic ought it to be?
Is that compatible with precluding some or all of the above features?

As for the Tunes project, the answer is YES everywhere; YMMV w/ lispOS.
My suggestion was that the standard "VM"
be the roughly a compact representation of an abstract syntax tree,
in some extensible global grammar, with dynamic deprecation of constructs.
Multiple kinds of lower-level sub-VMs can be safely explored,
not burdening us w/ legacy thanks to the high-level fallbacks.

> 2) What is wrong with the current virtual machines?
Low-Level Legacy.

> 3) What lisp implementations use a virtual machine architecture that
>    we could retarget to LVM.
Note that LISP itself is a (high-level) VM...

> Now I believe this using this method has merit.  But I need to be
> convinced it can be accomplished.
To me, anything that ends in Low-Level Legacy is *HARMFUL*.

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"