Re: Emacs Lisp JIT Compiler

[Tom Tromey <tom@tromey.com>]

>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:

Tom> Now, one thing that is portable is compiling Emacs Lisp code to C.  For
Tom> example, it would be easy to compile all the bytecode that is dumped
Tom> into Emacs.  The drawback is that this is just a fraction of what users
Tom> use; and would probably not show major benefits.  But, maybe it would
Tom> help some.  And, it would certainly allow some existing C code (looking
Tom> at you, widget-put) to be moved to Lisp, which seems worthwhile to me.

I wrote a bytecode->C compiler to see what this would look like.  It is
set up to walk the obarray and compile every lexically-bound bytecode
function that it finds there.

The resulting .o files are roughly the same size as the rest of the
Emacs .o files.  So, maybe that's a bit too big.  One idea would be to
segregate the code that is to be compiled.  This would allow rewriting
some of the C code into Lisp at least.

Another issue is that runtime linking -- that is, associating the
compiled code with the bytecode -- is hard.  My current approach (which
isn't fully hooked up yet) is to use the doc string index as a key.
However, this is not fantastic because it means that undocumented
functions can't be compiled.

Runtime linking is needed because of two issues; otherwise the compiler
could just emit DEFUNs.  One, I didn't want to deal with compiling
complex lisp constants to C.  Doing this properly would mean introducing
initialization code.  Two, I think the DEFUN approach wouldn't work for
closures.

Perhaps if the segregation approach were taken, there could just be some
rules against closures and complex constants, and the compiler could
error if they were introduced.

Tom