Re: Preprocessor

Hrvoje> My favorite strategy for elisp-to-C is the one (I think) originally Hrvoje> proposed by Kyle Jones some time ago: look at the opcodes that our Hrvoje> current compiler generates. Now look at the code in bytecode.c that Hrvoje> interprets it. A simple translator would simply take byte-compiled Hrvoje> code and translate it into C that looks like bytecode.c, but inlined Hrvoje> to directly *do* the stuff that P-code wants to do instead of Hrvoje> interpreting the P-code. Hrvoje> Although this looks simple-minded, I believe it would be a *huge* Hrvoje> speed win over the current virtual machine. First, the cost of Hrvoje> interpretation would be removed, which is by itself a big win -- Hrvoje> the huge `case' statement would finally be eliminated. Secondly, such Hrvoje> "unwound" C code would be processed by the C optimizer which would Hrvoje> remove the many many redundant checks and thus make the code run Hrvoje> really fast. Hrvoje> The advantage of this strategy is that it opts for huge speedup in a Hrvoje> *realistic* environment, i.e. it doesn't require rebuilding 100% of Hrvoje> XEmacs to work. Furthermore, it builds on the work already invested Hrvoje> in the byte-code compiler. I've done some thinking about this in the past. This is a very EASY translator to write compared to some of the other projects being considered. The hard part is integrating this into xemacs. Like figuring out the shared object loading mechanism across platforms. Should all the package lisp be compiled to .so at installation time, or should there be a JIT that optimizes hotspots at run-time (it would have to call the compiler transparently to do so, however). Don't expect it to be a huge win, however. All the optimized machine code will take up more memory than the bytecodes. And many elisp operations like (setq i (1+ i)) will not be compilable to C i++, but instead will still require expensive frobbing of the lisp symbol `i'. A function call like (foo) will still require the notoriously slow Ffuncall, even if foo is a subr, due to the dynamic nature of lisp. But this is a great hack.