Re: librep's indirect threaded bytecode interpretter

[Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>]

Miroslav Silovic <silovic@zesoi.fer.hr> writes:

> Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:
> 
> > What do you mean with "scheme-centric bytecode"?  A (good) VM is (or
> > should be) an abstraction of all the available hardware, not an
> > abstraction of a programming language.
> 
> Uh, define 'good' and 'should' in the above sentence.

Okay.  What about: "A VM is an abstraction over some "real" systems"?

This means that in our case you have to develop the abstract
behavioural model of all available CPU's and implement a virtual CPU
with a virtual stack (all CPU's have a stack), (one or more) virtual
registers, assembly code ("byte code") etc.


> anything you like - it depends on the specific purpose.

Right. There are additional contstrains. For example the VM may or may
not include some form of memory management (garbage collector), it may
or may not separate the code from the space where objects live etc.

Fortunately the Java VM already has everything we need (I think):
-> http://java.sun.com/docs/books/vmspec/2nd-edition/html/Mnemonics.doc.html

putfield  changes the internals of a goops class (note that we now
  can move the evaluator out of the mark space)

getfield  returns the internals of a goops class

invokevirtual  can be used to lookup a method in the method cache 

etc.


> If the VM is designed to comform to the specific programming language

That's the situation we currently have.  Every object is compiled 
into a tree structure before it gets evaluated.

This is ugly because I think we should separate the code from the
objects it manipulates.  The environment implementation for example
must maintain a table to transform code back into the original object.


> I tend to agree with one of the previous posts, though: parse trees
> are much easier to optimise (and, in general, transform) than stack
> machine strings (in fact, to compile the stack machine representation,
> the first step is to convert it back to a tree, so you can shuffle the
> nodes around).

-> http://www.openjit.org/docs/index.html


> Actually there is VERY simple practical issue about JVM: its FFI is
> quite different from Guile's, which makes its use completely academic,
> at least in my case - there's no bloody way I'd bother porting my
> extension libs to JVM (when SCM is still available).

Nonono.  I want to keep the object representation as well as the API.
But I want to split the evaluator into two functions, one that takes a
source expression and compiles it into java byte codes and one that
evaluates the compiled code.

Instead of inventing new obcodes and a new binary format (we'll need
binary format for compiled modules anyway!) I think we should make use
of Java's VM. 


Jost