mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ASM-Nachoptimierer


Autor: Stefan Helmert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe im PICmicro-Hochsprachenbuch gelesen, dass Compiler einen
nicht optimalen Code erstellen (obwohl manche 2300 Euro kosten).
Gibt es da so etwas wie einen Nachoptimmierer, der das erstellte
ASM-File in seiner Funktionsweise analysiert und anschließend das
optimale ASM-File generiert?
So könnte man jeden billigen Compiler und jede Hochsprache verwenden
und hätte immer die maximal mögliche Performance.

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Märchenstunde?

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist genau umgekehrt:

Ein C-Compiler kann seinen Code mehr oder weniger optimieren, aber nur
aus dem C-Code raus.
Ein gcc optimiert z.B. deutlich besser als ich es in Assembler könnte -
was allerdings nicht viel heisst :-)
Allerdings baut er auch etwas an Overhead ein, den man beim händischen
programmieren einsparen könnte.
Du solltest dir mal eine Assemblerausgabe von einem C-Compiler ansehen,
da ist nicht mehr viel rauszuholen.

Autor: Pimmelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan

Das gute an einer Hochsprache ist doch dass Sie einfach ist und man
sehr schnell Programmieren kann. Das hat natürlich den Nachteil dass
der Code nicht immer optimal ist.
Du willst den Fünfer und das Brötchen.

Anders gefragt braucht man einen Opimierten code?
Ich sage mal relativ selten wenn es um geschwindigkeit geseht eherer
wenn es um Speicherplatz geht.

Das einfachste ist du schreibst den Code mit einer Hochsprache und
lässt in in Assebler übersetzen und dann optimiert du den code von
Hand.

Gruss

Pimmelmann

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ergänzend hierzu hätte ich folgende Frage bzw. Handoptimierung.
Angenommen ich habe folgene Funktion mit inlines:

void Test(void)
{
   bla...
   bla...

   asm("ldi r10, 10")
   ...
}

Ist das denn zulässig ? Sprich, kann ich davon ausgehen, daß r10
benutzt werden darf ? Oder muß ich vorher r10 sichern, oder erkennt das
mein C-Compiler ? Wie macht man das am besten ?

Thorsten

Autor: Stefan Helmert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich wäre es doch gut wenn der Optimiere den vollen Speicherplatz
ausnutzen würde und die Geschwindigkeit optiemiert, damit man einen
langsameren Quartz nehmen kann um Strom zu sparen.
Dabei sollte der Optimierer aber intelligent vorgehen z.B. die selten
genutzten Routienen Speicherplatzoptimieren und die oft benötigten
geschwindigkeitsoptimieren. Aber er soll genau analysieren, d.h. wenn
in der Hochsprache ein float definiert wurde, der aber nur die Werte 1
und 2 annimmt und diese Variable aber auch noch mit einer anderen
multipliziert wird, so wird stattdessen ein bit verwendet und zum
multiplizieren der rlf-Befehl genutzt.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte auch irgendwo mal Werbung für einen 8051-Optimierer gesehen
mit märchenhaften Kompressionsraten und Geschwindigkeitszuwächsen.

Ist warscheinlich sowas wie die RAM-Doubler:
Man will das Geld von Leuten abgreifen, die sich nicht so auskennen.
Und dann verschwindet diese Firma sang und klanglos schnell wieder.


Die beste Optimierung kann nur der Programmierer und der Compiler
selber machen, da er noch alle Informationen hat.

Ist erstmal Assembler draus entstanden und sind alle Adreßbezüge
aufgelöst, ist alles vorbei. Zu erkennen, wie man nach Rausstreichen
oder Umstellen einer Codesequenz alle Adreßbezüge korrigieren muß, kann
kein noch so intelligentes Programm der Welt schaffen.


Peter

