This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: librep's indirect threaded bytecode interpretter
Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:
> 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.
Uh, define 'good' and 'should' in the above sentence. VM can be
anything you like - it depends on the specific purpose.
If the VM tries to abstract many different types of hardware, it gets
portability but is harder to JIT compile.
If the VM is designed according to some specific hardware, it gains
performance on that hardware, at the expense of other types of
hardware.
In both cases, the compiler from any given programming language gains
in complexity (for proper optimisation).
If the VM is designed to comform to the specific programming language,
that particular language becomes easier to translate to the VM, at the
expense of JIT complexity and the complexity of the translation from
the other languages.
Frankly, I believe that at least one side of the execution pair
(source>VM, VM>native) has to have wide possibilities, so I prefer
either very low level (like VCODE) or very high level (like, say,
1-to-1 mapping of each guile primitive into opcode) VMs.
I tend to agree with one of the previous posts, though: parse trees
are much easier to optimise (and, in general, transform) than stack
machine strings (in fact, to compile the stack machine representation,
the first step is to convert it back to a tree, so you can shuffle the
nodes around).
> 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.
Well, JVM being Turing complete, you can implement ANY object model on
top of it. The only question is the performance one (which Per claims
to be answered positively).
Actually there is VERY simple practical issue about JVM: its FFI is
quite different from Guile's, which makes its use completely academic,
at least in my case - there's no bloody way I'd bother porting my
extension libs to JVM (when SCM is still available).
--
How to eff the ineffable?