-
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
Bitshift schlecht implementiert?
GCC lebt davon, dass er von Leuten verbessert wird. Mach es! Du hast keinen Anspruch darauf, dass andere es tun. Ausserdem kannst du der Optimierung auch im Quellecode nachhelfen. Statt [c] rf_sendspi
Gilt logischerweise nur für Megas die eine HW-MUL unterstützen. Normalerweise setzt man solche Optimierungen im Compiler voraus, sie sind Standard. Klar das dies für GCC nicht gelten kann, lebt dieser von der Eigenintiative ambtionierter Programmierer. Ich denke das keiner hier GCC oder deren Entwickler
-
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
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
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
Variablen in ISR static - sinnvoll oder nicht?
Hallo, das wird wohl stark von der Laune der GCC-Optimierung und dem Variablentyp abhängen. Er könnte z.B. eine Registervariable nutzen, wenn es nicht static ist, bei static muß er den Wert in jedem Fall irgendwo im Ram sichern. Auch wenn ich im
, die der Compiler in effizienteren Code umsetzen kann. Ein Hauptgrund dafür ist, das solche Optimierungen eher marginale Wirkungen haben im Vergleich zu Optimierungen des Algorithmus. Um ein Gefühl für Optimierung von Algorithmen zu bekommen, kann man sich mal die verschiedenen Varianten von Sortieralgorithmen
-
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
[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
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
SPI mit GCC sehr speicherintensiv
1. Lass die Finger weg von __attribute__, der GCC ist nicht annähernd so dumm, wie man meint. 2. Übersetze nicht mit -O2, sondern mit -Os. In deinem Makefile steht -O2, also Optimierung auf Geschwindigkeit. 3. Verpacke die Initialisierungssequenz
noch Platz im Speicher frei ist (was > an sich ja vollkommen ok ist, wenns mal eng wird, wird der GCC sich > schon melden und anders optimieren). Melder wird er sich, d.h. der Linker wird es. Die Optimierung umstellen musst du dann aber schon selber.
-
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
code optimierung
Hi, ich habe da ein Problem mit dem GCC Compiler im Zusammenhang mit Volatile-deklarierten Variablen und Code-Optimierung. compiler: Gcc 4.3, avr lib 1.6, device atmega8, Kom: 8N1, 400000Hz ich bin grad relativ erfolgreich am Debuggen
UART_TX_BufferRead neu holen soll? Woran kann meiner Fehler liegen? Zur Fehlersuche habe ich die Optimierung von Os in O0 geändert, hat nichst gebracht. Vielen Dank im Voraus! Meier
-
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
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
Bitmanipulation Shiften
Dr. Sommer schrieb im Beitrag #5298580: > Was heute ohne Optimierungen funktioniert, klappt morgen mit > Optimierungen vielleicht unbemerkt nicht mehr weil der Compiler die > Register-Zuordnung geändert hat. Dr. Sommer schrieb im Beitrag #5298580: > Allein schon
innerhalb von GCC portierbar. Beispielsweise erzeugt avr-gcc folgenden Code: [c] #include <stdint.h> int8_t ashr1 (int8_t x) { return x >> 1; } int8_t ashr7 (int8_t x) { return x >> 7; } int8
-
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
.discards qualifiers from pointer target type
foo( Text ); Genauso ist es mit volatile. Volatile markiert eine Variable als 'mach keine Optimierungen damit'. Wenn nun eine Funktion auf einem übergebenen Parameter keine Optimierungen machen will, dann ist das doch auch in dem Fall kein Beinbruch, wenn sie es im Prinzip machen könnte (weil
> Vielleicht wurde das Problem aber jetzt schon behoben (ist schon länger > her) und AVR-GCC optimiert nicht mehr bei Zuweisungen in denen Register > mitspielen? Der gcc selbst hat von den Registern keine Ahnung. Diese sind aber in der avr-libc bereits als volatile definiert.