heby <h...@p...onet.pl> napisał(a):
> 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ć.

>> Cały czas chodzi o programy bare metal, bez schedulera.
> Przerwania to multitasking, taki sam jak w schedulerze preemptive.

Chodziło o to, że jak jest scheduler to zwykle też masz pod ręką semafory,
kolejki itd.

> W pierdołowatych małych cpu zapewne tak. W dużych absolutnie nie. Pisząc
> relatywnie duże programy, o dużej złożoności, z masą wątków i wymianą
> danych między nimi, nie miałem okazji użyć volatile ani razu. Z
> ciekawostek: w poważnych firmach słowo volatile jest wyłapywane przez
> linter kodu i wymaga zgody komisji za zielonym suknem.

Miałem właśnie na myśli MCU.

>> I jakoś w Internecie nie widzę polemiki z tym polecaniem volatile
> Bo jej nie szukasz. Google aż krzyczy "nie uzywaj volatile, to nie działa
> jak myślisz".
> Choćby wiki:
> https://en.wikipedia.org/wiki/Volatile_(computer_pro
gramming)
> [...]Furthermore, in C and C++ it does not work in most threading
> scenarios, and that use is discouraged.[...]"
> "[...]Operations on volatile variables are not atomic, nor do they
> establish a proper happens-before relationship for threading. This is
> specified in the relevant standards (C, C++, POSIX, WIN32),[1] and
> volatile variables are not threadsafe in the vast majority of current
> implementations. Thus, the usage of volatile keyword as a portable
> synchronization mechanism is discouraged by many C/C++ groups[...]".
> Niezliczona ilość postów/stron wyjasnia, dlaczego volatile nie jest tym, o
> czym myślisz, że do czego jest.
> Serio, nie zauważyłes?

Ale cały czas mi chodzi o ten problem cache. Wiem dobrze, że volatile nie
rozwiązuje zacytowanych wyżej problemów.

> W małym procesorze tak.
> Teraz weź duży procesor. Być może Ci zaskoczy, że jeśli to przerwanie to
> inny wątek na innym rdzeniu, to mimo, że rdzeń zapisze z = 1, to pętla
> nigdy się nie zakończy. Bo możesz mieć system ze słabą koherencją cache i
> bez bariery/fence informacja nigdy nie zostanie zsynchronizowana z
> lokalnymi cache obu rdzeni. Albo ciekawoski z przestawianiem zapisów,
> kiedy jeden rdzeń widzi zapis w innej kolejnosci niż wykonany w sąsiednim
> rdzeniu.
> Swoją drogą ten problem jest trudny do zauważenia przez przeciętnego
> wciskacza klawiszy, bo x86 jest wyjątkowo tolerancyjny dla dziadowskiego
> kodu. Tam to działa przypadkiem i wiele osób ma podejrzenie, że nie bez
> powodu takie decyzje projektowe podjęto: łatwiej było zaprojektować
> tolerancyjny procesor niż liczyć na poprawianie miliardów lini kodu po
> kiepskich programistach.

Zgadza się. Niemniej dlatego wspomniałem, że problem dotyczy MCU.

> Powoduje: zablokowanie optymalizacji *całej* zmiennej, wszędzie oraz nie
> usuwa innych problemów z wątkowością, takich jak weak memory ordering czy
> synchronizacja cache.
> Ogólnie działa tylko na małych systemach, gdzie nie ma tego typu zagrożeń,
> co powoduje że volatile jest narzędziem workaroudującym prawidłowe metody,
> a nie metodą samą w sobie.
> Na większych sens jest zerowy, poza dostępem do rejestrów.

OK, tutaj zgoda.

> Jak już musisz mieć niskopoziomowo to wyjasnione, to może zerknij tutaj:
> https://www.kernel.org/doc/html/latest/process/volat
ile-considered-harmful
> .html

Dzięki.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On Thu, 16 Feb 2023 13:20:42 +0100, Piotr
Gałka<p...@c...pl> wrote:
> Tam było, że jak się coś robi z programowaniem flasha z wnętrza
> programu
> to ogólnie nie ma gwarancji, że wszystko się uda. I to zdanie było
> ogólne - czyli nawet jak ruszasz inną stronę niż jesteś to może coś
> nie
> zadziałać. Nie napisali co dokładnie, ale skoro może coś się nie
> udać to

Ciekawe. Nie wiem jak w arm ale w mips setki tysięcy razy
programowałem flash z kodu będącym w innej stronie niż strona
programująca i nigdy nie miałem z tym problemu.

--
Marek

do góry

On Thu, 16 Feb 2023 13:54:54 +0100, heby <h...@p...onet.pl> wrote:
> Było to omawiane w tym wątku. Ogólnie, jesli ma to związek z
> programowaniem flasha, to boje się zapytać, czy jakoś się
> zabezpieczacie
> prze utratą zasilania w trakcie.

A co to za problem? Jak się przerwie programowanie z jakiekolwiek
powodu to bootloader zaprogramuje ponownie po resecie. Jeśli
urządzenie wymaga idiotycznego "nie wyłączaj urządzenia podczas
aktualizacji" to nadaje się do kosza a "twórcom" należą się baty.

--
Marek

do góry

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.

>>> Cały czas chodzi o programy bare metal, bez schedulera.
>> Przerwania to multitasking, taki sam jak w schedulerze preemptive.
> Chodziło o to, że jak jest scheduler to zwykle też masz pod ręką
> semafory, kolejki itd.

