>> Alez byla. Twoja zmienna jest typu int, czyli ma 2 bajty. AVR nie ma
>> instrukcji ladowania z pamieci 2 bajtow jednoczesnie, a wiec takie
>> przeslanie nie jest atomowe. Dlatego musisz okreslic ta zmienna jako
>> volatile i zapewnic atomowosc operacji przez blokowanie przerwan.
>> Zauwaz, ze gdyby uzyte przeslanie 16-bitowe bylo atomowe to blokowanie
>> przerwan w ogole nie byloby potrzebne.
>
> No dokładnie taki był mój tok rozumowania. Ponieważ pobranie zmiennej
> int wymaga dwóch rozkazów blokuję możliwość przerwania tej operacji
> przez inny wątek poprzedzając je rozkazem cli wstawionym "z palca". W
> momencie gry program staje się jednowątkowy trudno mówić o ulotności
> zmiennych.

Teoretycznie tak. Problem w tym, ze skad kompilator ma wiedziec, ze
wartosc zmiennej moze sie zmieniac poza glownym ciagiem instrukcji? Do
tego wlasnie sluzy volatile. Bez tego kompilator nic nie wie, ze cos
moze zmienic twoja zmienna np. w przerwaniu, w efekcie optymalizuje to
sobie jak uwaza za stosowne i z tego punktu widzenia umiejscowienie cli
w stosunu do pobrania zmiennej jest bez znaczenia.

> P.S. Choroba... w WinAVR_20071221 program wynikowy zajmował 15023 bajty,
> a po skompilowaniu w WinAVR_20090313 wyszło już 16154. Całe szczęście,
> że to nie ATmega16 ;-)

Zapewne problem z bardziej agresywnym inlinowaniem funkcji. Mozna to
wylaczyc.

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