This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB
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