The spec mentions that the M0 will generate a Hardfault when unaligned accesses are detected. I would like to find out where is this implemented in RTL and understand it a little better.
Does the GCC compiler detects unaligned code accesses during compilation as well?
eugch said:Is the performance penalty here referring to the compiler splitting unaligned accesses into separate (more) instructions - say 1 unaligned word access into 2 aligned hword accesses?
_Only_ if the compiler knows about the access.
struct unaligned { char a; int b; } __attribute__((packed));
Here, the compiler will likely split the access to "b" into multiple operations. But you should try. Maybe it "knows" that the Cortex-M can do unaligned accesses.
Note: The struct must be packed, else the compiler will insert 3 dummy bytes _after_ "a".
Also if you do something like this:
char a;
char b;
char c;
char d[4];
GCC will often put each at a word boundary, especially for debug builds (-O0). When you optimize for size it might pack them, it might not. I have seen code done where by luck gcc was placing all variables on word boundaries which masked some bugs in the code. For example one customer was taking 4 byte array to a float by *(float *)d. Which worked just fine because GCC allocated char d[4] on a word boundary by luck.
Thanks guys, that's gives me an idea where to start if I need to pursue this further.
I typically work on the RTL end of the MCU, so I'm trying to understand how the firmware and hardware work together with respect to unaligned/aligned memory accesses.