Re: librep's indirect threaded bytecode interpretter

[Per Bothner <per at bothner dot com>]

"Jorgen 'forcer' Schaefer" <forcer@mindless.com> writes:

> But i don't understand why it would be useful to have our VM
> execute more instructions than it has to?  Reading a complex
> statement and executing that will always be slower than reading a
> simple expression and executing the complexer equivalent directly
> in machine code.

I don't what you are trying to say.  A more Scheme-centric, more
compact bytecode may be more efficient on a *simple* interpreter -
but it really depends more on how smart the compiler is that
generates the bytecode, and how clever the interpeter (augmented
by a just-in-time compiler) is.

Most of Scheme is just procedure calls, plus some control flow.
When the procedure is known at compile time, it is easy to
generate compact and fast Java method calls.  When the procedure
is unknown, you can use a virtual method call, which is also fast.

> How easy is it to implement a Goops (TinyClos)-like object-system
> ontop of the JVM? e.g. how far does the JVM support the (limited)
> Java Object System insofar as to make supporting something like
> Goops unfeasable?

See http://www.bothner.com/~per/papers/jaoo99.html (best viewed on a
browser with decent css support) for my design (not yet implemented)
for implementing CLOS-style multiple inheritance.

Summary:  Someting like GOOPS is quite practical, and not that
difficult to implement.  The paper only talks about classes.
The other important part of CLOS is generics and method selection.
I have a partial framework for that implemented, but it doesn't
do anything very interesting yet except it is used to select the
most specific Java method when invoking a Java method.  But, yes
I do intend to implement something like GOOPS.  (Help welcome, of
course.)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/