Re: C++ ośla łączka - Grupy dyskusyjne w eGospodarka.pl

eGospodarka.pl › Grupy › pl.misc.elektronika › C++ ośla łączka › Re: C++ ośla łączka

Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.chmurka.net!.POSTED.h82-143-187-50
-static.e-wro.net.pl!not-for-mail
From: "J.F" <j...@p...onet.pl>
Newsgroups: pl.misc.elektronika
Subject: Re: C++ ośla łączka
Date: Fri, 17 Feb 2023 09:30:50 +0100
Organization: news.chmurka.net
Message-ID: <yit3srw9t6ov$.zvy567zcrqzg.dlg@40tude.net>
References: <16qbnwht7z74n.8802zax2iioq$.dlg@40tude.net>
<trelrs$g0p$1$Janusz@news.chmurka.net>
<trgbkf$st9$1$PiotrGalka@news.chmurka.net>
<63dbd22e$0$9601$65785112@news.neostrada.pl>
<ts6rps$roo$1$PiotrGalka@news.chmurka.net>
<63e9f424$0$19625$65785112@news.neostrada.pl>
<tsg6eb$96a$1$PiotrGalka@news.chmurka.net> <tsgv8m$2kn8s$1@dont-email.me>
<tsiqth$55n$1$PiotrGalka@news.chmurka.net> <tsj9if$2v62r$1@dont-email.me>
<a...@n...neostrada.pl>
<tsjl9d$30gq5$1@dont-email.me>
<63ed6483$0$9597$65785112@news.neostrada.pl>
<tski4a$365ef$1@dont-email.me>
<63ee1784$0$9589$65785112@news.neostrada.pl>
<tsl8hv$38gns$1@dont-email.me>
<63ee3c75$0$19611$65785112@news.neostrada.pl>
<tsln7m$3a7hn$1@dont-email.me>
<63ee71e2$0$19606$65785112@news.neostrada.pl>
<tslu9v$3b1u7$1@dont-email.me>
<63eed9cb$0$19611$65785112@news.neostrada.pl>
NNTP-Posting-Host: h82-143-187-50-static.e-wro.net.pl
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Injection-Info: news.chmurka.net; posting-account="jfoxwr";
posting-host="h82-143-187-50-static.e-wro.net.pl:82.143.187.50";
logging-data="5290"; mail-complaints-to="abuse-news.(at).chmurka.net"
User-Agent: 40tude_Dialog/2.0.15.1
Xref: news-archive.icm.edu.pl pl.misc.elektronika:778395
[ ukryj nagłówki ]
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.