Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Bill Gatliff <bgat at billgatliff dot com>]

Vincent:


Gcc's unoptimized code is extremely bloated, but I don't have a problem 
with that.  I think it's set up that way to make debugging easier, or 
something to do with compiler backends, or something (remember, I'm not 
on the gcc team!).  So the fact that gcc's unoptimized output is larger 
than anyone else's is neither surprising, or discouraging.  At least to me.

With optimizations turned on, however, I've seen gcc really close the 
gap with ADS since the 2.95.x days.  I haven't done any formal 
comparisons, but I haven't seen any heinous output from gcc, either.  
I'll be very interested to find out where the size difference is coming 
from.

One potential source is runtime libraries.  ADS's library structure is 
pretty granular, and their linker seems to be pretty good at discarding 
unused code.  GNU-compatible runtime libraries don't seem to be as 
fine-grained in their implementation as ADS, so the GNU linker isn't as 
helpful at keeping unused modules and/or functions out of the resulting 
image.  Or maybe it's because the GNU linker is more simplistic, and the 
library architecture isn't the source of the bloat.  Dunno.

At any rate, I've seen this contribute to size differences from time to 
time, although the difference was usually small for real-world 
programs.  The difference is frequently huge for "hello, world!", 
however, mostly because the bulk of that application *is* the runtime 
library.  That isn't realistic, and so I don't use hello-world as a 
benchmark for anything except the ability to get a clean link.  :^)


b.g.



Vincent Rubiolo wrote:

> Thank you Richard, Bill and Yves for your replies,
>
> More info about on what I want to achieve : the conversion of our 
> project from ADS 1.2 to the GNU toolchain. The project uses some code 
> which is provided by another company for hardware interfaces along our 
> own code.
>
> As of today, the conversion seems fine. Files were adapted and the 
> global behaviour is acceptable (some regression tests still failing 
> though).
>
> Richard :
> The --mstructure-size=8 option helped gaining little space. Quoting 
> from ADS 1.2 manual, the alignment rules are much more complex than 
> those of gcc for structures _members_ :
>
> Field alignment
> Structures are arranged with the first-named component at the lowest 
> address. Fields are aligned as follows:
> ·A field with a char type is aligned to the next available byte.
> ·A field with a short type is aligned to the next even-addressed byte.
> ·Bitfield alignment depends on how the bitfield is declared. See 
> Bitfields in packed structures for more information.
> ·All other types are aligned on word boundaries.
>
> So we may run into problems with others structs (see end of post for 
> expl of problematic struct).
>
>
> Bill and Yves :
> The padding problem came of the following struct declarations :
>
> typedef struct
> {
> ... (16 bits members)
>   unsigned short int Bob;
>   struct2 Jane;
> ... (other stuff)
> } struct1;
>
> where struct2 is the following :
>
> typedef struct
> {
>    unsigned char   A[11];
>    unsigned char   Reserved;
> } struct2;
>
> With ADS, Bob is aligned on a 16 bits boundary and Jane begins just 
> after so everything is fine. With gcc, padding is inserted after Bob 
> to reach a 32bit boundary hence system crashes because these 
> structures are HW mapped. The packed attribute solved the issue for 
> that struct.
>
> Behind my question was the issue of code footprint.
> I have found that the GNU toolchain produces code which is 30 to 50% 
> bigger than the one of ADS, especially when debugging info is turned 
> off. As I stated before, the project uses mixed ARM and THUMB code, so 
> interworking is in the brawl. I am trying to figure, with the help of 
> the binutils, why does gcc produces such big code.
>
> We have two memory zones, RAM (little code, mainly data) and FLASH 
> (code).
> If debugging information is not enabled, ADS outstands GNU by 63% on 
> FLASH and 12% in RAM (optimised for size on both).
> If debugging is enabled, the difference falls to 13 and 10% (still 
> optimised or size for gcc, no optimisations for ADS).
>
> I am still investigating and trying to find ways to reduce the footprint.
>
> Thank you again for your consideration.
>
> Regards,
>
> Vincent

--
Bill Gatliff
Linux, NetBSD, RTEMS, eCos: yea, I do free software!
bgat@billgatliff.com



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com