Rynek pracy STM32

Mylisz się, używa się jako informację żeby kompilator nie optymalizował tej zmiennej, widzisz wydaje ci się że wszystko wiesz a jednak nie, trafiony, zatopiony.

W dniu 2022-07-19 o 19:13, Piotr Gałka pisze:

Tego nie znam.

No to właśnie o nim pisałem, później jak wszedł DX to sobie z nimi dałem spokój, tym bardziej że używałem amatorsko a DX już się nie dało tak używać.

W dniu 2022-07-19 o 20:21, heby pisze:

Możesz się odstosunkować ode mnie?

Janusz <janusz snipped-for-privacy@o2.pl napisał(a):

Nie panujesz, bo po latach zapominasz dlaczego tą lub tamtą linijkę napisałeś właśnie tak. Albo kiedy wprowadziłeś daną zmianę. Kontrola wersji świetnie to rozwiązuje, szczególnie jeśli pisze się sensowne komentarze do commitów. Znika też problem zmian wprowadzanych "na chwilę" i wycofywania ich.

Praca zespołowa jest praktycznie niemożliwa bez systemu kontroli wersji. Poza tym kłania się wspomniana już integracja z CI/CD.

W dniu 2022-07-19 o 21:27, Grzegorz Niemirowski pisze:

Przecież to samo mogę napisać w komentarzu i skopiować na początek pliku gdzie opisuję wszystkie zmiany albo mieć osobnym pliku opisowym bez całych ceregieli z SVN-em.

W dniu 2022-07-19 o 21:09, heby pisze:

Acha.

To mi zakrawa na Lisp czy Prolog. Assembler 8051 najpierw próbowałem napisać w Prologu :)

Cały czas mieszasz to co ja chciałbym popróbować pisząc na komputer z embedded nie związanym ze mną tylko z moim bratem. P.G.

Janusz <janusz snipped-for-privacy@o2.pl napisał(a):

To nie jest to samo. W systemie kontroli wersji masz opis do zmiany (commita) obejmującej różne linie w różnych plikach. Widzisz, że w zmianie z dnia tego i tego, o komentarzu takim a takim, w pliku a.c wstawiłeś te linijki a te zmodyfikowałeś, a w pliku b.c takie linijki skasowałeś. Każda lininijka kodu ma opis (powiązanie ze zmianą, która jej dotknęła). Opisy w treści pliku nijak tego nie zapewniają. Nie mówiąc już o historii linii, w tym tych usuniętych. Piszesz jakbyś nigdy nie używał systemu kontroli wersji.

Oba przykłądy pokazują polimorfizm. Jedne dynamiczny (z metodami wirtualnymi), drugi statyczny.

Nie, teraz się wycofujesz z debilizmów. Popkoru mam jeszcze trochę, dawaj dalej.

Z faktu, ze ich nie pojmujesz, nic nie wynika dla faktów.

Jesli kompilator wyoptymzliował Ci tą zmienną, a nie powinien, to masz buga w kodzie, który załatałeś nieprawidłowym volatile.

Nie masz pojęcia o programowaniu.

Nie mogę. Łżesz z powodu ignoracji. Jesli ktoś to robi, to nie można pozostać bezczynnym, nalezy rozgniatać w miejscu.

Ciekawe jakie różnice w skompilowanym kodzie. AVR ma rozkaz call register?

I kto gwarantuje że to co napisano w komentarzu ma jakiekolwiek powiązanie z tym co znajdzie w reszcie pliku?

Nie ma sensu porównywać. Statyczny polimorfizm ma większe szanse za zerowe obciązenie, dynamiczny prawie na pewno będzie fizycznie wołał metody wirtualne. Ale sprawdzę, jak znajdę chwię, w środowisku Arduino jeszcze nie robiłem objdumpa.

ijmp i icall?

heby snipped-for-privacy@poczta.onet.pl> napisał(a):

Co to znaczy, że nie powinien? Jakie to jest nieprawidłowe volatile? Janusz podał 3 poprawne przykłady użycia volatile.

Janusz Twierdzi, że kompilator zredukował mu kod do zera, który robił coś z jakąs zmienną.

Odrzucając hipoteze o bugu w kompilatorze:

Jedynym powodem, że jakiś kod korzystajacy ze zmiennej został wyoptymalizowana do zera, to że kompilator w kodzie nie zakładał zmian tej zmiennej w zewnątrznych funkcjach, lub mógł je wyliczyć statycznie widąc cały kod.

Skoro tak, to miał prawo zoptymalizować ten kod do zera.

Janusz narzeka że tak sie stało.

Wnioskuje więc że:

Użyte w sytuacji, kiedy tak naprawdę chcesz barierę. Bariera mówi kompilatorowo: uwaga, ta zmienna może zostać zmodyfikowana przez inny, nieznany czynnik, w tym miejscu nie wolno jej przechować ani zakładać że ma jakaś starą wartość po przejściu bariery.

Zaznaczenie "volatile" na zmiennej powoduje, że kompialator wyłączy cacheowanie jej wartości, co uniemożliwi optymalizację kodu.

Tymczasem prawie na pewno w algorytmie jest bug, albo wcale nie chodziło o wyłaczenie optymalizacji, tylko o poinformowanie kompilatora, że zmienna może być zmodyfikowana poza tym kodem. Od tego są bariery.

Dla procesorów posiadajacychc cache, baeriery są *JEDYNYM* sposobem zapewnienia synchronizacji stanu zmiennych między watkami. Na niektórych złośliwych architekturach możliwe jest, że mimo volatile, zmiana zmiennej w wątku A nigdy nie będzie widoczna w wątku B bez użycia bariery. Na innych może się zdażyć, że zapis z jednego watku w kolejności A a potem B, bedzie widziany w innym wątku jako zapis B a potem A. Tutaj znowu, volatile nic nie pomoże - od tego są bariery.

Ponieważ Janusz nie przedstawił spornego kawałka kodu - nie wiadomo dlaczego kompilator usunął mu ten kod. Wiec można sobie na sucho pogdybać w jakich okolicznościach może i dlaczego volatile nie jest od tego, do czego go źle używają prawie wszyscy.

PS. To nie aby ja podałem 3 przykłady, w tym dwa błedne ;) ?

W dniu 2022-07-19 o 21:47, Grzegorz Niemirowski pisze:

Się domyślam, w zastosowaniach jednoosobowych mi wystarczy.

W systemie kontroli wersji masz opis do zmiany

Całe szczęście nie jestem zawodowym programistą chociaż kilka zawodowych programów popełniłem ale było to w czasach Clipera i nikt wtedy o svn-ach nie słyszał. Teraz piszę w zasadzie dla siebie.

Piszesz jakbyś nigdy

Próbowałem ale sie poddałem, zbyt pokopane żeby tracić na to czas, myślałem że jest to bardziej intuicyjne.

Nic mi ten obrazek nie mówi, może poza lewym panelem gdzie są jak przypuszczam wymienieni ci którzy coś grzebali w kodzie.

Ja, bo to dla siebie robię.

Możesz mnie wiesz gdzie pocałować.

W dniu 2022-07-19 o 22:37, heby pisze:

Ależ wiadomo, długa sekwencja switch case gdzie zmienna jest zmieniana wielokrotnie. Kodu już nie ma bo go poprawiłem i pozmieniałem, został rozbudowany.