Re: Preprocessor
Hrvoje Niksic writes:
Raymond Toy <toy(a)rtp.ericsson.se> writes:
> Then why not use gcl then?
Because it's highly questionable how useful Gcl is.
To be useful in short-term future, an elisp-to-C translator should not
try to reimplement XEmacs from scratch or to turn Elisp into Common
Lisp (or, for that matter, CLtL1).
My favorite strategy for elisp-to-C is the one (I think) originally
proposed by Kyle Jones some time ago: look at the opcodes that our
current compiler generates. Now look at the code in bytecode.c that
interprets it. A simple translator would simply take byte-compiled
code and translate it into C that looks like bytecode.c, but inlined
to directly *do* the stuff that P-code wants to do instead of
interpreting the P-code.
CLiCC was designed to do something like this. The web site references
a PostScript file that describes their method better than I am about to
attempt.
CLiCC actually compiles the Lisp to a set of specialized C macros
which are then compiled by a normal C compiler. Perhaps CLiCC could
be adapted to use the (X)Emacs bytecode C code.
One major advantage of CLiCC is that it is designed to do global
optimization for the entire application. This is something that C
compilers rarely (if ever) do.
Although this looks simple-minded, I believe it would be a *huge*
speed win over the current virtual machine. First, the cost of
interpretation would be removed, which is by itself a big win --
the huge `case' statement would finally be eliminated. Secondly, such
"unwound" C code would be processed by the C optimizer which would
remove the many many redundant checks and thus make the code run
really fast.
I have found that simple is usually best.
Craig
The advantage of this strategy is that it opts for huge speedup in a
*realistic* environment, i.e. it doesn't require rebuilding 100% of
XEmacs to work. Furthermore, it builds on the work already invested
in the byte-code compiler.