> Zdarzyło mi się kiedyś, że postanowiłem, że coś muszę zmodyfikować w
> jednym programie. Wyszukałem miejsce gdzie to należy poprawić - a tu
> "już ktoś to zrobił". Według daty pliku wynikało, że góra miesiąc temu :(

Ostro :)
Ja czasami robie błąd składni w kodzie, jak wiem że będę musiał
zaglądnąć w jakieś miejsce przy następnej okazji.
Przy kompilacji błąd wskazuje gdzie zaglądnąć, a tam już opis robi swoje :)
Trza sobie radzić jak szare zszarzały :(

Miłego.
Irek.N.

do góry

Irek.N. <t...@j...taki.jest.pl> napisał(a):
> Ostro :)
> Ja czasami robie błąd składni w kodzie, jak wiem że będę musiał zaglądnąć
> w jakieś miejsce przy następnej okazji.
> Przy kompilacji błąd wskazuje gdzie zaglądnąć, a tam już opis robi swoje
> :) Trza sobie radzić jak szare zszarzały :(

Jeśli to C, to można skorzystać z dyrektywy preprocesora żeby nie psuć
dobrego kodu:
#error "Tu zrobic zmiany"

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

do góry

> Jeśli to C, to można skorzystać z dyrektywy preprocesora żeby nie psuć
> dobrego kodu:
> #error "Tu zrobic zmiany"
>

95% mojego kodu to ST, reszta to raczej VB niż C i pokrewne.

Miłego.
Irek.N.

do góry

W dniu 2019-02-13 o 21:13, Irek.N. pisze:
>
>> A swoja droga - czy Keil sam ich nie wylacza ? Dla zmiennych volatile
>> powinien.
>
> Niestety ale ignoruje zupełnie volatile, a nie powinien moim zdaniem.
Ale volatile oznacza tylko tyle że kompilator nie zoptymalizuje zmiennej
aby ją np wyciąć albo trzymać tylko w rejestrach, taka zmienna będzie zawsze
trzymana w pamięci, a kto i kiedy ją modyfikuje czy czyta to go nie
obchodzi.


--
Pozdr
Janusz

do góry

Irek.N. <t...@j...taki.jest.pl> wrote:

> Trza sobie radzić jak szare zszarzały :(

To nawet nie o to chodzi. Im mniej zaśmiecasz swoją pamięć, tym lepiej.
Ja często zapisuję sobie rzeczy, o których pewnie bym pamiętał, właśnie
po to, żeby nie musieć pamiętać :) Zyskuję wtedy taki dziwny spokój, że
coś do zrobienia już jest zapisane i nie muszę o tym pamiętać (czyli tak
naprawdę myśleć).

To, czy pamiętam o zajrzeniu do notatek i czy w ogóle nad nimi panuję, to
zupełnie osobny temat. Kiedyś je uporządkuję. To również jest zapisane.

--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika

do góry

J.F. <j...@p...onet.pl> wrote:

> Ale nie spojrzec jaki to typ przy sprawdzaniu/szukaniu bledu ... czas
> na lecytyne :-)

Jak masz w głowie, że to musi być int, to możesz przeoczyć :)

> A swoja droga - czy Keil sam ich nie wylacza ? Dla zmiennych volatile
> powinien.

Wbrew intuicji -- nie :) Modyfikator `volatile` oznacza tylko tyle, że
kompilator nie może robić założeń co do zawartości zmiennej opatrzonej tym
modyfikatorem, bo zmienna może zmienić wartość poza ścieżką wykonania (np.
jest to sprzętowy rejestr, lub inny wątek ją modyfikuje, lub właśnie
przerwanie). `volatile` nie oznacza, że kompilator gwarantuje atomiczny
dostęp do zmiennej (czyli że wyłączy wszystko inne, co może zmienić jej
wartość w trakcie dostępu -- czy to wątki, czy przerwania, czy zewnętrzny
sprzęt).

AVR ma to rozwiązane w ten sposób:

https://www.nongnu.org/avr-libc/user-manual/group__u
til__atomic.html

--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika

do góry

Dnia Wed, 13 Feb 2019 21:47:36 +0000 (UTC), Queequeg napisał(a):
> J.F. <j...@p...onet.pl> wrote:

>> A swoja droga - czy Keil sam ich nie wylacza ? Dla zmiennych volatile
>> powinien.
>
> Wbrew intuicji -- nie :) Modyfikator `volatile` oznacza tylko tyle, że
> kompilator nie może robić założeń co do zawartości zmiennej opatrzonej tym
> modyfikatorem, bo zmienna może zmienić wartość poza ścieżką wykonania (np.
> jest to sprzętowy rejestr, lub inny wątek ją modyfikuje, lub właśnie
> przerwanie). `volatile` nie oznacza, że kompilator gwarantuje atomiczny
> dostęp do zmiennej (czyli że wyłączy wszystko inne, co może zmienić jej
> wartość w trakcie dostępu -- czy to wątki, czy przerwania, czy zewnętrzny
> sprzęt).

No ale czy nie powinien ? Bo skoro sie moze zmienic w sposob
niekontrolowany, to jak mozna wierzyc wartosci odczytanej
nieatomicznie ?

> AVR ma to rozwiązane w ten sposób:
> https://www.nongnu.org/avr-libc/user-manual/group__u
til__atomic.html

No i widac ja sie te pomysly nadaja do prostego:
while (ctr) ;

:-)

J.

do góry

