On Wed, Aug 26, 2009 at 2:30 AM, Tom Schouten<[email protected]> wrote: > Bout time I have a look at it then.. Is the compiler tied in closely > to the rest of the system? I'm wondering if I it would be difficult > to embed it in PLT Scheme through the concatenative -> Scheme wrapper > macros used in Staapl.
Factor has two compilers. And yes, in theory you can port the whole system over to PLT Scheme, but at that stage it would be so much more advanced than PLT Scheme itself that you may as well build your own, self-hosting Scheme implementation, and before you know it you'll have a multi-year project on your hands :-) The source code for Factor's optimizing compiler is located in basis/alien, basis/compiler and basis/cpu. Within basis/compiler, you'll find that compiler.cfg and its subvocabularies are somewhat like a set of classical compiler passes resembling stuff you'd find in a text book (value numbering, copy propagation, etc), whereas compiler.tree contains Factor-specific stuff (most importantly a 'propagation' pass which infers types and inlines methods in a really general way). These two complement each other; they are the 'low-level' and 'high-level' optimizers, respectively. The remaining two parts of the optimizing compiler play a supporting role: the C FFI is in basis/alien and CPU-specific backends are in basis/cpu. You can look at the output of the optimizing compiler's two optimization passes: USE: compiler.tree.debugger ! Look at high-level optimizer IR [ 1000 [ ] times ] optimized. USE: compiler.cfg.debugger ! Look at low-level optimizer iR [ 1000 [ ] times ] test-mr mr. The optimizing compiler always compiles a word at a time, with quotations used in that word folded in most cases. The optimizing compiler more closely resembles the compilers of languages such as Ocaml, SBCL and C, than Forth implementations. The non-optimizing compiler, on the other hand, is a classic Forth-style subroutine-threaded compiler with inlining and tail-call optimization. It compiles individual quotations, not words, into linear code blocks without any internal control flow. The non-optimizing compiler is implemented in C++, in vm/jit.cpp and vm/quotations.cpp. It is used for bootstrap as well as a fallback for dynamic quotation execution. The CPU-specific backends are in basis/cpu/*/bootstrap.factor. If you construct a quotation using sequence words at runtime, and call it using call(, it will be instantly compiled into really compact code by the non-optimizing compiler. In this sense it differs from a Forth compiler in that it is completely transparent; the non-optimizing compiler is completely encapsulated as far as 'user-space' Factor code is concerned, because its presented in terms of a simple notion of completely dynamic quotations which are also callable. The non-optimizing compiler can load source an order of magnitude faster than the optimizing compiler; its runtime is essentially linear in the length of a quotation, and the constant factor is very low, whereas the optimizing compiler performs a lot of expensive static analysis which operate on entire words at a time. Compare loading time of modules such as "regexp" after entering enable-optimizer and disable-optimizer in the listener. On the other hand, the optimizing compiler produces code that runs up to 100x faster (benchmark.mandel is one example where quotation inlining, complex float unboxing, value numbering and what Dan referred to as DCN all contribute to an order of magnitude difference between subroutine threading and optimized SSA). Slava ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
