Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32470

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

Show all headers | View raw

On 20/01/2026 17:55, pozz wrote:
> Il 20/01/2026 17:07, David Brown ha scritto:
>> On 20/01/2026 13:26, pozz wrote:
>>> I just discovered that my arm-gcc assigns an alignment of 8 to a 
>>> struct with uint64_t member.
>>>
>>> First of all: I can't explain why. Cortex-M0+ shouldn't have any 
>>> special load/store instructions for 64-bits data. I think the 
>>> uint64_t variable is *always* accessed with two separate instructions.
>>>
>>
>> There are other Cortex-M devices that /can/ access 64 bit data with a 
>> single instruction (though not always as an atomic function).
>>
>> Compilers use family ABI's, not ABI's specifically tuned for exact 
>> devices.  The EABI for 32-bit ARM says long long's are 8 byte aligned, 
>> so that's what is used for all targets that use the EABI.  (There's a 
>> lot to dislike about the EABI - this is not the worst thing.)
> 
> So the ABI used by arm gcc is EABI that is valid for a list of Cortex-M 
> devices, a few of these that require 8-byte alignment of 64-bits integers.
> 

I don't think any of the 32-bit Cortex-M cores actually need 8 byte 
alignment in the hardware - it could have been for compatibility with 
64-bit devices.

> 
>>> Second thing. Is it safe to force the alignment of such structs to 4 
>>> with __attribute__((aligned(4)))?
>>
>> 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.
> 
> But this is the opposite of what you write below!

No, but I might have been unclear.

Adding the "aligned" attribute to the /struct/, or to the field members 
/directly/, does not help you here.  Adding it to a new typedef does.

> 
> 
>>> I have big arrays of structs that contains uint64_t members, so I'm 
>>> thinking how to save some space.
>>
>> The best way is to organise the fields so that they are naturally 
>> aligned, and don't have padding for alignment.  I like "-Wpadded" to 
>> tell me if there is unexpected padding.
>>
>>
>> What you /can/ do, however, is define a type that is 64 bits, but 4 
>> byte alignment:
>>
>> typedef uint64_t __attribute__((aligned(4)) uint64_a;
>>
>> Now you can use "uint64_a" instead of "uint64_t", and it will have 4 
>> byte alignment.
> 
> Before you wrote it's impossible to reduce the alignment from 8 to 4 
> with __attribute__((aligned(4))), but now you write it is possible.
> 

Putting it in a typedef lets you change the alignment.

See <https://godbolt.org/z/3fac7n7Yo>, and look at the code generated 
for the M0+ and the M4 to see how "packed" and "aligned" affects things.

Back to comp.arch.embedded | Previous | Next — Previous 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