This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]