ccsv5 compiler5.0.1 big-edian ARM
Does the compiler5 treat the first member of a struct as the MSB ,diffrent from ccs2 ?
Is there any instruction to make the first member to be LSB?How can I make the "0x0002"match to "Charge = 1",just like the struct is a nomal data?
I tried use RBIT and change the struct define.Any other ways?
I have read the EABI migration document,but it just refers to the number of address a struct takes up ,and doesn't refer to the sequens of the bits. The C compiler user guide describe the struct store in memory,but it's diffrent from my test result.
example in C compiler user guide :"Bit fields are packed in memory from most significant byte to least significant byte ."
1.The big-edian talks about bytes,when the bit field talks about bits.Are they completely independent ?
2.The followed three points look like incompatible,which make me puzzled:
first,TMS570 Manual indicate that Big-endian systems store the most-significant byte of a multi-byte data field in the lowest memory address.Writing 0x11223344 to address 0xFFF7F448 shows the following when viewing the memory in 8-bit modes.
So for a 32bit data,the most-significant byte is discribed as byte3,when the least-significant byte is discribed as byte0.
second, C compiler user guide indicate that Bit fields are packed in memory from most significant byte to least significant byte .But it's example indicate the bit field definitions and corresponding bit-field packing as follows:
my question:in this example,which byte is the significant byte,byte0 or byte3?Is this byte3 also is stored in the lowest memory address?
fan Linlin said:2.The followed three points look like incompatible,which make me puzzled:
first,TMS570 Manual indicate that Big-endian systems store the most-significant byte of a multi-byte data field in the lowest memory address.Writing 0x11223344 to address 0xFFF7F448 shows the following when viewing the memory in 8-bit modes.
So for a 32bit data,the most-significant byte is discribed as byte3,when the least-significant byte is discribed as byte0.
By "TMS570" manual, I presume you mean the TI document "ARM Optimizing C/C++ Compiler User's Guide." Is that correct? Which version, exactly?
That document talks about storage of bit-fields to memory being done with a byte-by-byte, rather than bit-by-bit, transfer. You should ignore this for now, because that only makes a difference for little-endian mode. Focus on the bit layout in a register, which does not refer to bytes. You only need to know the memory layout if you attempt to read parts of the field directly from memory without going through the C language bit-field access, and only if you are in little-endian mode.
From the diagram for "Big-endian register", you will see that the fields are indeed packed starting at the Most Signficant (MS) bit, and packed bit-wise. For a big-endian bit-field, the MS bits will indeed end up in the MS byte.
Here is a program demonstrating how the bits get packed. You should study the output of this program, and watch the memory of the object as the program executes.
#include <stdio.h>
union {
struct{
unsigned int A:7;
unsigned int B:10;
unsigned int C:3;
unsigned int D:2;
unsigned int E:9;
} x;
unsigned int whole;
} u;
int main()
{
int i;
u.whole = 0;
puts("filling A");
for(i=0;i<7;i++)
{
u.x.A = (1<<i);
printf("%08x\n", u.whole);
}
u.whole = 0;
puts("filling B");
for(i=0;i<10;i++)
{
u.x.B = (1<<i);
printf("%08x\n", u.whole);
}
u.whole = 0;
puts("filling C");
for(i=0;i<3;i++)
{
u.x.C = (1<<i);
printf("%08x\n", u.whole);
}
u.whole = 0;
puts("filling D");
for(i=0;i<2;i++)
{
u.x.D = (1<<i);
printf("%08x\n", u.whole);
}
u.whole = 0;
puts("filling E");
for(i=0;i<9;i++)
{
u.x.E = (1<<i);
printf("%08x\n", u.whole);
}
}
third,in my test I defined a struct,
typedef union
{
struct
{
uint16 SelfCheckG : 1;
uint16 Charge : 1;
uint16 Modulate : 1;
uint16 DischargeRotor : 1;
uint16 Bit4 : 1;
uint16 Bit5 : 1;
uint16 Bit6 : 1;
uint16 Bit7 : 1;
uint16 SelfCheckR : 1;
uint16 Synchronize : 1;
uint16 Connect : 1;
uint16 FaultReset : 1;
uint16 Bit12 : 1;
uint16 Bit13 : 1;
uint16 Bit14 : 1;
uint16 Bit15 : 1;
} B;
uint16 all;
} unAppMainCtrlWordMode4;
And in the view of memory,it shows:
It shows the first member SelfCheckG as the bit0.And you said that the first member will be the MSB,the same as C compiler user guide indicate that Bit fields are packed in memory from most significant byte to least significant byte .It's incompatible that SelfCheckG is bit0 and at the same time MSB.
