On Fri, 17 Feb 2023 02:35:07 +0100, JDX wrote:
> 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. :-)

Ale przybywa rdzeni, wiec samo volatile to raczej nie jest zastępnik.

> 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).

jest ldrexd/strexd ... ktorych zdaje sie nie ma w armv7-M.

A dwa ldrex/strex nie bedą atomic.

J.