-
Thread
Performance des GCC
diese wegoptimiert. Das volatile habe ich bei den späteren Tests wieder entfernt. Die wirkliche Optimierung kam aber (zumindest bei dem Windows MinGW GCC) erst mit der weiteren Übersetzungsoption -msse2. Der grundsätzliche fragwürdige "Benchmark" ist auch nicht auf meinem Mist gewachsen, siehe codeproject
vielleicht passend zur Thematik. ich habe in letzten Tagen auch mit GCC (version 4.5.3) herumexperementiert. Interessant sind die Vergleiche zwischen -O1 und -O2 und ohne Optimierung. Einmal mit konstantem Parameter, einmal mit einem laufzeitabhängigen Parameter. $
-
Thread
Wann Compiler-Optimierung in Embedded ausschalten
wobei es dann nicht Compilerzertifizierung an sich unnötig ist sondern nur die Zertifizierung der Optimierung. Und die Optimierung wäre ebenfalls unnötig. Wäre nicht das erste mal das Compiler feature enthalten die man eigentlich nicht will. Aber dann hätte man kein Verkaufsargument um sich vom gcc und
damit beschäftigt, daß das nicht stimmt. Interessanterweise gibt es offenbar gerade im Optimizer von gcc sogar einen Teil, der für die Optimierung einen Zufallsgenerator verwendet.
-
Thread
uint8_t auf int16_t erweitern
geht's auch ohne >> pgm_read_byte(). > > Kommt meiner dunklen Erinnerung nach darauf an welche GCC > Version man verwendet. Wird unterstützt ab GCC v4.7 (Release 2012). https://gcc.gnu.org/gcc-4.7/changes.html#avr Allerdings wird es nicht in C unterstützt sondern nur mit GNU-C; mit -std
Seltsam, dass es trotz des fehlerhaften Zugriffs überhaupt einigermaßen funktionierte. Wegen der gcc-Version: im MAP-File fand ich dies: gcc/avr/5.4.0 Gruß Wulf
-
Thread
Warum verwendet WinAVR nie swap/mul ?
schlechter optimiert worden ist. Es gibt eine gewisse Tendenz, dass bei AVR tatsächlich die Optimierung nachgelassen hat (was im Sinne von GCC durchaus als `regression' gilt und damit mehr Priorität beim Bugfixing geniest als feature fixes -- so man die Bugs denn auch berichtet), aber es gibt durchaus
habe ich in der Tat gesehen weil ich mir selbst mal die Mühe gemacht habe, ein ICCAVR-Projekt auf GCC zu portieren. Es handelte sich um eine GPS-Anwendung mit aufwendiger Menüsteuerung (grafisches Display). ICC erzeugte 61kByte Code mit Optimierung, der GCC machte daraus 79kByte mit Optimierung. Ich
-
Thread
Entprellen (kein AVR) Gesperrt
blt .L3 nop add sp, fp, #0 @ sp needed ldr fp, [sp], #4 bx lr .size optimierung, .-optimierung .ident "GCC: (15:6.3.1+svn253039-1build1) 6.3.1 20170620" 2) arm-none-eabi-gcc dummy.c -O1 -S optimierung: @ Function supports interworking. @ args = 0, pretend =
frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. bx lr .size optimierung, .-optimierung .ident "GCC: (15:6.3.1+svn253039-1build1) 6.3.1 20170620" W.S. schrieb im Beitrag #6218621: > Insofern ist der GCC eben kein anständiger Compiler Doch, der gcc ist ein
-
Thread
zugriff auf arrays optimieren
@Lars R.: Du solltest mal die Optimierung beim AVR GCC einschalten! Du wirst sehen, dass er dann viele deiner tollen "Handoptimierungen" von selber macht! Bei dem was du da schreibst, hast du entweder die Optimierung nicht an, oder beziehst
Hallo Klaus, > @Lars R.: > > Du solltest mal die Optimierung beim AVR GCC einschalten! [...] Ist diese Antwort ernst gemeint, soll ich nun lachen?!? Ich aktiviere grundsätzlich die Optimierungsstufe -Os beim avr-gcc. Ich habe auch extra noch angemerkt
-
Thread
avrgcc erzeugt sinnlosen code?
Der GCC mach noch andere unsinnige Sachen. Ein Port zugriff wird erst an einer höheren Optimierung zu einem Befehl. Vorher holt er das Port Register, macht die Operation und schreibt dann das Register
Beitrag #2592333: > Es ist halt nur schade das alle AVR Compiler es vernünftig umsetzen, nur > der GCC erst ab einer höheren Optimierung. Das hängt sehr stark von deiner Vorstellung von "vernünftig" ab. Wer unbedingt Code ohne Optimierung nutzen muß, dabei aber trotzdem auf "vernünftige" Optimierungen
-
Thread
Code optimieren und delay Funktionen beibehalten?!
falsche Ansatz so lange die Ursache noch unbekannt ist. Um deine Neugier zu stillen: Erst GCC ab Version 4.4 (also nicht für WinAVR2010... inklusive! Aber möglicherweise mit der Atmel AVR Toolchain) bietet ein #pragma zur Einstellung von Optimierungen auf Funktionsebene an (http://gcc.gnu.org
UND DANN optimierung für die delay-Funktion abschalten ;)
-
Thread
c++ 11/14/17?
pin; void write(bool level) { HAL_GPIO_WritePin(&gpio, pin, level); } [/c] Das erzeugt bei GCC mit Optimierung (inkl. LTO) optimalen Code, _wenn_ das Pin Objekt als const angelegt wird. Dies klappt auch, wenn das Objekt in andere Objekte via Konstruktor injiziert wird. Dummerweise failed der
noch keiner das Gegenteil beweisen. interessant schrieb im Beitrag #6543016: > Das erzeugt bei GCC mit Optimierung (inkl. LTO) optimalen Code, wenn > das Pin Objekt als const angelegt wird. Das ist jetzt aber nicht dein Ernst? Und dann HAL_xx Aufrufe? Noch schlimmer gehts nicht. Ich greife
-
Thread
[AVR] Seltsame Optimierung
91C0010A LDS R28,0x010A Load direct from data space [/pre] Wieso kann es sein, dass avr-gcc denkt, dass die Variable niemals einen Wert bekommt (ich meine, wieso sollte er sonst den Sprung zum nachfolgendem Code wegoptimieren?). Stell ich die Optimierung aus, läuft der Code, wie er sollte,
Dürfte ein volatile Problem sein. Der GCC ist da sehr rabiat im Wegoptimieren, wenn die globale Variable nicht volatile ist. Peter
-
Thread
GCC Compiler Optimierungen
Code im Anhang. Es wird die Variable dcc_daten[] in der ISR und in main verwendet. Sobald ich den GCC den Code optimieren lasse, ist der Inhalt von dcc_daten[] nur noch in der ISR selbst korrekt. In main lese ich nur noch "Müll" aus der Variablen. Was mache ich falsch? [c] #ifndef F_CPU #define
richtig C -konform deklariert, so das der Compiler mir da etwas wegoptimiert. Wie gesagt ohne Optimierung geht das so (mit 1300 Byte) mit Optimierung (egal welche) werden es dann ca. 800 Byte aber der Inhalt von dcc_daten[] ist nur noch in der ISR richtig.
-
Thread
C Code Optimierung für LCD (AVR32)
abgearbeitet werden kann: [avrasm] ldi r24, 0 sbic 0x09, 6 ldi r24, 1 ret [/avrasm] gcc 4.3.2 mach sowohl bei Optimierung auf Codegröße als auch bei Optimierung auf Geschwindigkeit (-O2 und -O3) daraus: [avrasm] foo: in r24,41-32 ldi r25,lo8(0) ldi r18,6 1: lsr r25 ror
Benutzerseite >Jeder der sich etwas mit AVR auskennt würde folgenden "optimalen" Code >hinschreiben: >gcc 4.3.2 mach sowohl bei Optimierung auf Codegröße als auch bei >Optimierung auf Geschwindigkeit (-O2 und -O3) daraus: >foo: > in r24,41-32 > ldi r25,lo8(0) > ldi r18,6 >1: lsr r25 > ror
-
Thread
Wie optimiert man Systematisch (AVR GCC)
Lord Ziu schrieb im Beitrag #1744091: > In dem du das hier durchgehst: > > [[AVR-GCC-Codeoptimierung]] Hat eigentlich schon mal wer kontrolliert, welche der Tips in diesem Artikel mit dem aktuellen GCC noch Gültigkeit haben. Ein paar dieser Optimierungen erscheinen da sehr zweifelhaft
Karl heinz Buchegger schrieb im Beitrag #1744122: >> [[AVR-GCC-Codeoptimierung]] > Hat eigentlich schon mal wer kontrolliert, welche der Tips in diesem > Artikel mit dem aktuellen GCC noch Gültigkeit haben. > > Ein paar dieser Optimierungen erscheinen da sehr
-
Thread
Unbekannte Warnung
Stefan schrieb im Beitrag #6625731: > Johannes S. schrieb: >> Die Warnung kommt ja weil die Optimierung "-fstrict-aliasing" gesetzt >> ist. [...] > > Danke! Ich hatte die Hoffnung schon aufgegeben... Hast du dir überhaupt angeguckt, was "-fstrict-aliasing" genau macht? In der gcc-Doku steht
wieso das, wenn ich fragen darf? Bei memcpy muss man doch erstmal davon ausgehen, dass es (ohne Optimierung) byteweise kopiert, bei der union nicht. Und es erscheint mir etwas lesbarer. Die union wird hier https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/Optimize-Options.html ja sogar als Positivbeispiel
-
Thread
Geteilt Rechnung vereinfachen in C
Optimizer nicht aktiv werden darf? Ansonsten kann man sehr bequem für Teile des Programms die Optimierung verbieten oder umschalten. #pragma GCC push_options #pragma GCC optimize ("O0") hier dein kritischer Code #pragma GCC pop_options
andere Konstante">>"noch eine andere Konstante". Das ganze nennt sich Barrett-Verfahren und wird vom GCC in der Tat vollautomatisch eingesetzt, sobald Optimierungen aktiv sind und es der Wertebereich erlaubt. Für deine Problematik, d.h. "Konstante"/"Variable" existiert meines Wissens nach kein derartiges
-
Thread
C++ auf AVR: new und virtuelle Methoden
Johann L. schrieb im Beitrag #3014835: > Mit den richtigen Optimierungen erzeugt avr-gcc für einen > ATmega32 folgendes: Karl Heinz Buchegger schrieb im Beitrag #3015015: > Das ist fies. Ist ja alles geinlined worden :-) Oha. Johann, welche Optimierungen waren
Roland H. schrieb im Beitrag #3015206: > Oha. Johann, welche Optimierungen waren denn das bitte? avr-gcc 4.8 mit -flto -O2, sollte aber auch mit 4.7 gehen.
-
Thread
Optimierung verstehen
Hallo, bin Anfänger auf dem Gebiet, also haut mich nicht gleich. Ich hab das Problem, dass GCC mir das weg optimiert: [c] U08 msg_new[msgSize]; U08 i; uint8_t address = msg[0]; for(i=0; i<msgSize; i++) { msg_new[i] = msg[i+1]; } [/c] Optimierung steht auf: -O0 Wenn ich
AVR Beginner schrieb im Beitrag #5326652: > Optimierung steht auf: -O0 > Wenn ich die Optimierung ausschalte geht es. Kaum zu glauben. Bist Du sicher mit dem O0? Auszug aus: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html -O0
-
Thread
Inline Funktion in Interrupt Routine
gcc-Option -lto beim Compilieren _und_ Linken angeben. Wichtig: Beim Linken auch noch die Optimierung einschalten, z.B. -Os. Dann hast Du zumindest eine Chance, dass die Funktion "geinlined
Michael Reinelt schrieb im Beitrag #3618108: > GCC does not inline any functions when not optimizing unless you specify > the ‘always_inline’ attribute for the function [...] Mit Optimierung sieht gcc ein inline ohne "always_inline" allerdings
-
Thread
Fühlt sich der gcc hier veralbert?
why-do-compilers-not-warn-about-out-of-bounds-static-array-indices > > "Enable optimization. Without at least -O2, GCC is not doing enough > analysis to know what a is, and that you ran off the edge." Das wäre jetzt auch mein Vorschlag gewesen, mal die Optimierungen einzuschalten. > WTF? -.- Wie meinst? Der
Rolf M. schrieb im Beitrag #8072654: > Das wäre jetzt auch mein Vorschlag gewesen, mal die Optimierungen > einzuschalten. Optimierungen sind eingeschaltet. [pre] $ grep "^:set make" ~/.vimrc :set makeprg=\(gcc\ -Wall\ -Wextra\ -pedantic\ -O3\ -std=c2x\ -save-temps\ -c\ %\ 2>&1\\\|tee\ errors
-
Thread
GCC-Option -mint8 vermeiden?
sizeof(int) gerechnet werden ist diese Variable nun 16 Bits breit. Der Rest folgt daraus. Diese Optimierung ist global, für alle Architekturen, und kümmert sich nicht um die Frage, ob eine Teilwortoperation möglicherweise billiger ist als eine Maschinenwortoperation. Für GCC hat das Maschinenwort auch
um eine 32-Bit Instruktion handelt. Diese Optimierung hat erst avr-gcc 4.7 (PR49939) Beispiel: [c] char c; void foo (char a, char b) { if (a) c = b; }[/c] compiliert mit avr-gcc -S -Os -mmcu=at90s8515 zu [code]foo:
-
Thread
Was benötigt weniger Takte If oder case?
Teil fehlt: der Binärbaum. Welcher Compiler (auf welcher Architektur) macht das tatsächlich ? GCC ? IAR ?
PS: Wie beim avr-gcc allgemein üblich kann es durchaus vorkommen, dass die Gewichtung etwas schief liegt. Weshalb es speziell im avr-gcc eine Möglichkeit gibt, table switches auszuschliessen (-mno-tablejump). PPS: Ich
-
Thread
AVR-GCC pointer post-increment
Markus F. schrieb im Beitrag #7459576: > in der Phase ist er mit seinen eigenen > Optimierungen längst durch Das ist so nicht richtig. GCC asm statements werden in der Optimierung mitbedacht. Aber natürlich nur soweit es die Schnittstellendefinition, Constraints und Clobbers erlauben.
https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
-
Thread
delay.h - Problem beim Debugging
dem ARM7 passende Stack-Frames zu errichten (FIQs, > wenn ich mich recht erinnere) - bei voller Optimierung. Den ARM-GCC kenne ich nicht, aber wenn dem so ist, sollte das wohl jemand reparieren... Für den AVR-GCC sind mir derzeit keine Bugs bekannt, die durch Einschalten der Optimierung eine Generierung
>Für den AVR-GCC sind mir derzeit keine Bugs bekannt, die durch Einschalten >der Optimierung eine Generierung falschen Codes bewirken würden Ich habe mich zu keinem Zeitpunkt auf den AVR-GCC beschränkt... ich meinte
-
Thread
C: Konstante weak definieren Gesperrt
Schau mal unter http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html Stichwort weak
. > In C++ ist sowas erlaubt wie const int n=11; int a[n];. In C geht das > nicht (selbst wenn gcc das erlauben sollte). Und was hat das jetzt mit Optimierung zu tun?
-
Thread
Riesige Änderungen zwischen WinAVR 030913 und der aktuellen Version? Gesperrt
selbe Kode unterschiedliche Ergebnisse bringt. 2006 läuft und 2007 bzw. 2008 läuft nichtmehr. Der GCC ist mit dem Makefile standardmäßig konfiguriert (MFILE). Die einzigen Änderungen der Konfig waren die Abschaltung der Optimierung, setzen der float für die printf, CPU-Geschwindigkeit und der Dateiname
Kontrolle. Das, was der gcc (oder irgend ein anderer C-Compiler) produziert, ist, egal, ob mit oder ohne Optimierung, selten das, was man von Hand programmiert hätte. Trotzdem funktioniert es. Oliver
-
Thread
static Funktionen und Flashverbrauch
Regsister mehr frei. Wenn du Pech hast, legt gcc Frames an (s.u.) und die "Optimierung" geht nach hinten los! *RAM-Zugriffe* Überfliege mal kurz dein List-File (aus dem .elf erstellt). Wenn du Nester von 4-Byte Zugriffen sieht, machst du was falsch. Zumindest bieten sich Möglichkeiten zu Optimierungen gegen Codegröße. (Implizites) Inlining kann da kontraproduktiv sein, weil gcc mehr Infos zu sehen bekommt, als gut ist. Sammle zusammengehörige Daten in Strukturen. Das macht die Quelle klarer
-
Thread
Verstehe GCC nicht
Compiler => komplexe Regeln. Wenn du einen einfach nachvollziehbaren Compiler willst, nimm nicht GCC, sondern z.B. SDCC. Am GCC wird seit 2 Jahrzehnten herumgefeilt mit Optimierungen aller Art. Mit Architekturen wie PowerPC, Itanium usw. im Auge, AVR ist da nur ein kleines Nebenprodukt.
ist, meine ich, absolut unverhersehbar beim GCC, und hat nichts mit "Optimierungen" zu tun. Gruß Hagen
-
Thread
Shift vs. Union - Was ist effizienter?
kaputtoptimiert. Mit konstanter Regelmäßigkeit folt auf "das ist kaputt in GCC" oder "Optimierung muß für dieses Modul und GCC deaktiviert werden" falscher, d.h. nicht standardkonformer Code. - Type Punning und und Strict Aliasing - Falsche Verwendung von float / double -
Interesse besteht, habe mal mit angehängtem Code und verschiedenen Compilern experimentiert: 1. ARM, gcc 4.8.3, -Ofast -mthumb -mcpu=cortex-m0plus Generiert sehr ähnlichen Code für alle drei Fälle, immer Shifts und bitwise ORs. Wenn man -Os als Optimierung verwendet, generiert der gcc erstaunlicherweise
-
Thread
avr-gcc: -fsplit-wide-types ja oder nein?
Neuere Versionen von avr-gcc kennen den Schalter [pre]-fsplit-wide-types[/pre] der bei angeschalteter Optimierung automatisch aktiviert wird. Durch [pre]-fno-split-wide-types[/pre] kann der entsprechende Optimierungs-Pass in gcc deaktiviert werden. Mit interessiert nun, welche Ergebnisse bei euch mit bzw. ohne diese Optimierung erzielt werden, und welche Verbesserungen mit/ohne diese Optimierung in "echten" Projekten beobachtet
-
Thread
Define für Optimierungsstufe?
Die sind aber schon lange im gcc. [pre] klaus@a64a:~ > gcc -Wall tst.c && ./a.out keine Optimierung klaus@a64a:~ > gcc -Wall -Os tst.c && ./a.out Optimierung nach Groesse klaus@a64a:~ > gcc -Wall -O1 tst.c && ./a.out Optimierung nach Geschwindigkeit klaus@a64a:~ > gcc -Wall -O2 tst.c && ./a.out Optimierung nach Geschwindigkeit klaus@a64a:~ > gcc -Wall -O3 tst.c && ./a.out Optimierung nach Geschwindigkeit klaus@a64a:~ > cat tst.c #include <stdlib.h> #include
-
Thread
effiziente Division durch 10
Marc P. schrieb im Beitrag #3512557: > In den gcc-Sourcen hab ich die Optimierung auch noch nicht gefunden... In gcc/expmed.c:expand_divmod() oder in Unterroutine davon wie choose_multiplier(). http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/expmed.c
Marc P. schrieb im Beitrag #3512557: > Und zu allem "Uberfluss ist diese Optimierung mindestens im gcc-4.8.1 > drin, wenn man f"ur einen ARM7 (UMULL, SMULL!) compiliert (-O2). Tja, mittlerweile bin ich desillusioniert. gcc-4.8.1 macht die Optimierung auf 32-bit Werten, aber
-
Thread
Wie baut man in C Strings zusammen?
erst einmal mathematisch > vereinfacht, bevor er Assembler-/Maschinencode daraus generiert. Im GCC kein voll ausgewachsenes CAS (wäre zu langsam), aber immerhin eine Beschreibungssprache die Vereinfachungen beschreibt: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/match.pd https://gcc.gnu.org
entsprechende Vorgaben machen können, >> was man gerne als Ergebnis hätte. > > Die Option -O existiert. GCC kennt mehr als 500 Optionen und Parameter (--param) alleine zum Tunen der Optimizer: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html Hinzu kommen die genannten Sammeloptionen wie -O0,
-
Thread
ISR Aussetzer durch Volatile-Variablen-Polling ?
Vielleicht könnten die infos in dem Link irgendwie nützlich eingesetzt werden: https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
unspecified-behaviour kann der Keil-Compiler natürlich > füllen. Es funktioniert auch mit dem arm-gcc.
-
Thread
AtmelStudio 7 util/delay.h funktioniert nicht
" from project "E:\Projekte\Testprojekt\atemga 328p\GccApplication3\GccApplication3\GccApplication3.cproj" (entry point): Done building target "Build" in project "GccApplication3.cproj". Done building project "GccApplication3.cproj". Build succeeded
Marco H. schrieb im Beitrag #6266105: > Und sie funktioniert nicht mit Optimierung ! Es ist anders herum. Sie funktioniert nicht ohne Optimierung.
-
Thread
STM32: Drama mit "Hard Fault Error"
und kann ihn einkreisen, so auch hier. Bloss wieso ... ewig Theater mit den Optimierungstsufen des GCC. Aber die schaffen locker mal 20% weniger Code. Wieso zur Hölle crashed dieser Code, wenn ich die Optimierung, die auf -OS steht zulasse? Ich traue mich bald keine Vars mehr ohne volatile zu definieren
Ja, vermutlich dass die Leute ungültigen C Code schreiben, der bei Verwendung von Compiler Optimierungen kaputt geht, was dann natürlich immer auf den Compiler geschoben wird. Ich bin schon auf diverse Fehler im GCC gestoßen, aber noch auf keinen einzigen, wo der Optimizer falschen Assembler Code
-
Thread
int8_t deklariert, int16_t bekommen? (AVR Studio 5)
künstlichem Schleifenzähler. Allerdings nehme ich an, dass nur Compiler der Komplexitätsklasse eines GCC überhaupt solche Optimierungen durchführen - es sei denn, die Zielmaschine hat besonders effiziente Schleifenbefehle, die dann genutzt werden können.
Reinhard R. schrieb im Beitrag #2398568: > Gibt es eine Erklärung dafür [...]? GCC-Schalter -f[no-]tree-loop-optimize Passt übrigens besser ins GCC-Forum das.
-
Thread
STM32Fxxx: Frage zur Initialisierung mit der StdPeriphLib
hilfreiche API's und Funktionen schreiben, welche aber von vernünftiger Optimierung abhängig sind. Die üblichen Unit/Integerations-Tests sollten eventuell scheiternde Optimierung in neuen Compiler-Versionen aufdecken. Nop schrieb im Beitrag #5356027: > Beim GCC verbietet sich
Nop schrieb im Beitrag #5356169: > Da kann man in aller Ruhe auch mit der eher > umständlichen GCC-Methode manuell arbeiten. Oder eben ganz manuell oder mit Stichproben-Tests, und sich über die hilfreiche Compiler-Optimierung freuen.
-
Thread
Bitte um Hilfe bei Code-Optimierung
daher muss ich noch viel der > Eigenheiten lernen. Die Großzahl der Optimierungsalgorithmen in GCC ist maschinenunabhängig, was Optimierung aber in Wirklichkeit fast nie ist. GCC zielt eben eher auf 32-Bit-Architekturen und versucht näher an die Konkurrenten wie Intel C-Compiler ranzukommen. Naja, und solche Optimierungen führen für AVR dann manchmal zu schlechterem Code als ältere Compiler-Versionen. Ein bisschen hatte ich auch im von Dir genannten Thema dazu geschrieben. Aber GCC lernt bestimmt noch dazu. Das
-
Thread
Bug in WinAVR oder wieso macht der Compiler so einen Müll ?
habe jetzt mal alles weggelassen, außer den beiden Funktionen, das Problem existiert weiterhin. GCC Version: avr-gcc (GCC) 3.4.5 WinAVR Version vom 25.01.2006
die meisten Programme > werden damit etwas kleiner. Sach ich doch. Im Durchschnitt ist die Optimierung beim AVR mit dieser Version besser als mit den 3.x-ern. Sicher findest du allemal pathologische Fälle, wo der 3.x-er GCC besseren Code erzeugt hat, aber in der realen Welt ist 4.1.x wirklich
-
Thread
for(;;){} Schleife
implementation-defined." Genau, Du benutzt etwas, was nicht dazu gehört. Insofern muss sich der GCC gar nicht darum kümmern und kann deswegen auch gar keine (Frontend)-Optimierungen ausführen. >> Was hat das mit main() zu tun? > > Dass main() in einem freestanding environment einfach gar nicht
sollte man? wird man normalerweise?) > -ffreestanding angeben. Würde ich nicht machen. Im avr-gcc gibt es zum Beispiel Optimierungen, die NICHT für freestanding gemacht werden. Und das betrifft dann ziemlich jedes Programm, weil es um main geht (das bei freestanding keine Sonderrolle hat).
-
Thread
Portzugriffe und Optimierung
Wie verhindere ich, dass der gcc (ich benutze noch den alten 3.4.3) Port-Zugriffe wegoptimiert. Das Code-Beispiel unten soll einen Clock an zwei Pins auf Port-A erzeugen. Allerdings optimiert der gcc die drei Zugriffe irgendwie weg
Optimierung -O0, einmal mit der Optimierung -Os. Man sieht, dass bei Optimierung -Os einige Pulse fehlen, insbesondere die RCK Pulse aber auch Clock Pulse. Im Grunde macht das Programm nichts anderes
-
Thread
Wie funktionniert ein Compiler?
Alternative überlegen, ob du nicht statt eines kompletten Compilers eher ein language frontend für den GCC schreiben willst. Dann profitierst du vom kompletten middleend und backend des GCC, d. h. musst dich nicht um Optimierung und Codegenerierung für die Zielmaschine kümmern. Für 'ne Scriptsprache
ab GCC 4.x auch SSA. TREE und SSA (static single assignment) dienen als Darstellungen, auf denen sich gut algebraische Transformationen ausführen lassen. Grundbedungung für jede Optimierung. RTL (register
-
Thread
Compiler Optimierungen - Was kann man erwarten?
Leider habe ich keinen asm Output und das manuelle Erzeugen ist mir zu mühsam im Moment. Ist der GCC cleer genug sehr kurze Funktionen als Inline zu realisieren? Und wenn ja, muss dazu die -os Speed Optimierung gewählt werden oder geht das auch mit der -o3? zb wenn die Funktion nur eine Zeile ist?
Christian J. schrieb im Beitrag #4098199: > Ist der GCC cleer genug sehr kurze Funktionen als Inline zu realisieren? Ja. > Und wenn ja, muss dazu die -os Speed Optimierung gewählt werden Nein.
-
Thread
GCC Startet nicht main() auf Mega168
schrieb: > Indem der Compiler davor schreibt: "epilogue start". Ich habe ja > den Vergleich mit dem GCC 4.2.2 gebracht, da steht auch beim > Epilog sauber drin "epilogue: naked". GCC 4.3.x schreibt das beim > Prolog auch so hin, aber beim Epilog verheddert er sich offenbar. In GCC 4.3 wurde die
Hallo! Bug ist aufgenommen http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240 Gruß Stefan
-
Thread
avr-gcc optimiert nicht?
war früher nicht da und ich möchte es auch in > Zukunft nicht da haben, was kann ich tun? Optimierung Abschalten. 8-Bit-Schleifenvariable verwenden. Grund: Der GCC hat deine Schleife umgedreht, statt >> for(i=0;i<WLC;i++) macht er >> for(i=WLC;i;--i) warum? 'i' kann er schön im Register-Paar
Macht steht und das ist unterm Strich schon nicht schlecht. An einigen Stellen wird er sogar Optimierungen finden an die hättest selbst Du nicht gedacht, an anderen Stellen hättest Du vielleicht von Hand noch 2 Takte rausgekitzelt oder ein paar Bytes gespart aber unterm Strich ist der gcc schon gar
-
Thread
avr-gcc: 3.4.6 contra 4.3.0
mehr gebraucht. Zweiteres braucht nicht nur mehr Code, sondern ist auch langsamer. Die Arbeit in GCC 4 ist beachtlich, sie dürfte zum Großteil das Middleend betreffen, also Implementierung von SSA und von auf SSA basierenden maschinen-unabhängigen Optimierungen. Genaugenommen sind Optimierungen
Schätze es könnte sich lohnen gcc/tree-ssa-ifcombine.c abschaltbar zu machen. Alles mögliche an Optimierungen kann man per Switches abschalten, aber den pass leider nicht.
-
Thread
Bitmanipulation, verschieben von Bits, optimierung
umsortieren sind: [c] uint8_t vermischt=__builtin_avr_insert_bits (0x04217563, abc, 0); [/c] http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/AVR-Built_002din-Functions.html
Anhänge mit folgendem Compiler: [code] leo@cb:~/src/avr/tmp$ avr-gcc -v Using built-in specs. COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.2/lto-wrapper Target: avr Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib -
-
Thread
if (uint16_t) --blink) == 0 Ok. if(--blink == 0 ) nicht ok?
avr-gcc-4.2.4 -O2 -mmcu=attiny13 --> gleich avr-gcc-4.2.4 -O2 -mmcu=atmega1280 --> gleich avr-gcc-4.2.4 -O3 -mmcu=attiny13 --> gleich avr-gcc-4.2.4 -O3 -mmcu=atmega1280 --> gleich
avr-gcc-4.3.6 -O1 -mmcu=attiny13 --> gleich avr-gcc-4.3.6 -O1 -mmcu=atmega1280 --> gleich avr-gcc-4.3.6 -O2 -mmcu=attiny13 --> gleich avr-gcc-4.3.6 -O2 -mmcu=atmega1280 --> gleich
-
Thread
c volatile -> wann bracht mans wirklich?
nur fuer integer und nicht fuer bitfields oder sonstige Variablen zulaessig ist. Grundsaetzlich zu GCC: Gcc does not implement a correct semantics for accesses to volatile struct members in non volatile objects. Dies ist bekannt und da gcc sowie g++ eine gemeinsame Codebase haben, wird sich daran auch
Funktionsverschachtelungen und die dynamische Datenstruktur sowieso nie eine Chance dahingehend Optimierungen durchzuführen, dann müsste es also auch ohne irgend ein volatile zuverlässig funktionieren. Deswegen ja auch die Frage hier. Chris schrieb im Beitrag #7300286: > Grundsaetzlich zu GCC: > Gcc
-
Thread
Negative Ganzzahlen von 32bit in 16bit konvertieren
erzählen vom Krieg. >kann! Low-Level Optimierungen überlass ich dem Compiler. Jain. Man muss wie immer wissen was man tut und ob es sich lohnt. [[AVR-GCC-Codeoptimierung]]
dabei ist, daß auf Größe optimiert wird, aber Code erwartet wird, wie er bei Geschwindigkeits-Optimierung erzeugt wird. Erst ab avr-gcc 4.7 verhält sich der Compiler nicht ganz wie erwartet, d.h. bei Optimierung auf Größe mittels -Os erzeugt er Code, der mehrere Instruktionen größer sein kann als