Re: librep's indirect threaded bytecode interpretter

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

Per Bothner <per@bothner.com> writes:

> [Java bytecode for guile]
> 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.

I strongly recommend *not* to use java bytecode for guile.  The JVM
is too a restricted language as that it would be worthwhile.
It's almost impossible to optimize JVM bytecode well for the
local requirements.  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).

The exists an Oberon project with a similar goal as Java, but
uses "parse trees" as intermediate storage[*].  The contained
semantic information was enough to make the final program
multiple times the speed of a similar JIT compiled java program.

[*]: Juice, http://www.ics.uci.edu/~juice/
Sadly, they seem to have removed the extensive discussion of the
Juice approach i read there. If i remember correctly, they used
the normal approach taken by compilers like gcc, in which the
language is read in and optimized until just before the last
stage which is CPU dependant.  They stored that intermediate
representation and used it as "portable code" -- which enabled
them to just write the backend for each platform, just like Java
JIT compiler, and gained an enormous speed bonus.


So i don't think that JVM code would be worthwhile for Guile to
use.

just my .2 cent,
        -- forcer

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