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

[Tom Tromey]

>>>>> "Wojciech" == Wojciech Meyer <address@hidden> writes:

Tom> So, lots of grunge work, just to get the point where you could start
Tom> actually working on the GC.  I would look at automated rewriting to
Tom> make this work -- that worked out great on the concurrent branch.

Wojciech> Maybe that work should be actually done even without thinking
Wojciech> currently about GC. AFAIR MT Emacs rewriting was in Elisp,
Wojciech> ideally maybe using GCC would be better at some point.

You would have to hack GCC a little bit, because most of the code
locations you want to change arise from macro expansion, and GCC does
not keep all that information.  (Though there's a WIP patch for this.)

Maybe it could be done more simply using a simple parser in elisp that
recognizes just the needed forms.  Or maybe something based on clang.

This would get you most of the way there, though there are still some
bad things you have to fix up by hand.


For the concurrency stuff, we did two kinds of automated rewriting.

One was just pure elisp that searched the .c for DEFVAR_LISP and then
made various changes.

The other one modified the source (in a compile-breaking way), then ran
the compiler, then visited each error to perform a rewrite.  This
approach might also work for the GC problem, I am not certain.

These scripts are both in src/ on the concurrency branch.

One problem with any compiler-based approach is that it only works on
the sources it sees.  That is, the not-taken #if branches won't get
rewritten.  This argues for trying some kind of custom parser.

Another problem we ran into is that this approach doesn't work if the
problem code itself appears in a macro.  There were a few spots that we
had to fix by hand -- no big deal, the automation is still worthwhile
even if it only does 85% of the work.


My advice is to try to do this bulk rewriting work on head, so that it
doesn't rot.  I think that's been a problem for the concurrency work :-(

Tom