This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Odd memory allocation of structure

I have a structure defined as

struct typeEEDevConf {
unsigned long         EEulng52modCfg;
unsigned long         EEAulngA[5];
unsigned int          EEAuintM[5];
unsigned int          EEAuintB[5];
unsigned char         EEuchrDispIntensity;
unsigned char         EEuchrTopDispIndex;
unsigned char         EEuchrBtmDispIndex;
unsigned char        EEAuchrDisplayParams[16];
unsigned int          EEuintDispUpdateRate;
unsigned char         EEuchrWaveType;
struct typePIConst    EEudtPIConst;
struct typePWMCtrl    EEudtPwmCtrl;
unsigned char         End;     //only used to get address of end of struct
};
struct typeEEDevConf EEDevConf;

There is a discrepency in size of this structure. Manually counted, I get 60 bytes (where 1byte = 16bit). The sizeof(EEDevConf) operator returns 62 bytes. If I take the difference of the start and end address of the structure, I get 61. ie (&EEDevConf.End - &EEDevConf + 1 = 0x61, the +1 is to account for the size of EEDevConf.End).

After some digging, I find that there is a byte in between EEuchrWaveType & EEudtPIConst. ie:

&EEDevConf.EEuchrWaveType = 0x912A

&EEDevConf.EEudtPIConst = 0x912C

What happened to memory at 0x912B? I find the value at 0x912B to be: *((char *)0x912B) = 0xA042.

 

You may ask why it matters. The reason is because I have external EEPROM chip that I copy this entire structure to, so I have to account for every byte.

  • Hi Henry,

    structures are aligned to the even address by the compiler so the 0x912B is a padding word inserted by the compiler. From my experience it is smart to allocate data within structure sorted by the size of data (e.g. first come the structures, than longs and floats and at the end ints and chars)

     

    Regards, Mitja

  • Mitja's answer is very close, but not quite accurate.  The compiler aligns a structure to the most restrictive alignment required by any member it contains.  

    Also, be aware that different compilers, even for the same CPU, may lay out a structure differently.  Using a structure to model hardware layout is inherently not portable.  Be prepared to change this code if you ever change compilers.

    Thanks and regards,

    -George

     

  • Thanks for the info. What exactly is the most restrictive alignment? Is there documentation on how different types are aligned?

    Yes, I do have my code written to be portable. The entire structure is copied exactly as is, including padding. I was just curious why it was the way it was.

  • I should have said "largest" instead of "most restrictive".  Documentation on how types are aligned is in the compiler manual for your target.  All of the TI compiler manuals are available in this Wiki article http://tiexpressdsp.com/index.php/Before_asking_for_CGT_support .

    Since a different compiler may lay that structure out differently, describing hardware layout with a structure is inherently not portable.  Note I am not saying you are doing this the wrong way.  I'm just pointing out one disadvantage.  When all things are considered in balance, a structure could be the best overall choice.

    Thanks and regards,

    -George