Martin Rubey <[EMAIL PROTECTED]> writes: | Dear Gaby, | | > On 22 Mar 2008 11:50:34 +0100, Martin Rubey <[EMAIL PROTECTED]> | > wrote: | | > > Do you know, or can you point me to, the place where SPADreplace is used? | > > Up to now I thought the lisp compiler would just compile the code.lsp | > > files, but how would it make use of the SPADreplace property then? | > | > see the functions `optSpecialCall' and `opitimize' in src/interp/g-opt.boot. | | many thanks, that was very helpful. I particularly like | | )lisp (setq $|reportOptimization| t) | | !!! | | Although I should be rather doing other stuff, I can't wait to see if I find a | way to produce better optimizations. (and I should admit that I'm rather | pessimistic, because I know next to nothing about compilers...)
Well, look for work done by Neil Jones, Alan Mycroft and friends on Abstract Interpretation for Functional Programming Languages. Mathematically inclined minds should find their ways through. | > The irony of insisting on Lisp is that no matter what you've done to inform | > the translator about the behaviour of your Spad programs, you have to be | > untrusted just as anybody else who did not go through the pain of writing a | > strongly, statically, typed program. No amount of hacks would restore back | > the efficiency lost in translating to such a poorly performing machine. | | Sorry, I do not understand. It'd be interested if you could expand on that. | Are you pointing to a general problem created by introducing an intermediate | step when compiling, i.e., | | SPAD -> Lisp -> machine code vs. SPAD -> machine code I meant that using Lisp sa runtime system is flawed from many points of view -- it is a machine that gets you started very quickly; however, on the long run, it is a liability. | (with sbcl, we do not create intermediate C code, I believe) SBCL is a good Lisp implementation. The problem isn't with SBCL. It is with the choice. | or do you think that it would be easier to optimize | | SPAD -> C -> machine code? I think most of the optimizing transformations done by the Spad compiler are largely language neutral in their spirit. I suspect that my point was that it you target an abstract machine that is bound to introduce inefficiency in the translated code where none existed in the source code, it does not really matter how clever you're at divising hacks to work around a fundamental flaw. -- Gaby ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
