Linker / Compilier Auto aligh uint_32's?

[CarlFST60L]

Hi,

MQX3.6.2 + CW7.2+MCF52259evb

I have the following C file

in envm.c#include <ctype.h>#include <mqx.h>#include <bsp.h>#include "envm.h"#pragma explicit_zero_data on#pragma force_active onvolatile uint_32 TEST1 = 1;         //This is a specific random number defined in the headervolatile uchar TEST2 = 0;volatile uint_32 TEST3 = 2;         //This is a specific random number defined in the headervolatile uchar TEST4 = 4;        //Compile Time#pragma explicit_zero_data off#pragma force_active off

In my linker, I added the following twoENVM_DATA   (RW): ORIGIN = 0x10050000, LENGTH = 0x00001000  # MRAM space for some dataand .ENVM_DATA_Page: {  envm.c (.data)  envm.c (.rodata)  envm.c (.text) } > ENVM_DATA

In xMAP output I get the following:

# .ENVM_DATA_Page
  10050000 00000004 .data   TEST1    (envm.c)
  10050004 00000001 .data   TEST2    (envm.c)
  10050008 00000004 .data   TEST3    (envm.c)
  1005000C 00000001 .data   TEST4    (envm.c)

I want to understand why TEST3 is aligned at 10050008 instead of 10050005

I have tried adding the following in my linker, the results were the same

. = ALIGN (0x1);

Is there a reason for this? Is it normal? Can I force them to be 'one after the other' and still work as expected?

[JuroV · Accepted solution]

Hi Carl,

what you see is normal behaviour of compiler, where all 32-bit value is aligned. That's because of bus access optimization.

You can use #pragma align as the compiler directive to change default alignement of a variable.

[CarlFST60L]

Thanks for the reply,

I would have though that . = ALIGN (0x01); would have worked.

Thanks again, we ended up using a slightly different techniques to get around the issue we were having.

Thanks again,

Carl

[JuroV]

You know, accessing unaligned variables can have impact not only to linker, but also to compiler- depends on architecture (getting each byte and assembling a 32bit value). That's why the #pragma is used during compilation time.

[CarlFST60L]

That makes sense, thanks JuroV!