Super!

Danke fuers austesten, dann wissen wir jetzt was sich lohnt
Ich denke die Sache mit den Shifts bringt am meisten...

Ich verstehe aber noch nicht warum -Os besser ist als -O3. O3 optimiert teilung in Bit Shift.
Os Code (100k) ist jedenfalls kleiner als O3 Code (114k). Ist 114k zu gross fuer den Atmega644p?

scheveningen meinte

Ich verstehe aber noch nicht warum -Os besser ist als -O3. O3 optimiert teilung in Bit Shift.
Os Code (100k) ist jedenfalls kleiner als O3 Code (114k). Ist 114k zu gross fuer den Atmega664p?

-Os == Optimize for Size
-O3 == Optimize for Speed

O3 macht Loop-unrolling und aehnliches... Optimiert also so, dass bei beliebig viel Programmspeicher optimal schneller Code rauskommt.

Os optimier auf Speicherplatz. Das heisst es kommt langsamerer Code raus, wenn er dafuer kompakter ist. Das heisst auch, dass garantiert kein Loop-unrolling und aehnliches gemacht wird. Eigentlich waehlt man diese Option nur dann, wenn man zu wenig Platz hat.

Beim NG optimiere ich mit -O3...

Gruss
- Amir

Divisionen auf signed ints können auch nicht so einfach zu shifts umgewandelt werden (Vorzeichenbit!) *zu-cascade-schiel*.
Sobald man aus dem "int" ein "unsigned int" macht, optimiert der Compiler auch von alleine.

Zitat

Ich habe auch den "if();if();" vs "if();else if();" Test gemacht. Das lohnt sich nicht weil es gleiche code ergebt.

Der Code ist ähnlich, aber die Sprungziele sind unterschiedlich
Der Ausdruck im zweiten if() wird nur im "else" Fall ausgewertet.

razzor, du hasst recht mit die shifts! Mit die if's sehe ich es nicht so deutlich...

int test3 (int c)
{
 if (c > 10)
 c=9;
 if (c<5)
 c=6;
 return c;
}

int test4 (int d)
{
 if (d > 10)
 d=9;
 else
 if (d<5)
 d=6; 
 return d;
}

werd:

0000001c <test3>:
 
int test3 (int c)
{
 1c: 9c 01 movw r18, r24
 if (c > 10)
 1e: 8b 30 cpi r24, 0x0B ; 11
 20: 91 05 cpc r25, r1
 22: 04 f0 brlt .+0 ; 0x24 <test3+0x8>
 24: 29 e0 ldi r18, 0x09 ; 9
 26: 30 e0 ldi r19, 0x00 ; 0
 28: 00 c0 rjmp .+0 ; 0x2a <test3+0xe>
 c=9;
 if (c<5)
 2a: 85 30 cpi r24, 0x05 ; 5
 2c: 91 05 cpc r25, r1
 2e: 04 f4 brge .+0 ; 0x30 <test3+0x14>
 30: 26 e0 ldi r18, 0x06 ; 6
 32: 30 e0 ldi r19, 0x00 ; 0
 c=6;
 return c;
}
 34: c9 01 movw r24, r18
 36: 08 95 ret

00000038 <test4>:

int test4 (int d)
{
 38: 9c 01 movw r18, r24
 if (d > 10)
 3a: 8b 30 cpi r24, 0x0B ; 11
 3c: 91 05 cpc r25, r1
 3e: 04 f0 brlt .+0 ; 0x40 <test4+0x8>
 40: 29 e0 ldi r18, 0x09 ; 9
 42: 30 e0 ldi r19, 0x00 ; 0
 44: 00 c0 rjmp .+0 ; 0x46 <test4+0xe>
 d=9;
 else
 if (d<5)
 46: 85 30 cpi r24, 0x05 ; 5
 48: 91 05 cpc r25, r1
 4a: 04 f4 brge .+0 ; 0x4c <test4+0x14>
 4c: 26 e0 ldi r18, 0x06 ; 6
 4e: 30 e0 ldi r19, 0x00 ; 0
 d=6; 
 return d;
}
 50: c9 01 movw r24, r18
 52: 08 95 ret

razzor meinte

Divisionen auf signed ints können auch nicht so einfach zu shifts umgewandelt werden (Vorzeichenbit!) *zu-cascade-schiel*.
Sobald man aus dem "int" ein "unsigned int" macht, optimiert der Compiler auch von alleine.

Ich dachte der GCC führt bei einer signed variable einen arithmetic shift aus, d.h. das Vorzeichen wird korrekt behandelt.

Klaus Leiss

LeissKG meinte

razzor meinte

Divisionen auf signed ints können auch nicht so einfach zu shifts umgewandelt werden (Vorzeichenbit!) *zu-cascade-schiel*.
Sobald man aus dem "int" ein "unsigned int" macht, optimiert der Compiler auch von alleine.

Ich dachte der GCC führt bei einer signed variable einen arithmetic shift aus, d.h. das Vorzeichen wird korrekt behandelt.