Ich istnienie jest rozdzielne. Do tego stopnia, że trafiłem kiedyś na
urządzenie o nazwie "Tiger" zawierajace "TigerBASIC", taki panel do
kontroli automatyki, z wyświetlaczem graficznym. Gdzie rozdział
poświęcony miltithread miał opis 1 funkcji tworzącej wątek i kończył się
na "należy zwrócić uwagę na dostępie do zmiennych w innych wątkach". I
wsio na temat synchronizacji.

>> W pierdołowatych małych cpu zapewne tak. W dużych absolutnie nie.
>> Pisząc relatywnie duże programy, o dużej złożoności, z masą wątków i
>> wymianą danych między nimi, nie miałem okazji użyć volatile ani razu.
>> Z ciekawostek: w poważnych firmach słowo volatile jest wyłapywane
>> przez linter kodu i wymaga zgody komisji za zielonym suknem.
> Miałem właśnie na myśli MCU.

A ja wskazuje, że granica między dużym systemem i uC/MCU zaciera się
coraz szybciej. Mam przed sobą pdf dwurdzeniowego ARM za normalne $. Do
migania diodą nadaje się tak samo jak AVR. Może nawet konsumuje mniej
energii, nie zdzwiłbym się.

>> Niezliczona ilość postów/stron wyjasnia, dlaczego volatile nie jest
>> tym, o czym myślisz, że do czego jest.
>> Serio, nie zauważyłes?
> Ale cały czas mi chodzi o ten problem cache. Wiem dobrze, że volatile
> nie rozwiązuje zacytowanych wyżej problemów.

volatile źle rozwiązuje równiez "ten problem z cache" w sensie
optymalizacji. Bo zabrania *zawsze* optymalizacji danej zmiennej,a nie
tylko w miejscu, gdzie jest błędem logicznym.

> Zgadza się. Niemniej dlatego wspomniałem, że problem dotyczy MCU.

MCU za chwile będą takie jak duże systemy. Duże systemy idą w szerokość
(ilośc rdzeni) to samo czeka uC. Prawdę mówiąc bardzo mi szkoda, że
Parallax Propeller nie dał rady stać się popularnym, to był bardzo
interesujacy CPU do aplikacji real-time.

do góry

On 16/02/2023 19:27, Marek wrote:
>> Było to omawiane w tym wątku. Ogólnie, jesli ma to związek z
>> programowaniem flasha, to boje się zapytać, czy jakoś się
>> zabezpieczacie prze utratą zasilania w trakcie.
> A co to za problem? Jak się przerwie programowanie z jakiekolwiek powodu
> to bootloader zaprogramuje ponownie po resecie. Jeśli urządzenie wymaga
> idiotycznego "nie wyłączaj urządzenia podczas aktualizacji" to nadaje
> się do kosza a "twórcom" należą się baty.

Czyli sporej częsci urządzeń wyświetlajacych ten komunikat. Ja bym
zaczął od Windowsa. Co prawda to nie flash, ale w sumie co za różnica.

do góry

On 16.02.2023 13:20, Piotr Gałka wrote:
[...]
> On by potrzebował sizeof(funkcja).
>
> Ale jak próbuje to zrobić to dostaje 1.
> Zasugerowałem, że może jak wstawi etykietę (przypomnieliśmy sobie, że
> chyba w C coś takiego jest) na nawiasie zamykającym funkcję to uda się
> policzyć różnicę między jej adresem a adresem początku funkcji.
> Właśnie mi krzyknął (jego pokój jest piętro niżej), że z zewnątrz
> funkcji nie ma dostępu do tej etykiety.
Sugeruję jednak zapoznanie się ze skryptami linkera - zakładam, że
używacie GNU toolchaina. W sieci jest mnóstwo przykładów jak odczytać
adres początku danej sekcji, jej końca, jej długość i jak wyeksportować
te dane do linkowanego programu.

Hint: Można sobie zdefiniować sekcję i umieścić w niej tylko jedną funkcję.

> Z adresem początku sobie radzi, choć mówi, że wskaźnik na funkcję jest
> zawsze większy o 1 od prawdziwego adresu i ustalając fragment do
> kopiowania on musi tę jedynkę odejmować.
To podstawy:
https://developer.arm.com/documentation/ka002971/lat
est
https://stackoverflow.com/questions/37004954/functio
n-address-in-arm-assembly-have-one-byte-offset

Przy czym należy dodać, że Corteksy M (M-profile) wspierają tylko zestaw
instrukcji Thumb/Thumb-2, a ten nieszczęsny bit został tam zapewne
dlatego, że ,,duże ARM-y" (A-profile i R-profile) oprócz zestawu Thumb
wspierają też zestaw instrukcji ARM.

do góry

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

do góry

On Thu, 16 Feb 2023 19:57:58 +0100, heby <h...@p...onet.pl> wrote:
> Czyli sporej częsci urządzeń wyświetlajacych ten komunikat. Ja bym
> zaczął od Windowsa. Co prawda to nie flash, ale w sumie co za
> różnica.

Nie ma wyjątków.

--
Marek

do góry

On 17/02/2023 02:35, JDX wrote:
>> 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. :-)

Tak, bo to biedaarchitekura. To jest to miejsce, gdzie stosujesz
sztuczki specyficzne dla danej arch. Tak samo jak na AVR i 8051 nie da
się bez tego żyć.

Rzecz w tym, aby tych sztuczek nie traktować jako normy ogólnej.

do góry

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.

do góry