Użytkownik Zbych napisał:
> Tutaj akurat kompilator ma rację - może przestawiać instrukcje do woli
> póki nie wpływa to na wynik obliczeń (ani cli, ani sei nie wpływa na
> obliczenia, atomowość nie jest brana pod uwagę). Żeby kompilator nie
> wywlekał obliczeń poza sekcję krytyczną trzeba zrobić barierę na
> pamięci. Twój program powinien wyglądać tak:
>
> int GetEncoder(void) {
> asm volatile ("cli":::"memory");
> int e = *pEncoderValue;
> asm volatile ("sei":::"memory");
> return e;
> }
>
> Lepiej będzie jednak jak użyjesz makr zdefiniowanych w pliku atomic.h
>

Pamiętam, że jakaś starsza wersja (chyba z 2006) kompilowała to bez
przestawiania. Funkcja jest z biblioteki, którą napisałem dawno temu i
sprawdzałem kod wynikowy. W wersji WinAVR20090313 faktycznie pomogło
volatile przy definicji wskaźnika int *pEncoderValue. Zaskoczyło mnie,
że volatile może być tu przydatne, bo jednak bardziej służy ono do
lokalnego wyłączenia optymalizacji dotyczącej danej zmiennej, a nie do
zmiany kolejności operacji nie mających nic wspólnego z tą zmienną.
Z punktu widzenia zmiennej *pEncoderValue kod jest tak samo optymalny, a
niemalże identyczny:

int *pEncoderValue;
daje w wyniku:
int GetEncoder(void) {
151c: f8 94 cli
151e: 78 94 sei
1520: e0 91 3a 01 lds r30, 0x013A
1524: f0 91 3b 01 lds r31, 0x013B
1528: 80 81 ld r24, Z
152a: 91 81 ldd r25, Z+1 ; 0x01
152c: 08 95 ret
}

volatile int *pEncoderValue;
daje
int GetEncoder(void) {
1520: f8 94 cli
1522: e0 91 3a 01 lds r30, 0x013A
1526: f0 91 3b 01 lds r31, 0x013B
152a: 20 81 ld r18, Z
152c: 31 81 ldd r19, Z+1 ; 0x01
152e: 78 94 sei
1530: c9 01 movw r24, r18
1532: 08 95 ret

Z drugiej strony taka zmiana sekwencji rozkazów sterujących przez
kompilator wydaje mi się trochę dziwna, bo w pewnych sytuacjach ma ona
wpływ na wartość obliczeń (właśnie aby tego uniknąć blokowałem
przerwania). Idąc tym tropem kompilator mógłby "dojść do wniosku", że
sekwencję:
sbi(PORTB, 1);
sbi(PORTB, 2);
sbi(PORTB, 3);
można zamienić na:
sbi(PORTB, 3);
sbi(PORTB, 2);
sbi(PORTB, 1);
lub jeszcze optymalniej (3 takty zegara zamiast 6) na:
in r24, PORTB
ori r24, 0x0E
out PORTB, r24
bo w sumie efekt końcowy (całkowity wynik operacji) jest ten sam:
wyjścia 1,2 i 3 portu B zostały ustawione w stan wysoki. Tyle, że jeśli
te linie są sygnałami CS/CLK/DATA dla jakiegoś rejestru szeregowego, to
już reszta układu tak samo działać nie będzie. Na szczęście nigdy nie
zauważyłem aby robił takie podmianki :-)


Dzięki serdeczne za podpowiedź.
Pozdrawiam
Grzegorz