-
Thread
winavr-c-2006 hat es geschafft.
neuen Version von WinAVR wurde der erzeugte Code größer, > das Programm also langsamer, und die Optimierungen schlechter. Für genau ein Exemplar von ,Programm', oder? Nicht, dass ich den GCC für den Stein der Weisen hielte. IAR zum Bleistift bringt es in einemßen Projekt, an dem ich gerade arbeite
Teil des Codes eher Mittelmaß: beide diese Optimierungen sind so gut, wie GCC mit -Os. Wenn ich beim GCC -O3 ansetze, wird der Code zwar nochmal 10 % größer, aber dieser Teil auch weitere 10 % schneller. Im Übrigen wurde das Projekt mit dem GCC
-
Thread
ARM-GCC: stderr
Hallo Klaus, beim AVR-GCC habe ich das im Griff. Die Frage bezieht sich auf dem ARM-GCC. Viele Grüße W.T.
die in einer Schleife Byte für Byte kopiert. Siehe die Liste der built-in-Funktionen hier: http://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Other-Builtins.html#Other-Builtins
-
Thread
AVR unter Windows in C, welche Toolchain?
ich gesehen das es neuere AVR Tollchain-Versionen gibt. 1) http://gnutoolchains.com/avr/ avr-gcc5.3.0.exe 2) http://blog.zakkemble.co.uk/avr-gcc-builds/ avr-gcc-7.3.0-x64-mingw.zip (51.22 MB) Ist es sinnvoll eine neuere Version zu installieren? Was ist verbessert worden? Ist der generierte
nur dann Sinn, wenn sie gleichzeitig beim Compiler und Linker angegeben wird. Der Umstieg von avr-gcc 4.3.3 auf avr-gcc 4.7.2 bringt also in diesem Beispiel 28% kleineren Code! Es verhält sich so, wie Frank es beschrieben hat. Danke nochmals für die Infos. Gruss, Jan
-
Thread
GCC: Arg unzulängliche Optimierungen?
ist doch recht schlimm. > nur mal wieder ein Beispiel für die die vielen arg unzulänglichen > Optimierungen. da braucht man doch eigentlich kein fortgeschrittene KI? avr-gcc ist ein Open-Source Compiler, du kannst mithelfen ihn zu verbessern. Wenn solche Änderungen trivial für sich sind, mach eben
anstatt nur rumzumotzen ;-) Die Funktion horcht auf den Namen lshrsi3_out und findet sich in http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr.c?content-type=text%2Fplain&view=co happy hacking
-
Thread
avr-gcc - unnützer Assembler-code?
Programmieranfänger mit reinem Assembler oft nicht so kompakt hinbekommen hätte. Nimm bitte die neueste GCC-Version dafür, Johann hat da noch einiges an Mikro-Optimierungen im AVR-Bereich nachgezogen in letzter Zeit.
nicht alles bis zur Trivialität weggestrichen wird. > Nimm bitte die neueste GCC-Version dafür, Johann hat da noch einiges > an Mikro-Optimierungen im AVR-Bereich nachgezogen in letzter Zeit. Sowie ich das verstehe, geht es darum, dem Compiler bei der Arbeit zuzuschauen und
-
Thread
Was bewirkt in C folgender Befehl
>> Warum sollte das Quatsch sein? gcc tut das, und das ist gut > if(CompilerOptimierung == 0) > { > KonstruktInMaschinenCodeUebernehmenAberUeberspringen(); > } > else > { > KonstruktEntfernen(); > } Wobei das Ausschalten
Gleitkommaberechnungen) gemessen und kein Mensch schaltet Optimierungen aus. Warum sollte man sonst so viel Kohle für z.b. IAR EWB ausgeben wenn gcc ohne Optimierungen auch alles "richtig" übersetzt.
-
Thread
Optimierung von Rechnungen und If Schleife
Und dass wir hier im GCC-Forum sind :-) (ack)
> Könnte mir jemand diese GCC Erweiterung erklären, da ich nur Standard > c(++) behersche. Das GCC-Handbuch kann das. > Prüft der Switch ob sich Werte dazwischen befinden? Nicht dazwischen, aber ob sie sich in dem angegebenen
-
Thread
Feedback zum Artikel "Plattformunabhängige Programmierung in C"
" brauchte. Heute sind solche Aktionen bei hochoptimierenden Compilern Alltag. Manche Probleme mit GCC rühren daher, dass die Optimierung dieses Compilers aus dem Highend-Sektor stammt und er daher aggressiver und mit anderem Ziel vorgeht, als Compiler, die nur den Mikrocontroller-Markt adressieren.
durch die > entsprechende Konstante ersetzt wird. Jo, stimmt. Sind ja beide Parameter bekannt. GCC 4.8 faltet das sogar ohne Optimierung...
-
Thread
C++ mit AVR-Dude
die Optimierung ist in beiden Fällen im Makefile auf s. Und natürlich will ich Optimierung. Oder muss ich die Optimierung noch irgendwo anders "anschalten"/auswählen ???
fuchs[3] = 77; if (fuchs[3] == 5) { fuchs[3] = 5; } return 0; } ^D $ avr-gcc -Os -xc -mmcu=atmega1281 -o foo.elf foo.c $ avr-size foo.elf text data bss dec hex filename 264 0 0 264 108 foo.elf $ avr-gcc -Os -xc++ -mmcu=atmega1281
-
Thread
Copy Constructor Riddle
GCC compiliert es problemlos, und die Ausgabe ist: This space has been intentionally left blank: ->1<-
Ausgabe an cout, die sich durch die Optimierung ja tatsächlich nicht verändert.
-
Thread
Hardware-Multiplier auf Mega32 ungenutzt?
mulhi3 ; 9 *mulhi3_call [length = 1] ret ; 30 return [length = 1] [/avrasm] Für Optimierung auf Größe dürfte das unschlagbar sein (wenn man mehr als ein Aufruf von __mulhi3 im Code hat. Aber das kann gcc nicht global wissen, da er immer nur modulweise sieht) -- bis auf die Tatsache, daß in avr-gcc noch keine Tail-Calls drine sind (rcall+ret = rjmp) Die Optimierung nach Speed sieht auch verdächtig flott aus (12 Ticks), da dürfte ne "normale" Multiplikation kaum mitkommen... Johann p.s
-
Thread
C-Funktion von Assembler aus Aufrufen: Prologue?
Gegenteil, das ist ganz und garnicht einfach zu optimieren. Daß klar ist, was das Resultat der Optimierung sein soll, haißt noch lange nicht, daß es einfach zu implementieren ist. I.W. bedeutet es, fast das ganze avr-Backend des GCC neu zu schreiben. Ich selbst bin nie an diese Optimierung (PR20296
Weg vorbei. Ohnehin wird das 0-Register bei größeren Funktionen fast immer gebraucht, d.h. die Optimierung würde nur bei Mini-Funktionen was bringen. Aber es steht jedem frei, das anders zu sehen und in medias res zu gehen, d.h. in die GCC-Quellen und ein Patch zu erarbeiten :-) Pfiffige Entwickler
-
Thread
STM32F767 GPIO Geschwindigkeit hängt an Debug/Release
Der arm-gcc hat dazu die Kompromiss-Option: -Og Damit optimiert er so viel wie möglich, ohne den Debugger lahm zu legen.
passend zum Cortex-M / STM32 und GCC: http://blog.atollic.com/optimizing-code-size-with-the-gnu-gcc-compiler-for-stm32-and-other-arm-cortex-m-targets
-
Thread
GCC Optimierer macht Code funktionsuntüchtig
wird > wenn die erste true ist. So weit stimmts. > Das ganze passiert nur bei aktivierter Optimierung, > da der Compiler erst dann das lazy and nutzt. Das stimmt nicht. && ist immer lazy, auch ohne Optimierung.
tuppes schrieb: >> Das ganze passiert nur bei aktivierter Optimierung, >> da der Compiler erst dann das lazy and nutzt. > > Das stimmt nicht. && ist immer lazy, auch ohne Optimierung. Ich hab gcc schon Code erzeugen gesehen, wo er die zweite Bedinung auswertete
-
Thread
Compile Error AVR MAc
Steve van de Grens schrieb im Beitrag #7549177: > Das wüsste ich auch gerne. Mit dem avr-gcc 12.1.0 bekomme ich die > gleiche Fehlermeldung, mit dem avr-gcc 5.4.0 (den ich normalerweise > benutze) jedoch nicht, der kann das Projekt compilieren. GCC 12 verhält sich standardkonform hinsichtlich inline (und das tatsächliche Verhalten hängt auch noch von der [hier fehlenden] Optimierung ab). Bei GCC 5 gab es sowas noch nicht im Standard, daher war das Verhalten anders. Die korrekte Auflösung wurde bereits in der ersten Antwort im Thread genannt: deklariere die Funktion nicht
-
Thread
C30-Compiler von Microchip
C30-Compiler kenne ich nicht. Ihr verwechselt das jetzt nicht mit dem PIC32-Compiler? Das ist ein GCC für den MIPS mit Microchip-Optimierungen. Ich hab gerade nochwas zum C18 gefunden... printf kann z.B. kein float. Okay, muss auch nicht sein, kann man auch eine selbtsgeschriebene Funktion zur
> Ihr verwechselt das jetzt nicht mit dem PIC32-Compiler? Definitiv nicht. > Das ist ein GCC für den MIPS mit Microchip-Optimierungen. Der C30 auch. Nicht jedoch der C18. > printf kann z.B. kein float. Das wiederum interessiert den Compiler selbst rein garnicht, sondern ist Bestandteil
-
Thread
Aufbau von Structs im Speicher
problematisch, wenn es ein pointer typ ungleich des struct pointers ist, also z.B. char*. Bei Optimierung höher O1 wird gcc keinen funktionierenden code mehr produzieren (Stichworte: pointer aliasing, strict aliasing rules). nötig ist das aber manchmal, beispielsweise um netzwerk-packete oder genauer
undefiniertem > Verhalten. Mist! Danke für die Verbesserung! Aber immerhin läuft diese Methode mit Optimierung >O1, also mit -fstrict-aliasing: Aus "using gcc": [code]The practice of reading from a different union member than the one most recently written to (called “type-punning”) is common. Even with
-
Thread
Compiler optimizations disabled
Martin W. schrieb im Beitrag #3370773: > Die Compiler optimierung steht im Makefile auf s, also laut diversen > anderen Foren sollte die Optimierung eingeschaltet sein.. also hast du im Makefile "-Os"?
Hat keine sonst eine Idee? Wie stelle ich die Optimierung in der IDE ein?
-
Thread
User Sections GCC
das bisher soweit, aber letztens musste ich weil ich keinen Platz mehr im Bootloader hatte, die Optimierung einschalten. Also Wechsel von -O0 auf -O1 das war alles. Jetzt habe ich das Problem, dass dieser Shared- Memory nicht mehr so funktioniert wie er ohne Optimierung funktioniert. Umsetzung:
tutgccadding-crc-and-app-length-hex-files http://mcuoneclipse.com/2012/11/01/defining-variables-at-absolute-addresses-with-gcc/ sg
-
Thread
8bit Pointer bei großen AVR's
sein. Aus dieser 'Muss' Klausel folgt unmittelbar, dass Optimierungen keine C Regeln ausser Kraft setzen können. Insbesonders können Optimierungen kein illegales Programm plötzlich legal machen. > > Aber ich kann mich täuschen, und jeder Compiler mag es anders
#3963559: > Der Compiler darf nach Lust und Laune optimieren, aber immer nur 'as if' > die Optimierung nicht statt gefunden hätte. D.h. das Endergebnis muss > dasselbe sein. Aus dieser 'Muss' Klausel folgt unmittelbar, dass > Optimierungen keine C Regeln ausser Kraft setzen können. Insbesonders
-
Thread
Optimierung zeitweise ausschalten?
Hi ist es möglich im GCC die Optimierung für ein bestimmtes Statement auszuschalten? Beim Optimieren wird hier ein Zugriff auf eine volatile-Variable wegoptimiert was aber an dieser Stelle nicht passieren darf und einen Fehler
GCC aus dem CVS? Wenn ja, CVS Head oder `stable' branch? Habe eben in der avr-gcc Liste gelesen, daß Denis Chertykov irgendeinen Patch nur für den Head (gcc-3.4.x) genehmigt bekommen hat, nicht aber
-
Thread
Präprozessor und Macros
die Compiler nicht immer wissen, wie es die Arithmetik auszuführen hat. Um das zu kennzeichnen kennt gcc den Schalter -frounding-math (oder so). Optimierungen wie double a=sin(2.0) sind eine Sache, die gcc inzwischen am lernen ist bzw. gelernt hat. Das Problem ist hier, daß man nicht die float-Einheit
nach Architektur günstiger ist, weil kein Sprung benötigt wird. Analoge Fälle gibt es für &&, und gcc führt solche Optimierungen auch aus. If Fällen wie [c] if (a && *a) [/c] geht das natürlich nicht.
-
Thread
Attiny 2313A - ROM am Limit? Probleme mit Optimierer
mit doppelter Belegung des Speichers zu tun hat. Leider bemerkte ich dann auch, dass schon Optimierung "-Os" aktiviert war. AVR-GCC meldet auch ca. 98% ROM-Auslastung. Ich habe versucht mit "-O1" zu kompilieren, was jedoch mit Fehler abbricht ("Program memory 114% Full"). Ich habe schon alle
lokale. Denn 8-Bit relativ zu SP ist einen Takt langsamer ('08). Für die 12er gibts übrigens eine GCC Implementierung. Wobei GCC für Akku-Architekturen alles andere als ideal ist. Darin finden sich einige Pseudo-Register im RAM. GCC wird vorgegaukelt, als hätte der einige Register. Auch in einer Version
-
Thread
Frequenzmessung und Optimierung -Os
programmiert um später evtl. auch ein LC-Meter zu bauen. Ich programmiere grundsätzlich immer mit der Optimierung -O0. Das Programm funktioniert damit auch schon sehr gut. Nun habe ich mal die Optimierung auf -Os umgestellt, da ich ja die delay.h verwende und in der Hilfe zu der lib steht, dass man unbedingt
rechnet der µC ja nur in > unsigned int. Kann es da zu Überläufen kommen? Das würde aber auch ohne Optimierung passieren...
-
Thread
Unnütze Registersicherungen in ISR
https://gcc.gnu.org/PR20296
...und Änderungen gibt es durchaus. Die letzte Änderung im GCC ist 3 Tage her und war auch nicht ganz winzig (PR81072): http://gcc.gnu.org/r249124 http://gcc.gnu.org/PR81075 ist im Review, vor 3 Wochen: http://gcc.gnu.org/r248332 In Binutils kamen in den
-
Thread
-Os liefert schlechtes Ergebnis Gesperrt
Verlangsamung gegenüber der direkten Berechnung ohne Funktionsaufruf. Das Verhalten zeigte sich mit dem AVR GCC 7.4. und 9.2 identisch. Dieses Beispiel soll zeigen, dass die Optimierung durchaus nennenswert dazwischen grätschen kann. Evtl. hilft das ja irgendwem irgendwann einmal weiter ;) P.S.: Die Abfrage
Im GCC kann man Optimierung auch im Quellcode sektionsweise steuern.
-
Thread
GCC - seltsames Verhalten bei for-Schleife
Wenn du statt der Verbreitung von FUD zu fröhnen lieber aktiv mithelfen willst, dass ungünstige Optimierungen repariert werden, dann schreib bitte für alles, was du findest, ordentliche Bugreports (in GCCs Bugzilla, nicht einfach irgendwo in ein Forum) und diskutiere das dann mit den GCC-Entwicklern
OK. Passt. Gibts denn beim GCC nicht die Möglichkeit, die Optimierung für einzelne Codesegmente unterschiedlich einzustellen? So a la #pragma O1 ?
-
Thread
gezielte Optimierung einzelner Funktionen mit gcc?
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas
848: b9 cf rjmp .-142 ; 0x7bc <__vector_11+0xb2> } [/avrasm] das mit avr-gcc 4.3.3 Keine Ahnung warum der gcc bei -O3 einen Code dermaßen zerrupft - super unschön. Zumal mit schlechter lesbarer Nachhilfe die Optimierung viel besser ist: -O3 / Os [avrasm] act_pos_buf
-
Thread
Funktionen aufrufen aber wie?
man doch die <time.h> einbinden oder? Gibt aber nur Fehlermeldungen. Wie schalte ich den die Optimierung aus. Ich verwende AVR Studio mit der GCC Applikation. mfg N.O.
geht ganz speziell um _delay_ms(), nicht irgend ein anderes delay... > Wie schalte ich den die Optimierung aus. > Ich verwende AVR Studio mit der GCC Applikation. Project -> Configuration Options -> General -> Optimization Default ist -Os = Optimierung auf Codegröße Du brauchst für deinen Code -O0
-
Thread
Switch Case compiler übersetzung in asm. fehlerhaft
schrieb im Beitrag #2699346: > -mshort-calls Davon rate ich ab. Das Problem ist da: http://gcc.gnu.org/viewcvs/branches/gcc-4_7-branch/gcc/config/avr/avr.c?view=markup&pathrev=187343#l9455
Johann L. schrieb im Beitrag #2699366: > Davon rate ich ab. Das Problem ist da: > http://gcc.gnu.org/viewcvs/branches/gcc-4_7-branch/gcc/config/avr/avr.c?view=markup&pathrev=187343#l9455 Das musst du mir erklären, ich sehe da nur viiiiiel Code...
-
Thread
AVR-Studio - Code Größe anzeigen
Kompilat zu quetschen. Sonst noch irgendwelche guten Ratschläge (außer die, die im Artikel Code-Optimierung bzw. im AVR-Datenblatt stehen), wo man nochmal nach ein wenig Speicher auf die Suche gehen kann? Was verbraucht i.d.R. viel Flash-Speicher, was nicht? Und ja, die Optimierung steht auf -Os!
aufzwirbeln, der sofort verschwindet, wenn man bemerkt, dass es ein uint8_t auch getan hätte. Der GCC hat zwar manchmal so seine Schwierigkeiten, aus der von C geforderten int-Rechnerei auf uint8_t abzuspecken, aber generell macht er einen guten Job, wenn es um Optimierung geht. D.h. das Hauptaugenmerk
-
Thread
Codeoptimierung vom Compiler
Ich wuerde dir gcc.godbolt empfehlen, und mir mal den assembler output vom gcc, clang und msvc anschauen
Man sollte wissen, dass der gcc nur dann halbwegs optimierten code erzeugt, wenn man auch zumindest -O oder -Os anwählt.
-
Thread
Variableninitialisierung beim GCC debug versus release Modus
sicherheitsrelevanten Informationen anderer Prozesse darin vorhanden sind. Da bei abgeschalteter Optimierung (-O0) prinzipiell /alle/ Variablem im Stackframe angelegt werden, bleibt natürlich ein großer Teil des Stacks dann auf diesen Nullen sitzen. GCC unterscheidet übrigens nicht zwischen "debug
Jörg Wunsch schrieb im Beitrag #2578915: > GCC unterscheidet übrigens nicht zwischen "debug mode" und "release > mode". Optimierung und Anlegen von Debuginformationen sind völlig > voneinander unabhängig; auch bei aggressivser Optimierung (-O2
-
Thread
Unterschied in Codegröße zwischen CodeVision und WinAVR
Was die Optimierung von in Speicher plazierten Variablen sehr effektiv aushebeln kann ist, ist die Gefahr von Aliasing. Vielleicht ist etwas gewonnen, wenn du GCC davon überzeugen kann, dass diesbezüglich von pu8Bytezeiger
Steffen Graap wrote: > In CV brauchte ich dies nicht machen. Mag sein, aber GCC ist nicht für Microcontroller optimiert, sondern für High-End Maschinen in denen zeilen/blockübergreifende Optimierung wichtig ist. Und es ist auch nicht GCC oder Jörg, der "volatile" fordert, sondern
-
Thread
C versus Assembler->Performance Gesperrt
noch lange nicht gesagt. Du kämpfst gegen Windmühlen. https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
Kannste beim GCC auch, ist aber nicht portabel: https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html
-
Thread
WinAVR Compiler-Optimierung
Optimierungsstufe -O3. Wie kann das sein? Gibt es eigentlich bald mal ein Update vom WinAVR? Ist AVR-GCC unter Linux besser?
. Die gleicher Version vom GCC liefert unter windows genau das gleiche Ergbniss wie unter linux.
-
Thread
Assembler wieder auf dem Weg nach vorn Gesperrt
manchmal Fehler machen (sehr selten) die im Quellcode nicht zu erkennen sind. Gerade die 'optimierungen' mancher Compiler können einem echt die Karten legen. Z.B. beim Xmega den Takt umschalten geht in GCC je nach Optimierungsstufe mal und mal nicht. Grund ist das zwischen dem freischalten und
Ab einer gewissen Größe. Beim einen 10K, beim anderen 1K, beim dritten Null. > Gerade die 'optimierungen' mancher Compiler können einem echt die Karten > legen. > Z.B. beim Xmega den Takt umschalten geht in GCC je nach > Optimierungsstufe mal und mal nicht. Grund ist das zwischen dem > freischalten
-
Thread
Frage bezüglich Optimierung
> dein erster Fall dürfte eine fehlende Optimierung des GCC sein die eben > nur zuschlägt wenn du zwei Bits setzt. Die Optimierung kann er möglicherweise schon, aber PORTB ist volatile. Das heißt, das bei PORTB |= _BV(1) | BV(2); das Register
Rolf Magnus wrote: >> dein erster Fall dürfte eine fehlende Optimierung des GCC sein die eben >> nur zuschlägt wenn du zwei Bits setzt. > > Die Optimierung kann er möglicherweise schon, aber PORTB ist volatile. > Das heißt, das bei > > PORTB |= _BV(1) | BV(2
-
Thread
Unbenutzten Code durch GCC entfernen lassen
Liebe GCC-Spezialisten, ich erstelle ein Programm in C mit GCC und möchte jetzt gerne den unbenutzten Code durch den GCC rauschmeißen lassen. Dazu nehme ich nach WEB-Anleitung den Compilerswitch CFLAGS
>ich erstelle ein Programm in C mit GCC und möchte jetzt gerne den >unbenutzten Code durch den GCC rauschmeißen lassen. Unbenutzten Code schmeißt man nicht rau, man schreibt ihn erst gar nicht erst rein. :)
-
Thread
Korrupte Daten und Volatile
siehe oben. optimierung ausschalten löst auch das problem. was mach ich denn nun? ist der avr-gcc denn bekannt dafür dass er nicht so gut mit optimierungen umgehen kann?
>siehe oben. optimierung ausschalten löst auch das problem. >was mach ich denn nun? ist der avr-gcc denn bekannt dafür dass er nicht >so gut mit optimierungen umgehen kann? Welche Version hast du? Gibt da gerade
-
Thread
ARM DSP LIB Speicherverbrauch
Die FPU ist aktiviert, dafür spricht auch die Performance. Die Optimierung ist über die Projektoptinen eingeschaltet, im Konsolenfenster ist zu sehen, dass u.a. "-s" an den gcc übergeben wird, damit werden ca. 2kB eingespart, nicht viel gemessen an der Gesamtgröße. Standardeinstellung
/articles/ARM_GCC
-
Thread
SDCC 4.0.0 release candidate 1
Alternative. Beim MCS51-Port sehe ich es genau so: Der Keil-C51 ist wunderbar. Allein dessen Optimierung mit mehreren Durchläufen ist schon den Kaufpreis wert. Schade, dass weder der XC8 für die PIC noch der avr-gcc nur annähernd mithalten können.
Alternative. > > Beim MCS51-Port sehe ich es genau so: Der Keil-C51 ist wunderbar. Allein > dessen Optimierung mit mehreren Durchläufen ist schon den Kaufpreis > wert. Schade, dass weder der XC8 für die PIC noch der avr-gcc nur > annähernd mithalten können. Weder XC8 noch Keil-C51 sind frei. Aber
-
Thread
Projekt: Pascal-Compiler für AVR Gesperrt
http://de.wikipedia.org/wiki/GNU_Pascal Es gibt doch ein Pascal Frontend für den GCC. Weiß da jemand, ob das mit dem avr-gcc funktioniert?
Dass diese Problem bei ziemlich alten Compilern nicht auftritt, liegt an der dort fehlenden Optimierung.
-
Thread
Strukturierte Programmierung: Anti-Switch-Case
-O1 ist halt minimale Optimierung. Bei -O2 macht er es. Außerdem ist gcc 5.4 schon recht alt.
verstehe den Begriff der > "hosted-Umgebung" in diesem Zusammenhang nicht. Schau' mal hier: https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html (-ffreestanding bzw. -fno-hosted).
-
Thread
AVR-GCC: Funktionspointer in ISR
größer, daß der Compiler erkennt, wie der Code des Callie denn genau lautet. Warum die o.g. Optimierung von GCC nicht durchgeführt wird — da müsst ihr die GCC-Entwickler fragen. Wahrscheinlich wie bei so vielen anderen Dingen auch: Es ist nicht implementiert, weil es bislang niemandem wichtig genug
Johann L. schrieb im Beitrag #3337659: > Warum die o.g. Optimierung von GCC nicht durchgeführt wird — da müsst > ihr die GCC-Entwickler fragen. Ich könnte mir vorstellen, dass der GCC bei einer externen Funktion grundsätzlich erstmal davon ausgeht, dass diese
-
Thread
Wieviele Taktzyklen benötigt ein Befehl in C
Hoffnung halt nicht aufgegeben ;) Gibt es nicht einmal eine Auflistung von der Umwandlung im AVR-GCC ohne Optimierung? Soetwas würde mir ja auch schon weiterhelfen...
nosico wrote: > Gibt es nicht einmal eine Auflistung von der Umwandlung im AVR-GCC ohne > Optimierung? Soetwas würde mir ja auch schon weiterhelfen... Wobei würde dir das weiterhelfen? In den meisten Fällen ist die Notwendigkeit der Kentniss der Taktzyklen in Indiz dafür, dass
-
Thread
delay Funktion
vorhandenen? Die sind getestet und funktionieren. https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 >Ich hab das gefühl, dass die Funktion gar nicht angesprungen wird, hat >das vielleicht irgendwas mit der Optimierung zu tun Richtig. Der Optimizer schmeißt
Optimierung ausschalten -O0 (OH NULL) Trotz dem nimm die fertigen Funktionen. Da ist das Zeitverhalten sicher, vor allem wenn du Optimierung eingeschaltet lässt. Hopix
-
Thread
Wie Umwandlung von Integer -> 2xByte beschleunigen?
Danke für Euer Feedback. Ich wusste nicht, dass der GCC Compiler das optimiert. Ich probiere das mal im Vergleich zu der union-Variante aus. Führt er diese erwähnte Optimierung in allen Optimierungsstufen durch, oder erst in höheren? Danke oli
Optimierung in allen Optimierungsstufen durch, > oder erst in höheren? Naja, mit -O0 natürlich nicht. ;-) Aber ab -O1 schon. Für den AVR-GCC ist in der Praxis -Os erfahrungsgemäß die Optimierungsstufe
-
Thread
[arm] Kompileroption -flto bewirkt daß der uart (ungefähr) doppelt so schnell läuft
Johann L. schrieb im Beitrag #3930370: > Optimierung nicht aktiviert? -Os denn Optimierung ist ja das Ziel der Übung. > Oder nicht LTO-sicher programmiert? Ich finde nichts im gcc manual zum Themembereich "LTO-sicher programmieren", es liest
nicht compilerseitig, sondern es sind Fehler im Programm, die erst durch diese modulübergreifende Optimierung offensichtlich werden. Welche Kommandos werden denn konkret ausgeführt, d.h. wie wird gcc etc. aufgerufen? /Nicht/ als make-Schnippel, sondern als Kommando, das von make /ausgeführt/ wird.
-
Thread
µC rechnet falsch oder ich finde den Fehler nicht
Lothar Miller schrieb im Beitrag #2989825: > Welche Optimierung hast du eingeschaltet? Unter Vorbehalt sage ich mal, dass dies das Problem war. Optimierung war auf -O1. Augenscheinlich auf -Os funktioniert es (zumindest UART-Ausgabe von oben gepostetem Code
Ne, so alt nun auch wieder nicht. Das ist die Versionsnummer der Atmel-Toolchain (nicht des avr-gcc). Da ist AFAIK ein avr-gcc 4.5 drin.