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


> There are many free bytecode interpreters, at least two of which
> incorprate Just-in-Time compilers (Kaffe and Jikes), some
> ahead-of-time compilers (gcj), etc.
> 
> Writing a simple compact interpreter is straight-forward.
> 
> Using a pre-compiler like gcj to pre-compile the standard classes
> (including the standard Scheme functions) produces fast start-up.
> 
> The point is that there are a number of choices, with different
> characteristics.

A few extra points, starting with a free interpreter and making a
few wekk defined changes to the bytecode to make it more scheme
friendly is a very fast way to bootstrap yourself, especially if we
can do so without breaking Kawa compatibility (i.e. if we delete
some bytecode that Kawa never uses and reimplement that).

If we document the deviation from Java standard accurately then 
future advances in the free interpreter can easily be integrated
into our modified interpreter (or at least 90% or them can).

> > Hmm, "Guile" is an "extension language" for programs written in C.  I
> > don't think this is possible with Kawa, is it?---Yes, I know that
> > there are "bridging technologies" like Corba, but still Kawa and Guile
> > belong to two different domains.

Not if there is an easy way to take an existing free interpreter
and make it into an embedded virtual machine. I don't know how
difficult this might be but I'm sure it is possible.

> The more relevant briding technlogy is JNI - Java Native Interface,
> which is a "foreign function call" standard for writing Java
> methods in C or C++.  (Gcj has in addition gcj, an alternative
> interface that is more convenient and efficient but less
> portable than JNI.)  JNI has an "invocation interface" which
> lets you start up a Java environment in an existing C thread.

If it gets too difficult to work directly with whatever native interface
then there can always be a library call that abstracts the messy bits
(and possibly that library call includes non-portable code but all other
code that uses the library call is portable).

Keeping as much Java compatibility as possible would be nice but
the desired result is scheme compatability and something that does
what the users want.

	- Tel

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