Author Topic: data alignement(GNU GCC Compiler)  (Read 7034 times)

manny

  • Guest
data alignement(GNU GCC Compiler)
« on: September 11, 2005, 05:51:02 pm »
Don't know if this a right place to ask about compiler options but since I use Code::Blocks I've decided to post here.

for example I create this structure:

   struct   test
   {
      char   buff[5];    // 5 bytes
      DWORD   var;  // 4 bytes
   };

sizeof(test) returns 12 instead of 9. Second variable starts only from 8th byte instead of 5th. Is there some compiler option in GCC GNU Compiler to remove 32bit data alignement in structures?

p.s. Use WindowsXP.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: data alignement(GNU GCC Compiler)
« Reply #1 on: September 11, 2005, 05:54:04 pm »
-fpack-struct

However, be really careful with such options, these create code that is not binary compatible with other code!

EDIT:
And that is not all, it also creates code that is an awful lot less efficient and takes an awful lot more instructions.
Everything found in http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Code-Gen-Options.html should be handled with a lot of prudence because you can run into problems that may not be not obvious.
« Last Edit: September 11, 2005, 05:57:08 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

grv575

  • Guest
Re: data alignement(GNU GCC Compiler)
« Reply #2 on: September 11, 2005, 09:05:26 pm »
Yeah keep in mind that assembly programers (who obviously care most about speed), put in
align 16
statements before branches and data structures all the time to force alignment.  The cache fetching memory system run much faster if it's not unaligned access.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: data alignement(GNU GCC Compiler)
« Reply #3 on: September 12, 2005, 12:58:53 am »
Plus, in addition to unaligned access, which is a lot slower already, you need an additional shift instruction (and sign extension) to access your data. Opposed to all that is saving 3 bytes of memory, which is nothing (except if you have a million elements).
If your struct has more elements, you may even be able to use the currently unused space by cleverly arranging elements (the compiler might for example fill bool values into the holes).
Also, speaking of "arranging", you generally help the compiler a lot to produce good code if you group things of the same size and put the "larger" types (unsigned long int in this case) first and the "smaller" ones (like char[5]) second.  That ensures that the compiler can properly align everything without wasting a lot of space. In this particular case, it makes no difference, but with more elements, it does. There are a few good tutorials out there how to efficiently arrage structs, but I was unable to find one right now.

If you write a device driver and need that structure to access a hardware register with a specific layout, then of course you must use -fpack-struct and use that very layout.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."