W dniu 2019-02-13 o 22:47, Queequeg pisze:
> J.F. <j...@p...onet.pl> wrote:
>
>> Ale nie spojrzec jaki to typ przy sprawdzaniu/szukaniu bledu ... czas
>> na lecytyne :-)
>
> Jak masz w głowie, że to musi być int, to możesz przeoczyć :)
>
>> A swoja droga - czy Keil sam ich nie wylacza ? Dla zmiennych volatile
>> powinien.
>
> Wbrew intuicji -- nie :) Modyfikator `volatile` oznacza tylko tyle, że
> kompilator nie może robić założeń co do zawartości zmiennej opatrzonej tym
> modyfikatorem, bo zmienna może zmienić wartość poza ścieżką wykonania (np.
> jest to sprzętowy rejestr, lub inny wątek ją modyfikuje, lub właśnie
> przerwanie). `volatile` nie oznacza, że kompilator gwarantuje atomiczny
> dostęp do zmiennej (czyli że wyłączy wszystko inne, co może zmienić jej
> wartość w trakcie dostępu -- czy to wątki, czy przerwania, czy zewnętrzny
> sprzęt).
G..o prawda.

>
> AVR ma to rozwiązane w ten sposób:
> https://www.nongnu.org/avr-libc/user-manual/group__u
til__atomic.html
Mylisz pojęcia, atomic blok i voltaile to są zupełnie dwie różne sprawy.
jakbyś zerknął do kodu to byś zobaczył że dla volatile kompilator
nigdy nie robi atomic bloków, to musi programista w kodzie
zrobić.


--
Pozdr
Janusz

do góry

Irek.N. <t...@j...taki.jest.pl> wrote:

>> A swoja droga - czy Keil sam ich nie wylacza ? Dla zmiennych volatile
>> powinien.
>
> Niestety ale ignoruje zupełnie volatile, a nie powinien moim zdaniem.

Skąd wiesz?

Zrób test. Napisz funkcję:

int i;
void fn(void) { do { } while (i != 42); }

Skompiluj z optymalizacją, zobacz kod. Potem dodaj volatile, zobacz kod.

Sprawdziłem na raspi (arm), gcc -O2 -S.

Bez volatile:

#v+
ldr r3, .L5
ldr r3, [r3] ; tu ładuje zmienną do rejestru
.L2:
cmp r3, #42 ; tu porównuje rejestr
bne .L2 ; tu skacze z powrotem do porównania
#v-

Z volatile:

#v+
ldr r2, .L5
.L2:
ldr r3, [r2] ; tu ładuje zmienną
cmp r3, #42 ; tu porównuje
bne .L2 ; tu skacze z powrotem do załadowania
#v-

Podobnie na amd64. Bez volatile:

#v+
movl i(%rip), %eax ; tu ładuje zmienną
.p2align 4,,10
.p2align 3
.L2:
cmpl $42, %eax ; tu porównuje
jne .L2 ; tu skacze z powrotem do porównania
#v-

Z volatile:

#v+
.L2:
movl i(%rip), %eax ; tu ładuje zmienną
cmpl $42, %eax ; tu porównuje
jne .L2 ; tu skacze z powrotem do załadowania
#v-

Jeszcze ciekawiej się robi, gdy dodasz modyfikator `static`. Bez volatile,
arm:

#v+
.L2:
b .L2
#v-

Bez volatile, amd64:

#v+
.L2:
jmp .L2
#v-

Dlaczego tak? Bo kompilator wie, że inna jednostka kompilacji nie zmieni
wartości tej zmiennej (bo jest statyczna, widoczna tylko w obrębie danej
jednostki kompilacji), więc nie ma sensu żadne sprawdzanie, bo zmienna i
tak jest zero (bo zmienne globalne są inicjalizowane zerami; spróbuj
zamiast 42 wstawić 0 i zobacz, jaki kod wtedy kompilator wygeneruje).

Oczywiście z volatile działa tak, jak byśmy chcieli.

--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika

do góry

Janusz <j...@o...pl> wrote:

>> Wbrew intuicji -- nie :) Modyfikator `volatile` oznacza tylko tyle, że
>> kompilator nie może robić założeń co do zawartości zmiennej opatrzonej tym
>> modyfikatorem, bo zmienna może zmienić wartość poza ścieżką wykonania (np.
>> jest to sprzętowy rejestr, lub inny wątek ją modyfikuje, lub właśnie
>> przerwanie). `volatile` nie oznacza, że kompilator gwarantuje atomiczny
>> dostęp do zmiennej (czyli że wyłączy wszystko inne, co może zmienić jej
>> wartość w trakcie dostępu -- czy to wątki, czy przerwania, czy zewnętrzny
>> sprzęt).
> G..o prawda.

A co konkretnie?

>> AVR ma to rozwiązane w ten sposób:
>> https://www.nongnu.org/avr-libc/user-manual/group__u
til__atomic.html
> Mylisz pojęcia, atomic blok i voltaile to są zupełnie dwie różne sprawy.

Nie mylę, może nieprecyzyjnie się wyraziłem. AVR ma wspomniane mechanizmy,
których programista może użyć, jeśli interesuje go atomiczny dostęp lub
tak naprawdę jakakolwiek inna sekcja krytyczna.

> jakbyś zerknął do kodu to byś zobaczył że dla volatile kompilator
> nigdy nie robi atomic bloków, to musi programista w kodzie
> zrobić.

Tak (i prawidłowo), o tym właśnie piszę.

--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika

do góry