• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 80 subscribers
  • Views 688 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430FR6989: speed packed vs byte aligned vs word aligned MSP430

Yannick Daelemans
Intellectual 590 points
Part Number: MSP430FR6989


Hi all, 

I am absolutely no expert in the data alignment speed comparisons. But from what I gather, it is better to have data alignment on a byte or word level (at least in the MSP430) so that there are direct assembly commands that can be used (eg MOV.B and MOV). This way, the processor needs to do less work and hence save time. 

However, is there any speeds difference between data that is aligned by byte, by word, and by a mixture of the two (which could happen if one would use the 'packed' attribute).

For example, would there be a speed difference when using either of these two structs: 

struct __attribute__((packed)) structure2
{
   int id1;
   char name;
   int id2;
   float percentage;
   char c;
} structure;

VS

struct structure2
{
   int id1;
   char name;
   int id2;
   float percentage;
   char c;
} structure;

The packed one would have a size of 12 bytes, compared to 20 in the non-packed one. However, I would intuitively expect reading out the packed one to be slower, but I am not sure anymore if this would be the case, since the assembler can apparently read out individual bytes too. 

With kind regards.

  • 0
    TI__Expert 7015 points

    Hi, Daelemans, 

    There is no any speeds difference between data that is aligned by byte, by word, and by a mixture of the two. You can compare it by outputting GPIO signals and measure the time duration by oscilloscope. 

    Thanks, 

    Lixin 

  • 0
    Guru 25195 points

    I am not sure where you got the sizes from. I get 12 bytes for the unpacked version: the float is 4, and 4 ints at 2 each. (The char variables take up an extra byte to keep everything else aligned on word boundaries.) Using the packed attribute saves the wasted bytes for the char's but at the cost of making tid2 and percentage unaligned. Accessing those will not go well on something like a MSP430 that cannot automatically do an unaligned word access.

    Assuming that the compiler generates the code for it, it will be slower.

    If you really need to save the space, just move "char name" next to "char c".

  • 0 in reply to David Schultz
    Intellectual 590 points

    Yeah, I was working with the int=4 bytes idea. Forgot it was 2 on the MSP. 

    I have somewhat "found" the solution you came to as well. The only link in my story I did not know was that the MSP430 cannot automatically do unaligned word acces. 

    I already compared assembly code writing in the two different structs, and found exactly the behaviour you describe. Namely at the second int, it writes to bytes because of this disalignment. 

**Attention** This is a public forum