On 23 December 2010 10:23, Ian Piumarta <[email protected]> wrote: > Hi Michael, > > On Dec 20, 2010, at 06:39 , Michael Haupt wrote: >> take a look at Ian's recent S3 paper, download the corresponding source >> code, and have fun. > > I'm glad you had fun with that code. > > Here's another small example that might provide some fun. > > http://piumarta.com/tmp/maru > > (On Linux, type "make". On Darwin, edit the first line of emit.l to set > __MACH__ to anything other than () then type "make". MinGW has library > issues and doesn't work -- sorry.) > > This is a metacircular evaluator for an s-expression language, plus a "level > shift" from s-expressions down to IA32 machine code to escape the infinite > metacircular regress. > > boot-eval.c contains a reader/evaluator for the s-expression language, > written in C. eval.l contains the same evaluator, written in the > s-expression language. emit.l contains a compiler from s-expressions to IA32 > machine code, written in the s-expression language. boot.l contains some > data structures and algorithms needed by emit.l, written in the s-expression > language. > > boot-eval.c is compiled and then run on boot.l+emit.l+eval.l to create > eval.s, a machine code implementation of the s-expression evaluator. eval.s > is then assembled and linked to make eval, which can be run on > boot.l+emit.l+eval.l to create eval.s. The C compiler is then entirely out > of the loop (unless you lose a working evaluator and need to bootstrap again). > > The s-expression language has a few interesting characteristics. You can get > a feeling for some of them by looking how messaging and multimethods are > implemented. The compiler makes some attempt to be small and simple (1750 > loc for all three ".l" files, including some debugging cruft that could be > removed) and no attempt whatsoever to optimise. Even so, the generated code > runs at 40% the speed of aggressively-optimised C on my E5430, measured by > the convenient macro benchmark: dividing the run time of regenerating eval.s > via eval by that of generating it initially via boot-eval.
Interesting. The code it emitting using only three registers: eax, ecx and esp. And without any heavy optimization and any kind of register allocation whatsoever, it is 40% of speed of optimized C code. This number is interesting. A lot of energy and thousands of human hours put to make a high optimization compilers, just to run 2.5 faster than "naively" generated code? I can't believe! :) So, the main questions which raising your number is: do we need a high optimization compilers ? do we need a CPU with so much instructions and registers? > > Wrap up warm against all that snow, and have a happy new year! > > Regards, > Ian > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
