This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: librep's indirect threaded bytecode interpretter
Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:
> Okay. What about: "A VM is an abstraction over some "real" systems"?
That's a rather eccentric definition. Why would you want an abstraction
over some real system? What you want is an abstraction that can be
*implemented* efficiently on top of 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.
I think you're missing the point of a VM.
> 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
You can do that on a VM that supports the GOOPs model directly.
(I realize that is what you are proposing, which is an alternative
to what I am proposing.)
Otherwise, you would probably use an interface method call.
I.e. getting slot A in value x of class T would be compiled to
x.getA()
and setting the slot should be compiled to
x.setA(newValue)
> Nonono. I want to keep the object representation as well as the API.
Why? The Guile object representation is pretty ugly, and using lots
of pre-defined mask bits doesn't really make sense with an extensible
type system. A few immediate types may have some performance benefit
for common types, though I prefer the simplicity and consistency of
always using pointers (plus unboxed numbers when type inference or
declarations permit it).
> 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.
Well, you lose much of the benefit of using Java bytecodes, since
you're tied to a single VM implementation.
However, this approach may be a reasonable one in some ways. It
may allow you to use the Kawa compiler. It may also be a
workable migration path.
--
--Per Bothner
per@bothner.com http://www.bothner.com/~per/