<div class="gmail_quote">On Sat, Dec 26, 2009 at 9:44 PM, Marko Kocić <span dir="ltr"><<a href="mailto:marko.kocic@gmail.com">marko.kocic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I just came across some mails from about a year ago about LLVM back<br>
end in ECL. Is this idea still viable? Also, what is the status of new<br>
compiler implementation?</blockquote><div><br></div><div>As of these days I am just making sure both compilers can coexist and that ECL is able to build itself using the new one. The last part is not yet done and no code has yet been pushed to the main repository. I will not do that until I get some stability.</div>
<div><br></div><div>The new compiler is much better structured than the old one. It consists on a kind of "parser" layer that builds an intermediate representation which is a merge between the current interpreter and the old compiler's C1FORMs.</div>
<div><br></div><div>The advantage is that now this intermediate representation is linear: just a list of forms, instead of a nested and very complicated graph. This simpler structure is much much easier to process. Eliminating unused variables and forms without side effects is about 10 lines. Creating the code graph and eliminating dead code chunks will be just as simple. It will also help me in concentrating, simplifying and better rationalizing the code for deciding variables representations, etc.</div>
<div><br></div><div>After all that pre-processing, which is really optional, a final backend produces the C code. This is yet the ugliest part of it all and needs to be reorganized, but that is just a consequence of how I have incrementally developed the new compiler -- instead of just pushing in the code in my blog --.</div>
<div><br></div><div>My goals are, right now,</div><div><br></div><div>* Make ECL build itself and pass all tests</div><div>* Push the code into the repository</div><div>* Improve type inference, which is broken in the new representation</div>
<div>* Improve decisions based on unboxing</div><div>* Code graph and dead code elimination</div><div>* Reorganize the backend in a separate package and a smaller set of files</div><div><br></div><div>A longer term plan</div>
<div><br></div><div>* A pass to build SSA code, that is, ensuring static-single-assignment by introducing new temporaries</div><div>* A new backend for LLVM</div><div>* A new backend for the interpreter</div><div><br></div>
<div>Hope this answers some of your questions about the future. I think that once Step 1 is done, anyone willing to could collaborate in the project.</div><div><br></div><div>Juanjo</div></div><br>-- <br>Instituto de Física Fundamental, CSIC<br>
c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a><br>