Re: librep's indirect threaded bytecode interpretter

[Jorgen 'forcer' Schaefer <forcer at mindless dot com>]

Per Bothner <per@bothner.com> writes:

> "Jorgen 'forcer' Schaefer" <forcer@mindless.com> writes:
> 
> > Also, it lacks useful stuff which don't make
> > sense for Java, but make alot of sense for Scheme (check with
> > Kawa and their problems implementing the whole Scheme standard
> > ontop of the JVM).
> 
> As the author of Kawa, I know something about this.

I didn't know you were the author of Kawa, sorry for that.  That
removes half of my presumed knowledge of the JVM, which i based
on a paper/document on the kawa homepage stating that the JVM
isn't very well suited for Scheme, so there were some major
problems in implementing tail-calls as well as call/cc.  Some
time later, I heard that tail-calls were implemented, and
considered that to be very good -- Compiling Scheme to the JVM
would be very nice, for some applications.

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.  So a Scheme-centric bytecode would be very
useful, especially since it would allow us to circumvent the
JNI-specific problems for interfacing with us.  

> One possibility to consider if you're not happy with Java bytecodes:
> JVM has about 50 unassigned single-byte opcodes.  These can be used
> for common Scheme operations, on a Scheme-extended Java bytecode
> interpreter.  It should be easy to modify Kawa so that it can
> *optionally* generate these Scheme-specific bytecodes.  Then you have
> the best of both worlds: The user can choose whether to compile
> Scheme-optimized bytecodes for the Guile-JVM or can compile portable
> bytecodes to "run everywhere".  Almost all of the compiler and runtime
> code will be common to the two modes.

If it's feasable to do so, i'd like that idea alot.

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?
        -- forcer

-- 
((email . "forcer@mindless.com")       (www . "http://forcix.cx/")
 (irc   . "forcer@#StarWars (IRCnet)") (gpg . "/other/forcer.gpg"))