I've posted on my blog about the next release of my Church-State system: http://subvert-the-dominant-paradigm.net/blog/?p=41
---------------------------------------- * Macros and dynamic compilation February 17th, 2009 I have released the next version of my Church-State system at: http://subvert-the-dominant-paradigm.net/~jewel/church/church-alpha-1.tar.gz. This release adds proper Church macros and dynamic compilation to the system. In this example, a macro for moving an immediate value to a register macro MOVLir imm reg << _Or_L 0xb8 (_r4 \reg) \imm >> you can see quoted code wrapped in angular brackets and backslashes used to unquote values that must be inserted into the template. The macro syntax is not final (like most of Church’s syntax) and it should look cleaner as it matures. To handle macros like these the system is now capable of taking Church source code parsed out of the macro body, compiling it to low-level State code and then compiling and linking the resulting machine code into the running image. This involves resolving low level symbols (I use dlsym) and modifying the Church dispatch tables and macro rewriters to use the new macros. I also have to run an initialization function which sets up the “code vector” with constant values (interned symbols etc). Now that I have dynamic compilation working, it should be fairly easy to add a REPL to the system. * Performance As part of this release I have also disabled a lot of optimizations that I had worked on before. These include inline caches for method dispatch and slot access. The reason I have disabled these optimizations is that they cost too much in terms of space compared to the benefit they provide in improved speed. I’m now pursuing a new approach which uses “class wrappers” marked with random seeds. The idea is that these seeds can be used to hash into lookup tables which memoize the effective method for dispatch. I hope to be able to incorporate these ideas plus others from contemporary implementations (of javascript vms etc) to make the system substantially faster. John Leuner On Fri, 2009-02-06 at 16:01 +0200, John Leuner wrote: > I'm pleased to announce the first release of my Church-State system. > Church-State is an experimental programming language based partly on > fonc projects (OMeta and jolt-burg). Church is a dynamically typed > language along the lines of lisp / smalltalk / python / ruby. > > It features: > > - an indented syntax like python / haskell that uses spacing to > determine structure > > - an object system with classes and dynamic dispatch > > - lisp-style macros (church macros are not completely implemented yet) > > - a native code compiler that creates ELF object files > > This release marks the first point where the Church compiler can compile > itself (making it a meta-circular system). From the outset I was keen to > see what it would take to make a language that could compile itself > using a minimum amount of source code and with a minimal reliance on > third party libraries. > > As released this system is about 10 000 lines of code, relies on > "ld" (the UNIX linker), a third party hash-table implementation and the > Boehm garbage collector. > > These are the release notes from the announcement on my blog: > > http://subvert-the-dominant-paradigm.net/blog/?p=40 > > ------------------------------------------------------------- > > *Church release* > > I’m proud to have reached the stage where my Church-State system can > compile itself (ie the compiler is bootstrapped). > > I have made the first alpha release available at: > > http://subvert-the-dominant-paradigm.net/~jewel/church/church-alpha-0.tar.gz > > To try it out you’ll need a 32-bit x86 linux system with “ld” installed. > (Usually ld will be installed if you’ve installed something like gcc). > > There are two simple test files mentioned in the README and there are > also instructions for bootstrapping the system. > > One thing missing from the release is a compiler that compiles the > output from the OMeta parser generator to Church files. That means it’s > not possible to change the grammars just yet. > > Another incomplete feature is that Church and State macros are > hard-coded into the compiler. If you look at church-pass1.church and > state-pass1.church you’ll see the various hard-coded macros (some of > which are quite complex). To be able to include these macros in the > source files where they are used I need to be able to dynamically > compile and load church code. I’ve completed the first step of this > process, see state-dynamic.church and church-test-dynamic-alloc.church > for working code that can compile a church file down to native code, > allocate memory for it and link it into the running image. > > Once I have Church macros working, I plan to rewrite a lot of > assembler-i386.church to use macros instead of functions for emitting > machine instructions. I think that this will dramatically improve > compilation times. While preparing for this release I did a lot of work > on performance, even removing array bounds checking and some other > safety checks to make it faster. Currently the system bootstraps in 90 > seconds on my laptop, but my goal is to be 2 or 3 times as fast. > > John Leuner > > > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
