-
Thread
[C++] Code-Optimierung auf AVR
anderes: Wenn ich nur einen Codeteil mit O2 kompilieren will gibts immer einen Fehler: #pragma GCC optimize("O2") SRF05.cpp:124: error: ignoring #pragma GCC optimize
A. K. schrieb im Beitrag #3940487: > N. G. schrieb: >> SRF05.cpp:124: error: ignoring #pragma GCC optimize > > Beitrag "Re: [C++] Code-Optimierung auf AVR" Peinlich, übersehen. Wird direkt ausprobiert. Sorry
-
Thread
GCC und MMX-Optimierung
kleiner sind als 64 bit und als Array vorliegen, würde ich schätzen. Du kannst die MMX-Befehle im GCC auch explizit nutzen. Siehe: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/X86-Built_002din-Functions.html#X86-Built_002din-Functions
builtin_ia32_pand (di, di) "di" ist wohl der Datentyp nachdem ich gesucht habe. Die Frage ist halt, ob GCC dann auch wirklich MMX Optimierungen verwendet oder ob da nur ein typedef unsigned long long dahintersteckt. Aber das seh ich ja dann gleich ... Explizit will ich eigentlich die MMX-Befehle nicht
-
Thread
Zusammenfügen von 2 mal 8 bit zu einem 16 bit Wert funktioniert nicht richtig
1) Weil vor einiger Zeit die Ansteuerung eines Displays ohne optimierung nicht ging 2) Weil in diesem Artikel http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung die Optimierung -Os empfohlen wird. Was ist das korrekte Verfahren?
hat die Nummer PR46779. Er ist behoben in 4.5.4, 4.6.2 und neueren Versionen. Und das ist die GCC-Version, nicht die "Atmel-Version". Die GCC-Version wird angezeigt mit avr-gcc --version
-
Thread
Nicht Kompilieren bei einem bestimmten Wert in einem const array
aufgerufen werden. * Geht nur, wenn der Compiler nicht genutzte Funktionen löschen darf. Beispiel ``gcc -O1``. Ohne Optimierung wird der Fehler immer immer geworfen. */ #define STATIC_ASSERT_ON_LINKTIME(cond, msg) do { \ extern void assert_by_nonexisting_function__##msg(); \
warum nur bist 1000? Also, es bleibt leider Mist. - Abhängig von der Optimierung - Abhängig vom pragma - Abhängig von der Array-Größe > [c] > #pragma GCC unroll 1000 > for(size_t i=0; i<ARRAY_COUNT(test); i++) { > STATIC_ASSERT_ON_LINKTIME(test[i][1] < 5,
-
Thread
Downgrade von ATMEL Studio 6.2 auf 6.0 wg GCC Fehler?
so wohl kaum feststellen. > > Also, Thema geschlossen und vielen Dank an euch alle. #pragma GCC push_options #pragma GCC optimize ("O2") // your code #pragma GCC pop_options Damit kannst Du die Optimierung nur für ein einzelnes Codestück ändern und so die Ursache einkreisen.
Frank K. schrieb im Beitrag #3886398: > > #pragma GCC push_options > #pragma GCC optimize ("O2") > > // your code > > #pragma GCC pop_options > > Damit kannst Du die Optimierung nur für ein einzelnes Codestück ändern > und so die Ursache einkreisen
-
Thread
Spass mit C Code
Doch ist die Ausgabe bei jedem Aufruf anders, auch beim unmodifizierten Quelltext. Mein Compiler ist gcc (GCC) 4.6.2 20111125 (prerelease)
PHP <3 schrieb im Beitrag #2470271: > Also mit gcc 4.5.2 gehts ohne Probleme. Auch weitere Parameter machen > dem ganzen nix. Mit oder ohne eingeschaltete Optimierungen?
-
Thread
Assembler Frage
. Und ich auf ein krasses Unverständnis von der Arbeitsweise eines solch komplexen Werkzeuges wie GCC. Es ist beim GCC (und bei allen anderen ernsthaften Compilern) nicht mehr sinnvoll, willkürlich nach dem Sinn irgendeines Schnippels zu fragen. Ganz einfach deshalb, weil zwischen C-Quelltext und
oder anderen Form mitspielt. Auch in deinem Code ist es sehr wahrscheinlich nicht eine einzige Optimierung, die für das Ergebnis verantwortlich ist, sondern da sind viele Optimierungen am Werk, die sukzessive und in Schritten den Ausgangscode auf das letztendlich generierte Ergebnis transformieren.
-
Thread
Wie in C zum Quadrat? Gesperrt
wurde ein "Haken" noch nicht diskutiert, der insbesondere in einer µC-Umgebung relevant sein kann: gcc (zumindest, clang weiß ich nicht) macht die 'pow()'-Optimierung nur, wenn man *nicht* mit -ffreestanding übersetzt (was ja in einer µC-Umgebung durchaus eher mal der Fall ist).
dich halt jetzt auf ein "volatile" versteifen. Traurig. Markus F. schrieb im Beitrag #6174337: > gcc (zumindest, clang weiß ich nicht) macht die 'pow()'-Optimierung nur, > wenn man nicht mit -ffreestanding übersetzt (was ja in einer > µC-Umgebung durchaus eher mal der Fall ist). War ja keine Zielplattform
-
Thread
Optimierung bei Multiplikation
Hallo! Ich verwende bei eine Treiber für ein T6963 Display eine Multiplikation für das linksschieben Optimiert wird mit -Os auf einemn ATMega128 Ungefähr so <code> i = PowerOf2Tab[7-i]; tmpDaten._int = ((uint8_t)Daten * (uint8_t)i); <code/> Wobei tmp_Daten._int eine Union von größe int ist, welches dann je als Byte in nem Cache Abgelegt wird und dann zum LCD Geschickt. i ist PowerOf2 für schieben. der Gcc optiemiert diesen vorgan auch recht ordentlich, nämlich so. andi r24,lo8(7) ldi r30,lo8(7) ldi r31,hi8(7) sub r30,r24 sbc r31,__zero_reg__
-
Thread
Optimierung bei USART Registerzugriff
schrieb im Beitrag #3198790: > Ich hätte eine Frage, warum mit -O3 ? Wie gesagt, bei allen Optimierungen (1,2,3,s) gibt es das gleiche Ergebnis. Ich benutze avr-gcc 4.7.0
Die Anzahl der Zyklen sind für avr-gcc ziemlich wurscht. GCC erzeugt i.W. Code, der den Boliden wie ARM oder x86 genehm ist; was die maschinenunabhängigen Optimizer für Hänflinge wie AVR treiben interessiert eigentlich keinen...
-
Thread
WinAVR 20080402
auch nur dann, wenn sie nicht sowieso schon an anderer Stelle im Programm benötigt wird. Der GCC wäre aber nicht der GCC, wenn man das unglückliche Feature - wie auch die meisten anderen Optimierungen - nicht selektiv abschalten könnte, und zwar mit -fno-tree-scev-cprop Mit dieser Option
So, die beiden Optimierungen haben voll eingeschlagen (14% weniger), ist schon fast wieder an den GCC4.2.2 ran. Ich hab dann mal gesucht, wo der nächste Codefresser sitzt und ihn gefunden. Vielleicht findet ja noch jemand
-
Thread
Comileroptimierung - was kann er und was nicht?
GCC kennt die Eigenschaften der eingebauten Funktion __builtin_strlen(), auf die irgendwo in den Includes die Funktion strlen() umgesetzt wird. Damit ist volle Optimierung möglich. Das /kann/ ein Compiler
A. K. schrieb im Beitrag #3979782: > GCC kennt die Eigenschaften der eingebauten Funktion __builtin_strlen(), > auf die irgendwo in den Includes die Funktion strlen() umgesetzt wird. > Damit ist volle Optimierung möglich. Das kann ein Compiler
-
Thread
avr-gcc: direkter Register Zugriff vs structure-mapping und fehlende Optimierung?
suboptimal sind. Du hast die Frage nicht verstanden! Ich bin ja mit der nicht so ganz vollständigen Optimierung des gcc im Falle (1) vollkommen zufrieden. Die Frage ist, warum wird das durch Version (2) verhindert. Oliver S. schrieb im Beitrag #7350030: > Es ist schlicht sinnlos, zu fragen, warum ein
MemoryBarrier (oder auch ggf. ein Output-Clobber bzgl. counter hier) fälschlicherweise auch eine Optimierung bzgl. der globalen Variable `g` verhindert. Also, insgesamt 3 Fehler im aktuellen gcc, wobei jeder für sich schon die Generierung eines optimalen Code verhindert. Workaround ist hier, auf den
-
Thread
STM32 GCC Compilereinstellungen für Minimum Size -Os
inzwischen doch schon längerer Zeit Link time optimization erfunden, kurz lto. Ist zwar im Falle vom gcc/clang nicht ganz zutreffend, weil die Optimierung trotzdem vom Compiler durchgeführt werden, der ist aber sozusagen in den Linker gerutscht, und sieht dort den gesamtem Code. Oliver
ich so nicht nachvollziehen. LTO ansich optimiert ja auch garnix. Es sorgt nur dafür das die Optimierungen nicht zur Compilezeit sondern erst zur Linkzeit erfolgen. Dazu wird in die einzelnen Objektdateien kein Binärcode sondern ein Zwischencode geschrieben. Je nach GCC-Version und Optionen wird der
-
Thread
GCC Bug?
interessieren den größten Teil der GCC-Hacker wohl einfach nur die `mainstream'-Targets (IA32, AMD64, vielleicht noch UltraSPARC, PowerPC und ein bisschen MIPS). Deren Optimierungen am Compiler werden also alle nur an diesen Prozessoren
> GCC Bug? Ja, GCC ist ein Bug.
-
Thread
Compilter Optimierungen für bestimmte Codeabschnitte deaktivieren
/gcc-4.7.2/gcc/Function-Attributes.html#Function-Attributes
Ich nehme mal an, daß du von GCC sprichst. GCC hat ab Version 4.4 Pragmas mit denen man funktionsgenau die Optimierung steuern kann, man kann die Optimierungsoptionen auch als Funktionsattribute anhängen: http://gcc.gnu.org/onlinedocs
-
Thread
gcc 3.4.2 zum gcc 4.2.0 problem
Hallo. Wollte ungern über die Qualität von gcc diskutieren. Problem ist nur mit gcc 3.4.2 funktioniert die Funktion auch bei Optimierung. Bei 4.2.0 geht sie nicht. Man kann ja jetzt schlecht alle funktionen durchgehen wenn man gern updaten
Tomi wrote: > Hallo. > > Wollte ungern über die Qualität von gcc diskutieren. > > Problem ist nur mit gcc 3.4.2 funktioniert die Funktion auch bei > Optimierung. > Bei 4.2.0 geht sie nicht. Dann zeig doch mal die Funktion her. Und wenn du 'funktioniert nicht
-
Thread
Compileroptionen
bewaffnet mit der Fehlermeldung kann man dem Compiler ja den präprozessierten Quelltext entlocken (gcc -E) und sieht das Problem dann meist sofort. > Solche einzeiligen Funktionen optimiert der gcc schon weg. Darum musst > du dich nicht manuell kümmern. Jein. Die Optimierung ist nicht das vordringliche
Rolf M. schrieb im Beitrag #7915116: >> Der GCC tut dies bei kleinen Funktionen und eingeschalteter Optimierung >> auch recht häufig, so dass die Verwendung von "inline" oft gar keinen >> Unterschied macht. > > Doch, es macht einen Unterschied
-
Thread
Ich suche einen "etwas anderen" C-Compiler Gesperrt
movne r1, #65536 ; 0x10000 88c8: 03a01801 moveq r1, #65536 ; 0x10000 Wenn ich seh was gcc (-O2) so macht - ist die Antwort Ja Inline Assembler ist schlecht, weil der Compiler Probleme mit der Optimierung bekommt.
heinz schrieb im Beitrag #3526502: > Wenn ich seh was gcc (-O2) so macht - ist die Antwort Ja Welche Version? > Inline Assembler ist schlecht, weil der Compiler Probleme mit der > Optimierung bekommt. Dafür gibt es die entsprechenden Constraints, geht,
-
Thread
"Include-Libs" - Teufelswerk?
so dass > es nicht funktioniert. Neuere Versionen können vermutlich auch die > "normalen" Optimierungen -O2 etc besser. Lieber eine nicht-antike > Compilerversion verlangen als hässlichen Code zu schreiben... gcc4.7.2 ist antik?!? Das glaubst Du doch selbst nicht.
einem frühen zeitpunkt des Compilevorgangs, also vor Inlining > von Funktionen und anderen Optimierungen. Beim LTO-Lauf extrahiert der > Compiler die LTO-Info und hat dann die globale Information über alle > Module / Danke für die Hintergrundinfos. Für den Laien kann man also sagen: Der gcc
-
Thread
AVR Optimierung verbessern
Wenn du Optimierung willst, schreib dein Programm in Assembler :D
Flash sein, und da reichen 8 Bit nicht. Einen Pointer, der nur auf Ram zeigen kann, gibt es in AVR-GCC nicht.
-
Thread
GCC Compiler: Optimierung ein oder aus?
Zusammengefasst: Einschalten! -O2 dürfte in den meisten Fällen die geeignete Wahl sein. Fehler durch die Optimierung sind in praktisch allen Fällen Fehler im eigenen Code. Insbesondere die delay-Funktionen funktionieren nur _mit_ Optimierung.
Als Ergänzung zu möglichen Problemen, wenn man die Optimierung vorher noch nie genutzt hat: ein "vergessenes" volatile (vgl. avr-libc FAQ#1) macht sich sehr wahrscheinlich erst bei eingeschalteter Optimierung durch Fehlerverhalten in der Anwendung bemerkbar
-
Thread
C++ - Warum gibt es hier einen SegFault?
Bei x86-64 GCC Version 7.3.0 funktionierts, bei Clang 6.0.0 auch. Beim ARM-GCC 8.2.1 hingegen nicht - auch hier wird das "pop {r4, pc}" weggelassen. Im C++-Standard Draft (n4659) heißt es in 9.6.3 2: "Flowing
diesem UB (also das vom Anfang) kann man m.M.n. sehr schoen erkennen, warum UB so gefaehrlich ist: GCC ohne Optimierung: kein SegFault GCC mit Optimierung: SegFault Clang ohne Optimierung: SIGILL Clang mit Optimierung: kein SIGILL Wenn man mal mit valgrind reinguckt: Mit gcc compiliert (mit
-
Thread
Probleme nach Optimierung
...oder man hat einen GCC 4.3.0-2 (debian), der optimiert schon mal uint32_t Operationen (z.B. division) weg...
sei() hinkommen muss. Nirgends. Das ist schon richtig so. Dringende Literaturempfehlung: [[AVR-GCC-Tutorial]]
-
Thread
Fehler in For-Schleife?!
Dominik K schrieb im Beitrag #1909856: > Aber was den nun? > Der eine sagt Optimierung muss aus, der andere sagt das führt zu > Fehlern, der dritte sagt das geht gar nicht. ohne optimierung geht delay nicht, also braucht du auf jeden fall die Optimierung. Und alle Fehler die durch
Ohne Optimierung macht "for(i=0;i<16;i++) led_on();" folgendes: led_on(); led_on(); led_on(); led_on(); ... led_on(); (insgesamt 16x). Mit Optimierung aber das: led_on(); Das liegt daran, dass
-
Thread
Idee für Optimierung? (Scope-Clock auf Speed)
Was ist denn die eigentliche Zielrichtung der Optimierung? Die von dir gestellte Frage ist sehr konkret, aber dass du an der Struktur der ISR nur begrenzt drehen kannst ohne dem GCC ein neues Registermodell beizubringen ist dir ja selber schon klar. Insofern
werden oft mehrfach verwendet. A. K. schrieb: > Was ist denn die eigentliche Zielrichtung der Optimierung? Die von dir > gestellte Frage ist sehr konkret, aber dass du an der Struktur der ISR > nur begrenzt drehen kannst ohne dem GCC ein neues Registermodell > beizubringen ist dir ja selber schon
-
Thread
Präprozessor-Trick gesucht
Wenn der Code portabel sein sollte, ev auch bei versch GCC gibt es mit der optimierung von ?: probleme, bzw wird diese zur Laufzeit und nicht zur Kompilerzeit gemacht. Also, bits zählen mit | oder +, ein ?: kann sehr schnell zu einem if/else ausarten.
Auswertung konstanter Ausdrücke sowieso können muss, zählt diese üblicherweise auch nicht zu den Optimierungen. So macht der GCC (aber wahrscheinlich auch jeder andere C-Compiler) auch bei ausgeschalteter Optimierung aus dem zweiten Beispiel einfach x=20. Das gleiche gilt für die in diesem Thread geposteten
-
Thread
Lokale Variable statt static, aber optimiert. Wie?
Ich glaube, du übertreibst es da mit Optimierung. Ist es wirklich nötig?
/avr-gcc-list/2012-05/msg00044.html
-
Thread
for Schleife in C
von einem Compiler anno 2019 erwarten Warum sollte die Jahreszahl daran etwas ändern? Der AVR-GCC ist von Grund auf relativ, naja, eigenwillig aufgezogen worden. Soweit ich Johann (Lay) mal verstanden habe, muss man ihm daher alle entsprechenden Optimierungen einzeln als Mikrooptimierungen beibringen
Nutzen stellen), werden sich solche Dinge folglich nicht rein zufällig durch eine allgemein kluge Optimierung ergeben. Andere von GCC bediente Architekturen als AVR wiederum haben das Problem sowieso nicht. Bei denen ist das Reduzieren eines "int" auf einen 8-Bit-Typ eher teurer als billiger.
-
Thread
Optimierung mittels typecast
Variablen sind vom Typ uint_8t. Verstehe ich blos den Code grundlegend falsch oder wie bringe ich gcc (Aufruf enthält die Anweisung -Os zur Optimierung) dazu den Code zu optimieren?
lo8(1) 296 008c 8983 std Y+1,r24 297 .L9: Übrigens mit der neuesten gcc-Version und Jörgs Muster-Makefile (mit wenigen Änderungen). Viele Grüße, Stefan
-
Thread
Konstanten-Deklaration
besteht aber die Gefahr, dass so > viele "Test"s angelegt werden, wie der Header Male includet wird. gcc bzw. der Linker erkennen das. Der macht sogar ganz kranke Optimierungen. Beispiel: [C] #include <stdio.h> int main() { const char* p1 = "Hallo Welt"; const char* p2 = "Welt";
wenn kein const davor steht. Bei initialisierten char-Array wie im ersten Beispiel greift die Optimierung nicht, und das trotz const. Damit hast du ein starkes Argument für die Deklaration mit char-Pointern gefunden. Leider scheint diese Optimierung nur in der x86-Version des GCC bzw. der Binutils
-
Thread
Optimizer Bug mit (-O3) bei WinAVR-20090313
kann, -Os ist oft auch am schnellsten. Würd ich auch empfehlen als Grundlage. > Andere Optimierungen neben -Os würden nur Sinn machen, wenn man sie > selektiv anwenden könnte (im Sourcecode auf einzelnen Funktionen). Das geht ab 4.4.0 per [c] #pragma GCC optimize ... __attribute__((__optimize
Peter Dannegger schrieb: > Außerdem arbeiten die Optimierungen mit der Brechstange, d.h. es wird > alles gleich optimiert, egal, ob alle 10 Tage aufgerufen oder alle 10µs. Nicht grundsätzlich, GCC kann Laufzeitergebnisse des Profilers gprof bei der Optimierung
-
Thread
while (1) Äquivalenz
Hermann K. schrieb im Beitrag #6240068: > Bei vielen modernen Compilern wird das bei aktivierter Optimierung > tatsächlich äquivalent sein. Es gibt da die Tail call optimization > (keine Ahnung wie das auf Deutsch heißt). Nicht nur das. Bei mir macht gcc sämtliche Aufrufe komplett weg und ersetzt
W.S. schrieb im Beitrag #6244013: > OK, ich selber benutze den GCC aus derartigen Gründen nicht, aber es > erstaunt mich immer wieder, mit was für eigentümlichen Hakeleien die > GCC-Benutzer sich herumschlagen müssen. Der gcc macht diese Optimierung gerade *NICHT
-
Thread
Optimierungvorgabe einer einzelnen Funktion
5.52.12 Function Specific Option Pragmas: http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas
die Variablen später verwendet? > schaut man sich nun das compilat an stellt man bei keiner optimierung > zunächst einen lästigen epilog von pushs unsd pops... und ein reges > nutzen des stacks. Der GCC generiert hier noch einen frame pointer. Mit -fomit-frame-pointer sieht das schon anders
-
Thread
Fehlerhafter RETURN bei Optimierung
diese ist relativ aufwändig und gibt dann mittels return etwas zurück - mit ausgeschalteter Optimierung geht das alles wunderbar - schalte ich die Optimierung ein, so springt das nach return Programm an eine beliebige ( immer gleiche) Stelle im Programm Simulation in AVR-Studio Chip: ATMEGA
ist relativ aufwändig und > gibt dann mittels return etwas zurück - mit ausgeschalteter > Optimierung geht das alles wunderbar - schalte ich die Optimierung > ein, so springt das nach return Programm an eine beliebige ( immer > gleiche) Stelle im Programm > > Simulation in AVR-Studio >
-
Thread
AVR: Watchdog löst keinen Interrupt aus
Jahrzehnte langer Verwendung von Interrupts - einem der zentralsten Themen in der uC Entwicklung - im avr-gcc immer noch ohne jegliche Warnung zur Weg-Optimierung einer globalen Variablen in einer ISR kommt. Es ist m.E. einfach nicht mehr zeitgemäß, dem Optimierer des avr-gcc da nicht eine entsprechende Regel
langer Verwendung von Interrupts > - einem der zentralsten Themen in der uC Entwicklung - im avr-gcc immer > noch ohne jegliche Warnung zur Weg-Optimierung einer globalen Variablen > in einer ISR kommt. Es ist m.E. einfach nicht mehr zeitgemäß, dem > Optimierer des avr-gcc da nicht eine entsprechende
-
Thread
Atmega8 - DS1621 auslesen ( über TWI[ i2c]) Gesperrt
\ does not exist gcc plug-in: Created directory C:\TempDS1621\default\ gcc plug-in: Error: Object file not found on expected location C:\TempDS1621\default\TempDS1621.elf gcc plug-in: Error: Object file not found on expected
optimierung habe ich.... os3 "schande über mich"...
-
Thread
UART RX Interrupt Problem
sonst benutzt wird, dann darf das weg. Nicht aber die Schleife selbst. Zum Glück kennt sich der XYZ-GCC aber besser mit C* und Optimierung aus, als so manscher Poster hier.
hoffen. Ich bin mir sicher, ich hätte sonst auch einige Probleme mehr. Ein Glück weis der gcc es besser als ich, deshalb überlasse auch ich ihm die Optimierungen.
-
Thread
Ein Bytecode-Interpreter für ATMega644 u.a.
Register-Basis schneidet besser ab als ein nicht-optimierender auf > Stapel-Basis. Ein paar einfache Optimierungen führt auch mein Compiler durch. Sicher macht da GCC viel mehr. Aber ein nicht unerheblicher Teil der Optimierungen von GCC wird wohl der Ausnutzung der Register dienen, was bei einer Stapel-Maschine
werden müssen. Aber wenn ich eine Register-Maschine implementieren würde, könnte ich manche Optimierungen ebenfalls nicht so gut wie GCC durchführen, aber die anderen weiterhin. Ich gehe davon aus, dass sich eine Register-Maschine nur bei einem GCC-Port lohnt (wenn fertige Teile von GCC die Optimierungen
-
Thread
einzelnen Pin invertieren (nicht ganzen Port)
zweite Sequenz ableiten wenn er weiß, dass der entsprechende AVR das kann, aber sowas hat dem AVR-GCC noch niemand beigebracht.
sämtliche Ports nur ganz normale C-Makros, und bei > denen darf der Compiler so etwas nicht. Die Optimierung von memory-mapped IO auf den separaten IO space macht er doch auch, genau wie die Optimierung auf SBI/CBI, wenn diese möglich ist.
-
Thread
Warum wird aus einem right-shift eines uint8_t ein 16-Bit arithm.-shift beim avr-gcc
steht, dass eine Promotion durchgeführt werden muss. Also haben wir hier eine fehlschlagende Optimierung. Da es bei den älteren gcc-Versionen geht, ist es wohl ein Regression.
Doch, ich werde den Bug eintragen ;-) Aber: für den avr-g++ und nicht für den avr-gcc. Denn: Asche auf mein Haupt, ich habe das Beispiel im Language-Mode C++ übersetzt. Übersetzt man es im Language-Mode C, dann findet die Optimierung auch statt. Nun: DAS ist echt merkwürdig.
-
Thread
"weg-"optimierung while(funk(.))
Varianten ein fehlendes volatile erkennen? Für den vorliegenden Fall "Programm läuft nur ohne Optimierung" gibt es doch beim avr-gcc gar nicht so viele mögliche Ursachen. Ein fehlendes "volatile" dürfte zu 99,99999% die Ursache sein. Früher (so zu Zeiten von Turbo-C o.ä.) gab es noch den Effekt, daß (lokale?) Variablen ohne Optimierung mit Null vorbelegt, mit aber undefiniert waren. Das ist aber Geschichte. Fällt jemandem sonst noch was ein? Und die Kenntnis darüber, was der gcc genau bei den einzelnen Optimierungsstufen
-
Thread
Verschiedene Bits effizient auslesen
Die Optimierung steht bereits auf -Oo, leider mit dem selben Ergebnis. mfg
Michael K. schrieb im Beitrag #2309843: > War tatsächlich (wieder) ein Problem mit der > Optimierung. Es gibt tatsächlich weder jetzt noch wieder Probleme mit der Optimierung. Es gibt nur fehlerhaften Code, die der Optimierer dann anders versteht, als der Programmierer. > Selbst mit -O0
-
Thread
USB des STM32 F103C8T6 nutzen
Christopher J. schrieb im Beitrag #5104982: > Das Problem ist doch einfach nur, dass GCC ab -O2 und damit auch bei -Os > die Nop()-Funktion einfach wegoptimiert. Das Problem ist keines da man selektiv die Optimierung mit Pragmas ausschalten kan.
totem Code aufgefüllt wird. Du wirst hier genau diesen Unterschied feststellen: gcc mit -O vs. gcc ohne -O. Lässt Du die Optimierung weg, hast Du in den meisten Fällen genau das, was Du willst. Zu 99% brauchst Du dann zum Beispiel überhaupt keine volatile-Variablen mehr. Denn der
-
Thread
C++ call by reference Frage
ist. Jedoch ist das schon eine Zeit her, und ich habe es tatsächlich nur gerade nochmal für AVR und gcc-9.2 vesrus 10.0 geprüft. Also: kläre uns bitte auf! Wo findet diese Art der Optimierung statt?
Wilhelm M. schrieb im Beitrag #6094682: > Also: kläre uns bitte auf! Wo findet diese Art der Optimierung statt? IPA-Optimierungen in den IPA-Passes, diese können mit -fdump-ipa-xxx gedumpt werden, wobei xxx den Pass bezeichnet. "all" für alle IPA-Passes. http://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html
-
Thread
Optimierungs-Bug mit Registern?
Semantic eines "volatilen Registers" per se irgendwie widersprüchlich. Weil das so ist, wirft der gcc dazu auch eine warning: >warning: optimization may eliminate reads and/or writes to register variables Die gcc-Doku sagt dazu folgendes: >The volatile modifier does not inhibit all optimizations
output parameter. Die GCC Hilfe (oder Google) sollten mit den Details helfen. Kann nicht garantieren dass es funktioniert, ist halt so eine Idee. Frage: Wie verhinderst Du eigentlich, dass der GCC das R2 register von sich
-
Thread
direkter Zugriff auf Low/High Byte von 16bit-Werten
Spezialfall. Das mag sein, aber 8Bit µc gehören nun mal nicht zu den primären Zielplattformen des GCC, und dementsprechend sind derartige Optimierungen doch ein Spezialfall.
Funktionen static deklariert, und sie dann inline übersetzt werden. Wahrscheinlich verhält sich der gcc lediglich bei volatiles so ungünstig beim Low-Byte-Zugriff über Schieben/Maskieren. Ich hatte in meinem künstlichen Beispiel oben mit Absicht volatiles gewählt, um Optimierungen seitens des Compilers
-
Thread
AVR-C-Compiler !?!
auswählen in der Granularität, die dein Prozessortakt erlaubt), dass aber nur eine eingeschaltete Optimierung es erlaubt, dass diese Gleitkommarechnung auch wirklich nur zur Compilezeit erfolgt und aus dem AVR-Code selbst eliminiert wird. Leider kommt das GCC-Plugin vom AVR Studio mit ausgeschalteter
hm ich glaub avrstudio kann gar keine c-compiler integrieren, und hat nur den nicht optimierten gcc von grund auf inklusive.... nun mal ganz einfach ich hab von der firma icboard, den icprog version 2.0, möchte den gcc compiler verwenden (mit optimierung), in einer Software den Code schreiben
-
Thread
CooCox parasitär?
erinnert. Deren 16- und 32-Bit Umgebungen basieren auf GCC, dem sie zusätzliche Optimierungen beigebracht haben, ohne diese als Quellcode zu veröffentlichen. Das haben sie dadurch legal erreicht, indem sie den Compiler zwischendurch quasi aufbrechen, die Optimierungen
16- und 32-Bit > Umgebungen basieren auf GCC, dem sie zusätzliche Optimierungen > beigebracht haben, ohne diese als Quellcode zu veröffentlichen. Quelltexte gibt es schon http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html
-
Thread
Assembler (AVR) Freaks bitte: der schnellste Weg, einen ganzzahligen Wert zu skalieren? Gesperrt
schnell wie in Assembler. Die Frage ist halt immer, wieviel Aufwand man – zusätzlich zu einer C-Optimierung – in eine Assembler-Optimierung stecken möchte, die den Code vielleicht gerade mal um 20% schneller macht.
generieren. Bezüglich Warnungen hingegen ist der Compiler freier in seinen Entscheidungen. >> Der GCC kennt allerdings ein Funktionsattribut (“always_inline”), bei >> dem das Inlining erzwungen wird. > > Mal schauen ob der gcc-avr das auch hat. Der AVR-GCC /ist/ ein GCC. Das Frontend ist grundsätzlich