What alignment is needed for an 8-bit AVR?

I would expect the 8-bit AVR platform to require no alignment. However, I found the following comment in the LLVM commit :

The previous data structure caused problems when working with atomics.

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

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

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

Most of the alignment controls were intact since I originally imported the old SVN repository from SourceForge. I haven't done this much, and therefore my knowledge is rather poor.

It's safer to assume that if something looks intentional, it probably isn't: P

What is alignment history on (8-bit) AVR?

+3


source to share


1 answer


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

In a classic AVR processor, 16-bit data alignment is not required, since access to 16-bit memory is always evaluated with two 8-bit samples for two registers.

There is some "alignment limitation" though using an instruction movw

available on some AVRs that moves data from one register pair to another. Here, the lower case register number must be even. However, this has nothing to do with memory alignment, but can make a difference when building the compiler and possibly also when trying to access the contents of a register via a register file as memory (lowest 32 RAM addresses), depending on exactly how the compiler is implemented ... The compiler may restrict itself to having the option open to access 16-bit values ​​in registers through memory access to the register file, which would then really need word alignment.



The second type of "alignment constraint" is applied when trying to write to program memory (Flash). The manual explicitly states that in the SPM instructions, the least significant bit of the address must be cleared. This is understandable since the AVR flash is word-addressed according to the minimum instruction size. However, you can readprogram memory with byte addresses using the LPM command. However, since direct access SPM is not supported on all AVRs, I don't know if this is actually relevant. How SPM and "atomic types" will relate to each other, as this can lead to noticeable errors - when writing, accessing program memory, all access must be done as atomic, disabling interrupts. And gcc still handles accessing program memory in libraries.

Outside of these specific cases (register file, program storage), the AVR memory has absolutely no problem accessing word values ​​at odd addresses.

+4


source







All Articles