This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: GUILE projects (was Re: I resign as Guile maintainer)
- To: Lynn Winebarger <owinebar at free-expression dot org>
- Subject: Re: GUILE projects (was Re: I resign as Guile maintainer)
- From: Marius Vollmer <mvo at zagadka dot ping dot de>
- Date: 02 Dec 1999 21:06:45 +0100
- Cc: guile at sourceware dot cygnus dot com
- References: <Pine.LNX.4.10.9912011842420.730-100000@se232.math.indiana.edu>
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