-
Thread
Optimierung von Bit-Transfer-Operationen
#5204824: >> doch geht es mehr darum zu verstehen, warum >> das so wie oben beschrieben ist. > > GCC ist Open Source, mit reichlich Optionen für die Darstellung der > Zwischenstufen bei der Optimierung. Und wenn jener Forenteilnehmer mit > recht viel Einblick in BLD/BST Optimierungen derzeit nicht
#5204824: >> doch geht es mehr darum zu verstehen, warum >> das so wie oben beschrieben ist. > > GCC ist Open Source, mit reichlich Optionen für die Darstellung der > Zwischenstufen bei der Optimierung. Und wenn jener Forenteilnehmer mit > recht viel Einblick in BLD/BST Optimierungen derzeit nicht
-
Thread
GCC bei kompilieren beschleuigen
schneller - Preprocessed Headers (PPH) verwenden - Auf Optimierungen wie LTO verzichten - Keine Dumps oder temporären Dateien erstellen lassen - Bei selbsterstelltem GCC darauf achten, daß dieser mit -O2 o.ä. erzeugt wurde!
Frederick schrieb im Beitrag #3017051: > Ich meine nicht die Code Optimierungen, Er auch nicht. Ohne Optimierung zu übersetzen spart Übersetzungszeit.
-
Thread
Neuer gcc compiler für ARM und Optimierungen
Mit dem Wechsel von Debian 11 auf Debian 12 wurde auch der gcc für ARM aktualisiert (jetzt arm-none-eabi-gcc (15:12.2.rel1-1) 12.2.1 20221205). Leider liefen damit einige meiner Projekte nicht mehr. Also hab ich die Ursache eingegrenzt und bin auf eine Optimierung
Schiebe die Funktion in ein eigenes C-File und kompilier es mit -ffreestanding. Dann weis GCC, das er für die Datei keine libc vorrausetzen darf und lässt diese Optimierung weg. Ggf. funktioniert auch -fno-builtin-strlen in deinem Fall.
-
Thread
Registeroptimierung von Assemblercodes
zubereiten. Für einen realen Prozessor oder was theoretisches? Im ersteren Fall: Compilerbau/Code-Optimierung ist zwar ein sehr schönes Feld, aber alles andere als einfach. Gerade das Optimieren ist alles andere als trivial. Angefangen mit brauchbarem IR (Intermediate Representation, bspw. GIMPLE beim gcc
ihr solltet euch mal grundlegende Gedanken über das Projekt machen und was ich erreichen wollt. Optimierung nur der Optimierung willens macht nur Arbeit und bezweckt genau gar nichts. Man muss sich das schon sehr gut überlegen...
-
Thread
Welche GCC Version ist empfehlenswert?
Hi, welche GCC Version ist momentan empfehlenswert, wenn man wenig Wert auf Ueberraschungen wie explodierende Binarygroesse oder kaputte Optimierungen legt? :-)
Postix schrieb im Beitrag #3274105: > welche GCC Version ist momentan empfehlenswert, wenn man wenig Wert auf > Ueberraschungen wie explodierende Binarygroesse oder kaputte > Optimierungen legt? :-) für welchen Platform denn?
-
Thread
delay für µs
Welche Optimierungen?
man dort auch die Option -O angeben, gefolgt von einer Kennung für die gewünschte Optimierung, also z.B. -OS für eine Size-Optimierung (möglichst kurzer Code), -O3 für möglichst schnellen Code, -O0 zur Abschaltung aller Optimierungen. Für die effektive delay-Nutzung müssen Optimierungen
-
Thread
Cycle Count auswerten und verstehen anhand von Shifts und Arrays
Du das probiert? Mit gcc 4.7.4 und -Ofast ist im Disassembly Output nichts von einer rotate Operation zu sehen?
Ruediger A. schrieb im Beitrag #5198379: > Mit welchen Optimierungsstufen hast Du das probiert? Mit gcc 4.7.4 und > -Ofast ist im Disassembly Output nichts von einer rotate Operation zu > sehen? arm-none-eabi-gcc 5.4.1 -O2 Ist nicht das Neueste, aber was Du da hast ist schon ziemlich antiquarisch
-
Thread
Wie auf Union mit Bitfeldern direkt zugreifen?
deren Einstellung zu nicht-standardkonformem Code kennt, dann ist es eine wirklich schlechte Idee, GCC für solche Zwecke einzusetzen. Denkbar wäre es z.B., daß man auf ARM bei Optimierung auf Geschwindigkeit immer 32bit-Ints zugrundelegt, weil das schneller geht als etwa 8 bit. Bei Optimierung auf
Erstens: nein, nicht grundlos. Es ist gerade der Spielraum des undefined, der so aggressive Optimierungen überhaupt erst ermöglicht, wie heutige C-Compiler sie beherrschen. Das sind zwei Seiten derselben Medaille. Mal ein Beispiel, WIE aggressiv GCC das kann: Neulich hatte ich das Problem, in einer
-
Thread
WINAVR produziert falschen Code
Johann L. schrieb: > Da gibt es aber böse Fallen wie > http://www.rn-wissen.de/index.php/Avr-gcc#Bit_7_bei_SFR-Zugriff Der sieht natürlich wirklich interessant aus. Mit aktuellen Versionen des GCC gelingt es mir aber nicht, das irgendwie zu reproduzieren. Im Prinzip müsste man die Optimierung
definitiv auszuschliessen, ist dedizierte RTL-Konstrukte dafür zu verwenden. So ziemlich das einzige, wo GCC keine algebraische Vorstellung von hat sind UNSPEC und UNSPEC_VOLATILE. Das würde solchen Optimierungen verhindern. Es müsste aber jemand geben, der solche Konstrukte erst erzeugt, und das kann nur
-
Thread
Wie feststellen in C, ob Zahl grade oder ungrade?
Mach das bitte. Mich interessiert jetzt nach der Diskussion hier doch jetzt auch was GCC so aus den Vorschlägen macht.
call 0x406a ; 0x406a <printf> [/a] bei -Os. Sehr interessant die sehr unterschiedliche Optimierung.
-
Thread
AVR/Delay.h Wie aufrufen?
zulässig, das entspricht dann der 1 (weil -O äquivalent zu -O1 ist). > Wo sind die verschiedenen Optimierungs levels beschrieben? Im gcc-Manual. Sollte bei Dir lokal installiert sein, oder ist im Web zu finden (http://gcc.gnu.org/ wenn ich mich recht entsinne). > Die Datei .lss hab ich schon angeschaut
hmmmmm ... merkwürdig, seit Deinem Posting kommt der Fehler nicht mehr. Kontrolliert gcc etwa den Browser? Stecken gcc und Mozilla unter einer Decke? Aber Spass beiseite: es ist garnicht so einfach, ein Testprogramm zu schreiben, dass gcc nicht komplett wegoptimiert :-) Stefan
-
Thread
AVR-spezifische Optimierung wirkt nicht in Member-Funktion
, Bit nicht. Tja, da kann ich dich nur dafür beglückwünschen, dass es dir gelungen ist, die Optimierung vom GCC auszuhebeln. Nobody is perfect, auch der nicht.
/gcc.gnu.org/bugs/#need
-
Thread
kostenloser Compiler gesucht
eben... Welcher GCC verwöhnt Dich denn? Der AVR-GCC kann es jedenfalls nicht sein. Der erzeugt für die gleiche Applikation auf dem AVR deutlich größeren Code, als der C51 auf dem 8051. Die Optimierungen des Keil
> Der AVR-GCC kann es jedenfalls nicht sein. > Der erzeugt für die gleiche Applikation auf dem AVR deutlich größeren > Code, als der C51 auf dem 8051. Kannst du an einem Beispiel konkretisieren? > Die Optimierungen
-
Thread
Linker entfernt Symbole?!
/freertos/portable/GCC/ARM_CM4F/port.c.o .text.vPortEndScheduler 0x0000000000000000 0x38 src/freertos/portable/GCC/ARM_CM4F/port.c.o .debug_macro 0x0000000000000000 0xa78 src/freertos/portable/GCC/ARM_CM4F/port.c.o .debug_macro 0x0000000000000000 0x174 src/freertos/portable/GCC/ARM_CM4F/port.c.o ... [/pre] und in der Tat, wenn ich den Code debugge und an diese Stelle gerate, sieht
-
Thread
X32 Softcore
Thomas W. schrieb im Beitrag #5212083: > Da ja eine GCC Toolchain existiert, gibt es wohl keinen Bedarf für den > LCC. Naja, der GCC-Port ist recht alt (2.95), und es gibt einige Nervigkeiten, die man ändern könnte, aber bei dem GCC Moloch nicht unbedingt
LCC-Beispiel gespannt. Thomas, hast du zum LCC ein paar Statistiken, was > Code-Generierung/Optimierungen angeht? Macht euch da keine großen Hoffnungen. Der LCC ist quasi ein Uni Projekt. Ein Zwerg gegen den Riesen GCC. Optimierungen gibt es aber nur sehr rudimentär. Die Stärken des
-
Thread
Strings mit AVR - aber richtig
#7328738: > PR92606 mischt Strings im Flash mit Strings im RAM, daher muss diese > (Compiler-)Optimierung deaktiviert werden. Du meinst den Bug 92606: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606 Und -fno-ipa-icf-variables ist ein Work-around für diesen Bug. Dein Patch wurde ja (leider)
92606: Ja. PR steht für "Problem Report", und es gibt eine fortlaufende Numerierung. https://gcc.gnu.org/PR92606 > Welche Optimierungen fallen denn noch weg, wenn -fno-ipa-icf-variables > gesetzt ist? Es fällt genau diese Optimierung weg: [code] -fipa-icf-variables Perform
-
Thread
Ausdruck optimieren auf Laufzeit
Andreas Ferber schrieb im Beitrag #1670589: > Compiler die Optimierung selbst nicht durchführen. Bei welchen Werten treten denn verschiedene Ergebnisse auf? Immerhin führt GCC genau diese Optimierung durch, in beiden Vorzeichenvarianten (x86 und avr). Weder Shift
C bleibt es aber undefined). Trotzdem bleibt (warum auch immer): >> Immerhin >> führt GCC genau diese Optimierung durch, in beiden Vorzeichenvarianten >> (x86 und avr). > Prinzipiell schon, aber er erweitert dazu den Wert auf 16 Bit (x ist > jeweils int8_t, kompiliert mit avr-gcc -O6
-
Thread
Problem mit Optimierung?
Hallo, ich bastl gerade unter Kubuntu 11.10 und aktuellem gcc mittels Eclipse_CDT an einem kleinen Programm. Ich lese eine Textdatei mittels fgets() aus. In meinen Textdateien steht in der ersten Zeile immer eine Zahl, danach folgen in den restlichen Zeilen irgendwelche Daten. Da ich die Zahl extra brauche lese ich diese aus und speichere sie ab, die restlichen Zeilen lese ich in einer while-Schleife aus. So lese ich meine Zahl aus: count = atoi(fgets(lineBuffer, 4, file)+2); Da ich count momentan zwar speichere, aber noch nicht weiter verwende optimiert mir der gcc die Zeile
-
Thread
CDC für xmega
ich gleich anhänge, habe ich die Optimierung lokal mit #pragma GCC optimize ("O1") aktiviert, den Rest des Programmes lasse ich mit -O0 laufen. >> 3. Bei dem CDC-Beispiel aus ASF >> funktioniert die Verbindung weiter, wenn man zwischenzeitig
egal wie lange hier die Pause ist } return 0; } // Konfiguration muss mit Optimierung laufen, sonst funktioniert Entsperrung der Code Protection nicht #pragma GCC optimize ("O1") void Config32MHzClock(void) { unsigned char tmp; // get USBRCOSC NVM.CMD = NVM_CMD_READ_CALIB_ROW_gc
-
Thread
ARM-GCC: Wert auslesen
Hallo zusammen, ich habe es mal wieder geschafft, mich in eine totale Anfängerfrage zu maneuvrieren: Ich will ein Register auslesen, da dadurch das Statusflag zurückgesetzt wird. Den ausgelesenen Wert kann ich allerdings für nichts gebrauchen. Also mal schnell und naiv: [c] void dummy(void) { volatile temp; // Auslesen, um Flag zu löschen temp = I2Cx->SR2; // temp wird nicht weiter gebraucht und nicht weiter verwendet } [/c] Wie kann ich sicherstellen, daß diese Leseoperation nicht wegoptimiert wird. Immerhin kann der Compiler von ihrer Nebenwirkung ja nichts wissen?
-
Thread
Division mit GCC (AVR Studio)
benutze das sowieso nie. Das willst du nicht wirklich, weil genau das mit ein Grund ist, warum du GCC benutzt und nicht BASCOM Basic programmierst. Der "Optimierungsblödsinn" macht dir ein korrektes Programm (normalerweise, sonst ist es ein Compilerbug ...) nicht kaputt. Wenn etwas mit Optimierung
4" eben "...%stepsY" schreibe, bricht er wieder dort ab. Wohlbemerkt alles mit -O0 also keiner Optimierung. Gruß Manuel
-
Thread
Welche Programmiersprache ?
Funktionen (macht Dir aber in Assembler auch niemand als Du selbst ;-) abgesehen, bin ich aber mit der Optimierung gerade des AVR-GCC im Großen und Ganzen zufriedener als Du. Ich kenne ein paar Dinge, die er besser machen könnte (beispielsweise control expressions vom Typ int auf 8 bits einkürzen, wenn nicht
Natürlich wollte ICH so einen Compiler NIEMALS programmieren wollen :) Denoch wäre es eine super Optimierung, die der Mensch eben bei handmade Assembler automatisch on the Way macht. Potential ist auf alle Fälle noch ne Menge im AVR GCC. Ich habe halt bisher noch keinerlei Vergleiche zu anderen verfügbaren
-
Thread
Bitmanipulation beschleunigen
(ret). > >>das erwarte ich als Selberverständlichkeit von einem Compiler. > > Das macht der gcc ja auch ohne den Hack, der macht es nur noch einen > TICK schneller. Ist eine OptimierungsoptimierungOptimierung. Ich würde > sie einfach weglassen. Offensichtlich hilft man dem GCC beim Optimieren
Eingabe und Ausgabe hat; gcc weiß nach dem asm also nicht mehr, dass out=0 ist, und daher kann die o.g. "Optimierung" nicht angewandt werden. Wenn man aber wirklich darauf angewiesen ist, dass der Code diesen Grad an Effizienz
-
Thread
Unterschiede des Variablen-Erstellens
die Variable offiziell davor nicht existiert. Aber natürlich gilt, die 'oberste Direktive der Optimierung', die 'as-if' Regel: Der Compiler darf alles machen und umstellen, solange das Programm die Optimierung nicht feststellen kann und die Programmlogik gleich bleibt.
tut - wie in deinem Fachgebiet auch. > >>Aber natürlich gilt, die 'oberste Direktive der Optimierung', >>die 'as-if' Regel: Der Compiler darf alles machen und umstellen, >>solange das Programm die Optimierung nicht feststellen kann und >>die Programmlogik gleich bleibt. > > Naja, das ist
-
Thread
AVR: 16bit Quadratwurzel in 63 Takten, fsqrt16.asm
Sprache, mit der man nicht vertraut ist ;-) > Ich kann leider (noch) nicht nachvollziehen wie die Optimierung zustande > kam. Welche Optimierung meinst du denn? Sie kam genauso zustande wie deine Optimierungen auch: via Brain 0.9. Keine Magie im Assembler, keine im Disassembler. > Ein Size-optimierte
Der macht wohl schon lange sinnvollere Dinge, z.B. die avr-gcc-Bugs aktualisieren.
-
Thread
[C] Böse Falle: Datentyp korrekt angegeben, falscher verwendet
Man sollte seinen Compiler kennen: Du verwendest wohl einen AVR, da rechnet der gcc intern halt standardmäßig mit 16 Bit ints. Ein gcc für ARM Cortex-M würde hier mit 32 Bit ints rechnen.
Zweifel insofern anmelden, dass es nur noch mit unfairen Mitteln geht. Ich arbeite mit den neusten GCC Versionen für ARM, die optimieren für normale Funktionen unschlagbar gut. Gerade wenn Funktionen dann noch etwas größer sind steigt man mit händischer Optimierung nicht mehr durch. Und schließlich gibt's
-
Thread
Hilfe - AVR-GCC "optimiert" Schleife zur Endlosschleife
Ich würde sagen: <0 ist beim gcc FALSE. Also hat er die komplette Schleife rausgeworfen, und die for() blieb übrig.
und pfeift auf den C-Standard. Falsch. Dir wurde bereits erklärt, was der Standard sagt. Der gcc hält sich mit wie ohne Optimierung daran. Er macht sogar das, was man tendentiell erwarten würde. > Und ich hätte mindestens erwartet, daß er mir eine Warnung ausgibt, wenn > er diese eindeutig
-
Thread
AVR-GCC und kleine Controller
man gcc, da steht's weiß auf Schwarz: -O, -O0, -O1, -O2 und -O3. Das Assembler-HOWTO ist also offensichtlich falsch.
es -O levels > 3 wirklich gibt (die Manpages, der Sourcecode), aber der Glaube an den Gott der Optimierung wirkt stärker... Dabei ist in der Doku zum gcc wirklich recht detailliert beschrieben, welche Stufe welche Optimierungen einschließt. Im Gegensatz zu irgendeinem Howto stammt diese aber von
-
Thread
-
Thread
c++ Zwischcode c anzeigen
google-Suche) > sieht man doch dass du dich auf einem Niveau bewegst auf dem absehbar > ist dass du den gcc-Optimierer nicht toppen kannst. > Unabhängig vom konkreten Problem. Ich glaube nicht, dass er versucht die Optimierungen vom gcc zu toppen. Es geht eher um langsamen C++ Code, den der gcc nicht
#4435184: > Und ein aktueller C++ Compiler optimiert auch entsprechend selber so das > eigene Optimierungen nicht wirklich besser sein dürften. Das ist stimmt zum Teil, aber: - GCC ist kein moderner Compiler. - Compiler werden überlicherweise besseren Maschinencode erzeugen wenn man das Gesamtergebnis
-
Thread
_delay_ms() läuft 4 Mal schneller als erwartet
nicht drin, Anatolij mag den irgendwie nicht. Den Patch hab ich nicht 1:1 übernommen. http://gcc.gnu.org/onlinedocs/gcc/AVR-Built_002din-Functions.html#AVR-Built_002din-Functions http://gcc.gnu.org/viewcvs?view=revision&revision=172416 Etwas seltsam finde ich manche Builtins schon; die gingen
Johann L. schrieb im Beitrag #2191158: > Den Patch hab ich nicht 1:1 übernommen. > > http://gcc.gnu.org/onlinedocs/gcc/AVR-Built_002din-Functions.html#AVR-Built_002din-Functions > http://gcc.gnu.org/viewcvs?view=revision&revision=172416 OK. Vielleicht baue ich das nochmal um, wenn deine Version
-
Thread
gcc vs. mbed online (ARM compiler v5)
das enthält ein printf() und das FatFS von ChaN. Der mbed Online Compiler erzeugt 27,9 kB Code, der gcc 4.9.3 macht aus dem gleichen Projekt 38 kB, also über 10 kB mehr. Optimierung steht auf -Os, -O3 erzeugt gleich viel und kleine Optimierungen noch mehr. Kann das sein das der online Compiler (soll ein
Eine Variante zur Codeverkleinerung beim GCC ist noch die linker time Optimierung einzuschalten...
-
Thread
switch case optimierung
Hi, ich habe ein ATtiny10-C-programm mit einer switch case Anweisung geschrieben. Der Compiler hat es wundervoll mit einem berechneten Sprung optimiert, die einzelnen Sprungziele liegen jeweils 6 Adressen auseinander. Aber was ich nicht verstehe: wie macht er die Multiplikation mit 6? Hier ein Auszug aus der iss-Datei: [c] //********************************************************************* void light_wave(uint8_t Color,uint8_t position) { Color = 4; switch(position) 7a: e6 2f mov r30, r22 7c: f0 e0 ldi r31, 0x00 ; 0 7e: e1 31 cpi r30, 0x11
-
Thread
avr-gcc 4.9, Atmel Studio 7 unterschlägt Code
Hallo Leute, ich bin fast verzweifelt. Der Code unten läuft korrekt unter Studio 6 mit avr-gcc 4.8 aber mit dem neuen avr-gcc ab (einschliesslich) Optimierung -O2 wird der Test der Adresse einfach "wegoptimiert". Liegt das jetzt an meinem Code oder ist das ein Compiler-Bug? Danke für eure
Programmierer den Code so geschrieben hat, dass es gar nicht erst zum Overflow kommt, was diese Optimierung ebenfalls rechtfertigt. Neuere Versionen des GCC nutzen an mehreren Stellen die Regeln für undefined Behavior und strict Aliasing für aggressive Optimierungen. Unsauber programmierter Code
-
Thread
Codesize WinAVR 20060421 vs WinAVR-20090313
Registervariablen sind eben was komplett anderes als globale Variablen!! Und ganz am Rande: Auch bei -O0 führt gcc Optimierungen durch. Er faltet zum Beispiel Konstanten. Beispiel: a=1+2 wird zu a=3. Und was das zu "Nullinitialisierung" steht, muss man nicht wirklich verstehen... Johann
Registern idR noch keinem Hardware-Register zugeordnet sind. Ich hätte noch nichtmal ne Idee, wo man in gcc diese Optimierung einbauen könnte. Expand (also direkt nach dem Übergang GIMPLE->RTL) wäre nett, ist aber viel zu früh, weil man nix über die Kosten weiß. CSE (common subextression elimination) wäre
-
Thread
GCC Codebeispiel, doppelte variablen?
dann im Ergebnis erst Teile des Registers maskieren müssen). Auf Grund seiner Geschichte hat der GCC daher in der Vergangenheit eher wenig Optimierungen in diesem Bereich erfahren, verglichen mit vielen anderen Bereichen (bei denen er teilweise Optimierungen vornimmt, die du als Assemblerprogrammierer
. Eigentlich gibt es derzeit wohl nur einen einzigen richtig aktiven AVR-GCC-Hacker (Björn Haase). Wenn ihm irgendeine Optimierung zu dünn ist, dann repariert er sie (und benutzt das dann auch in produktivem Code). Den Support für ATmega256x haben wir auch ihm zu verdanken
-
Thread
Blöder Compiler - Optimieren in C?
sie als 2 getrennte 8-Bit Variablen. Allerdings ist trotzdem recht viel Raum für Verbesserungen. Optimierung von Operationen auf Teilworte ist nicht die stärkste Seite von GCC. Ist zwar wesentlich besser geworden (da hat wohl Johann einigen Anteil), aber perfekt ist das nicht. Der Compiler weiss möglicherweise
avr schrieb im Beitrag #4566271: > Das Problem scheint zu sein, dass der GCC ungern/nie Variablen im Ram > manipuliert ohne sie komplett in die Register zu lesen. Im Zwischencode und in weiten Teilen der Optimierung sind das Wortoperationen, keine Byteoperationen. Zu Bytebefehlen
-
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
Counter Geschwindigkeit
Mit folgenden Einstellung braucht die For-Schleife für einen Durchlauf 37 Takte: avr-gcc -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=1000000UL -O0 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT test.o -MF dep/test.o.d -c ../test.c Optimierung
Vielleicht sollt ich ja > nen umstieg auf AVRStudio wagen. Zumindest erheblich weniger als mit dem AVR-GCC (WINAVR, AVRStudio). Sachen, die nicht im C-Standard festgelegt sind, behandelt jeder Compiler unterschiedlich, z.B. Inline-Assembler, Interrupthandler. Und die Compileroptionen (Optimierungs-Level
-
Thread
[AVR] ATmega16 startet neu bei EEPROM-Zugriff auf 0x1F0?
wenn sie Code vorgeworfen bekommen an dem sie sich austoben können. Und die meisten Leute die mit gcc arbeiten wissen eigentlich das sie Optimierung aktivieren sollten. -Os ist im µC/embedded bereich ja sehr verbreitet, -O2 auf "normalen" Systemen. (Wobei -Os auf modernen kleinen CPU wie VIA C7 etc.
möglich, in Compiler, Assembler oder Libs zu umschiffen). > 2) Aus welchem Grund kann eine Optimierung NICHT erwünscht sein? Optimierung erschwert Debugging. Bei manchen Compilern schliesst sich Debugging und Optimierung sogar aus. Bei gcc jedoch nicht, aber die Debug-Info wird zunehmend übel,
-
Thread
ATMega Flash wird langsam knapp. Upgrade o. Plattformwechsel?
machen. Apollo M. schrieb im Beitrag #5968393: > nd wenn noch nicht geschehen tausche auch die gcc version, gute > erfahrung habe ich mit v8.3 bzgl. optimization. Nein ich benutze die GCC Version 5.4.0 die Version 8.3.0 kann ich nicht finden habe nur die AVR-GCC 9.2.0 gefunden zum Downloaden:
Felix N. schrieb im Beitrag #5968537: > Nein ich benutze die GCC Version 5.4.0 die Version 8.3.0 kann ich nicht > finden habe nur die AVR-GCC 9.2.0 gefunden zum Downloaden: > > http://blog.zakkemble.net/avr-gcc-builds/ ... die gcc v8.3 findest du auch bei
-
Thread
c++ Code langsam
foobar2_gcc_O3_march=native ./foobar3_gcc_O3_march=native ./hans_gcc_std=c++17_O3_march=native ./heinzel_gcc_std=c++17_O3_march=native ./heinzel2_gcc_std=c++17_O3_march=native ./native_gcc_O3_ma rch=native 'python
Die Zehn Zeilen strtok goodness bieten noch etwas Raum fuer optimierung... ;-)
-
Thread
Einfacher Fehler in C-Berechnung
' > oder kalten Kaffee bezeichnet. Manche Optimierungen sind durchaus nicht trivial. Aber was ich damit nur ausdrücken wollte, ist, dass da deutlich mehr gemacht wird als man gemeinhin erwartet. > Das Problem bei den Optimierungen ist, das man sich
Optimierung das Gegenteil von dem, was man möchte. Das Abschalten der Optimierung - unterdrückt oft Warnungen, weil der Compiler Probleme erst bei höheren Optimierungsstufen erkennt. - verschleiert
-
Thread
C: "unsigned char"-Vergleich immer mit 16 Bit?
Die Version von Atmels Studio ist irrelevant. Die Version vom Compiler ist wichtig, also vom gcc in WinAVR. Wie schon gezeigt: avr-gcc 4.7.2 macht es besser.
ist und avr-gcc auf C:\avr-gcc-4.7.2-mingw32\bin\avr-gcc.exe make auf C:\avr-gcc-4.7.2-mingw32\utils\bin\make.exe _automatisch_(!) eingestellt wurde. 7. Compilieren und über das kleinere Binary freuen
-
Thread
optimierung von sbi/cbi
hi, gibt's eigentlich eine möglichkeit, dem compiler beizubringen, zb das folgende automatisch zu optimieren? da kann man ja so einiges zusammenfassen. von hand wäre das aber mühsam und fehleranfällig. normalerweise schreibe ich ja nicht "PORTB |= _BV(PB5);" sondern habe makros für sowas. [c] PORTB |= _BV(PB5); 393c: 2d 9a sbi 0x05, 5 ; 5 PORTB |= _BV(PB4); 393e: 2c 9a sbi 0x05, 4 ; 5 PORTB |= _BV(PB2); 3940: 2a 9a sbi 0x05, 2 ; 5 PORTB |= _BV(PB3); 3942: 2b 9a sbi 0x05, 3 ; 5 PORTB |= _BV(PB0); 3944: 28 9a sbi
-
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
Ist 'static' für globale Variablen Pflicht?
> Wenn ich die Optimierung ganz ausschaltete, dann wurde nichts > überschrieben, nur bei eingeschalteter Optimierung passierte das. Du hast irgendeinen anderen Fehler im Program. Was du siehst, sind die Symptome und
> Aber hier knallt's Macht für den gcc keinen Unterschied. Der gcc ist schlau genug zu verstehen, was mit der Adresse eines Arrays gemeint ist. Die Datentypen stimmen nicht, daher die Warning. Das Endergebnis sieht aber völlig gleich
-
Thread
Bitstatusabfrage Macro - ist das sicher?
und Variante 1 selber auf > Variante 2 umschreiben, aber darauf würde ich mich nicht verlassen. GCC/amd64 macht das bei eingeschalteter Optimierung. Aber auch ich würde das lieber bleiben lassen. Bei GCC/AVR könnte das bei abgeschalteter Optimierung auf ziemlich schaurigen Code rauslaufen. Das
Variante 1 selber auf >> Variante 2 umschreiben, aber darauf würde ich mich nicht verlassen. > > GCC/amd64 macht das bei eingeschalteter Optimierung. Aber auch ich würde > das lieber bleiben lassen. Bei GCC/AVR könnte das bei abgeschalteter > Optimierung auf ziemlich schaurigen Code rauslaufen.
-
Thread
C++11 std::array mit struct
jv@JamesWebb:~/kicad/build/debug$ gcc --version gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even
drin. aber eigentlich kannst du was neueres installieren. ich habe auch 18.04 parallel und da ist gcc-9 drauf.
-
Thread
ATMEL billiger und leistungsfähiger als PIC
Stabil, dafür gibt es gute Dokumentationen und es gibt keinerlei Codelimit. Lediglich die maximale Optimierung wird nach drei Monaten zurückgefahren... (Das kann man aber bei den GCC basierenden Compilern auch umgehen in dem man die Quellcodes -die ja offen liegen- selbst kompiliert) Mit dieser Umgebung
16MHz komme ich mit einem aktuellen GCC (4.3 oder neuer) auf 96,4µs statt 641µs bzw. 657µs. Entweder war damals der GCC sehr viel schlechter als heute oder (wahrscheinlicher) es wurde vergessen, die Optimierung einzuschalten.