Re: librep's indirect threaded bytecode interpretter

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

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

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

someone remove my email access after the sun goes down please.
This of course means the Goops-like system you came up with,
which you mention in a previous mail.  Is it *easy* to implement
this in JVM?

I basically like the JVM approach, but i wouldn't like Guile to
be "behind" other interpreters in possible execution speed just
because we were stuck with the JVM.  Using the remaining 50 bytes
of JVM opcodes is a nice idea, but only if we have to use just a
few.  If too many useful Scheme operations have to be implemented
in long JVM code, or consume too many of those 50 bytes (it could
lead to problems with future Java VM specifications if we use too
many of those).

        -- forcer

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