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

[Matthew Mondor]

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.
> 
> The commits basically accomplish the following:
> 
> - ECL uses more braces {} now and less C labels
> - C code is indented, so that the braces reflect the original structure
> - No redundant labels. Formerly you would see "goto L7" followed by L7:
> - Removed redundant C comments, such as functions whose name is evident
> from the C code.
> - More spaces in assignments and function calls
> - Additional optimizations in IF forms leading to more compact C code.
> 
> This is accompanied with a few optimizations in other places.

I'll have to look at this, as I frequently looked at the C code
(generally after passing it through "gindent -kr -l160" first :)
I'll first have to test a more recent gmp though, which is necessary
for ECL HEAD.

The extra labels and gotos were of course optimized out by GCC, but
they indeed added some visual bloat.  Since this is on topic, I
remember reading about various utility macros in the public interface
to setup exception frames etc, but the C generated code didn't use
those macros.  I'm not sure if it makes sense for the generator to use
them or if it'd cause side effects or other problems, but it might be
something to consider, perhaps.

One thing which at first surprised me were these macros expanded from
the corresponding eclh like { VT1 VLEX1 CLSR1 STCK1 ...

The other thing that I remember is that when the code refers to data,
via VV and an offset within a huge array, I'm not sure if it'd be
possible to have some kind of short comment to help knowing what is at
that location...  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?

Not that any of this really matters however, they're very low priority
things.
-- 
Matt