Frage an die Compilerbauer

Ich kenne die Antwort nicht, aber wenn ich vor der gleichen 
Fragestellung stehen würde, würde ich mir den erzeugten Assemblercode 
ansehen.

Gruß
Dennis

Bei Os wird die <__mulhi3> aufgerufen währen bei den anderen Stufen dies 
wohl nicht erfolgt.

O2:

1

    Temp2 = Temp * 60;

2

  58:  20 91 60 00   lds  r18, 0x0060

3

  5c:  30 91 61 00   lds  r19, 0x0061

4

  60:  c9 01         movw  r24, r18

5

  62:  82 95         swap  r24

6

  64:  92 95         swap  r25

7

  66:  90 7f         andi  r25, 0xF0  ; 240

8

  68:  98 27         eor  r25, r24

9

  6a:  80 7f         andi  r24, 0xF0  ; 240

10

  6c:  98 27         eor  r25, r24

11

  6e:  82 1b         sub  r24, r18

12

  70:  93 0b         sbc  r25, r19

13

  72:  88 0f         add  r24, r24

14

  74:  99 1f         adc  r25, r25

15

  76:  88 0f         add  r24, r24

16

  78:  99 1f         adc  r25, r25

17

  7a:  90 93 63 00   sts  0x0063, r25

18

  7e:  80 93 62 00   sts  0x0062, r24

Os:

1

  Temp2 = Temp * 60;

2

  58:  80 91 60 00   lds  r24, 0x0060

3

  5c:  90 91 61 00   lds  r25, 0x0061

4

  60:  6c e3         ldi  r22, 0x3C  ; 60

5

  62:  70 e0         ldi  r23, 0x00  ; 0

6

  64:  06 d0         rcall  .+12       ; 0x72 <__mulhi3>

7

  66:  90 93 63 00   sts  0x0063, r25

8

  6a:  80 93 62 00   sts  0x0062, r24

Speicherverbrauch ist bei OS 132Byte Flash und 4Byte RAM
Speicherverbrauch ist bei O2 138Byte Flash und 4Byte RAM

Somit wird hier für 6Byte weniger Flashverbrauch Faktor 4,5 bei der 
Geschwindigkeit in Kauf genommen!? Krass

Daraus schliesse ich, dass wenn es nicht unbedingt auf ein paar Byte 
ankommt man doch lieber O2 nutzen sollte entgegen dem Artikel hier?
AVR-GCC-Codeoptimierung

Ingo Less schrieb:
> Somit wird hier für 6Byte weniger Flashverbrauch Faktor 4,5 bei der
> Geschwindigkeit in Kauf genommen!? Krass

In dem Code, den der Compiler hier sieht, beträgt der Unterschied nicht
6, sondern 20 Bytes, und das ist schon ein deutlicher Unterschied. Der
Platzbedarf für die Bibliotheksroutine dürfte schon bei zwei
Multiplikationen dieser Art mehr als kompensiert werden.

Ingo Less schrieb:

> Somit wird hier für 6Byte weniger Flashverbrauch Faktor 4,5 bei der
> Geschwindigkeit in Kauf genommen!? Krass

Aber nur dann, wenn dein Programm ausschliesslich aus 16*16 Bit 
Multiplikationen besteht.

Leicht off topic .....

.... aber ich finde es sehr interessant wieviele Comilerbauer es
hier im Forum gibt:

Ingo Less schrieb:
> Frage an die Compilerbauer

Da muss es ja vor (erschaffenen) Compilern nur so wimmeln (wenn
jeder so im Background seine(n) Compiler baut), bzw. hier gibt es
soviel Optimierungspotential dass ja ein ganz toller optimierter
GCC für die AVRs dabei herauskommen muss.....   (   ;-)   )

Eberhard F. schrieb:
> Leicht off topic .....
Nein, leicht überflüssig ..... (   ;-)   )

Eberhard F. schrieb:
> .... aber ich finde es sehr interessant wieviele Comilerbauer es
> hier im Forum gibt:

