Skip to main content
Sego2
Sego2
Associate II
April 15, 2022
Question

Code alignment questions

  • April 15, 2022
  • 2 replies
  • 2035 views

Hello,

I am working with STM32G0 with uCOS-II.

I was reading some of the actions are fragile to unalignment;

I was wondering how to align the code. As per now, the only command I know is :

#pragma data_alignment =8 which I use just before launching the OS.

I was wondering if every variables or other ressource. should be aligned or if my previous line

#pragma data_alignment = 8 would be enough. to align all the code.

Also, how can I verify that every ressource is aligned? ( I mean does every thing perceivable on dissasembly would be located at a pair addresse? )

Additionally how can I check if a functions check for alignment ? ( I've heard about memcmp for example which is susceptible of checking alingment )

On the image below a R4 value is an unpair addresse for example

Thank you!

0693W00000Ly5TXQAZ.png

This topic has been closed for replies.

2 replies

S.Ma
S.Ma
Principal
April 15, 2022

Usually the compiler linker does a good job. What is special are DMA accessed arrays which should be 16 or 32 bit aligned in some cases. This is where the pragma will be mostly needed first.

Tesla DeLorean
Tesla DeLorean
Guru
April 15, 2022

Ok, but what is R4 in this context?

Looks to be the address of code in FLASH.

Remember Cortex-M devices execute only 16-bit THUMB mode code, the code addresses will be ODD, as this flags it's 16-bit code, rather than EVEN which is 32-bit ARM code which it CAN'T execute.

You might want to consider reading the processor architecture manuals, or supporting materials like Joseph Yiu's Essential Cortex-M series books.

You just have to watch memcpy() memcmp() or inline optimizations some compilers perform, if the optimizer makes poor decisions with limited information, short copies can be translated to register based LDR/STR or LDRD/STRD combos which can expose alignment issues if it assumes pointers are what they claim to be. There's a general expectation that uint32_t* will be aligned, and it's really that reckless casting from uint8_t* / void* pointers is where the headaches start.

I'd imagine most compilers have white papers on such topics.

When debugging perhaps use assert()s liberally, and be more careful about casting pointers, and pay more attention to warnings about incompatible type conversions.

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
Terms & ConditionsAccessibility statement