Autor: Stefan Helmert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich meine das so:
Es ist doch egal wie ein Programm geschrieben ist ASM, C, Basic. Es
kommt theoretisch nur auf die Funktion an und diese soll der
Nachoptimierer herausfinden und ein Programm generieren, dass
effizienter arbeitet. Und wenn das Programm in C geschrieben und
Compiliert wurde hat es doch die gleich Funktion nur der genaue Ablauf
ist anders. Der Nachoptimierer soll das Programm nicht umschachteln,
sondern im ersten Schritt herausfinden wie das Programm reagiert und
anschließend weg von diesem Programm einen völlig anderen (optimalen)
Code erstellen.

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sagen wir es mal so:

Ich habe mir grad was ausgerechnet, es kommt 23 heraus.
Kannst du bitte meine Rechnung optimieren?

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das ne Fangfrage?
Kommen jetzt die Illuminaten? g

 :-)

Autor: Stefan Helmert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
23 ist hier ja schon das Optimum. Wenn aber der ASM-Programmierer oder
Compiler den µC stattdessen immer deine berechnung macht z.B.
x = x + 20
x = x + 3
anstelle von:
x = x + 23
ist das schon mist.
oder wenn man in der Hochsprache schreibt:
konst = 23

schleife
x = x + konst
Befehle...
goto schleife

und die Variable konst wird nur einmal gesetz und nie verändert, so das
man auch schreiben könnte:

x = x + 23

anstelle von:

x = x + konst

so müsste der µC für x = x + konst mehr rechnen als für x = x + 23
weil konst ja erst beim PIC ins W-Register geladen werden musst.
Und genau solche Unsinnigkeiten (die ja auch ein Mensch lösen könnte
obwohl dieser selbst das Programm nicht erfunden hat) soll der
Nachoptimierer finden.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

der SDCC ermöglicht tatsächlich soetwas. Die nennen das peep hole
optimizer. Hier wird nach der Kompilation des C-Quelltextes der
ASM-Coder (vor dem eigentlichen Assemblieren) nochmal geparst und
irrige Konstruktionen wie

mov R1,#40
orl R1,#30

zu einer Instruktion zusammengefasst. Das ganze ist regelbasiert und
kann beliebig erweitert werden.

Matthias

Autor: Gerhard Gunzelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Beisammen

ich meine daß man bei einem Hochsprachenprogramm unterscheiden muß in
die reinen Hochsprachenbefehle wie if, while, for und die Benutzung der
Bibliotheken. Bei ersteren kann der Compiler optimieren, bei der
Verwendung der Bibliothek nicht. Natürlich könnte der Compiler
optimieren wenn da steht
x = x + 20
x = x + 3

aber ich denke daß der Compiler-Hersteller (ganz oben) mit nicht
optimal meint, daß die Verwendung der Bibliothek unvermeidlich einen
Funktions-Overhead mit sich bringt, den der Compiler gar nicht
beeinflussen kann. Ich meine z.B. wenn ich rechen a = 5 + 7, so wird
hier die gleiche Funktion verwendet, als wen ich rechne a = 2300 +
4500. Ersteres könnte man mit einem einzigen Assemblerbefehl
erschlagen, das 2. Beispiel kann ein 8-Bitter nicht mehr mit einem
Befehl erschlagen und hier ist die Bibliothek auch für ausgelegt, also
für Integer, LONG Integer oder was noch schlimmer ist: float oder
double. Das ist nur ein Beispiel, das trifft für andere
Bibliotheksfunktionen - nicht nur für mathematische - zu.

Gerhard

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das bringt doch alles nix.
Wenn jemand z.B. für den gcc Verbesserungsmöglichkeiten sieht, dann
soll er das doch den Entwicklern mitteilen.
Dann haben alle was davon.

Mir sind noch keine offensichtliche Dummheiten (mit eingeschalteter
Optimierung) aufgefallen, aber ich hab auch keine Übung im Assembler.

Autor: Gerhard Gunzelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Fritz

