-
Thread
GCC Optimierung?
Viele Optimierungen von GCC gehen wie die Sprache C selbst davon aus, dass die Wortbreite der zugrunde liegenden Maschine für "int" und für Pointer ausreicht. AVR ist die m.W. einzige Architektur mit offizieller GCC
noch erst ein "Hallo Wach" nehmen. Also bei dem Vergleich der Codegröße der gesamten Schleife ist der GCC doch schlechter. Bei GCC mit -Os aber allerdings nicht. Sorry für die Verwirrung. Hier der Auszug vom GCC über die gesamte Schleife [avrasm] ; Optimierung -O3 while(size--) { b4: 2f 3f
-
Thread
GCC Optimierung
Leute, ich habe nachfolgende komplexe C Funktion und ein par Fragen in grundsätzlicher Art zur Optimierung. In der Funktion deklariere ich einige Variablen gleich am Anfang der Funktion und auch später bei Bedarf. Die Frage ist ob es besser für die GCC Optimierungs Möglichkeiten ist diese Variablen
dieser Struktur habe ich schon als Kopie in lokale Variablen genommen. Die Frage ist ob es für die Optimierung des GCC nun besser ist alle notwendigen Member ebenfalls in lokale Variablen zu übernehmen ? Es würde ja dann ein sehr großer Registerdruck für den GCC entstehen und dadurch eventuell gerade in
-
Thread
AVR-GCC: Optimierung?
Hallo zusammen, ich schreibe gerade an einem kleinen Ladecontroller und bin dabei auf eine Frage gestoßen, die ich gern im Vorfeld klären möchte (also bevor ich den Code laufen lasse). Es geht um folgenden Codeausschnitt: [c] while ( (_batteryVoltageCB() <= _vTerminateCharge) && (_batteryCurrentCB() < _iChargeMax) && (_pwmValue < 255) ) _setChargerPWM(++(_pwmValue)); [/c] Beabsichtigt ist, dass die Funktionen ...CB() bei jedem Schleifendurchlauf ausgeführt werden! Geht das so, oder muss ich da "vorsorglich" eingreifen, damit der Compiler nicht "denkt", dass ein Aufruf für die
-
Thread
Problem mit GCC-Optimierung
gebraucht, bis ich darauf gekommen wäre. Nochmal vielen Dank! @ A.K. Ich wollte das Problem nicht dem GCC unterstellen, für mich war halt nur ein Zusammenhang zur Optimierung erkennbar.
Andreas schrieb im Beitrag #3429328: > @ A.K. Ich wollte das Problem nicht dem GCC unterstellen, für mich war > halt nur ein Zusammenhang zur Optimierung erkennbar. Hatte ich auch nicht so aufgefasst. Unlängst war hier allerdings jemand zugange, der sich über ähnliche "Mängel
-
Thread
AVR-GCC Optimierungen
Hallo, Es gibt ja die Optimierungen -O0, -O1, -O2, -O3, -Os. Dabei bedeutet -O0 ja keine Optimierung. -Os steht für Optimierung der Codegröße. Sind -O1 bis -O3 dann nur 3 Abstufungen von Optimierungen die nicht auf Codegröße
und 4 Bytes mehr. Die Optimierungen der Laufzeit haben oft nur lächerlich geringe Auswirkungen gegenüber -Os (<1%). Ich habe noch kein Programm gesehen, was von den Laufzeitoptimierungen -O1..3 merkbar profitiert. Manchmal erzeugen
-
Thread
[F] GCC Optimierung
Unten ein Codeauszug, bei dem ich meine, dass der GCC (avr-gcc (WinAVR 20100110) 4.3.3) Optimierungen (Stufe S(ize)) nicht oder nicht vollständig durchführt. *1 Da in R24 der Wert schon steht, braucht er nicht extra gelesen werden. *2 SUBI setz
-
Thread
GCC Optimierungs problem!
im Forum und versuch mal mein Glück, weil mit meinem Latein bin ich definitiv am Ende. Und da ich GCC nicht aufgeben will mein Gesuch hier an alle besser Erfahrenen... ich verwende WINAVR mit comilper avr-gcc (GCC) 4.1.2 (WinAVR 20070525) sobald ich die Optimierungs option Os einschalte funktioniert
CPPFLAGS += $(CSTANDARD) also über hilfe jeglicher art wäre ich echt dankbar, weil sonst müsste ich GCC wirklich aufgeben... sniff danke mal und liebe grüsse
-
Thread
GCC Optimierung killt Funktion
Hallo, ich werde noch wahnsinnig mit dem GCC :-( Jedesmal wenn ich Hardwarefunktionen codieren, die einwandfrei laufen OHNE OPTIMIERUNG und die dann einschalte kommt es zu seltsamen Dingen, meist einfach "funktioniert nicht mehr" bis "Hard Fault
langsamen Code erfreuen, weil die Optimierung da ja scheinbar schlechter ist, als diejenige des GCC.
-
Thread
ARM GCC Optimierung auf Variablen
mit "der Compiler kann eventuell eine Optimierung an Variablen vornehmen (z.B. caching)". Hinsichtlich Optimierung gibt es zahlreiche Optionen: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html Aber Beispiele bezogen auf das Caching
das extern beobachtbare Verhalten dasselbe bleibt. Rein praktisch gesehen wird GCC bei -O0 keine solchen Optimierungen durchführen, aber garantiert ist es nicht. Wenn Du den Sinn von volatile wirklich verstanden hättest, kämest Du gar nicht erst auf so eine Frage.
-
Thread
GCC-Optimierungen bei -ffast-math
Lukas K. schrieb im Beitrag #4305255: > Was für eine > anscheinend doch sehr effiziente Optimierung hat hier zugeschlagen? An GCC wird seit fast 30 Jahren gearbeitet. Man muss davon ausgehen, dass nicht mal die GCC-Maintainer über jedes Detail Bescheid wissen. Bei solchen Details ist die einzige Dokumentation häufig der Source-Code. https://gcc.gnu.org/wiki/FloatingPointMath enthält ein paar grundlegende Erklärungen, aber nicht die exakten Optimierungs-Algorithmen die verwendet werden. Wenn ich es richtig verstehe sind nicht nur der Compiler
-
Thread
GCC Optimierung, unterschiedliche Codelänge
Mit ein und demselben Sourcecode wird je nach Controller unterschiedlich langer Binärcode generiert. AVR-Studio 4.18, Build 716, Optimierung -0s Atmega 168p 1022 Bytes Atmega 644p 1006 Bytes Anders herum wäre es das erwartete Ergebnis, da der 644 mehr Interrupts hat. Aber so? Ohne Optimierung betragen die Codelängen (168:644) 4938 : 4940 Was zwar tendenziell besser passt, aber der 644 hat 5 Interrupts mehr als der 168, sodaß die Interruptvektortabelle 20 Bytes länger ist. Warum entsteht bei im Grunde gleichen Controllern unterschiedlicher Code? Hierbei handelt es sich um einen Bootloader
-
Thread
gcc Optimierung nicht ganz nachvollziehbar
generieren in denen ich verschiedene Funktionen aufrufen kann. Soweit so gut. Stelle ich die Optimierung des gcc ab (-o0), dann funktioniert der Code auch wie gewünscht. Aktiviere ich die Optimierung läuft der Code bei o2, o3 und os nicht mehr wie gewünscht, was für mich nicht ganz verständlich ist
sollte mal ins Forensystem was einbauen, so dass man schon beim Tippen der Begriffe "Compiler" und "Optimierung" automatisch bei einer passenden Erklärung von "volatile" landet. ;-)
-
Thread
WINAVR GCC Optimierungs Problem
im Forum und versuch mal mein Glück, weil mit meinem Latein bin ich definitiv am Ende. Und da ich GCC nicht aufgeben will mein Gesuch hier an alle besser Erfahrenen... ich verwende WINAVR mit comilper avr-gcc (GCC) 4.1.2 (WinAVR 20070525) sobald ich die Optimierungs option Os einschalte funktioniert
CPPFLAGS += $(CSTANDARD) also über hilfe jeglicher art wäre ich echt dankbar, weil sonst müsste ich GCC wirklich aufgeben... sniff danke mal
-
Thread
avr-gcc Optimierung und volatile
Hi! Ich habe da mal eine Frage zu den "Registerdeklarationen": Ist es nicht so, daß alle Register per deklaration für den Compiler flüchtig (volatile) sind? Würde diese Voraussetzung das "asm volatile ("nop"::);" in einer warte-while-schleife (was'n Wort :) obsolet machen? >#include <inttypes.h> >#include <avr/interrupt.h> > >void my_eeprom_write_byte(uint16_t *addr, uint8_t val) >{ > cli(); /* disable all ints */ > /* Wait for completion of previous write */ > while(EECR & (1<<EEWE)) asm volatile ("nop"::); > /* Set up address and Data Registers */ > EEAR = *addr; > EEDR
-
Thread
Wie External SRAM mit GCC Optimierung ansteuern?
Reihenfolge so genau festlegen? In Assembler. In C geht das wohl per Sprach-Definition gar nicht, aber der gcc hält sich zumindest bei Zugriffen auf volatile-Variablen an die vorgegebene Reihenfolge. >2. Muss man sowas inlinen? Nein. 3. Kann man die Optimierung für bestimmte Programmteile abschalten?
Da gibt er mit und ohne Optimierung nur die unteren 8 Bits aus, und der Compiler dazu eine Warnung. Oliver
-
Thread
avr-gcc: Optimierung von indirekten Funktionsaufrufen
Hallo Forum, Mir ist beim schreiben einer Library ein mögliches Optimierungsproblem aufgefallen: Testcode: [c] typedef unsigned char uint8_t; extern uint8_t (*fp)(uint8_t); void foo(uint8_t (*param1)(uint8_t)) { fp = param1; } void bar(void) { fp(0xFF); fp(0xFF); } [/c] kompiliert mit avr-gcc -S -Os -Wall -mmcu=avr6 test_fp.c zu [c] foo: sts fp+1,r25 sts fp,r24 ret bar: lds r30,fp lds r31,fp+1 ldi r24,lo8(-1) eicall lds r30,fp lds r31,fp+1 ldi r24,lo8(-1) eijmp .ident "GCC: (GNU) 5.3.1 20160106
-
Thread
avr-gcc: Optimierung: mehrere RCALLs erzeugt
lediglich dazu, 6 Bytes Platz auf dem Stack für dein lokales Array zu schaffen. Das dient der Optimierung der Codegröße, da es das mit lediglich zwei Instruktionen schafft. Alle anderen Möglichkeiten wären größer.
geschickterweise erwähnt, dass sich um so einen handelt: N. G. schrieb im Beitrag #4840491: > wird mit avr-gcc -s -Os -mmcu=avr6 Ich hatte anfangs auch gedacht, dass da doch eigentlich noch 2 Bytes fehlen, und dann hab ich obige Zeile gesehen.
-
Thread
AVR-gcc. Optimierung ignoriert Vergleich mit volatile Variable
zurück zum if-Vergleich. Bei der Optimierung -O0 ist alles OK, bei -O2 funktioniert es auch nicht. Die Deklaration des bt_rx_rdptr Zeigers als volatile bringt keine Änderung (ist auch nicht sinnvoll, da der USART-Rx-Interrupt sie auch
vorherige Zeichen aus dem Ringpuffer. Ich finde keinen Fehler im C-Code und vermute ein Bug im gcc. Kann ich als Workaround die Optimierung für diesen Bereich gezielt abschalten ? AVR-GCC-Version : 4.4.3 , avr-libc 1.6.8 Zielprozessor : ATMega128A Host: Ubuntu-Linux 8.04 Gruesse aus
-
Thread
C - GCC Optimierung ändert float-multiplikation auf integer mult
Hallo, eine simple Funktion auf Eclipse / DAVE4 / Infineon XMC / ARM4 Core / GCC [c] static int16_t PhysicalToDigits(float physical, float factor) { return (int16_t)(physical * factor); } [/c] funktioniert wie erwartet im Debug Mode. Sobald die Optimierung -O oder -O1
#7267241: > https://hightec-rt.com/en/products/development-platform.html > > Basierend alle auf dem GCC. GCC (alt) oder Clang/LLVM (neu).
-
Thread
avr-gcc: Optimierung von Addition uint8_t + int8_t
Hallo, mir ist gerade aufgefallen, dass avr-g++ (im Gegensatz zu avr-gcc) folgendes nicht durchoptimiert: [c] volatile signed char s; volatile unsigned char i; int main() { s += i; } [/c] avr-g++ macht daraus: [pre] volatile signed char s; volatile unsigned char i; int main() { s += i; 7c: 80 91 60 00 lds r24, 0x0060 ; 0x800060 <_edata> 80: 20 91 61 00 lds r18, 0x0061 ; 0x800061 <s> 84: 90 e0 ldi r25, 0x00 ; 0 86: 82 0f add r24, r18 88: 91 1d adc r25, r1 8a: 27 fd sbrc r18, 7 8c: 9a 95 dec r25
-
Thread
gcc und Optimierung
Samuel K. schrieb im Beitrag #2395677: > Ich weiß, aber hier ist nichts anderes sinnvoll. Gcc hat keine > Bitverschiebungsfunktion. Bitte?!? Schonmal "<<" und ">>" probiert? M.e. gibt es keinen Grund, Assembler zu verwenden, außer es kommt wirklich auf allerhöchste Optimierung bei der
M.e. gibt es keinen Grund, Assembler zu verwenden, außer es kommt > wirklich auf allerhöchste Optimierung bei der Geschwindigkeit an. gcc > optimiert so hervorragend, dass Assembler im Grunde überflüssig ist. Wenn man bits kopieren möchte (verschieben war ein schlechter Ausdruck), sind die HW-Instructions
-
Thread
"Optimierung" bei Multiplikation
Da es in der Mehrzahl der Fälle nicht so dolle ist, wäre es wohl das kleinere Übel, auf diese "optimierung" ganz zu verzichten - da es ja scheinbar seit Feb nicht möglich ist, das zu beheben. Da gibt auch viele Bugs, die wesentlich älter sind. Nö.. stattdessen werden immer neue GCC Version 4.x.x übernommen
Multiplikation will mir aber ganz und garnicht einleuchten. Ist das nie getestet worden, bevor diese "optimierung" in den avr-gcc aufgenommen wurde ? Oder hat das mal ein einer alten Version funktioniert ? Wobei, das wäre nur noch ein Argument mehr, auf diese Versionitis zu verzichten, und zu forken.
-
Thread
Schwerer Bug in AVR-GCC 4.1.1 Gesperrt
ASM-Listing kontrolliert werden !". Ich konnte nicht herausfinden, was für diese speziellen Optimierung von GCC verantwortlich ist, die bereits bei -O Optimierung stattfindet. Man kann die Codeerzeugung von GCC selbst debuggen (z.B. -dB Option u.a.) und sich Textdateien ausgeben lassen, die zeigen
GCC besseren Code bewirken, bleibt abzuwarten. Ich für meinen Teil bin da eher skeptisch und verwende weiterhin die stabile 3.4.6, die dichten Code erzeugt (dichter als 4.x). Optimierungen sind nämlich
-
Thread
Ineffiziente Berechnung von AVR-GCC Gesperrt
Hallo Compilerexperten, ich bin im Zuge der Optimierung des Codes eines AVR-GCC-Projekts auf ein mir nicht erklärliches Verhalten des Compilers gestoßen, zu welchem ich gerne Euren Rat einholen möchte. Um das Problem einfach beschreiben zu können, habe
selbst ausrechnen anhand des besseren Assembler). Daher halte ich das nicht für eine Mikro-Optimierung. Ob und wann die jetzt mainline geht, weiß ich nicht. Ist mir aber auch egal, da ich meinen avr-gcc eh selbst erzeuge.
-
Thread
Optimiert der Compiler Division durch 2^n wirklich?
weiteres machbar. Nur hatte offenbar bisher noch niemand genug Leidensdruck um eine derartige Optimierung in den gcc einzubauen.
weiteres machbar. > Nur hatte offenbar bisher noch niemand genug Leidensdruck um eine > derartige Optimierung in den gcc einzubauen. Für "int" ist sie ja drin und funktioniert auch. In -O1.
-
Thread
gcc11 könnte das avr Backend verlieren
AVR-Backends, es ist noch nicht einmal möglich, im AVR-Backend drumrum zu hacken. So ziemlich alle Optimierungen, die halbwegs sinnvoll im AVR-Backend implementierbar sind, sind dort implementiert. Außer http://gcc.gnu.org/PR84211
Frage, bei welcher Optimierungsstufe das auftritt. Veit D. schrieb im Beitrag #6148278: > O3 Optimierung ist erledigt. Ich halte beim GCC eine (globale) Optimierung mit O3 grundsätzlich für fraglich. Das gilt meiner Meinung nach insbesondere für Mikrocontroller, wo eben mal NOP-Schleifen ausgerollt
-
Thread
GCC und Optimierung
Hallo, ich hab hier auf meinem Linux einen GCC4.1.2 und möchte damit Code für meinen PC kompilieren. Bei den Flags ist mit -O2 Optimierung eingeschaltet. Außerdem -g für's Debuggen. Als Nebeneffekt verwendet GCC dann ab -O1 außerdem die Option
fomit-frame-pointer", die meinen GDB beim Debuggen im Single-Step durcheinander bringt. Weiß jemand, ob man GCC dazu zwingen kann Frame-Pointer anzulegen ohne gleich die ganze Code-Optimierung deaktivieren zu müssen? Mfg Thomas Pototschnig
-
Thread
ATMega - Volatile Funktionen im Interrupt OK?
. Und möglicherweise hat sich auch noch keiner drum gekümmert, weil jeder, den die fehlende Optimierung an dieser Stelle stört, die triviale, naheliegende Änderung an seinem Code macht, die den Vergleich auf int-Ebene ausführt. Wenn du /wiklich/ wissen willst, warum die Optimierung nicht in GCC
und Vergleiche der Fall. > ist denn eine nicht vorhanden optimierung ein Bug? Müsste man das nicht > als Feature Request einreichen? Die Bug-Nummern in GCC bzw. binutils bugzilla beginnen auf PR, kurz für "Problem Report". Dazu zählen auch die "missed-optimization
-
Thread
Allgemeine Fragen zu Eigenbau-libc
festgestellt, dass ich bis jetzt immer eine schnellere und kleinere > Variante von Grundfunktionen als GCC "heraus gezaubert" habe. Zu > mindestens OHNE Optimierungsoptionen von GCC. Das ist bei vielen Standardfunktionen auch mit eingeschalteten Optimierungen nicht schwierig. Der C Compiler weiss nicht
die Quellen angehängt. Einfach mit... [code] gcc -I ./ -o bench bench.c cycle.S memcpy_c.c memcpy_a.S [/code] ...compilieren. Ergebnis auf meinem System OHNE Optimierung: [code] glibc (system) memcpy(): Min: 589 Max: 29830 Avg: 2119 C:
-
Thread
AVR Inline Optimierung kaputt?
Da gibts einen weiteren Link auf einen guten Blog: https://www.airs.com/blog/archives/120 Der gcc macht diese Optimierungen schon seit 20 Jahren.
Ich habe jetzt mal versucht, das verhalten auf dem PC (gcc 10.1.0, mingw, Windows) nachzuvollziehen. Die UB-Optimierung habe ich dort nicht hinbekommen. Das einzige, was mir gelungen ist, ist eine Warnung in folgendem Programm: [c] #include <iostream>
-
Thread
Alternativen zu C, C++ auf ARM cortex M?
Mit der Vorgabe keiner Statement-übergreifender Optimierung landet man ähnlich. Was man nicht falsch machen kann, das macht man auch nicht falsch. Ob es dann allerdings überhaupt Sinn ergibt, hochkomplexe Compiler wie GCC oder LLVM als Grundlage zu nehmen
gut benötigen kann. Das Inline-ASM vom GCC ist enorm mächtig, gerade weil es sich nicht nur dazu eignet, ASM Funktionen zu schreiben, sondern sich recht weitgehend in die Optimierung des Compilers integriert und man oft nur sehr wenig ASM braucht
-
Thread
C - Function / Define / Macro / Obfuscated C ?
weniger gut dokumentierten Optionen ist es > denn nun? > https://www-user.tu-chemnitz.de/~hmai/gcc/Ausarbeitung_1/options.html Direkt an der Quelle wirds genauer als in Chemnitz: https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Optimize-Options.html#Optimize-Options
Sicherheit nicht. Woher nimmst du diese Weißheit? Andreas V. schrieb im Beitrag #5718011: > Bei Optimierung auf Codegröße(/O1) oder Schnelligkeit (/O2) O1 und O2 ist beides auf Geschwindigkeit. Os ist Codegröße, beim GCC jedenfalls.
-
Thread
ARM-GCC: No strict alias
Michael schrieb im Beitrag #6764055: > Gerade wenn es um Optimierungen usw. geht, sollte der vorhandene Code, > wie Linux usw., als Grundlage herhalten und sicherstellen, dass dieser > damit funktioniert. STOP! Diese Diskussion ("Hat sich der GCC an den Linix-Kernel
die Reputation der Sprache. (*) [c] Source File mit ca. 170000 Zeilen nach Präprozessor, Optimierung -O1: WinDDK cl 110 ms VS 2019 cl 160 ms clang-cl v11 250 ms Mingw gcc v10 280 ms [/c]
-
Thread
sei nicht schlauer als der Compiler?
Wilhelm M. schrieb im Beitrag #5059512: > Der avr-gcc machts in diesem Beispiel jedenfalls nicht. In der Sprache ist "int" als ein Basistyp der Zielmaschine definiert, also als Wortbreite dieser Maschine. Allgemeine Optimierungen des Compilers dürfen
A. K. schrieb im Beitrag #5059523: > Wilhelm M. schrieb im Beitrag #5059512: >> Der avr-gcc machts in diesem Beispiel jedenfalls nicht. > > In der Sprache ist "int" als ein Basistyp der Zielmaschine definiert, > also als Wortbreite dieser Maschine. Allgemeine Optimierungen des > Compilers
-
Thread
swap in C Vs. Asm
man ebenfalls meint klüger zu sein als der Compiler ist ja auch nicht tot zu bekommen. Und diese Optimierung ist schon wesentlich länger in dem AVR-GCC enthalten.
Ein Problem bei der Optimierung von Mul/Div zu Shift ist, dass der mit Shifts erzeugte Code länger sein kann als Mul/Div-Befehle oder der Aufruf einer Laufzeitfunktion. Und avr-gcc daher in seiner üblicherweise verwendeten -Os
-
Thread
WINAVR Portpins setzen
Peter schrieb im Beitrag #2126567: > Mir wäre es auch lieber der GCC würde das auch ohne Optimierung machen. Ohne Optimierung ist nur für Programme möglich, wo die Ausführungszeit völlig egal ist. Auch andere Compiler werden da nicht besser sein. In der Regel ist
. Leider ist das oft keine Optimierung und bewirkt sogar > etwas mehr Code. Das Umsortieren führt aber nicht dazu, daß der Code mit Optimierung nicht mehr läuft. Es mag ein paar ganz bestimmte Spezialfälle geben, bei denen der gcc
-
Thread
GCC Optimierer zerlegt Block (compound-statement)
, dass du es blöd findest. Nur ist GCC nicht für Mikrocontroller entworfen worden und diese Optimierungen sind allgemeiner natur, damit erwischt es jede Maschine. Wobei schon allerlei Optimierungen im AVR Backend abgeschaltet werden,
wir bei der Programmierung von MCUs öfter mal die Takte zählen und Interrupts fein steuern. Die Optimierung des GCC für einen PC, Mainframe oder Supercomputer ist sehr gut, aber bei zeitkritischen Programmen auf einer MCU ist die Optimierung mach mal hinderlich. Außerdem ist die 8 Bit AVR Architektur
-
Thread
Warum Keil (oder andere unfreie Compiler) statt SDCC?
selber sieht derlei nicht vor. Prinzipiell dürfte ein C-Compiler also auch bei abgeschalteten Optimierungen solche Leerschleifen rauswerfen. Wenn der Code mit Optimierungen kaputt ist, dann ist es es nämlich auch ohne Optimierungen immer noch.
Und auch der GCC unterlässt mit -O0 nicht alle Optimierungen Sonst müsste am AVR eine Schleife [c] while(true) PINB |= (1<<1); [/c] eine andere Frequenz ausgeben als [c] while(true) PINB |= (1<<7); [/c
-
Thread
Kommerzieller AVR C Compiler
viel davon ein so mächtiges System wie GCC auf einen AVR loszulassen. Alleine das die Optimierungen des GCC bei AVRs öfters mal nach hinten losgehen, ist ein recht deutliches Indiz dafür, das ein AVR nicht dem Hauptentwicklungsziel des GCC entspricht
AVR-GCC für ATTiny/8bit macht bei den Optimierungen viel Mist. Würde ich nur benutzen, wenn Du auf Optimierungen verzichten kannst. So der Stand mit Toolchain 2010-01-10. Zu anderen Targets/Versionen kann
-
Thread
CH32V003, float wirklich langsam?
(und im Anhang als Textdatei): [code] Benchmark Ergebnisse CH32V003 Compiler: riscv-none-elf-gcc Version 14.2.0 / ch32v003fun Framework | Zeit [s] | Optimierung | int8 | int16 | int32 | float | Codegroesse |
INT16-Test, korrektes Ergebnis: [code] Benchmark Ergebnisse CH32V003 Compiler: riscv-none-elf-gcc Version 14.2.0 / ch32v003fun Framework | Zeit [s] | Optimierung | int8 | int16 | int32 | float | Codegroesse | ------------------
-
Thread
Kann man denn jetz das hi- und low-byte eines uint16_t effizient lesen in c?
AVR-GCC-4.7.2 mit -Os optimierung... liegt wohl wieder am volatile dass GCC da so nen mist baut
Leo B. schrieb im Beitrag #2962266: > Ich nutze den AVR-GCC-4.7.2 mit -Os optimierung... liegt wohl wieder am > volatile dass GCC da so nen mist baut Bist du sicher, daß die beiden Varianten, die du vergleichst, nicht Äpfel und Birnen sind? Sind beide
-
Thread
An alle Logiker
Müller (Gast) >Habt ihr eine Idee, wie man das vereinfachen könnte, um es dem Compiler >(avr-gcc) einfacher zu machen? Warum? Ist es zu komplex? Ist die Ausführungszeit zu groß? https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung > Ich ziele auf
ad absurdum führtst! Ich verweise nochmals auf https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung Mit der Betonung auf "Verfrühte Optimierung ist die Wurzel allen Übels"
-
Thread
AVR GCC Optimizer Level in C-Programm abfragen
hast nachgemessen, ob O2 tatsächlich schneller ist als Os? Denn ich bezweifele das ganz stark. gcc ist ein toller Compiler, der ist aber primär nicht für AVRs gemacht. Dessen Optimierungen sind vor allem für die Hauptplattformen optimiert. Und selbst auf Intels oder Arms gilt immer noch : messen
Sommer schrieb im Beitrag #5165738: > Korrekter Code funktioniert immer unabhängig von > der Optimierung. Denkste. Wäre schön, ist aber wohl nicht generell so: Insbesondere habe ich einen Codeabschnitt gehabt, den der Optimizer kaputt-optimiert hat. Den musste ich einklammern in #pragma GCC
-
Thread
Was ein C++-"Guru" so ueber Geschwindigkeit erzaehlt.
Wer lesen kann:-) - Wenn man sich in der x86 Welt mal ansieht welche Unterschiede zwischen dem gcc und dem icc möglich sind. Da könnte einem schon der Verdacht kommen das beim Thema Optimierung zumindest beim gcc noch einiges an Luft für Verbesserungen vorhanden ist.
Irgendwer schrieb im Beitrag #3901199: > kommen das beim Thema Optimierung zumindest beim gcc noch einiges an > Luft für Verbesserungen vorhanden ist. Sicher. Ich würde mich aber doch etwas wundern, wenn der ICC bei der Optimierung des anfänglichen Codes automatisch
-
Thread
avr-gcc 4.7 I/O-Zugriffe
/Optimierungen im AVR-Teil dürfte das > absolut garnix zu tun haben, weil es dort von 4.3 bis 4.6 > einschliesslich de facto überhaupt keine Ändrungen gab. Die Teile von GCC, die den AVR betreffen, sind
> "maschinenabhängig" reichen. Dadurch ergeben sich natürlich viele > Möglichkeiten. Ist beim GCC auch so, siehe oben. In aller Regel sind die Optimierungs-Patzer darauf zurückzuführen, daß GCC ein Multi-Pass-Compiler ist. Beispiel: In einer Schleife wird eine Invariante gefunden. Ist es günstig
-
Thread
einfache Code-Optimierungen
Peter II schrieb im Beitrag #4027092: >> Der Compiler ist eine angepasste Version vom GCC. > > müsste er dann nicht frei sein? also die Änderung mit veröffentlich > werden? Jene Optimierungen, die GCC von sich aus durchführt, stehen als Quellcode zur Verfügung. Ich hatte den Compiler
die üblichen GCC Optimierungen inklusive -O2 und -O3 voll zur Verfügung stehen, halte ich für wahrscheinlich. Aber auch -O1 sollte schon völlig ausreichen.
-
Thread
GCC optimiert 32bit Bitoperationen schlecht/gar nicht?
in dieser Routine; mehr als C und AVR-Assembler braucht man dafür nicht zu beherrschen. http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/avr/avr.c?revision=221316&view=markup#l6076 Z.B. gibt "unsigned long >> 27" eine Schleife aus. Bei Optimierung auf Speed ist das echt übel. Und selbst für Size
beschrieben sind? Aaaaaaah! Jetzt ist der Groschen gefallen! Ich bin irgendwie davon ausgegangen, GCC würde immer beides betrachten (Dauer und größe) und abhängig von der Optimierung eins als primäres und das andere als sekundäres Sortierkriterium verwenden (z.B. optimierung auf Size: kürzsesten Code
-
Thread
C Optimierung ISR
Jörg W. schrieb im Beitrag #4346758: > GCC 4.7.2 rettet R15 … R31 (und natürlich R0/R1). > GCC 4.9.3 rettet R14 … R31 und R0/R1, generiert aber insgesamt 10 ... und die Register werden auch alle verwendet. (Wenn mir nicht eins durch die
bitte das Wesentlich nicht aus den Augen verlieren. https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
-
Thread
AVR128, CCP und Optimierung
werden. Das dich das überrascht zeigt, daß du anscheinend das allerstemal mit einem AVR und dem gcc dazu zu tun hast. Diese 4-Zyklen-Absicherung gibts bei allen AVRs für verschiedene Einstellungen, und das hat der gcc noch nie ohne Optimierung geschafft. Über das wieso, weshalb, warum zu sinnieren
> > Das dich das überrascht zeigt, daß du anscheinend das allerstemal mit > einem AVR und dem gcc dazu zu tun hast. Beileibe nicht. > Diese 4-Zyklen-Absicherung gibts bei allen AVRs für verschiedene > Einstellungen, und das hat der gcc noch nie ohne Optimierung geschafft. Nicht übertreiben
-
Thread
Böse Falle Boolean
static und durch die Optimierung ist der TE in die Irre geleitet worden.
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html -Og Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the