Re: Compiling Elisp to a native code with a GCC plugin

[Thomas Lord]

I've only loosely followed this thread so
its possible I'm off the mark (in which case - sorry)
but, i'm pretty sure it might be helpful to remark
about a variant of what I guess Tromey is suggesting:

Years ago - not for GC but for managing critical
sections wherein interrupts had to be deferred - 
we did something similar in a fork of GNU Guile.

In that case, semi-automated ad-hoc rewriting was
used a tiny bit but the most helpful thing turned
out to be:

a) rip a C grammar out of GCC (unless we used a 
different source, I forget).

b) hack the actions to hook up to a scheme (or
other lisp) run-time system and build an AST
as a big S-EXP.  Make sure this AST records source
files and line numbers.

c) write ad-hoc cheapo static analysis tools to 
walk the AST and find places where either it was
obvious fixes were needed, or where it was not obvious
fixes were not needed --- print those out like compiler
error messages.

d) Interactively page through those and, as you watch
each case, apply the ad hoc semi-automated rewrite tools
(or do it by hand in hard cases).

Step (d) can go very, very fast and, at least in that
case, steps (a .. c) can go a lot faster than
you might guess at first glance.

-t



On Tue, 2010-09-14 at 15:16 -0600, Tom Tromey wrote:
> >>>>> "Wojciech" == Wojciech Meyer <address@hidden> writes:
> 
> Tom> It could be done.  It just requires someone willing to do the work.
> 
> Wojciech> I know. I could get my old sources of generational garbage
> Wojciech> collector, to work. However it is a daunting job (the worse I
> Wojciech> could imagine, garbage collectors are nasty), plugging and
> Wojciech> debugging a new garbage collector to such huge and esoteric (I
> Wojciech> am sure people that who've been working on Emacs for years
> Wojciech> will not take this words badly and understand straight away
> Wojciech> what I am (a newbie) talking about) project like
> Wojciech> Emacs. However I might try to experiment with it (however
> Wojciech> unfortunately I am not that self confident about it ;) ).
> 
> It is always ok to ask for help.
> 
> The current collector is very simple to understand.  If you read
> alloc.c, and look through the data structures representing lisp objects
> (in lisp.h), you will have a pretty good idea of what is going on.
> 
> 
> FWIW, I looked at writing an incremental collector for Emacs.  I was
> primarily interested in using software write barriers... this turns out
> to be hard because there is a lot of code in Emacs of the form:
> 
>    FIELD_ACCESSOR (object) = value;
> 
> ... which for a software barrier has to be converted to:
> 
>    SET_FIELD_ACCESSOR (object, value);
> 
> (There are other bad things, too, like passing around a Lisp_Object*
> that points to the contents of a vector.)
> 
> So, lots of grunge work, just to get the point where you could start
> actually working on the GC.  I would look at automated rewriting to
> make this work -- that worked out great on the concurrent branch.
> 
> 
> There was a more real attempt based on the Boehm GC.  I think the bits
> from that are still on a branch.  This GC has a generational mode that,
> IIRC, is based on memory protection bits.
> 
> Tom
>