ich habe schon einige Steuerungen mit uC gebaut (PIC), ich verwende
dabei immer Assembler. Mein Arbeitskollege hat sich vor kurzem mit nem
ST62 und C rumgeärgert. Soll heissen er mußte eine Änderung an einem
bestehenden Programm durchführen, aber nach der Änderung hat das Timing
einiger Funktionen nicht mehr gepasst. Da genau ist der eigentliche
Vorteil des Assemblers. Gerade wenn sich ein Compiler "anmaßt" zu
optimieren kann bei Steuerungen Mist rauskommen. Das ist was mir zum
Thema Optimieren einfällt. Für mich gilt: Wenns nur um Bit-Klemptnerei
geht nimm ich nur Assembler - da weiß ich genaus wann was passiert. Nur
wenn's Rechen-intensiev wird, kommt für mich ein C-Compiler in Frage.

Gerhard

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie schon erwähnt: Märchenstunde...

Und ich behaupte sowas nicht ienfach so, sondern ich bin auch in der
Lage das zu beweisen *g*:

int
main(void)
{
  int a = 23;
  int b = 0;
  int c = 0;

  return (c = a + b);
}

Wird von avr-gcc übersetzt mit (aus dem Listfile):

    ldi r24,lo8(23)
    ldi r25,hi8(23)

Gute Compiler können das also ;)

Autor: Stefan Helmert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein total schlecht machen die Compiler das nicht, aber es könnte besser
gehen. Genau so wie man ein Gleichung auflösen (vereinfachen) kann, so
müsste doch das auc mit dem Programmcode gehen z.B. wenn man ein float
verwendet anstelle des eigentlich auch geeigneten Bytes oder wenn ein
aufwendige Divisionsroutine in den Programmspeicher geschrieben und
dann ausgeführt wird auch wenn nur die ein Division x=x/2 im Programm
steht wofür nur ein rrf-Befehl nötig ist.

Autor: Gerhard Gunzelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo oldbug

das ist eben kein guter Compiler. Aber sowas erfordert auch Intelligenz
und das fehlt Computern und Software eben. Es gibt aber und dies
bereits schon länger, oprimierende Compiler. Borland C++ - Fans läßt
die Optimierfreudigkeit dieses Compilers oft die Haare zu Berge stehen.
So hat "optimiert" dieser Compiler:

for( i = 0; i < 10000; i++ );

zu nix.

Der erkennt, daß da keine Funktion in der for-Schleife steht, schmeißt
sie raus und futsch ist die "schöne" Verzögerung. Aber es gibt auch
so Superteile wie für den Intel-Risc-Prozessor I860. da optimiert der
Compiler sogar die Registerverwendung.

Gerhard

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nana, deklarier i volatile und die Schleife bleibt :-)

Unsinnige (und das ist diese Schleife für den Compiler nun mal, da sie
nichts macht, ausser Zeit zu verschwenden) Schleifen werden
wegoptimiert.

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
btw: würd mich wundern, wenn der avr-gcc die Registerverwendung nicht
optimieren würde...

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann mir mal jemand einen vollständigen C-Code aufschreiben, der
optimiert werden soll?

