Re: Preprocessor

Raymond Toy <toy(a)rtp.ericsson.se&gt; writes: 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. 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. 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.