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.
I am writing a project for the MSP430F5419 using CCS v4.1.2.00027.
I have a C header file containing structure definitions which include unions used to provide bit and byte access to a flag:
struct SYSVARS_FIXED
{
unsigned char ucCommsAlarmState;
unsigned char ucBattThresh;
/// (FLAGS) General flags showing status of various events
union STATUSFLAGS_BB
{
/// Byte access to flag
unsigned char ucByte;
/// Bit access to flag
struct STATUSFLAGS_BITS
{
unsigned char b0 :1;
unsigned char b1 :1;
unsigned char b2 :1;
unsigned char b3 :1;
unsigned char b4 :1;
unsigned char b5 :1;
unsigned char b6 :1;
unsigned char b7 :1;
} bits;
} flStatusFlags;
unsigned char zdepVectors[6];
unsigned char ucTest;
....etc...
};
An instance of this struct is declared and used ok in C code but when I try to access it in an assembler file (using .cdecls to include the header file) the addresses of the later elements of the struct are slightly incorrect:
e.g. "MOV.B #4, &sv_fix.ucTest" is assembled as "MOV.B #4, 0x1c0a" when the actual address of the element is 0x1c09.
The problem appears to be that the C compiler aligns the flag union as a single byte however the asm .cdecls interpretation aligns it as a word - adding an extra byte of blank space. I have several similar unions in this (and other) structure(s) and the assembler access displays progressively larger errors when accessing the later elements. One way to remove the problem is to declare the union element as ints, thus forcing the alignment to be the same for the C code and the asm code however this obviously fills up variables with undesirable padding so I consider it more of a bodge than a fix.
The MSP430 Assembly Language User Guide (slau131d sect 12.2.13) states " C/C++ structures and unions are converted to assembly .struct and .union elements. Padding and ending alignments are added as necessary to make the resulting assembly structure have the same size and member offsets as the C/C++ source." suggesting to me that the structure should be interpreted correctly by the .cdecls...
Am I missing something? Are there any assembler/compiler/other commands that I can use to force the assembler and compiler interpretations to match up?
Thanks in advance.
Chris.
Thank you for letting us know about this problem. This is a bug in .cdecls handling. I filed SDSCM00037422 in our SDOWP system. Feel free to track it with the SDOWP link in my sig below. I cannot think of a better workaround than the one you have found.
Thanks and regards,
-George
FWIW, I think this bug may not be related to unions, but to bitfields. The following code, when assembled with 'cl2000 -v28 -al bar.asm', uses a size of 3 for the structure when it should be 2. If element c of the structure is moved to the beginning of the structure, the size of the struct becomes 2. If I allocate this structure from C code, the .bss allocation size is always 2. I've confirmed this behavior with both version 5.2.11 and 5.2.9, and I'm quite certain I've seen it in earlier versions.
.cdecls list
%{
struct foo {
unsigned a : 15;
unsigned b : 1;
unsigned c;
};
%}
mov al,#$sizeof(foo)
thanks,
galen
Apologies. I didn't notice that the original poster was using the MSP430. I'm using the 280x. Would you like me to start a new thread?
thanks,
galen