Bei meinen Kurz-Testprogramm optimiert er immer alles weg, bzw. rechnet
es schon zur compilierzeit aus :-(

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fritz: meiner ist doch vollständig...!?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

@Stefan
x=x/2; optimiert der gcc durchaus zu x>>=1;

Matthias

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@AlterKäfer:

Ich meinte einen Code, wo man mehr sieht. Bei mir macht er z.B. aus
int test(int x)
{
    return (x/2);
}

int
main(void)
{
  int a = 23;
  int b = 8;
  int c,i;

  c=test(b);

  for (i=0;i<a;i++)
    c=c+b+i;

  a=a+b;
  a=a/2;

  return (a);

}


diesen Code (sogar der Funktionsaufruf wird wegoptimiert):

   1:x.c           **** int test(int x)
   2:x.c           **** {
  42                 .LM1:
  43                 /* prologue: frame size=0 */
  44                 /* prologue end (size=0) */
   3:x.c           ****     return (x/2);
  46                 .LM2:
  47 0000 97FD          sbrc r25,7
  49                 .LM3:
  50 0002 0196          adiw r24,1
  51                 .L2:
   4:x.c           **** }
  53                 .LM4:
  54 0004 9595          asr r25
  55 0006 8795          ror r24
  56                 /* epilogue: frame size=0 */
  57 0008 0895          ret
  58                 /* epilogue end (size=1) */
  59                 /* function test size 6 (5) */
  61                 .Lscope0:
  64                 .global  main
  66                 main:
   5:x.c           ****
   6:x.c           **** int
   7:x.c           **** main(void)
   8:x.c           **** {
  68                 .LM5:
  69                 /* prologue: frame size=0 */
  70 000a C0E0          ldi r28,lo8(__stack - 0)
  71 000c D0E0          ldi r29,hi8(__stack - 0)
  72 000e DEBF          out _SP_H_,r29
  73 0010 CDBF          out _SP_L_,r28
  74                 /* prologue end (size=4) */
   9:x.c           ****   int a = 23;
  10:x.c           ****   int b = 8;
  11:x.c           ****   int c,i;
  12:x.c           ****
  13:x.c           ****   c=test(b);
  14:x.c           ****
  15:x.c           ****   for (i=0;i<a;i++)
  76                 .LM6:
  77 0012 80E0          ldi r24,lo8(0)
  78 0014 90E0          ldi r25,hi8(0)
  79                 .L8:
  81                 .LM7:
  82 0016 0196          adiw r24,1
  83 0018 8731          cpi r24,23
  84 001a 9105          cpc r25,__zero_reg__
  85 001c E4F3          brlt .L8
  16:x.c           ****     c=c+b+i;
  17:x.c           ****
  18:x.c           ****   a=a+b;
  19:x.c           ****   a=a/2;
  20:x.c           ****
  21:x.c           ****   return (a);
  22:x.c           ****
  23:x.c           **** }
  87                 .LM8:
  88 001e 8FE0          ldi r24,lo8(15)
  89 0020 90E0          ldi r25,hi8(15)
  90                 /* epilogue: frame size=0 */
  91 0022 00C0          rjmp exit
  92                 /* epilogue end (size=1) */
  93                 /* function main size 13 (8) */

Autor: Stefan Helmert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gibt es auch compiler, die die Verwendung von Interrupts, Timer und
andere Peripherie verändern? Und Unterprogramme völlig auseinander
reißen und nicht in Unterprogrammen stehende Teile in Unterprogramme
schreiben und entscheiden ob etwas im µC berechnet wird oder in der
Tabelle nachgeschaut wird?

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, sowas gibts, nennt sich "Programmierer" :-)

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Übersicht, was der gcc3.4 optimiert findet man auf:

http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/Optimi...

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gerhard:
> Hallo oldbug
>
> das ist eben kein guter Compiler

Warum denn nicht? Es wurde doch alles auf minimale Codegröße reduziert.
Und dass der Compiler eine sinnlose Schleife wegoptimiert ist doch nur
verständlich.

Optimierung auf Maschinencode-Ebene macht der GCC, nennt sich Peephole
Optimizer.

@Stefan Helmert:
> gibt es auch compiler, die die Verwendung von Interrupts, Timer und
> andere Peripherie verändern?

Mit Sicherheit nicht, ich bezweifle dass ein Programm hier bessere
Lösungen finden könnte als ein Mensch.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, und ich würde behaupten das es technisch möglich ist
Compiler-Maschinen zu bauen die immer besseren Code erzeugen als es der
Mensch je könnte. Es gibt dazu schon einige Ansätze die zB. mit Hilfe
von genetischen Algorithmen mathematische Formeln optimieren oder sogar
den Programmcode für hocheffiziente Formeln ermitteln. Deren Resultate
könnte ein Mensch in der Geschwindigkeit nicht erreichen. Die erzielten
Resultate finden meistens auch ein Optimum in einen enorm großen
Suchraum. Angenommen man hat einen Assemblercode mit 126 Bytes Code so
könnte eine sehr sehr schlechte Maschine alle möglichen Kombinationen
von gültigen Code durchprobieren. So ähnlich kann man sich die
genetischen Algortihmen vorstellen, nur eben das sie den maximalen
Suchraum enorm effizient und schnell durch Selektion begrenzen und
durchsuchen können. Ein gleichgelagertes Problem ist das Schachspiel.
Auch hier wurde lange Zeit behauptet das ein Computer niemals ein
Großmeister schlagen kann. Nun heutzutage behauptet man schon das ein
Großmeister die Schachprogramme in naher Zukunft nicht mehr schlagen
kann. Auch beim Schach geht es darum aus einem rießigen Suchraum den
Besten Zug zu finden. Übertragen auf einen Optimierer hiese das das man
aus einem Suchraum von gültigen Maschinencode den Code finden soll der
am effizientesten ist.