Ist nicht die erste Frage im Forum, die falsch gestellt war. Und wird 
auch nicht die letzte bleiben. Soll sie deshalb verhungern, weil sich 
niemand zu antworten traut?

PS: Ex-Compilerbauer, falls dich das beruhigt. ;-)

OK,

der eigentlich sinn hintet diesem Banalprogramm war eigentlich, 
herauszufinden ob der Optimizer aus *60 auf einem AVR ohne 
Multiplikationseinheit einen Shift macht.

Nämlich führt Temp2 = Temp * 60 zum selben Ergebnis wie Temp2 = Temp<<6 
- Temp<<2. Die Frage war ob er das selber herausfinden würde. 
Offensichtlich jedoch nicht.

EDIT: Gut, damit hätte ich auch früher rausrücken müssen...

ich würde wette aus *64 hätte er ein Lösung mit einem Shift gebaut ;)

Gruß J

Jonas Biensack schrieb:
> ich würde wette aus *64 hätte er ein Lösung mit einem Shift gebaut ;)
Bei O2 ja, bei Os nein

Ingo Less schrieb:
> Nämlich führt Temp2 = Temp * 60 zum selben Ergebnis wie Temp2 = Temp<<6
> - Temp<<2. Die Frage war ob er das selber herausfinden würde.
> Offensichtlich jedoch nicht.

Er macht das sogar noch besser: Nämlich mit

1

uint16_t Temp3 = Temp;

2

Temp2 = ((Temp3 << 4) - Temp3) << 2;

Das liegt dem barrel-shifter-losen AVR sehr viel besser. Beachte
außerdem, auf welch geniale Weise der Shift um 4 realisiert ist.

Edit:

Habe noch einen Klammerfehler und eine kleine Unstimmigkeit korrigiert.

Bisher habe ich ich immer OS genutzt, wie es empfohlen wird. hatte 
bisher auch nie das Bedürfnis etwas von Hand zu optimieren. Wie gesagt, 
hier war nur der Versuch was der Optimizer aus dem *60 macht. Aber er 
macht es ja scheinbar noch besser wie erwartet, auch wenn ich den 
Assemblercode mangels Assemblerkenntnissen nicht so recht nachvollziehen 
kann.

Meiner Erfahrung nach spart man bei Programmen aus der realen Welt mit
-Os prozentual deutlich mehr Flash-Bytes als mit -O2 Zyklen. Da ich
zudem häufiger Flash-Kapazitäts- als Laufzeitprobleme habe, verwende ich
normalerweise -Os.

Peter II schrieb:
> dann mach doch einfach
>
>

1

Temp2 = (Temp * 64) - (Temp * 4);

Und was soll da anders sein als mit * 60 ???

*60 in shifts etc. zu expandieren ist nur günstig, wenn es keine MUL 
Befehle gibt.

MUL mit 60 ist dann besser als Rumgeschiebe.

Das weiß die Kristallkugel.

Es ist weder Die Compilerversion genannt noch für welches Device 
übersetzt wurde.

Und ja, avr-gcc macht nicht immer den besten denkbaren Code, und das 
gilt auch für den Code, den er für Multiplikationen erzeugt — auch mit 
avr-gcc 4.9 oder 5.

SF6 schrieb:
> Denkst du nicht, der Compiler hätte den MUL Befehl eingebaut wenn es
> einen gäbe? Beitrag "Re: Frage an die Compilerbauer"

Der Code dort ist vermutlich für einen attiny übersetzt worden. Wenn man 
stattdessen einen atmega auswählt, wird auch MUL verwendet, und zwar 
sowohl bei -Os als auch bei -O2.

1

        lds r18,Temp

2

        lds r19,Temp+1

3

        mul r20,r18

4

        movw r24,r0

5

        mul r20,r19

6

        add r25,r0

7

        clr __zero_reg__

8

        sts Temp2+1,r25

9

        sts Temp2,r24