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: GUILE projects (was Re: I resign as Guile maintainer)


Lynn Winebarger <owinebar@free-expression.org> writes:

> On 1 Dec 1999, Marius Vollmer wrote:
> > Well, on top of that, I now think that before getting GOOPS right, we
> > need a compiler framework that can do expensive optimizations.
> [...] 
>
>      Well, I for one would be interested in working on a compiler
> front-end to gcc and modifications to the gcc internals to provide support
> for stackless tail-recursion and the like.

Yes, it might be very useful to have general tail-call support in GCC,
but I wasn't really thinking about native compilation.  What I think
would be benefitial would be to

    - separate macro expansion and memoization from the interpreter
      (we should probably still be able to memoize while 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.

- Marius

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