Hello All,
My I cannot see it documemented how CrossWorks arranges (ie packs) its
structures on an MSP430.
I know that compilers for 'larger micros' often 'pad' the
structure elements so that they fit on a 16bit/32 bit boundary.
But I cannot see where this is documented for the CrossStudio Compiler and
looking at my data (as memory) is not 'definitive'.
It seems to me that there would be a performance advantage to word-align
structures on a MSP.
But OTOH RAM is precious, so byte alignment would be 'more optimal'.
Which is it? Can _I_ control it?
FWIW, I am storing the contents of some data structures to serial memory.
This memory will then be read by a utility on a PC.
Think of a data logger type of app where the MPS430 logs stuff to NVMEM and the
PC reads the NVMEM, decodes the raw binary and 'does stuff'.
I did think about storing the data out is a more data agnostic format (CSV!?)
but I am trying to maximise the number of logged events - so storing it in
'binary' is the most compact,
Besides I can do the byte massaging on the PC - if I can just be certain whist
data to expect.
FWIW my structure is like that show below -
typedef struct user
{
INT8U rec_idx;
INT8U rec_type;
INT8U name[MAX_NAME_LEN+1]; // 17
INT8U key[MAX_KEY_LEN+1]; //9
INT8U tag[MAX_TAG_LEN]; //7
INT8U flags;
time_t expire_date; // 4
time_t start_time; // 4
time_t end_time; //4
}LOG_STRU;
TIA,
Ivan Vernot
How Does Crossworks layout structures on an MSP430
Started by ●August 5, 2005
Reply by ●August 5, 20052005-08-05
Ivan, > Hello All, > My I cannot see it documemented how CrossWorks arranges (ie > packs) its structures on an MSP430. > I know that compilers for 'larger micros' often 'pad' the > structure elements so that they fit on a 16bit/32 bit boundary. > But I cannot see where this is documented for the CrossStudio > Compiler and looking at my data (as memory) is not 'definitive'. > > It seems to me that there would be a performance advantage to > word-align structures on a MSP. > But OTOH RAM is precious, so byte alignment would be 'more optimal'. > Which is it? Can _I_ control it? The packing is chosen by the compiler and you cannot control the way in which the compiler lays out structures other than by defining the order of the fields. The alignment requirements of each type are specified in the manual, hence a struct with a char and an int will require four bytes of storage with one byte padding. > > FWIW, I am storing the contents of some data structures to > serial memory. > This memory will then be read by a utility on a PC. > Think of a data logger type of app where the MPS430 logs > stuff to NVMEM and the PC reads the NVMEM, decodes the raw > binary and 'does stuff'. > > I did think about storing the data out is a more data > agnostic format (CSV!?) but I am trying to maximise the > number of logged events - so storing it in 'binary' is the > most compact, Besides I can do the byte massaging on the PC - > if I can just be certain whist data to expect. > FWIW my structure is like that show below - typedef struct user { > INT8U rec_idx; > INT8U rec_type; > INT8U name[MAX_NAME_LEN+1]; // 17 > INT8U key[MAX_KEY_LEN+1]; //9 > INT8U tag[MAX_TAG_LEN]; //7 > INT8U flags; > time_t expire_date; // 4 > time_t start_time; // 4 > time_t end_time; //4 > }LOG_STRU; The general idea would be to put all your byte-aligned data first, as you have, then all word-aligned data. Byte-aligned data is packed on a byte basis with no padding, of course. Regards, -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, AVR and now MAXQ processors
Reply by ●August 5, 20052005-08-05
Thanks for the reply Paul, ----- Original Message ----- From: "Paul Curtis" <plc@plc@...> To: <msp430@msp4...> Sent: Friday, August 05, 2005 5:48 PM Subject: RE: [msp430] How Does Crossworks layout structures on an MSP430 <snip> >> I cannot see it documemented how CrossWorks arranges (ie >> packs) its structures on an MSP430. > > The packing is chosen by the compiler and you cannot control the way in > which the compiler lays out structures other than by defining the order > of the fields. The alignment requirements of each type are specified in > the manual, hence a struct with a char and an int will require four > bytes of storage with one byte padding. Sorry, Paul - WHERE is that - I could not find it... So if I understand you correctly my structure would be laid out in memeory as follows - INT8U rec_idx; INT8U rec_type; INT8U name[17]; // MAX_NAME_LEN+1 **PAD BYTE 1 INT8U key[9]; // MAX_KEY_LEN+1 **PADBYTE 2 INT8U tag[8]; //MAX_TAG_LEN INT8U flags; **PAD BYTE 3 time_t expire_date; // 4 time_t start_time; // 4 time_t end_time; //4 So I have 4 bytyes of padding? Is that right? Looking bak at the raw datad I think I only see PAD BYTE 4. Can you please confirm where the pad bytes will end up. The switchinhg between PC and Embeeded sys coing, poutring over memmory duymps makes my head hurt! > > The general idea would be to put all your byte-aligned data first, as > you have, then all word-aligned data. Byte-aligned data is packed on a > byte basis with no padding, of course. Yes I do this (almost) by instinct... So, if my understanding is correct - if I reorder 'flags' to be the third field I'll actually save 2 bytes. wohoo'-) Is that correct? Thanks Ivan > > Regards, > > -- > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk > CrossWorks for MSP430, ARM, AVR and now MAXQ processors > >
Reply by ●August 5, 20052005-08-05
On Fri, Aug 05, 2005 at 07:49:51PM +1000, Ivan Vernot wrote:
> So if I understand you correctly my structure
would be laid out in memeory
> as follows -
> INT8U rec_idx;
> INT8U rec_type;
> INT8U name[17]; // MAX_NAME_LEN+1
> **PAD BYTE 1
> INT8U key[9]; // MAX_KEY_LEN+1
> **PADBYTE 2
> INT8U tag[8]; //MAX_TAG_LEN
> INT8U flags;
> **PAD BYTE 3
> time_t expire_date; // 4
> time_t start_time; // 4
> time_t end_time; //4
>
> So I have 4 bytyes of padding? Is that right? Looking bak at the raw datad
I
> think I only see PAD BYTE 4. Can you please confirm where the pad bytes
will
> end up. The switchinhg between PC and Embeeded sys coing, poutring over
> memmory duymps makes my head hurt!
This byte padding is relevant in your case because you want to transfer your
struct to the PC in binary format. Maybe it is better (considering a
possible compiler change or a change in the compiler or a change of the PC
host system (64bits?) ;:-) to transfer the struct byte-wise to the PC.
Well this adds overhead (code and time), but you will be on the safe side.
At least, I would add some kind of CRC to your struct - you can be sure
that on the PC side the struct has arrived successfully (and you get notified
of this error very early after a update and not by accident).
M.
Reply by ●August 5, 20052005-08-05
Hi
msp430@msp4... schrieb am 05.08.05 11:55:14:
>
> On Fri, Aug 05, 2005 at 07:49:51PM +1000, Ivan Vernot wrote:
>
> > So if I understand you correctly my structure would be laid out in
memeory
> > as follows -
> > INT8U rec_idx;
> > INT8U rec_type;
> > INT8U name[17]; // MAX_NAME_LEN+1
> > **PAD BYTE 1
> > INT8U key[9]; // MAX_KEY_LEN+1
> > **PADBYTE 2
> > INT8U tag[8]; //MAX_TAG_LEN
> > INT8U flags;
> > **PAD BYTE 3
> > time_t expire_date; // 4
> > time_t start_time; // 4
> > time_t end_time; //4
> >
> > So I have 4 bytyes of padding? Is that right? Looking bak at the raw
datad I
> > think I only see PAD BYTE 4. Can you please confirm where the pad
bytes will
> > end up. The switchinhg between PC and Embeeded sys coing, poutring
over
> > memmory duymps makes my head hurt!
>
> This byte padding is relevant in your case because you want to transfer
your
> struct to the PC in binary format.
many compiler can use the option packed for using no pading. But even than that
struct
is not portable: On MSP430 it's little endian (on PPC/Mac it's big
endian) and time_t
has 8 (not 4) Bytes on Alpha, IA64, AMD64 ..., and after 2038.
So it can work but after an upgrade to an 64 bit OS and compiler on the PC
i'm sure it won't.
Structs are more portable when you implement them as a union with fields of
standard ints
(uint8_t, ...).
Regards,
Rolf
