[Ecls-list] Large set of changes (~29 commits)

[Juan Jose Garcia-Ripoll]

On Sun, Dec 2, 2012 at 4:22 AM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:

> On Sun, 2 Dec 2012 01:09:15 +0100
> Juan Jose Garcia-Ripoll <juanjose.garciaripoll at 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,


Noted.


> 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
> things.


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

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121202/89523b32/attachment.html>