Es stellt sich nun nur noch die Frage ob es schon Forschungen in dieser
Richtung gibt, ob ein solches Verfahren effizienter als der Mensch ist
und ob man bei der heutigen "Resourceverschwendung" überhaupt so ein
Verfahren benötigt.

Durchschnittlich gesehen übertreffen heutige Compiler schon jeden
Mesnchen. Sie sind umgerechnet auf den Zeit-/Kosten-/Wissensaufwand
heute schon effizienter.

Gruß Hagen

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe ja schon immer gesagt, dass nur ein Zufallsgenerator der den
Hauptspeicher mit zufälligen Bytes füllt reicht um alle möglichen
Programme zu schreiben, sogar total bug-frei. Das Problem ist nur, die
nicht-funktionierenden Programme auszuselektieren :-)

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss Hagen insofern zustimmen, daß es wohl möglich ist, die
Optimierer noch ganz wesentlich zu verbessern! Allerdings wird sich
wohl niemand daran aufhalten, einen "Nachoptimierer" zu
programmieren. Der effektivste weg wird immer noch der vom Sourcecode
bis zum Binary sein!

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

@Fritz
Nicht nur das aussortieren ist das Problem. Wenn wir mal von 8 KByte
Speicher ausgehen (also eine angenehme Speichergröße die man zur Not
noch mit ASM füllen könnte) macht das 64KBit. Wir haben also 65536 Bits
die entweder '0' oder '1' sein können. Also haben wir 2^65536
mögliche Kombinationen. Diese Zahl hat 19729 Dezimalstellen. Das
würde ich als Problem bezeichenen :-)

Matthias

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias: korrekt, aber so unwahrscheinlich es klingen mag, die Natur,
sprich Evolution hat 22 Chromosomen mit Milliarden von Genen zu
optimieren und hat es in 1 Millionen Jahre geschafft günstige
Kombinationen zu finden die den Menschen ausmachen. Exakt das
"Herausfilteren" der potentesten = optimalen Kombinationen aus einem
schier unvorstellbar großen Suchraum = max. Kombinationen ist die
Stärke von genetischen Algorithmen und Evolutionsstrategieen. Sie
werden dann EIN mögliches Optimum als Lösung finden, diese Optimum muß
aber nicht zwangsläufig DAS Maximum darstellen. Viele Info's findet
man dafür beim sogenannten Problem des Handlungsreisenden
"Tavelsman/Salesman Problem".

Die genetischen Algos. zur Formelerzeugung mit denen ich experimentiert
habe enthielten in ihrem Genaufbau = Allelen die Regelwerke welche
Formeloperaoren, Konstanten und Variablen wie korrekt zusammenzubauen
sind. Dies ist 1 zu 1 übertragbar auf die Assembler-Befehle. Somit
würde man über das clevere Design der Gene die Kombinatonsvielfalt von
untauglichen Assemblerkombinationen von vornherein ausschließen. Das
einzigste was der Programmier bei solchen Verfahren eingeben muß ist
die Selektions-Funktion. Diese entscheidet zu welchem Progranm sich die
Zufallserzeugten Individuen entwickeln werden. Aber exakt die klare
Definition einer solchen Selektions-Funktion ist das schwierige
Problem.

Gruß Hagen

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.