Avr-gcc/Optimierungen - Versionsgeschichte

Besserwessi: /* Optimierungsgrad */

2013-04-26T16:32:55Z

‎Optimierungsgrad

Lutz: /* Division durch Multiplikation */

2013-04-26T10:05:33Z

‎Division durch Multiplikation

Lutz: /* Vermeiden von float und double */

2013-04-26T10:04:55Z

‎Vermeiden von float und double

SprinterSB_alt: diffuse

2012-11-27T22:30:28Z

diffuse

SprinterSB_alt: Ausgelagert aus avr-gcc

2012-11-27T22:25:59Z

Ausgelagert aus avr-gcc

Neue Seite

Beim Programmieren in C möchte man sich möglichst wenig mit der Codeerzeugung selbst auseinandersetzen. Man verwendet ja gerade deshalb einen Compiler und programmiert nicht in Assembler, weil man sich nicht um Register-Belegungen o.ä. kümmern will, sondern nur um die zu lösende Aufgabe.

GCC erzeugt zwar recht guten Code, aber er ist nicht perfekt. Gerade auf Systemen wie AVR mit nur sehr begrenzten Resourcen muss man daher dem Compiler hilfreich zur Seite stehen, wenn man noch dichteren/schnelleren Code erhalten möchte.

:''"Unlike most other C compilers, GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.''

:''Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs."''

Um das Ergebnis zu beurteilen, hilft ein Blick ins Listfile.
Siehe dazu auch die Abschnitte
"[[Hallo Welt für AVR (LED blinken)#Listfile erstellen|Listfile erstellen]]"
und
"[[Hallo Welt für AVR (LED blinken)#Die Größe ermitteln|Die Größe ermitteln]]"
im [[Hallo Welt für AVR (LED blinken)|Hallo Welt für AVR]].

==Optimierungsgrad==
Als Optimierungsgrad erweist sich <tt>-Os</tt> (Optimize for Size) als der beste, evtl. noch <tt>-O2</tt>. Ohne Angabe eines Optimierungsgrades wird nicht optimiert, was gleichbedeutend mit der Option <tt>-O0</tt> ist. Abzuraten ist von der maximalen Optimierung <tt>-O3</tt>, die wegen function inlining und loop unrolling zu sehr breitem Code führt und für AVR absolut nicht angesagt ist.

==Vermeide printf, scanf, malloc==
Funktionen von diesem Kaliber sind die absoluten Platz- und Zeitfresser.

Alternativen findet man reichlich in der <tt>avr-libc</tt> wie <tt>itoa</tt> und <tt>atoi</tt>.
Und für <tt>malloc</tt> und Konsorten sind dynamische Arrays und das Compiler-Builtin <tt>__builtin_alloca</tt> effizientere Alternativen, siehe auch im Abschnitt "[[avr-gcc#Dynamische Speicherallokierung|Dynamische Speicherallokierung]]".

==Konstante Strings ins Flash==
Konstante Strings, wie sie zu Ausgabezwecken Verwendung finden, werden im Programm oft nicht verändert und brauchen nicht SRAM zu belegen (und damit auch Flash, von wo aus sie vom Startup-Code ins SRAM kopiert werden), sondern gehören ins Flash!

Entsprechende Routinen, um auf Strings im Flash zuzugreifen, tragen die Suffix <tt>_P</tt>, wie z.B. <tt>strcmp_P</tt> mit dem Prototyp
extern int *strcmp_P (char *, const prog_char *)
Die Implementierungen befinden sich in der <tt>avr-libc</tt>.

'''Anwendung:'''
#include <avr/pgmspace.h>

const prog_char str_p[] = "Ein String im Flash";
const char str2_p[] PROGMEM = "Noch ein String im Flash";
...
{{ccomment|String im SRAM mit String im Flash vergleichen}}
if (!strcmp_P (str_sram, str_p))
{
{{ccomment|mach was bei Gleichheit}}
}

{{ccomment|"foo" wird im RAM angelegt. Ineffizient für konstante Strings!}}
{{ccomment|Beachte, daß damit strcmp (nicht strcmp_P) benutzt werden muss.}}
if (!strcmp (str_sram, "foo"))
{
{{ccomment|mach was bei Gleichheit}}
}

{{ccomment|PSTR bewirkt, daß die String-Konstante "foo"}}
{{ccomment|im Flash angelegt wird}}
if (!strcmp_P (str_sram, PSTR ("foo"))
{
{{ccomment|mach was bei Gleichheit}}
}
...
}

