On Sun, Dec 2, 2012 at 4:22 AM, Matthew Mondor <mm_lists@pulsar-zone.net> wrote:
On Sun, 2 Dec 2012 01:09:15 +0100
Juan Jose Garcia-Ripoll <juanjose.garciaripoll@gmail.com> wrote:

> Last week I got a bit mad trying to read out the C code generated by ECL
> and so I decided to clean it up a bit. The result is a rather large set of
> patches which are being uploaded as I write. Testing of these patches will
> proceed in the following days, but I expect no major divergences. 
I'll have to look at this, as I frequently looked at the C code

Please report any thing you find odd about it, such as unoptimized or weird C code.
The extra labels and gotos were of course optimized out by GCC,

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.
various utility macros in the public interface
to setup exception frames etc, but the C generated code didn't use
those macros.

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.
One thing which at first surprised me were these macros expanded from
the corresponding eclh like { VT1 VLEX1 CLSR1 STCK1 ...

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.
The other thing that I remember is that when the code refers to data,
via VV and an offset within a huge array,

Another possibility would be to have multiple data
arrays, which perhaps might also mitigate the issue when using inline
constants vs the 64K limit of the Microsoft compiler?

I recall having tried this in the past.
Not that any of this really matters however, they're very low priority

If you need to analyze the generated code it becomes quite important after some time.


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)