Reducing code size of eLua

[BogdanM]

On Thu, Dec 2, 2010 at 2:15 AM, Martin Guy <[hidden email]> wrote:

>>> comp.Append(CCFLAGS = [...,'-fno-common']
>>>
>>> 110360 -> 109300
>>
>> Interesting, -fno-common didn't make any difference for me. What
>> version of avr32-gcc are you using ? (i'm on 4.3.2)
>
> The same. I was going to say that if the code size change does not
> cross a 512-byte boundary, you may not see the number change, though
> in my case it's a 1KB difference so you should be seeing it.
>
> You *did* remove all .o files before re-running scons?

Yes, I did scons -c first. I guess I still don't fully understand what
-fno-common does. However, it helped you and it didn't do anything bad
for me, so it's probably a good idea to use it anyway.

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On Thu, Dec 2, 2010 at 1:20 AM, Bogdan Marinescu
<[hidden email]> wrote:
> I still don't fully understand what -fno-common does.

If you have a global "int a;" in one file and also in a different
file, using -fno-common *doesn't* make them the same variable, but
leaves you with two separate variables.
That way, GCC can be sure that an uninitialized global will always be
in the same section as the code that references it, hence nearby, so
can use a short offset to access them instead of a full 32-bit
address.

Like I say, it saved 1% here. Nothing like the 10% you found though!

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Thu, Dec 2, 2010 at 2:31 AM, Martin Guy <[hidden email]> wrote:
> On Thu, Dec 2, 2010 at 1:20 AM, Bogdan Marinescu
> <[hidden email]> wrote:
>> I still don't fully understand what -fno-common does.
>
> If you have a global "int a;" in one file and also in a different
> file, using -fno-common *doesn't* make them the same variable, but
> leaves you with two separate variables.

So, if you have this:

int a; // file1
int a; // file2

there are two 'a' variables? Interesting :) GNU ld doesn't do this by
default, it tries to collapse the two global variables into a single
one. It might break some code that doesn't use 'extern'. Not eLua
though :)

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On Thu, Dec 2, 2010 at 10:39 AM, Bogdan Marinescu
<[hidden email]> wrote:

> On Thu, Dec 2, 2010 at 2:31 AM, Martin Guy <[hidden email]> wrote:
>> On Thu, Dec 2, 2010 at 1:20 AM, Bogdan Marinescu
>> <[hidden email]> wrote:
>>> I still don't fully understand what -fno-common does.
>>
>> If you have a global "int a;" in one file and also in a different
>> file, using -fno-common *doesn't* make them the same variable, but
>> leaves you with two separate variables.
>
> So, if you have this:
>
> int a; // file1
> int a; // file2
>
> there are two 'a' variables? Interesting :) GNU ld doesn't do this by
> default, it tries to collapse the two global variables into a single
> one. It might break some code that doesn't use 'extern'. Not eLua
> though :)

Yes. In very early versions of C (circa 1974), there was no "extern"
keyword, so header files said "int a", which was then included in many
files. The unification behaviour was retained so as not to break
existing code.  These days of course, you put "extern" in the header
file and define the variable in one .c file, so it should make no
difference.

    M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

> Yes. In very early versions of C (circa 1974), there was no "extern"
> keyword, so header files said "int a", which was then included in many
> files. The unification behaviour was retained so as not to break
> existing code.  These days of course, you put "extern" in the header
> file and define the variable in one .c file, so it should make no
> difference.

I don't like to do that. I declare the variable in one .c file and
then 'extern' it in every .c file that actually need it. This way is
much more clear which file needs the variable; if you put it in a
header it's not immediately obvious if the .c file that includes the
header needs that variable or includes the header for other purpose.
Of course this doesn't change the semantics, it's just a matter of
style.
Thanks for the C lesson, I didn't know that "extern" wasn't there from
the beginning.

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev