What alignment is needed on 8-bit AVR?

Question

I would have expected the 8-bit AVR platform to not require any alignment. However, I've found the following comment in an LLVM commit:

The previous data layout caused issues when dealing with atomics.

For example, it is illegal to load a 16-bit value with less than 16-bits of alignment.

This changes the data layout so that all types are aligned by at least their own width.

Unfortunately, the original author of this commit isn't sure if that is right either:

Most of the alignment stuff has been untouched since I originally imported the old SVN repository from SourceForge. I haven't dealt with it much and so my knowledge is pretty poor.

Safest to assume that if something looks intentional, it probably isn't ;P

What exactly is the alignment story on (8-bit) AVR?

Answer 1

This comment doesn't make any sense to me. AVR does not natively know 16-bit-types, and specifically not atomic access to 16-bit-types, regardless of any alignment.

On a classic AVR CPU, alignment of 16 bit data is not required as 16-bit memory access always evaluates to two 8-bit fetches to two registers.

There is a kind of "alignment restriction", though, when using the movw instruction available on some AVRs that moves data from one register pair to another - Here the register number of the lower registers must be even. This has nothing to do with memory alignment, though, but may have implications when building a compiler and maybe also when trying to access register content through the register file as memory (lowest 32 RAM addresses), depending on how exactly the compiler is implemented. The compiler might limit itself by keepint the option open to be able to access 16-bit values in registers through a memory access into the register file which would then indeed need word-alignment.

A second kind of "alignment restriction" applies when trying to write to program memory (Flash) - The manual explicitly states that on "SPM instructions, the least significant bit of the address should be cleared". This is understandable, as the AVR's flash is word-addressed according to the minimal instruction size. You can, however, read program memory byte-addressed with the LPM instruction. As direct-access SPM is not supported on all AVRs anyhow, I don't know if this is relevant at all, though. How SPM and "atomic types" would relate to each other escapes meas well - When write accessing program memory, the whole access must be made atomic anyhow, by disabling interrupts. And gcc handles program memory access in libraries anyhow.

Outside this specific cases (register file, program memory store) the AVR has absolutely no problems whatsoever to access word values on odd addresses.