Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32473

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

Show all headers | View raw

On 21/01/2026 04:38, Grant Edwards wrote:
> On 2026-01-20, David Brown <david.brown@hesbynett.no> wrote:
> 
>> (As an aside, I find it annoying that STRD can be interrupted in the
>> middle - it means you don't have an atomic 64-bit store.  LDRD can also
>> be interrupted in the middle, but as it is restarted, it gives you a
>> 64-bit atomic read.)
> 
> Yes, I just noticed that in the manual the other day, and it seemed
> like an odd decision.
> 

It's not odd from the implementation viewpoint, but disappointing from 
the user viewpoint.  The double loads and stores are implemented as a 
sort of combination of two instructions, or at least two actions. 
Disabling interrupts in the middle of the instructions would mean 
additional hardware logic.  (I think all longer-running instructions, 
like divisions, are interruptible.)  When the interrupt returns, the 
instructions are simply restarted.

That gives an atomic 64-bit load, so it lets you safely read 64-bit data 
that is changed by an interrupt or higher-priority thread - unlike using 
two separate 32-bit load instructions.  (Using a volatile read appears 
to force the use of LDRD on gcc for M3 and above, while non-volatile 
reads might be split and re-arranged depending on the surrounding code.)

An interrupted double store is, obviously, a very different matter - 
your interrupt routines or pre-empting threads see half-written data.

My guess as to the decision process is that making these instructions 
non-interruptible would have taken more hardware, and weakened 
guarantees on interrupt latency.  But if they had asked /me/, I'd have 
chosen to make STRD non-interruptible :-)

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