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@xxxxxxxxxxxxxxx