===Sprungtabelle===
Genauso macht man auch eine Sprungtabelle, um anhand von Kommando-Strings dazugehörige Funktionen ausführen zu lassen:
#include <avr/pgmspace.h>

int func1 (int arg)
{
...
}

#define TEXT_LEN 15

{{ccomment|Die Kommandostruktur}}
typedef struct
{
int (*func)(int); {{ccomment|Zeiger auf die auszuführende Funktion}}
int arg; {{ccomment|das Argument, das mitübergeben wird}}
char text[1+TEXT_LEN]; {{ccomment|Text, maximal TEXT_LEN Zeichen lang}}
} command_t;

{{ccomment|Das Array mit den Kommandos.}}
{{ccomment|Die funcx sind vom Prototyp (z.B. func1 oben)}}
{{ccomment|int funcx (int arg);}}
const command_t commands[] PROGMEM =
{
{ func1, 0, "Befehl 1" },
{ func2, 3, "Befehl für func2" }
};

{{ccomment|Sucht in commands[] nach text und führt gegebenenfalls}}
{{ccomment|die dazugehörige Funktion funcx mit Argument arg aus.}}
{{ccomment|Liefert den Rückgabewert von funcx}}
{{ccomment|oder -1, falls text nicht gefunden wurde.}}
int execute (const char *text)
{
{{ccomment|Schleifenvariable}}
unsigned char i;

{{ccomment|Wandert durch das Array mit Kommando-Strukturen}}
const command_t * cmd = commands;

{{ccomment|sizeof wird von gcc ausgewertet und ist wie eine Konstante,}}
{{ccomment|denn beide sizeofs sind zur Compilezeit bekannt}}
for (i=0; i < sizeof(commands) / sizeof(command_t); i++)
{
{{ccomment|Ist das der gesuchte String?}}
if (strcmp_P (text, cmd->text))
{
{{ccomment|Nein, dann weitersuchen}}
cmd++;
continue;
}

{{ccomment|Ja}}
int (*func)(int), arg;

{{ccomment|Dann Funktionszeiger und Argument besorgen,}}
func = (int(*)(int)) pgm_read_word (& cmd->func);
arg = (int) pgm_read_word (& cmd->arg);

{{ccomment|Funktion ausführen und deren Wert zurückliefern}}
return func (arg);
}

{{ccomment|text ist nicht in commands}}
return -1;
}

Nachteil dabei ist, daß jeder String den maximalen Platz von <tt>TEXT_LEN+1</tt> Zeichen belegt.
Falls man da noch weiter sparen will, dann kann man die Strings wieder ins Flash legen und ihre Adresse in der Struktur merken. Dadurch belegt ein String nur noch Länge+3 Zeichen (+3 wegen 1 Endezeichen und 2 Bytes für seine in der Struktur gemerkte Adresse). Die Definition der Tabelle wird aber umständlicher, weil jeder String einzeln angegeben werden muss:
#include <avr/pgmspace.h>

{{ccomment|Die Kommandostruktur}}
typedef struct
{
...
char * text; {{ccomment|Zeiger auf Text}}
} command_t;

const prog_char str_1[] = "Befehl 1";
const prog_char str_2[] = "Befehl für func2";

const command_t commands[] PROGMEM =
{
{ func1, 0, str_1 },
{ func2, 3, str_2 }
};

