<div dir="ltr">On Sat, Sep 13, 2008 at 2:23 AM, Gabriel Dos Reis <span dir="ltr"><<a href="mailto:gdr@integrable-solutions.net">gdr@integrable-solutions.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
However, I realize that ECL reports 8.9.0 as version, when previously<br>
it said 0.9l.  I was under the impression that you did not want to<br>
release 1.0 before the compiler is stable.  How should I interpret<br>
the new version?</blockquote><div> </div></div>Well, I have become a bit fed up with the old compiler. It does the job pretty well, but it is a mess to maintain, it is not very flexible and it duplicates the effort that I want to put into the bytecodes compiler, which currently, together with the library, is the most stable component in ECL.<br clear="all">
<br>Besides that, one sometimes needs an additional motivation to keep working, so I have decided to put the old compiler in pure maintainance mode and find me a more interesting task, which is to write a compiler from scratch.<br>
<br>As I have it in mind, this is going to be an incremental task. First born as a new frontend to the bytecodes system, it should coexist with it. It is going to be developed solely in lisp, though I do not discard a translation to C for stability and self-bootstrapping. The design should be based on two layers: a lisp -> SSA translation and two SSA -> anything backends, one for bytecodes and one for C. All in all, the library should remain the same and that is already more than 90% of the code.<br>
<br>SSA stands for static single assignment and it is something that I accidentally discovered by reading the LLVM manual and similar literature (*) It is really what the current lisp->C translator should have had from scratch, for it makes it so much easier to do type propagation and discovery of the actual representation of objects, as well as experimenting with different backends and doing unit testing of the different layers of the translator.<br>
<br>Also, SSA is well suited for doing lifetime analysis and register allocation, which is what the current bytecodes compiler is desperately missing. And finally, if we have an SSA frontent, perhaps some adventurous guy (not me) would find it easy enough to emit LLVM internal representation and thus get both an optimizing compiler and a JIT engine.<br>
<br>Anyway, this is currently my pet project. I guess it is going to take 10 times the time that it would take if I did not have a real life, a job and a mortgage to pay, but as I said before, one needs more than just polishing corners of something that already works pretty well (the interpreter and library) or trying to stretch something which is too limited by design (the current lisp->C translator)<br>
<br>And this is also the reason why I stopped thinking about 1.0 versions this week.<br><br>Juanjo<br><br>(*) Please bear in mind I am no Computer Scientist, and I am just finding out things 20 years later :-)<br><br>-- <br>
Instituto de Física Fundamental<br>CSIC, Serrano, 113, Madrid 28040 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a><br>
</div>