This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Byte-code compilation - good for loading.
Michael Vanier <mvanier@bbb.caltech.edu> writes:
> In this context, the work on the Juice compiler for Oberon is of
> interest. See http://caesar.ics.uci.edu/juice/intro.html for a
> description. They claim that a tree-code format is actually denser
> and produces faster code than bytecode.
I think we can find a compromise between tree-codes and byte-codes. I
am dreaming of `linearized tree-codes' which have the same strong
connection to Scheme expressions as the current tree-codes, but are
produced from a more involved and separate compilation process than
the current memoization. here is what I wrote about it in some
earlier article:
- separate macro expansion and memoization from the interpreter
(we should probably still be able to memoize whole functions on
demand, but not individual expressions)
- move the treecodes out of the tag-space for other SCM values and
out of the cons-heap and handle memoized code as an opaque
object.
- make the treecodes position independent and read-only.
- implement some way to store these treecodes in a binary file
that can be mmaped and executed right away (after setting up some
global indirection table or something to tie the code into the
system).
I think it would be nice to have setup where the compiler is not in
the critical path. We could then think about adding support for
declarations and some mild type analysis and optimizations (like
detecting non-escaping lambdas), etc.
I don't think that implementing a byte-code machine that is close to a
real cpu would be worthwhile. The current treecode evaluator might be
very tight, but it is conceptually simple because it is close to
Scheme. The rewriting of a `let' form into the internal memoized code
is straightforward and the execution of it, too. Compiling into code
for a register machine is probably much more involved. We don't need
to abandon these nice properties of treecodes.
I expect the position-independent, read-only treecodes to be slightly
slower than the existing one because they will like require more
indirections to get at global variables, for example, but hopefully
the other benefits (like being easier on the GC and allowing more
optimizations) will compensate.
But I'm not speaking out of experience here.