AVR ATmega32: switch/case vs if - optymalizacja szybkości programu

Mam problemy z szybkościa działania programu na AVR ATmega 32. CZy lepiej używa cinstrukcji switch/case :

switch(x)
{
case 0x04: pozmen1--; //jak tutaj damy -- to się zamota bo typ unsigned jest !
break;
case 0x03: pozmen1++;
break;
case 0x02: warstwa++; //we
break;
case 0x01: warstwa--; // wy
break;

}

czy lepiej if-ów :

if(x==0x04) pozmen1--; //jak tutaj damy -- to się zamota bo typ unsigned jest !
if(x==0x03) pozmen1++;
if(x==0x01) warstwa--; // wy
if(x==0x02) warstwa++; //we


jakie sa wasze spostrzeżenia co do różnicy szybkosci chodzenia programów ? Bo ja w swoim mam raz switche, raz casy, w zależności jak mo wygodnie...

W tym przypadku case będzie zawsze szybszy, bo od razu odrzuca pozostałe przypadki. Wydaje mi się że kod dla case i napisany przy pomocy IF tak jak poniżej będzie bardzo podobny:
if (x==0) .....
else if (x==1) ....
else if (x==2) ....

Ale tak naprawde wszystko zalezy od tego jak "inteligentny" jest kompilator.

Taki "multi-If" będzie działał z różną szybkością. To zalezeży ile warunków będzie trzeba sprawdzić po drodze żeby odrzucić pozostałe- to się będzie zmieniało właśnie w zależności od wartości X. Tak więc pewnie "Select case".

Mi osobiscie wygodniej jest uzywac If'ow ale szybsze jest case.

Zdecydowanie "if-ów" . Dlatego iż jednak zawsze ta instrukcja bedzie szybsza niż case oraz kod wynikówy programu bedzie mniejszy - może nie dużo ale zawsze - w mikroprocesorkach nieraz jest to bardzo istotne gdy mamy do dyspozycji kilka kilo.
Co do instrukcji "if' używać samo "if" bez "else" - jeśli jest potrzebne "else" użyć dwóch instrukcji "if"

Warhard, jestes pewny co do tego ostatniego -seria if-ow bez else ma byc Twoim zdaniem szybsza..? nie bardzo znajduje uzasadnienie dla takie tezy..

wtedy przy serii 5-ciu warunkow w pierwszym przypadku sprawdza sie srednio 2.5 razy warunki, w drugim przypadku (najoptymistyczniej) 5-ciokrotnie. gdzie jest zysk?

aa, i jesli juz tak stroic wydajnosc, to dobrze jest pomyslec chwile i ustalic wlasciwa (statystycznie) kolejnosc sprawdzania warunkow, aby ich srednia liczba byla mozliwie najmniejsza.
kompilator tego za nas nie zrobi, chociaz nie jestem pewny, czy jego algorytmy optymalizacyjne nie zaburza naszego "porzadku"

switch powinien byc szybszy (nowoczesne kompilatory nie wygeneruja raczej przy nich nieefektywnego kodu).

pozdro,
--
migod

Drodzy Panowie! Przecież nie ma w żadnym procku instrukcji, która sprawdza od razu 5 warunków! Żeby zrealizować switch'a trzeba kolejno sprawdzić warunki a potem ewentualnie gdzieś skoczyć, więc sprawa sprowadza się do tego samego co w if'ie.

Takie moje skromne spostrzeżenie...

No..co prawda jest metoda do szybkiego realizowania switch'y... na podstawie wartości zmiennej, od której zależy sekwencja case'ów, wylicza się adres, pod który sie skacze i gotowe (zeby to miało sens robi sie dwa skoki, pierszy na podstawie zmiennej do instrukcji właściwego, czyli drugiego skoku).
Pytanie tylko: Który kompilator to wykorzystuje? CVAVR nie.

