Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32475

Re: arm-gcc, Cortex-M0+, uint64_t and alignment

Show all headers | View raw

On 21/01/2026 09:11, pozz wrote:
> Il 20/01/2026 18:44, David Brown ha scritto:
>> On 20/01/2026 18:09, pozz wrote:
>>> Il 20/01/2026 17:41, Grant Edwards ha scritto:
>>>> On 2026-01-20, David Brown <david.brown@hesbynett.no> wrote:
>>>>
>>>>> You can't reduce the alignment of a struct or its elements by 
>>>>> adding an
>>>>> __aligned_ attribute to the struct itself or any of its fields.  The
>>>>> best you can do on the struct itself is __attribute__((packed)).  But
>>>>> that can come with disadvantages, and inefficient use.
>>>>
>>>> Yep making a structure aligned is an excellent way to introduce subtle
>>>> bugs that happen when somebody, somewhere passes a pointer to one of
>>>> those structure fields to some library function. 
>>>
>>> However, as long as the application runs on Cortex-M0+, the aligned 
>>> version shouldn't introduce issues, should it?
>>>
>>>
>>
>> Correctly aligned data is never a problem.  /Misaligned/ data is a 
>> problem.
>>
>> The Cortex-M0+ cannot access misaligned data directly.  But if the 
>> compiler knows that it is misaligned - by "packed" struct, or 
>> "aligned" attribute on the typedef - it should break apart the 
>> accesses into bytes or 16-bit half-words as necessary.  (Aligning a 
>> uint64_t to 4 byte alignment will not be a problem.)
> 
> However for Cortex-M0+ uint64_t aligned at 4 bytes is:
> - aligned for the core (two 4-bytes aligned accesses are required)

Yes.  As far as I know, the M0+ core does not need any alignment greater 
than 4 for any purpose.  (But I might not know everything about the 
core!)  There can be alignment requirements for other things, such as DMA.

> - misaligned for the ABI and the compiler

Yes.

> 
> We agree that forcing the gcc compiler to consider 4-bytes as the 
> required alignment of uint64_t (using aligned attribute) is always safe. 

No.

It will almost always be safe, but you don't have any guarantees.  The 
compiler knows that if "p" is of type "uint64_t *", then "(uintptr_t) p 
& 0x07" will always be zero.  Is it likely that you would have anything 
in your code where that is relevant, and also that the compiler would 
generate code that relies on that assumption?  No, it is very unlikely.

But there is a general principle that you should not lie to your 
compiler - don't write code that executes UB, breaks ABIs, or is 
otherwise breaking the contract you have with the compiler unless you 
are using compiler features that let you keep everything honest.

Part of that is that code you are writing now for the M0+ might be 
copied or adapted to a different target at a different time.  Maybe on a 
different core, the same data will be read using some kind of SIMD or 
vector instruction that /does/ require 8-byte alignment.  Don't mess 
these things without telling your compiler.  And don't mess with them 
without telling future maintainers and programmers using the code 
(including your future self).

I would be extremely surprised to find code that fails to work on an M0+ 
because of a uint64_t pointer that is 4-byte aligned but not 8-byte 
aligned.  But if /I/ want to use 64-bit integers with 4-byte alignments, 
I'd use the typedef'd aligned type for the object type and for any 
relevant pointers.


> However, what really changes in the binary output?
> 
> In some cases, the address of uint64_t can change from 8-bytes to 
> 4-bytes aligned address (because we instructed it to do so). What about 
> the code that accesses uint64_t aligned to 4-bytes? Is it identical 
> between 4- and 8-bytes alignment requirement? I think so, because in 
> both case, the compiler should add two load/store 4-bytes instructions.
> 

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

arm-gcc, Cortex-M0+, uint64_t and alignment pozz <pozzugno@gmail.com> - 2026-01-20 13:26 +0100
  Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-20 17:07 +0100
    Re: arm-gcc, Cortex-M0+, uint64_t and alignment Grant Edwards <invalid@invalid.invalid> - 2026-01-20 16:41 +0000
      Re: arm-gcc, Cortex-M0+, uint64_t and alignment pozz <pozzugno@gmail.com> - 2026-01-20 18:09 +0100
        Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-20 18:44 +0100
          Re: arm-gcc, Cortex-M0+, uint64_t and alignment pozz <pozzugno@gmail.com> - 2026-01-21 09:11 +0100
            Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-21 10:02 +0100
              Re: arm-gcc, Cortex-M0+, uint64_t and alignment pozz <pozzugno@gmail.com> - 2026-01-21 15:58 +0100
                Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-21 17:13 +0100
                Re: arm-gcc, Cortex-M0+, uint64_t and alignment pozz <pozzugno@gmail.com> - 2026-01-21 17:57 +0100
                Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-22 10:03 +0100
        Re: arm-gcc, Cortex-M0+, uint64_t and alignment Grant Edwards <invalid@invalid.invalid> - 2026-01-20 17:48 +0000
      Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-20 18:41 +0100
        Re: arm-gcc, Cortex-M0+, uint64_t and alignment Grant Edwards <invalid@invalid.invalid> - 2026-01-20 18:10 +0000
          Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-20 22:32 +0100
            Re: arm-gcc, Cortex-M0+, uint64_t and alignment Grant Edwards <invalid@invalid.invalid> - 2026-01-21 03:38 +0000
              Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-21 08:54 +0100
    Re: arm-gcc, Cortex-M0+, uint64_t and alignment pozz <pozzugno@gmail.com> - 2026-01-20 17:55 +0100
      Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-20 22:24 +0100

csiph-web