Cortex-M4: atomares Load oder Store

[Raoul D. (raoul_d219)]

Es geht um Cortex-M4+Fpu.
Der g++ macht aus

   volatile uint64_t x1;
   volatile uint64_t x3;

int main(){
    while(true) {
        x3 = x1;
    }
}

ein

main:
ldr     r0, .L4 @ tmp118,
ldr     r1, .L4+4       @ tmp119,
.L2:
ldrd    r2, [r0]        @ x1.0_1, x1
strd    r2, [r1]        @ x1.0_1, x3
b       .L2             @

oder manchmal auch ein

vldr.64 d7, [r5]        @ int   @ x1.0_1, x1
vstr.64 d7, [r4]        @ int   @ x1.0_1, x3

wenn der Registerdruck zunimmt. Also ein atomares load oder store. Ich 
meine keine atomaren RMW-Zyklen, das kann der Cortex-M generell nicht 
(dazu existiert ldrex/strex oder IRQ-Sperre).

Die Frage nun: gibt es ein GCC-intrinsic, womit ich feststellen kann, 
bis zu welcher Größer ein fundamentaler DT atomar gelesen oder 
geschrieben werden kann. Auf einer 32-Bit CPU kann ich sicher 32-Bit 
annehmen, aber hier geht ja auch 64-Bit.

[Johann L. (gjlayde)]

sig_atomic_t ?

[Raoul D. (raoul_d219)]

Johann L. schrieb:
> sig_atomic_t ?

Das ist ein Typ-Alias für int. Und der ist 32_bit, so wie es auch

# define SIG_ATOMIC_WIDTH 32

sagt.

Das wäre ja auch meine Vermutung gewesen. Ich bin nun etwas erstaunt, 
dass das auch für 64-Bit geht.

[Johann L. (gjlayde)]

Raoul D. schrieb:
> Ich bin nun etwas erstaunt, dass das auch für 64-Bit geht.

Was heißt es "geht auch" für 64-Bit?

Das Makro sagt, dass es für (unsigned) int geht.  Mehr nicht.

Ansonsten z.B. atomic Built-ins

https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html

[Vincent H. (vinci)]

Raoul D. schrieb:
> Das wäre ja auch meine Vermutung gewesen. Ich bin nun etwas erstaunt,
> dass das auch für 64-Bit geht.

Tut es nicht. Weder LDRD noch VLDR ist atomar.

https://developer.arm.com/documentation/ddi0403/latest/
(siehe S. A3-80)

std::atomic<T>::is_always_lock_free dürfte ein guter Indikator für deine 
zweite Frage sein:

#include <atomic>

static_assert(std::atomic<uint32_t>::is_always_lock_free);
static_assert(std::atomic<uint64_t>::is_always_lock_free); // Fails on 32bit M4

[J. S. (jojos)]

Sind in CMSIS keine Makros dafür vorhanden?

[Raoul D. (raoul_d219)]

Vincent H. schrieb:
> Raoul D. schrieb:
>> Das wäre ja auch meine Vermutung gewesen. Ich bin nun etwas erstaunt,
>> dass das auch für 64-Bit geht.
>
> Tut es nicht. Weder LDRD noch VLDR ist atomar.
>
> https://developer.arm.com/documentation/ddi0403/latest/
> (siehe S. A3-80)

Perfekt, danach habe ich gesucht!

[Arm (arm_arm)]

LDRD wird als 2 Instruktionen ausgeführt, diese kann aber nicht durch 
eine exception unterbrochen werden (s. B1 - 543, im Kontrast zu LDM).

Damit sollte LDRD auf single cores effektiv doch atomar sein?

[Bauform B. (bauformb)]

Arm schrieb:
> LDRD wird als 2 Instruktionen ausgeführt, diese kann aber nicht durch
> eine exception unterbrochen werden (s. B1 - 543, im Kontrast zu LDM).

An der Stelle wird LDRD/STRD nicht erwähnt und in A3.5.3 (S.80) heißt es

LDM, LDC, LDC2, LDRD, STM, STC, STC2, STRD, PUSH, POP, VLDR, VSTR,
VLDM, VSTM, VPUSH, and VPOP instructions are executed as a sequence
of word-aligned word accesses.
(...)
If an instruction is executed as a sequence of accesses according to
these rules, some exceptions can be taken in the sequence and cause
execution of the instruction to be abandoned. On exception return,
the instruction that generated the sequence of accesses is re-executed
and so any accesses that had already been performed before the exception
was taken might be repeated.

> Damit sollte LDRD auf single cores effektiv doch atomar sein?

Ich würde mich nicht darauf verlassen.
Außerdem darf man "core" nicht zu eng sehen. Zum Beispiel ist DMA auch 
ein Bus Master, genau wie die CPU und beide sind (nur) per 32 Bit 
angebunden. Theoretisch(?) könnte ein Buffer per DMA gefüllt werden und 
zur Verarbeitung liest jemand mit LDRD.