W dniu 13.06.2009 06:10, Grzegorz Kurczyk pisze:
> Użytkownik Zbych napisał:
>>
>> Dlatego napisałem, że do takich rzeczy jak sekcje atomowe są makra
>> zdefiniowane w pliku atomic.h, a ty uparcie chcesz rzeźbić ręcznie
>> (pomijając przy tym barierę).
>
> Nie, no nie chcę nic robić uparcie. Sugestie Kolegi bardzo mi pomogły,
> za co serdecznie dziękuję. Akurat w moim przypadku wystarczyło volatile,
> ale gdybym nie spojrzał do .lss to żyłbym w błogiej nieświadomości będąc
> pewnym, że zablokowałem przerwania w krytycznej sekcji programu i
> zastanawiając się dlaczego program kiksuje raz na ruski miesiąc. Tym
> bardziej, że w poprzedniej wersji kompilatora kolejność działań była
> taka jak w źródłówce. Z biblioteki atomic.h nie miałem jeszcze okazji
> korzystać, ale widzę, że chyba najwyższy czas :-) Nie narzekam na
> WinAVR, bo to niezły kompilator, ale główny problem w tym, że program,
> który w danej wersji WinAVR bez problemu się kompilował i co
> najważniejsze działał poprawnie, w nowszej wywala błędy kompilacji (co
> nie jest problemem), ale co gorsza kompilacja przechodzi bezbłędnie,
> tylko program chodzi nie do końca tak jak powinien. Z tego powodu z dużą
> rezerwą podchodzę do nowych wersji kompilatora.
> Problem w tym skąd mam wiedzieć (poza "brutalnym" zajrzeniem do pliku
> .lss), w którym momencie muszę posiłkować się sztuczką typu ATOMIC_BLOCK
> lub czymś podobnym, bo kompilator może wygenerować kod, nie do końca
> zgodny z założeniami autora kodu źródłowego. W podanym wcześniej
> przykładzie w jednej procedurze było źle, a w następnej już dobrze i
> nijak nie mogę wydedukować z czego to wynika. W przypadku volatile
> sytuacja jest jasna, ale z tym sei to kompilator zrobił mi psikusa, bo
> jest to pierwszy taki przypadek. Przecież sekcji cli() {..} sei() używa
> się dość często. W większych programach mam ich dużo i to jest jak na
> razie jedyna funkcja, w której takie zjawisko mi wystąpiło (choć po tym
> kwiatku nie jestem już tego taki pewien i dla pewności skorzystam z rady
> Kolegi Zbycha i porobię klamerki ATOMIC_BLOK).

To nie jest tak jak piszesz. W twoim przykladzie kompilator zachowal sie
zupelnie poprawnie. Zauwaz, ze nie podales nigdzie, ze pEncoderValue
jest volatile, w efekcie kompilator slusznie uznal, ze wartosc tej
zmiennej nie moze sie zmienic nigdzie poza aktualnie kompilowana sekcja,
a wiec miejsce gdzie nastapi przypisanie:
int e = *pEncoderValue;
jest zupelnie dowolne. W koncu skoro nic w miedzyczasie nie modyfikuje
pEncoderValue to umieszczanie tego w sekcji krytycznej nie ma sensu i
kompilator sobie zoptymalizowal to tak jak mu pasowalo. Dopiero
okreslenie tej zmiennej jako volatile mowi kompilatorowi, ze z ta
zmienna trzeba uwazac i nie mozna sobie dowolnie jej przekladac.
Z kolei jesli pEncoderValue jest modyfikowane poza procedura, ktora
pokazales np. w jakims przerwaniu to okreslenie tej zmiennej jako
volatile jest obowiazkowe! Inaczej masz efekty takie jak pokazales. Co
wiecej gdybys dalej cops robil z ta zmienna w swojej procedurze to
kompilator jej pewnie ponownie by nie ladowal, czyli mialbys kolejne
dziwne bledy. Ale to ciagle twoja wina i nie ma co zwalac na gcc.



--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.