This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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





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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]