A więc co do długości kodu każdy może sam ocenić same ify zajmują najmniej ale switch case jest chyba najszybsze (biorąc pod uwagę że spełniony będzie warunek a=4;


; SAME IF'Y

; if(a==1)b++;
MOV A,a?040
CJNE A,#01H,?C0001
INC b?041
?C0001:
; if(a==2)c++;
MOV A,a?040
CJNE A,#02H,?C0002
INC c?042
?C0002:
; if(a==3)b--;
MOV A,a?040
CJNE A,#03H,?C0003
DEC b?041
?C0003:
; if(a==4)c--;
MOV A,a?040
CJNE A,#04H,?C0004
DEC c?042
?C0004:

; TUTAJ SĄ IF'Y I ELSE

; if(a==1)b++;
MOV A,a?040
CJNE A,#01H,?C0005
INC b?041
SJMP ?C0006
?C0005:
; else if(a==2)c++;
MOV A,a?040
CJNE A,#02H,?C0007
INC c?042
SJMP ?C0006
?C0007:
; else if(a==3)b--;
MOV A,a?040
CJNE A,#03H,?C0009
DEC b?041
SJMP ?C0006
?C0009:
; else if(a==4)c--;
MOV A,a?040
CJNE A,#04H,?C0006
DEC c?042
?C0006:

; SWITCH I CASE

; switch(a){
MOV A,a?040
ADD A,#0FEH
JZ ?C0014
DEC A
JZ ?C0015
DEC A
JZ ?C0016
ADD A,#03H
JNZ ?C0018
; case 1:
?C0013:
; b++;
INC b?041
; break;
SJMP koniec
; case 2:
?C0014:
; c++;
INC c?042
; break;
SJMP koniec
; case 3:
?C0015:
; b--;
DEC b?041
; break;
SJMP konec
; case 4:
?C0016:
; c--;
DEC c?042
; break;
; default:;
; }
;

h0nza napisał:

; SWITCH I CASE
; switch(a){
MOV A,a?040
ADD A,#0FEH
JZ ?C0014
DEC A
JZ ?C0015
DEC A
JZ ?C0016
ADD A,#03H
JNZ ?C0018
; case 1:
?C0013:
; b++;
INC b?041
; break;
SJMP koniec
; case 2:
?C0014:
; c++;
INC c?042
; break;
SJMP koniec
; case 3:
?C0015:
; b--;
DEC b?041
; break;
SJMP konec
; case 4:
?C0016:
; c--;
DEC c?042
; break;
; default:;
; };

Troche cienki ten kompilator, większość kodów "switch/case" jakie widziałem była zbudowana w ten sposób że kod "wylicza sobie" PC na podstawie ofsetu oraz "numeru opcji" (pomnożonego przez stały współczynnik-długość instrukji), wpisuje wartość do PC, pod tym adresem znajduje się rozkaz JUMP, JMP, czy BRA który prowadzi do właściwej procedury. Nie wnikałem nigdy w implementacje na AVR, ale widziałem powyższy algorytm w programach pisanych (raczej w C) na procesory PIC oraz 51.

Ja jestem Ciekawy takim razie co to za kompilator taki kod wygenerowal. Mam nadzieje ze nie GCC :>

Keil 6.23a na mcs51

aczkolwiek panie elektryk proszę zwrócić uwagę że jeżeli miałbym warunki
case 0:
case '@': (chyba 64 ascii)
case 255:
to takie odsyłanie za pomocą funkcji jmp @a+dptr by nie działało poprawnie nie pokrywając całego zakresu - a ja korzystam z instrukcji switch case np przy wczytywaniu znaków z portu szeregowego

h0nza napisał:

aczkolwiek panie elektryk proszę zwrócić uwagę że jeżeli miałbym warunki
case 0:
case '@': (chyba 64 ascii)
case 255:
to takie odsyłanie za pomocą funkcji jmp @a+dptr by nie działało poprawnie nie pokrywając całego zakresu - a ja korzystam z instrukcji switch case np przy wczytywaniu znaków z portu szeregowego

Już kompilator o to zadba żeby było poprawnie, podczas analizu kilku programów napotkałem na takie sekwencje jumpów (do któych wcześniej prowadziło jmp @a+dptr), w których bardzo wiele instrukcji wykonywało skok pod jeden adres. Oczywiście jeśli kompilator jest odpowiednio mądry może coś jeszcze wymyśleć i wybrać "lepszą" taktyke do tego samego działania.

Zgadza się ważne jest to że działa i to znacznie szybciej niż w Bascomie
a jak komuś zależy na prędkości zawsze można w asm'iw trochę napisać

Zakończając temat przychylę się do wypowiedzi kolegów stwierdzając ze wszystko zależy od tego jak kompilator przetłumaczy nasz kod...