This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: librep's indirect threaded bytecode interpretter
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. 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.
What do you mean with "scheme-centric bytecode"? A (good) VM is (or
should be) an abstraction of all the available hardware, not an
abstraction of a programming language.
AFIK the jvm is quite simplistic, but it should even be possible to
implement it in (re-programmable and adaptive) hardware like FPGA's.
I think Transmeta has developed a similar vm which is adaptive, but I
don't think we'll get any papers/documents from them.
> How easy is it to implement a Goops (TinyClos)-like object-system
All CLOS based OO systems can be emulated by the "conventional" Java
OO paradigm. The only problem I see is that although Java supports
/multiple/ dispatch, it does not support real /dynamic/ dispatch.
This is a bug, IMHO.
> ontop of the JVM? e.g. how far does the JVM support the (limited)
> Java Object System
You're right when you say that the java OO paradigm is limited. But
for a good reason. Kiczales paper proposes similar limitations for
CLOS to prevent users from "shooting themselfs in the foot"[TM]. :)
Jost