This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]