[e-lang] Smallcaps: a simple capability VM

Darius Bacon e-lang@mail.eros-os.org
Mon, 14 Oct 2002 02:42:06 -0700


MarkM asked me to announce his new design for a virtual machine here:
it's meant to be simple to interpret and to generate code for from
Kernel-E (as transformed by Dean's transformer).  A non-goal is safety
for mobile code -- use Kernel E for that instead.

The first cut at the instruction set is documented here:
http://www.erights.org/javadoc/org/erights/e/elang/smallcaps/SmallcapsOps.html
http://www.erights.org/javadoc/org/erights/e/elang/smallcaps/SmallcapsEncoderVisitor.html

and the beginning of a Java implementation is here:
http://accesscom.com/~darius/e/smallcaps/
(Don't try to run it, it's still broken.  It's MarkM's code after some
hacks by me; my intent was to work up to a tested reference
implementation that can be recoded in C/C++, and also to try to get a
unified code-generator interface usable for emitting JVM code.)

Some known problems with the spec that need to be fixed:

 * Encoding constants like strings directly in the instruction stream
was a bad idea: a direct implementation would mean that methods with
longer names take longer to call!

 * Creating a new ejector for every branch looks too expensive, or
else too fancy if we try to make it that cheap to allocate ejectors.
Better to use different instructions.

 * The garbage collector can't do its job properly unless we tell it
which local variables are live at any point.  We need to propagate
live variable ranges into the object code, and not just for debugging.
(The JVM has the same issue for its local variables, and I can't find
any treatment of it in the spec, or in the Java spec either -- as far
as I can tell, it's considered a quality-of-implementation issue if
it's considered at all.  Does anyone know if the JVMs in use ever
trace dead locals?  This matters because E does try to make promises
about space usage -- I haven't seen them written down anywhere, just
Mark and Dean arguing. :-)

 * Some instructions aren't fleshed out yet (try/catch/finally and
object creation).

Darius