Goto page Previous 1, 2, 3 ... 13, 14, 15
Michael Baeuerle
Guest
Thu Feb 25, 2010 11:13 am
Joerg Wunsch wrote:
Quote:
Michael Baeuerle schrieb:
Da springt einem doch regelrecht ins Auge:
1)
Warum pushed er __zero__?
Weil ihm noch keiner beigebracht hat, den tatsächlichen Inhalt der ISR
zu analysieren. Daher generiert er einen ziemlich starren Prolog.
Der Gerechtigkeit halber muss man aber auch sagen, dass eine ISR, die
nichtmal SREG zerschießt, schon nahezu ein pathologischer Fall ist,
Da moechte ich widersprechen. Ich hatte schon mehrere Projekte wo AVRs
fuer latenzkritische Zwecke benutzt wurden, d.h. wo jeder verschwendete
Takt weh tat und sowas inakzeptabel gewesen waere. Dass die kritischen
ISRs da was SREG-zerschiessendes rechnen mussten kam nicht vor, das war
nur I/O und teilweise wirklich nur ein, zwei Zeilen. Da war auch nicht
die Laufzeit einer ISR direkt, sondern die dadurch erzeugte zusaetzliche
Latenz fuer die anderen ISRs ein Problem (ISR x darf nicht mehr als y
Takte verzoegert werden wegen Jitter-Limit).
Aber OK, oft reicht fuer sowas dann eine ganz kleine CPU und man kann
auch gleich alles in Assembler machen und hat damit die volle Kontrolle
ueber die Timings. Man muss nicht alles mit Gewalt in C gemacht haben,
portabel ist solcher Code sowieso nicht.
Quote:
für die er derzeit unoptimalem Code liefert. 99 % der ISRs benötigen
das Retten des SREG ohnehin, und dann ist das Einsparpotenzial schon
mal deutlich geringer.
Ack. Ich hatte ja auch geschrieben, dass abseits solcher Sonderfaelle
der GCC sehr guten AVR-Code erzeugt.
Micha
Michael Baeuerle
Guest
Thu Feb 25, 2010 11:58 am
Stefan Engler wrote:
Quote:
Am 24.02.2010 14:54, schrieb Michael Baeuerle:
Allgemein erzeugt der GCC z.B. exzellenten AVR-Code, man muss also auch
noch wissen _wo_ sich das hinschauen lohnt.
Wenn der AVR dafür entwickelt wurde C-Code zu verarbeiten, ist dies auch
kein Wunder.
13 gegen 9 Takte ist nicht die Welt und ja die paar Takte mögen hier
verschwendet sein.
Was der GCC erzeugt hat braucht aber 28 Takte. Die alternativen
Loesungen mit 13, 11 und 9 Takten waren von mir.
Quote:
Aber wenn im Speicher (liniare Adressierung des AVR
inkl. aller Register und Ports) schon etwas ist und man dies nicht
entsorgen möchte, so mag auch mal der Mehraufwand gerechtfertig sein.
Die Hochoptimierte Lösung lässt sich dann nicht mehr erweitern, weil die
Ports schon als FiFo missbraucht werden.
Ja, natuerlich gibt es genug Faelle wo die paar Takte absolut egal sind.
Da mache ich auch "make all" und schaue den Assemblercode gar nicht an.
Quote:
Optimieren sollte man erst ab Schleifen, die mehrere tausend-Male
durchlaufen werden. Der Rest ist zumeist Zeitverschwendung, wenn kein
Timing eingehalten werden muss.
Timing ist aber abseits des PC genau das, was in der Realitaet oft
relevant ist: Man muss auf einen Interrupt mit minimaler Latenz und/oder
minimalem Jitter reagieren. Ich habe in einem Fall eine NOP-Sequenz
gestartet die dann vom Interrupt unterbrochen wurde. Das Jitter war
dadurch nur 50ns statt 100ns wenn der Interrupt stattdessen eine
Schleife unterbrochen haette (weil der Sprungbefehl der Schleife atomar
ist und 2 Takte benoetigt). 50ns Jitter bzw. Faktor 2 rausgeholt,
gekauft mit dem Flash-Verbrauch der NOPs (Flash war in diesem Fall im
Ueberfluss vorhanden) ... manchmal entscheidet ein einzelner Takt ob man
Zusatzhardware bauen muss oder es der MC per Software miterledigen kann.
Micha
Goto page Previous 1, 2, 3 ... 13, 14, 15