{{ccomment|Sucht in commands[] nach text und führt gegebenenfalls}}
{{ccomment|die dazugehörige Funktion funcx mit Argument arg aus.}}
{{ccomment|Liefert den Rückgabewert von funcx}}
{{ccomment|oder -1, falls text nicht gefunden wurde.}}
int execute (const char *text)
{
{{ccomment|Schleifenvariable}}
unsigned char i;

{{ccomment|Wandert durch das Array mit Kommando-Strukturen}}
const command_t * cmd = commands;

{{ccomment|sizeof wird von gcc ausgewertet und ist wie eine Konstante,}}
{{ccomment|denn beide sizeofs sind zur Compilezeit bekannt}}
for (i=0; i < sizeof(commands) / sizeof (command_t); i++)
{
const prog_char * text_P;

{{ccomment|Liest die Startadresse von str_x}}
text_P = (const prog_char *) pgm_read_word (& cmd->text);

{{ccomment|Ist das der gesuchte String?}}
if (strcmp_P (text, text_P))
{
...

==Lokale Variablen verwenden==

Beim Manipulieren globaler Variablen kann es günstig sein, diese in eine lokale Variable zu kopieren, dort zu verändern, und sie danach wieder zu schreiben
<pre>
char var;

void foo1()
{
var++;
if (var > 10)
var = 1;
}
</pre>
Dadurch wird einmal unnötig gespeichert (der dritte Befehl kann vermieden werden).
<pre>
foo1:
lds r24,var ; *movqi/4 [length = 2]
subi r24,lo8(-(1)) ; addqi3/2 [length = 1]
sts var,r24 ; *movqi/3 [length = 2]
cpi r24,lo8(11) ; cmpqi/2 [length = 1]
brlt .L3 ; branch [length = 1]
ldi r24,lo8(1) ; *movqi/2 [length = 1]
sts var,r24 ; *movqi/3 [length = 2]
.L3:
ret
</pre>
Indem man eine lokale Variable (<tt>var2</tt>) verwendet für die Änderung von <tt>var</tt> vermeidet man dies:
<pre>
char var;

void foo2()
{
char var2 = var;

var2++;
if (var2 > 10)
var2 = 1;

var = var2;
}
</pre>
Dadurch wird erst am Ende gespeichert. <tt>var2</tt> lebt in Register <tt>r24</tt>.
<pre>
foo2:
lds r24, var ; *movqi/4 [length = 2]
subi r24,lo8(-(1)) ; addqi3/2 [length = 1]
cpi r24,lo8(11) ; cmpqi/2 [length = 1]
brlt .L2 ; branch [length = 1]
ldi r24,lo8(1) ; *movqi/2 [length = 1]
.L2:
sts var, r24 ; *movqi/3 [length = 2]
ret
</pre>

Bei diesem einfachen Beispiel spart man lediglich eine Instruktion. Bei komplexeren Rechnungen oder längeren Datentypen kann es aber durchaus lohnender sein, in lokale Register zu kopieren.

==Arithmetik==

=== Daten zerlegen/zusammensetzen ===

In systemnahen Programmen hat man oft was Problem, auf die einzelnen Bytes oder Bitfelder einer grösseren Datenstruktur zuzugreifen. Indem man sich ein Komposit baut, das die gewünschten Strukturen überlagert, kann man effizient z.B. auf Bytes zugreifen. Ausnahme sind Bitfelder, deren Verwendung etwas breiten Code ergibt. Bitfelder "von Hand" zu manipulieren, ist da manchmal effizienter, führt jedoch zu schlecht lesbarem Code.

Oft benötigt wird der Zugriff auf die einzelnen Bytes eines <tt>int</tt>, also der Zugriff auf die Bytes eines 16-Bit-Wertes:

typedef union
{
unsigned char asByte[2];
unsigned short asWord;
int asInt;
} data16_t;

data16_t data;
...
int foo;
uint8_t wert;

data.asInt = foo;
wert = data.asByte[1]; {{ccomment|die oberen 8 Bits von foo}}

Ein komplexeres Beispiel, das noch mehr Datentypen überlagert:
typedef ... foo_t;

typedef union
{
unsigned char byte[4]; {{ccomment| Zugriff als Bytes (8 Bit) }}
unsigned short word[2]; {{ccomment| Zugriff als Words (16 Bit) }}
signed long slong; {{ccomment| Zugriff als signed long (32 Bit) }}

struct {{ccomment| Zugriff auf einzelne Bitgruppen }}
{
unsigned bit_0_3 : 4; {{ccomment| 4 Bits (0..3) }}
unsigned bit_4_8 : 5; {{ccomment| 5 Bits (4..8) }}
unsigned bit_9_21 : 13; {{ccomment| 13 Bits (9..21) }}
unsigned bit_22_31: 10; {{ccomment| 10 Bits (22..31) }}
};

foo_t foo; {{ccomment| Zugriff als foo-Struktur }}
} data_t;

...
{
data_t data;

data.byte[2] = 12; {{ccomment| setzt byte 2 auf 12 }}
data.bit_4_8 = 0x1f; {{ccomment| setzt bits 4..8 (5 Stück) alle auf 1 }}

int anInt = data.foo.anInt; {{ccomment| liest ein Feld von foo (hier ein int) }}
...
}

===libgcc2 verwenden===

In der libgcc2 sind einige Arithmetik-Routinen in Assembler implementiert. Dazu gehören ein paar Algorithmen zu Division (mit Rest) und Multiplikation.

Von diesen Algorithmen werden durch die avr-libc jedoch nur zwei Strukturen und Funktionen veröffentlicht: <tt>div_t</tt> und <tt>ldiv_t</tt> resp. die Funktionen <tt>div()</tt> und <tt>ldiv()</tt>. Siehe dazu deine Dokumentation zur avr-libc. Damit kann man Quotient und zusätzlich den Rest bei einer Division 16/16 bzw. 32/32 berechnen lassen; den Rest bekommt man quasi kostenlos als Nebenprodukt. Das ist praktisch, wenn man z.b. eine Zahl in Dezimaldarstellung umwandeln möchte oder von/nach [[BCD]].

Zusätzlich zu den via avr-libc veröffentlichten Funktionen gibt es aber noch Routinen, die z.B. auf 8-Bit-Werten operieren oder mit <tt>unsigned</tt> Typen und dementsprechend effizienter sind.

'''Beispiel: Umwandeln nach Dezimalstring'''

Hier ein Beispiel, das Division mit Rest für <tt>unsigned short</tt> verwendet, um eine 16-Bit-Zahl in Dezimaldarstellung zu wandeln:

{{ccomment| Struktur definieren und Funktion bekannt machen }}
typedef struct
{
unsigned short quot;
unsigned short rem;
} udiv_t;

extern udiv_t udiv (unsigned short, unsigned short) __asm__("__udivmodhi4");

{{ccomment| 5 Ziffern (0...65535) und evtl. noch eine führende 0 }}
#define DIGITS 6

{{ccomment| +1 wegen String-Ende (wird im Startup auf 0 gesetzt) }}
char string[DIGITS+1];

{{ccomment| Wandelt zahl in Dezimaldarstellung um. }}
{{ccomment| Der return-Wert zeigt irgendwo ins string[]-Array. }}
{{ccomment| string[] wird verändert. }}
char* toString (unsigned short zahl)
{
{{ccomment| s zeigt auf das Ende von string }}
{{ccomment| string wird von hinten nach vorne gefüllt }}
char *s = string + DIGITS;

{{ccomment| qrem enthält Quotient (quot) und Rest (rem) der Divisionen }}
udiv_t qrem = {.quot = zahl};

do
{
{{ccomment| Division mit Rest durch 10 }}
{{ccomment| quot: Ergebnis für den nächsten Durchlauf }}
{{ccomment| rem: Rest ist die Ziffer im 10er-System }}
qrem = udiv (qrem.quot, 10);

{{ccomment| Ziffer in Zeichen wandeln und speichern }}
*(--s) = '0' + qrem.rem;
}
while (0 != qrem.quot);

{{ccomment| Falls eine führende '0' gespeichert wurde: weg damit }}
{{ccomment| ausser zahl war selbst schon 0 }}
if (*s == '0' && *(s+1) != '\0')
s++;

return s;
}

Falls man eine Division und/oder Rest für 8-Bit braucht, dann geht für <tt>unsigned</tt> analog.

'''Beispiel: BCD-Umrechnung'''

Wandeln einer 8-Bit-Zahl <tt>0 <= num < 100</tt> nach [[BCD]]

typedef struct
{
unsigned char quot; {{ccomment| Quotient }}
unsigned char rem; {{ccomment| Rest (remainder) }}
} udiv8_t;

extern udiv8_t udiv8 (unsigned char, unsigned char) __asm__ ("__udivmodqi4");

{{ccomment| Wandelt num nach BCD um, 0 <= num <= 99 }}
{{ccomment| return-Wert ist dann 0x0 <= return <= 0x99 }}
unsigned char to_bcd (unsigned char num)
{
udiv8_t qrem = udiv8 (num, 10);

return (unsigned char) (qrem.quot << 4) | qrem.rem;
}

===Division durch Multiplikation===
Bei den AVRs (Mega...) sind Multiplikationen deulich schneller als Divisionen. Besonders bei Fleißkommazahlen lohnt es daher eine Division durch die Multiplikation mit dem Kehrwert zu ersetzen. Bei Integer Zahlen sind dem durch die Rundung Grenzen gesetzt.

===Vermeiden von float und double===
GCC kennt für die AVRs zur Zeit nur einen Fleißkommatyp. Da keine Hardwareunterstützung dafür vorhanden ist, dauern Fleißkommarechnungen relativ lange. Gerade Additionen sind deutlich langsamer als bei Integer. Auch die Codelänge nimmt erheblich zu, selbst wenn nur wenige Fleißkommazahlen genutzt werden.

Ein Alternative zu Fleißkommazahlen ist die Benutzung von Festkommazahlen, auch wenn die nicht direkt von GCC unterstützt werden. Die Werte werden einfach alle mit einem konstanten Faktor (z.B. 256,1024 oder 1000) skaliert.
Es wird dann mit Integer oder Long Integer gerechnet und bei Multiplicationen / Divisionen der zusätzliche Skalenfaktor berücksichtig.

@@ Zeile 369: / Zeile 369: @@
 ===Vermeiden von float und double===
-GCC kennt für die AVRs zur Zeit nur einen Fleißkommatyp. Da keine Hardwareunterstützung dafür vorhanden ist, dauern Fleißkommarechnungen relativ lange. Gerade Additionen sind deutlich langsamer als bei Integer.  Auch die Codelänge nimmt erheblich zu, selbst wenn nur wenige Fleißkommazahlen genutzt werden.
+GCC kennt für die AVRs zur Zeit nur einen Fließkommatyp. Da keine Hardwareunterstützung dafür vorhanden ist, dauern Fließkommarechnungen relativ lange. Gerade Additionen sind deutlich langsamer als bei Integer.  Auch die Codelänge nimmt erheblich zu, selbst wenn nur wenige Fließkommazahlen genutzt werden.
-Ein Alternative zu Fleißkommazahlen ist die Benutzung von Festkommazahlen, auch wenn die nicht direkt von GCC unterstützt werden. Die Werte werden einfach alle mit einem konstanten Faktor (z.B. 256,1024 oder 1000) skaliert.
+Ein Alternative zu Fließkommazahlen ist die Benutzung von Festkommazahlen, auch wenn die nicht direkt von GCC unterstützt werden. Die Werte werden einfach alle mit einem konstanten Faktor (z.B. 256,1024 oder 1000) skaliert.
-Es wird dann mit Integer oder Long Integer gerechnet und bei Multiplicationen / Divisionen der zusätzliche Skalenfaktor berücksichtig.
+Es wird dann mit Integer oder Long Integer gerechnet und bei Multiplikationen / Divisionen der zusätzliche Skalenfaktor berücksichtig.
 [[Kategorie:Microcontroller]]
 [[Kategorie:Quellcode C]]

← Nächstältere Version		Version vom 27. November 2012, 22:30 Uhr
Zeile 373:		Zeile 373:
	Ein Alternative zu Fleißkommazahlen ist die Benutzung von Festkommazahlen, auch wenn die nicht direkt von GCC unterstützt werden. Die Werte werden einfach alle mit einem konstanten Faktor (z.B. 256,1024 oder 1000) skaliert.		Ein Alternative zu Fleißkommazahlen ist die Benutzung von Festkommazahlen, auch wenn die nicht direkt von GCC unterstützt werden. Die Werte werden einfach alle mit einem konstanten Faktor (z.B. 256,1024 oder 1000) skaliert.
	Es wird dann mit Integer oder Long Integer gerechnet und bei Multiplicationen / Divisionen der zusätzliche Skalenfaktor berücksichtig.		Es wird dann mit Integer oder Long Integer gerechnet und bei Multiplicationen / Divisionen der zusätzliche Skalenfaktor berücksichtig.
		+
		+	[[Kategorie:Microcontroller]]
		+	[[Kategorie:Quellcode C]]

@@ Zeile 15: / Zeile 15: @@
 ==Optimierungsgrad==
-Als Optimierungsgrad erweist sich <tt>-Os</tt> (Optimize for Size) als der beste, evtl. noch <tt>-O2</tt>. Ohne Angabe eines Optimierungsgrades wird nicht optimiert, was gleichbedeutend mit der Option <tt>-O0</tt> ist. Abzuraten ist von der maximalen Optimierung <tt>-O3</tt>, die wegen function inlining und loop unrolling zu sehr breitem Code führt und für AVR absolut nicht angesagt ist.
+Als Optimierungsgrad erweist sich <tt>-Os</tt> (Optimize for Size) als der beste, evtl. noch <tt>-O2</tt>. Abzuraten ist von der maximalen Optimierung <tt>-O3</tt>, die wegen function inlining und loop unrolling zu sehr breitem Code führt und für AVR absolut nicht angesagt ist.
 ==Vermeide printf, scanf, malloc==

@@ Zeile 364: / Zeile 364: @@
 ===Division durch Multiplikation===
-Bei den AVRs (Mega...) sind Multiplikationen deulich schneller als Divisionen. Besonders bei Fleißkommazahlen lohnt es daher eine Division durch die Multiplikation mit dem Kehrwert zu ersetzen. Bei Integer Zahlen sind dem durch die Rundung Grenzen gesetzt.
+Bei den AVRs (Mega...) sind Multiplikationen deulich schneller als Divisionen. Besonders bei Fließkommazahlen lohnt es daher eine Division durch die Multiplikation mit dem Kehrwert zu ersetzen. Bei Integer Zahlen sind dem durch die Rundung Grenzen gesetzt.
-−
-−
 ===Vermeiden von float und double===