On Sun, Dec 2, 2012 at 4:22 AM, Matthew Mondor <span dir="ltr"><<a href="mailto:mm_lists@pulsar-zone.net" target="_blank">mm_lists@pulsar-zone.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sun, 2 Dec 2012 01:09:15 +0100<br>
Juan Jose Garcia-Ripoll <<a href="mailto:juanjose.garciaripoll@gmail.com">juanjose.garciaripoll@gmail.com</a>> wrote:<br>
<br>
> Last week I got a bit mad trying to read out the C code generated by ECL<br>
> and so I decided to clean it up a bit. The result is a rather large set of<br>
> patches which are being uploaded as I write. Testing of these patches will<br>
> proceed in the following days, but I expect no major divergences. </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"> </div></blockquote>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'll have to look at this, as I frequently looked at the C code<br></blockquote><div><br></div><div>Please report any thing you find odd about it, such as unoptimized or weird C code.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The extra labels and gotos were of course optimized out by GCC,</blockquote><div><br></div><div>Hopefully, but ECL works with a variety of compilers and I am not sure it always performed so well. Analysis of code becomes cumbersome in that situation.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">various utility macros in the public interface<br>
to setup exception frames etc, but the C generated code didn't use<br>
those macros.<br></blockquote><div><br></div><div>Yes, it would be nice to use those macros now that the code is indented, but before it did not make much sense. Note also that the macros are not always as good as the generated C code (which may for instance save unused branches in CATCH, UNWIND-PROTECT, etc.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One thing which at first surprised me were these macros expanded from<br>
the corresponding eclh like { VT1 VLEX1 CLSR1 STCK1 ...<br></blockquote><div><br></div><div>This is a very old artifact dating back to KCL to be able to output the function declarations _after_ the body of the function has been built. Will be fixed soon.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The other thing that I remember is that when the code refers to data,<br>
via VV and an offset within a huge array,</blockquote><div><br></div><div>Noted.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Another possibility would be to have multiple data<br>


arrays, which perhaps might also mitigate the issue when using inline<br>
constants vs the 64K limit of the Microsoft compiler?<br></blockquote><div><br></div><div>I recall having tried this in the past.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Not that any of this really matters however, they're very low priority<br>
things.</blockquote></div><div class="gmail_extra"><br></div>If you need to analyze the generated code it becomes quite important after some time.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Juanjo<br clear="all">

<div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>


</div>