Compiler Ergebnis unverständlich

[Volker (Gast)]

Hallo,

Umgebung Attiny2313 1Mhz, neuestes Winavr


wollte mal das Timingverhalten bei Portpins testen und hab mir dazu das
Assembler-Listing angeschaut.

#define LED_rot_an   (PORTD |= (1<<LED_rot))
#define LED_rot_aus  (PORTD &= ~(1<<LED_rot))

In der main Routine dann
   do
  {
    LED_rot_aus;
    LED_rot_an;

  }
   while (1);

Daraus erzeugt der Compiler fogendes:
   do
  {
    LED_rot_aus;
  78:  95 98         cbi  0x12, 5  ; 18
    LED_rot_an;
  7a:  95 9a         sbi  0x12, 5  ; 18
  7c:  95 98         cbi  0x12, 5  ; 18
  7e:  95 9a         sbi  0x12, 5  ; 18
  80:  fb cf         rjmp  .-10       ; 0x78


Wieso wird vor rjmp nochmals ein cbi und sbi gemacht, obwohl ich das
gar nicht programmiert habe.

Sollte es nicht so aussehen:
   do
  {
    LED_rot_aus;
  78:  95 98         cbi  0x12, 5  ; 18
    LED_rot_an;
  7a:  95 9a         sbi  0x12, 5  ; 18
  rjmp

Bitte erklärt mir das, danke

Volker

[A.K. (Gast)]

-Os statt -O2
Willst Du Platz sparen, oder Zeit?
Stichwort: "loop unrolling".

[Volker (Gast)]

hab noch was vergessen:

#define LED_rot 5

natürlich macht es keinen Sinn eine LED mit so hoher Frequenz zu
takten, mir geht es lediglich ums Prinzip, dass der Compiler manches
wegoptimiert ist klar, aber dass er einiges hinzufügt verstehe ich
nicht ganz.

Viele Grüße

Volker

[Volker (Gast)]

@A.K.

danke, mit -Os gehts wunderbar, nur verstehe ich eines immer noch
nicht, durch den Zusatz ist weder Geschwindigkeit noch Platz optimiert
(beides ist schlechter).

Nun ja, du hast mir ja ein Stichwort gegeben, werde mal auf die Suche
gehen.

Volker

[A.K. (Gast)]

Welcher Code ist schneller? Die von dir erwartete Version (6 Takte pro
Iteration) oder die von GCC erzeugte Version (10 Takte pro 2
Iterationen, also effektiv 5 pro Iteration)? Du hast dem Compiler
gesagt, er soll auf Laufzeit optimieren. Das hat er getan.

Siehe http://www.nullstone.com/htmls/category/unroll.htm

[Volker (Gast)]

Jetzt hab ichs kapiert, hab auch noch einen anderen Thread gefunden,
da hatte jemand das gleiche Problem:

http://www.mikrocontroller.net/forum/read-2-214013.html#214472

vielen Dank nochmals, man lernt halt nie aus...

Volker