Richtig, dachte ich auch. Natuerlich nur bei Divisionen mit Zweierpotenzen...

Gruss
- Amir

Nochmal ein bisschen Code

Optimiert mit -Os:

int test (int a)
{
 0: 62 e0 ldi r22, 0x02 ; 2
 2: 70 e0 ldi r23, 0x00 ; 0
 4: 0e 94 00 00 call 0 ; 0x0 <test>
 8: cb 01 movw r24, r22

 return a/2;
}
 a: 08 95 ret

Optimiert mit -O3:

00000000 <test>:
int test (int a)
{
 0: 97 fd sbrc r25, 7
 2: 00 c0 rjmp .+0 ; 0x4 <test+0x4>
 4: 9c 01 movw r18, r24
 6: 35 95 asr r19
 8: 27 95 ror r18

 return a/2;
}
 a: c9 01 movw r24, r18
 c: 08 95 ret
int test (int a)
{
 e: 01 96 adiw r24, 0x01 ; 1
 10: 9c 01 movw r18, r24
 12: 35 95 asr r19
 14: 27 95 ror r18

 return a/2;
}
 16: c9 01 movw r24, r18
 18: 08 95 ret

We could gain more speed if we try to overclock the Mega644.

The http://belogic.com/uzebox/ uses even 28,6MHz on a Mega644 for clockspeed, thats 140% compared to the original 20MHz.

Zitat

The system runs overclocked at ~28.6Mhz (8 times the NTSC color burst frequency). Even if the part is rated at 20Mhz, I never experienced any problems to this day!

A downside:

Zitat

The more recent ATmega644P, seems to have problems with overclocking.
The UARTS suffers from severe glitches during operation.

Perhaps 26 MHz or less will do..

Of course the software needs to be modified, but hej who doesn't want to push a MK to its limits.

scheveningen meinte

razzor, du hasst recht mit die shifts! Mit die if's sehe ich es nicht so deutlich...

Scheinbar sind selbst alle funktionsinternen Sprungmarken ungültig wenn das Programm nicht gelinkt wurde.

Wenn man den Code vollständig linked sieht es anders aus:

int test1(int i) {
 if (i > 10) i = 3; /* geaendert auf i = 3, sonst optimiert gcc (sonst ist i < 5 nie möglich) */
 if (i < 5) i = 6;
 return i;
}

int test2(int i) {
 if (i > 10) i = 3;
 else if (i < 5) i = 6;
 return i;
}

int main(void) {
 test1(1);
 test2(2);
 return 0;
}

$ avr-gcc -Wall -Os avrtest.c -o avrtest
$ avr-objdump -d avrtest

00000054 <test1>:
 54: 8b 30 cpi r24, 0x0B ; 11
 56: 91 05 cpc r25, r1
 58: 1c f4 brge .+6 ; 0x60 <test1+0xc>
 5a: 85 30 cpi r24, 0x05 ; 5
 5c: 91 05 cpc r25, r1
 5e: 14 f4 brge .+4 ; 0x64 <test1+0x10>
 60: 86 e0 ldi r24, 0x06 ; 6
 62: 90 e0 ldi r25, 0x00 ; 0
 64: 08 95 ret

00000066 <test2>:
 66: 8b 30 cpi r24, 0x0B ; 11
 68: 91 05 cpc r25, r1
 6a: 1c f0 brlt .+6 ; 0x72 <test2+0xc>
 6c: 83 e0 ldi r24, 0x03 ; 3
 6e: 90 e0 ldi r25, 0x00 ; 0
 70: 08 95 ret
 72: 85 30 cpi r24, 0x05 ; 5
 74: 91 05 cpc r25, r1
 76: 14 f4 brge .+4 ; 0x7c <test2+0x16>
 78: 86 e0 ldi r24, 0x06 ; 6
 7a: 90 e0 ldi r25, 0x00 ; 0
 7c: 08 95 ret

00000054 <test1>:
 54: 62 e0 ldi r22, 0x02 ; 2
 56: 70 e0 ldi r23, 0x00 ; 0
 58: 0d d0 rcall .+26 ; 0x74 <__divmodhi4>
 5a: 97 2f mov r25, r23
 5c: 86 2f mov r24, r22
 5e: 08 95 ret

Der __divmodhi4() Call wird schon von -O1 unterdrückt (und zu einem arithmetic-shift gewandelt) und von -O2 schliesslich noch optimiert:

00000054 <test1>:
 54: 97 fd sbrc r25, 7
 56: 01 96 adiw r24, 0x01 ; 1
 58: 95 95 asr r25
 5a: 87 95 ror r24
 5c: 08 95 ret

Razzor, danke! Wann mein Kopter fliegt (in 2 Wochen?) werde ich versuchen die Code ein bisschen zu optimieren.
- mehr else Statements
- Wahrscheindlichkeitssortierung / profiling
- conditional compilation (fuer Leute die jetzt kein Kompass u.s.w. brauchen)