On 16.02.2023 19:56, heby wrote:
> On 16/02/2023 19:11, Grzegorz Niemirowski wrote:
>>> Przecież zlinkowałem arykuł, w którym masz jasno wypisane powody i
>>> ostrzeżenie.
>> I w sumie jako rozwiązanie podają std::atomic. Ciekawe czy atomic z C
>> też może być.
>
> A co broni użyć C++, szczególnie na nowej arch? Nawet na AVR to zmiana 2
> literek na dwa + w nazwie kompilatora i strata bodaj 4 bajtów na
> dodatkową sekcję, którą można łatwo usunąć, jak ktoś sępi. Więc na arch,
> gdzie atomic ma implementację, to powinno kosztować asymptotyczne zero.
A gdzie ma implementację? Bo na np. ARMv6-M (Cortex-M0 itp.) czy starą,
ale nadal żywą ARMv4T (np. ARM7TDMI) nie ma - kompilator woła funkcje
zewnętrzne (https://godbolt.org/z/xxjb1Khnc), które sam musisz sobie
zaimplementować bo libatomic dla tych architektur nie jest wspierana.
Więc może volatile + trochę ,,static inline" będzie szybsze - w sensie
zarówno pisania kodu jak i jego wykonania. :-)

Na ARMv7-M jest lepiej, ale IMO nie idealnie:
https://godbolt.org/z/o4Mj6er51 - niezbyt rozumiem dlaczego dla
64-bitowego inta jest wołana funkcja zewnętrzna zamiast zinajnowania
dodawania obudowanego LDREX/STREX tak jak na ARMv7-A (tutaj wygląda to
ładnie).