NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Czy różnice w pętli `while` w Keil C mogą wpływać na działanie programu?
Goto page Previous 1, 2, 3, 4, 5, 6 Next
Queequeg
Guest
Guest
Thu Feb 14, 2019 3:02 pm
antispam@math.uni.wroc.pl wrote:
Quote:
A to "`volatile` nie oznacza, ?e kompilator gwarantuje atomiczny dost?p do
zmiennej (czyli ?e wy??czy"?
Nie do??, ?e masz problem z czytaniem ze zrozumieniem, to jeszcze wyci??e?
kluczowy fragment, kt?ry pokazuje, ?e czepiasz si? bez sensu.
Januszowi wlasnie chodzilo o to ze nie:
zmiennej (czyli ?e wy??czy"?
Nie do??, ?e masz problem z czytaniem ze zrozumieniem, to jeszcze wyci??e?
kluczowy fragment, kt?ry pokazuje, ?e czepiasz si? bez sensu.
Januszowi wlasnie chodzilo o to ze nie:
I ja dokładnie to napisałem:
"`volatile` nie oznacza, że kompilator gwarantuje atomiczny dostęp do
zmiennej".
--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika
Queequeg
Guest
Guest
Thu Feb 14, 2019 3:04 pm
Queequeg <queequeg@trust.no1> wrote:
Quote:
dostępu do zmiennej szerszej niż magistrala adresowa).
Autopoprawka: danych. Magistrala danych.
--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika
Queequeg
Guest
Guest
Thu Feb 14, 2019 3:07 pm
Grzegorz Niemirowski <gnthexfiles@poczta.onet.pl> wrote:
Quote:
PS. tin nie obsługuje polskich liter?
Obsługuje, tylko nie domyślnie :)
Ja kompiluję z:
--disable-mime-strict-charset
--with-mime-default-charset=ISO-8859-2
I potem w ~/.tin/attributes:
scope=pl.*,alt.pl.*
mm_network_charset=ISO-8859-2
undeclared_charset=ISO-8859-2
--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika
J.F.
Guest
Guest
Thu Feb 14, 2019 5:03 pm
Dnia Thu, 14 Feb 2019 12:25:23 +0000 (UTC), Queequeg napisał(a):
Quote:
J.F. <jfox_xnospamx@poczta.onet.pl> wrote:
Na kilka instrukcji ... czemu nie.
Ale skąd kompilator ma wiedzieć, że dana zmienna jest akurat modyfikowana
w przerwaniu?
Na kilka instrukcji ... czemu nie.
Ale skąd kompilator ma wiedzieć, że dana zmienna jest akurat modyfikowana
w przerwaniu?
Po atrybucie volatile :-)
J.
J.F.
Guest
Guest
Thu Feb 14, 2019 5:10 pm
Dnia Thu, 14 Feb 2019 13:36:34 +0100, Grzegorz Niemirowski napisał(a):
Quote:
J.F. <jfox_xnospamx@poczta.onet.pl> napisał(a):
Na kilka instrukcji ... czemu nie.
Których instrukcji? Wszystkich odwołujących się do tej zmiennej? Nadmierna,
ukryta ingerencja w kod.
Na kilka instrukcji ... czemu nie.
Których instrukcji? Wszystkich odwołujących się do tej zmiennej? Nadmierna,
ukryta ingerencja w kod.
Ale wychodzi na to, ze niezbedna.
Quote:
Efektem będzie np. niepożądany jitter. Kod robi się
mniej przewidywalny.
mniej przewidywalny.
Liczenie cykli procesora w programie w C ?
Quote:
Szczegolnie, ze ... sam musze je wylaczyc, jesli nie chce takich
niespodzianek.
Albo przepisać tak, żeby wyłączanie nie było konieczne.
niespodzianek.
Albo przepisać tak, żeby wyłączanie nie było konieczne.
Jak dobrze przepisze, to i kompilator nie bedzie musial ich wylaczac.
J.
Queequeg
Guest
Guest
Thu Feb 14, 2019 6:14 pm
J.F. <jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
Ale skąd kompilator ma wiedzieć, że dana zmienna jest akurat modyfikowana
w przerwaniu?
Po atrybucie volatile
w przerwaniu?
Po atrybucie volatile
Czemu w przerwaniu a nie w sygnale?
Czemu w przerwaniu a nie w innym wątku?
Czemu w przerwaniu a nie przez sprzęt?
--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika
J.F.
Guest
Guest
Thu Feb 14, 2019 6:27 pm
Dnia Thu, 14 Feb 2019 16:14:03 +0000 (UTC), Queequeg napisał(a):
Quote:
J.F. <jfox_xnospamx@poczta.onet.pl> wrote:
Ale skąd kompilator ma wiedzieć, że dana zmienna jest akurat modyfikowana
w przerwaniu?
Po atrybucie volatile :-)
Czemu w przerwaniu a nie w sygnale?
Ale skąd kompilator ma wiedzieć, że dana zmienna jest akurat modyfikowana
w przerwaniu?
Po atrybucie volatile :-)
Czemu w przerwaniu a nie w sygnale?
Jakby na jedno wychodzi.
Quote:
Czemu w przerwaniu a nie w innym wątku?
Na jednym procesorze to nadal to samo,
ale teraz modne wielo rdzeniowe ... i sie komplikuje
Quote:
Czemu w przerwaniu a nie przez sprzęt?
W sensie, ze nie ma co przerwan wylaczac, skoro sprzet to robi?
No moze i racja ... bo problem nadal jest ...
J.
Grzegorz Niemirowski
Guest
Guest
Thu Feb 14, 2019 7:42 pm
J.F. <jfox_xnospamx@poczta.onet.pl> napisał(a):
Quote:
Których instrukcji? Wszystkich odwołujących się do tej zmiennej?
Nadmierna, ukryta ingerencja w kod.
Ale wychodzi na to, ze niezbedna.
Nadmierna, ukryta ingerencja w kod.
Ale wychodzi na to, ze niezbedna.
Nijak na to nie wychodzi, ponieważ ludzie od lat radzą sobie bez tego. Poza
tym:
Quote:
Jak dobrze przepisze, to i kompilator nie bedzie musial ich wylaczac.
powyższe :)
Quote:
Liczenie cykli procesora w programie w C ?
Nie chodzi o długość opóźnienia ale o stałość. Poza tym czasem się liczy.
--
Grzegorz Niemirowski
https://www.grzegorz.net/
Janusz
Guest
Guest
Thu Feb 14, 2019 10:13 pm
W dniu 2019-02-14 o 10:57, Queequeg pisze:
Quote:
Przeczytaj jeszcze raz fragment, który (celowo) zostawiłem niewycięty na
górze. Ze zrozumieniem.
Oki, przegapiłem to 'nie '.
górze. Ze zrozumieniem.
Oki, przegapiłem to 'nie '.
--
Pozdr
Janusz
Irek.N.
Guest
Guest
Thu Feb 14, 2019 10:46 pm
Quote:
Skąd wiesz?
Chociaż by z powodu występowania możliwości błędnego odczytu wartości 0
dla tej zmiennej gdy jest czytana połówkami. Mój przypadek.
Zastanawiam się, czy gdyby kompilator zrobił odczyt wielokrotny, czy
było by to "moralnie" poprawne, czy nadal miało by znamiona łaty?
Dlaczego miał by tak zrobić? Ponieważ volatile (w moim przekonaniu) mówi
kompilatorowi, że może się spodziewać problemów z tą zmienną i nie może
zakładać, że uda się ją odczytać etapowo (tak samo jak np. nie ma sensu
ją buforować, tylko za każdym razem trzeba czytać).
Miłego.
Irek.N.
Janusz
Guest
Guest
Thu Feb 14, 2019 11:02 pm
W dniu 2019-02-14 o 13:59, Queequeg pisze:
Quote:
J.F. <jfox_xnospamx@poczta.onet.pl> wrote:
Ale co kompilator może zrobić, jak sam procesor nie obsługuje
atomicznego dostępu do tej zmiennej (bo np. jest 8-bitowy, a zmienna
16-bitowa)?
To samo, co programista ma zrobic :-)
Programista ma kontekst, którego nie ma kompilator. Programista wie, kiedy
chce mieć sekcję krytyczną (która nie musi obejmować wyłącznie atomicznego
dostępu do zmiennej szerszej niż magistrala adresowa).
Zmienna może się zmienić między każdą z tych instrukcji.
Cos w tym jest.
Jest jest... po to są sekcje krytyczne.
Czemu? Co ma do tego ARM? Chodzi o szerokość magistrali danych? To
rozwiązuje tylko jeden problem,
Tak, problemu z int nie bedzie :-)
Z odczytem int nie, ale np. z read-modify-write już tak.
ale inne (chociażby ten pierwszy przykład wyżej) pozostają.
Ciezkie jest zycie programisty.
A to swoją drogą... ale raczej przez ludzi a nie przez komputery :)
Trzeba po prostu pamiętać, że (przynajmniej w przypadku C i C++)
kompilator nie tłumaczy kodu na język maszynowy jeden do jednego. Kod to
tylko pewien abstrakcyjny opis, który kompilator może traktować z dosyć
dużą dowolnością. Dochodzą do tego chociażby zagadnienia związane z
reorderingiem.
Przykładowo:
https://www.nongnu.org/avr-libc/user-manual/optimization.html
1. Dzielimy (powolna operacja)
2. Wyłączamy przerwania cli
3. Zapisujemy wynik dzielenia do zmiennej (szybka operacja)
4. Włączamy przerwania
A optymalizator twierdzi, że wyłączy sobie przerwania przed dzieleniem, bo
tak mu mnieszy kod wychodzi
Faktycznie tak robi, na całe dzielenie wył przerwania ale można ten
Ale co kompilator może zrobić, jak sam procesor nie obsługuje
atomicznego dostępu do tej zmiennej (bo np. jest 8-bitowy, a zmienna
16-bitowa)?
To samo, co programista ma zrobic :-)
Programista ma kontekst, którego nie ma kompilator. Programista wie, kiedy
chce mieć sekcję krytyczną (która nie musi obejmować wyłącznie atomicznego
dostępu do zmiennej szerszej niż magistrala adresowa).
Zmienna może się zmienić między każdą z tych instrukcji.
Cos w tym jest.
Jest jest... po to są sekcje krytyczne.
Czemu? Co ma do tego ARM? Chodzi o szerokość magistrali danych? To
rozwiązuje tylko jeden problem,
Tak, problemu z int nie bedzie :-)
Z odczytem int nie, ale np. z read-modify-write już tak.
ale inne (chociażby ten pierwszy przykład wyżej) pozostają.
Ciezkie jest zycie programisty.
A to swoją drogą... ale raczej przez ludzi a nie przez komputery :)
Trzeba po prostu pamiętać, że (przynajmniej w przypadku C i C++)
kompilator nie tłumaczy kodu na język maszynowy jeden do jednego. Kod to
tylko pewien abstrakcyjny opis, który kompilator może traktować z dosyć
dużą dowolnością. Dochodzą do tego chociażby zagadnienia związane z
reorderingiem.
Przykładowo:
https://www.nongnu.org/avr-libc/user-manual/optimization.html
1. Dzielimy (powolna operacja)
2. Wyłączamy przerwania cli
3. Zapisujemy wynik dzielenia do zmiennej (szybka operacja)
4. Włączamy przerwania
A optymalizator twierdzi, że wyłączy sobie przerwania przed dzieleniem, bo
tak mu mnieszy kod wychodzi
Faktycznie tak robi, na całe dzielenie wył przerwania ale można ten
problem obejść :)
void test2( unsigned int val )
{div_t wynik;
wynik=div(65535U,val);
e10: bc 01 movw r22, r24
e12: 8f ef ldi r24, 0xFF ; 255
e14: 9f ef ldi r25, 0xFF ; 255
e16: 0e 94 f7 08 call 0x11ee ; 0x11ee <__divmodhi4>
return 1;
}
static __inline__ uint8_t __iCliRetVal(void)
{
cli();
e1a: f8 94 cli
//val = / val;
ATOMIC_BLOCK(ATOMIC_FORCEON) {
ivar = wynik.quot;
e1c: 70 93 14 02 sts 0x0214, r23 ; 0x800214 <ivar+0x1>
e20: 60 93 13 02 sts 0x0213, r22 ; 0x800213 <ivar>
return 1;
}
static __inline__ void __iSeiParam(const uint8_t *__s)
{
sei();
e24: 78 94 sei
Da się? da sie
ale prawda jest taka że trzeba mu cały czas patrzyć na
ręce
czy nam czegoś nadmiernie nie zoptymalizował.
--
Pozdr
Janusz
Grzegorz Niemirowski
Guest
Guest
Thu Feb 14, 2019 11:03 pm
Irek.N. <tajny@jakis.taki.jest.pl> napisał(a):
Quote:
Dlaczego miał by tak zrobić? Ponieważ volatile (w moim przekonaniu) mówi
kompilatorowi, że może się spodziewać problemów z tą zmienną i nie może
zakładać, że uda się ją odczytać etapowo (tak samo jak np. nie ma sensu ją
buforować, tylko za każdym razem trzeba czytać).
kompilatorowi, że może się spodziewać problemów z tą zmienną i nie może
zakładać, że uda się ją odczytać etapowo (tak samo jak np. nie ma sensu ją
buforować, tylko za każdym razem trzeba czytać).
Na szczęście co mówi volatile to jest zdefiniowane w standardzie a nie w
czyichś przekonaniach :)
volatile dotyczy wyłącznie optymalizacji. "Problemy" ze zmienną mogą brać
się z wielu różnych przyczyn, nie tylko z przerwań. Jest też np. DMA. Nie ma
sensu rozważać volatile w kontekstach, do których nie zostało stworzone lub
też oczekiwać, że kompilator przejmie rolę menedżera pamięci lub inną,
należącą do systemu operacyjnego lub programisty.
--
Grzegorz Niemirowski
https://www.grzegorz.net/
Mateusz Viste
Guest
Guest
Fri Feb 15, 2019 8:57 am
On Thu, 14 Feb 2019 22:46:09 +0100, Irek.N. wrote:
Quote:
Zastanawiam się, czy gdyby kompilator zrobił odczyt wielokrotny, czy
było by to "moralnie" poprawne, czy nadal miało by znamiona łaty?
było by to "moralnie" poprawne, czy nadal miało by znamiona łaty?
Ale co miałoby to rozwiązać? Wartość może zmieniać się za każdym
odczytem, i co wtedy? Ma się zapętlać ad vitam aeternam?
Quote:
Dlaczego miał by tak zrobić? Ponieważ volatile (w moim przekonaniu) mówi
kompilatorowi, że może się spodziewać problemów z tą zmienną i nie może
zakładać, że uda się ją odczytać etapowo (tak samo jak np. nie ma sensu
ją buforować, tylko za każdym razem trzeba czytać).
kompilatorowi, że może się spodziewać problemów z tą zmienną i nie może
zakładać, że uda się ją odczytać etapowo (tak samo jak np. nie ma sensu
ją buforować, tylko za każdym razem trzeba czytać).
Ty natomiast zakładasz z góry, że wartość tej zmiennej zmienia się
wolniej niż pętla jest w stanie ją sprawdzić. Nadgorliwość gorsza od... :)
Mateusz
J.F.
Guest
Guest
Fri Feb 15, 2019 11:07 am
Użytkownik "Queequeg" napisał w wiadomości grup
dyskusyjnych:67cc78db-da90-4e43-be55-e269940aa85e@trust.no1...
Janusz <janusz_kk@o2.pl> wrote:
Quote:
AVR ma to rozwiązane w ten sposób:
https://www.nongnu.org/avr-libc/user-manual/group__util__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.
https://www.nongnu.org/avr-libc/user-manual/group__util__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.
Taka typowa sekcja krytyczna to jeszcze wymaga systemu operacyjnego, a
przynajmniej czegos na ksztalt, z przelaczaniem procesow ..
Ha, moze i faktycznie C++ trzeba uzyc nawet na 8051 - dostep do
zmiennych obiektu da sie przez wydzielone funkcje, ktore zadbaja o
potrzebne rzeczy :-)
J.
Irek.N.
Guest
Guest
Fri Feb 15, 2019 8:57 pm
Quote:
Ale co miałoby to rozwiązać? Wartość może zmieniać się za każdym
odczytem, i co wtedy? Ma się zapętlać ad vitam aeternam?
Ty natomiast zakładasz z góry, że wartość tej zmiennej zmienia się
wolniej niż pętla jest w stanie ją sprawdzić. Nadgorliwość gorsza od...
odczytem, i co wtedy? Ma się zapętlać ad vitam aeternam?
Ty natomiast zakładasz z góry, że wartość tej zmiennej zmienia się
wolniej niż pętla jest w stanie ją sprawdzić. Nadgorliwość gorsza od...
Wiem że masz rację, wiesz, myślenie życzeniowe :)
Miłego.
Irek.N.
elektroda NewsGroups Forum Index - Elektronika Polska - Czy różnice w pętli `while` w Keil C mogą wpływać na działanie programu?