-
Thread
C Compiler aber welcher?
Erklär doch mal, was Du mit ,,professionell'' meinst. Den Preis? OK, ich verkauf' Dir auch einen GCC für 2 Tausender, wenn Du das haben willst. :-)) Die Optimierung? Da liegt nach allem, was ich gehört und an Code gesehen habe, IAR ganz vorn, dicht gefolgt von GCC. IAR hat ein bißchen Heimvorteil, da er auf Microcontroller zugeschnitten ist, während der GCC ein allgemeiner Compiler ist, der gerade mit Harvard-CPUs bißchen mehr Probleme hat. Ansonsten bietet GCC aber sehr ausgefeilte Optimierungen, die keinen Vergleich mit den ,,kommerziellen'' scheuen
-
Thread
AVR removed in GCC 16 ?
g [/code] Verstehe ich das falsch oder muss jetzt etwas gemacht werden? Grüße https://gcc.gnu.org/gcc-15/changes.html https://gcc.gnu.org/backends.html
#7884522: > der vorgeschlagener Patch mit optimize_function_for_size_p() > zielt auch auf eine Optimierung hin. Also werde ich mich mal weiter > in die Richtung damit beschäftigen. Das Patch wurde abgelehnt weil es nicht die Ursache behebt: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/
-
Thread
Locala variable wird weg optimiziert, Coocox + GCC
unterschiedlich verhalten. Diese function kommt aus die WS2812 lib von UB. Alles anderes functioniert. Ohne optimierung gehts auch. Selbst wenn ich diese variable volatile (local) definiere, wird n noch immer wegoptimiert ?? Diese Function wird nur beim "Init" aufgerufen, so jetzt wird die nicht verwendet. Wie kann
debuggen geht (meist) nicht. Deshalb zeigt Dir der Debugger auch die falsche Stelle an. Nimmst Du die Optimierung raus, wird der Fehler aber nicht mehr auftreten - so wie es UB auf seiner Webseite auch beschreibt. Deshalb: Lass die Optimierung drin, definiere ws2812_dma_status als volatile und alles wird
-
Thread
Ist Usbasp gut?
zugegeben, ich verwende keine PICs, insofern bin ich da sicher nicht auf dem letzten Stand. > die Optimierungen braucht man meist auch > nicht wirklich vor alledem nicht als Anfänger Err, Nein. Falsch. Ganz falsch. Gerade als Anfänger will man einen guten Compiler, der alle Optimierungen macht. Weil
Bei den Cortexen kann ich z.B. meine Entwicklungsumgeben gleich lassen, ich verwende arm-none-eabi-gcc mit Makefiles. Damit kann ich sehr schön Code für LPC und STM32 generieren.
-
Thread
warum braucht Blinkbeispiel 780 byte Flash?
einem Atmega4809 läuft ein LED-Blink-Beispiel. Siehe das zip. Compiliert wurde mit WinAVR auf Basis GCC 8.4.0. Da der Code nicht viel macht stellt sich die Frage wofür die 780 bytes Flash im Einzelnen verbraucht werden.
https://stackoverflow.com/questions/56844328/how-do-i-generate-an-accurate-listing-file-using-avr-gcc
-
Thread
Mehr UB erkennen (C++)
im placement-new aufrufen. Heiko L. schrieb im Beitrag #6119900: > Dass type-punning ( auch mit gcc Erweiterung ) UB ist, liegt wohl eher > an komplexeren Aliasing Effekten Nein. Das Aliasing und die daraus ggf. folgende, falsche Optimierung hat mit dem UB des Type-punning nichts zu tun. Aber
M. schrieb im Beitrag #6120418: > Nein. > Das Aliasing und die daraus ggf. folgende, falsche Optimierung hat mit > dem UB des Type-punning nichts zu tun. Aber: eine Verletzung der > strict-aliasing-rule ist selbst natürlich wieder UB. Nur in theoretischem C++. In gcc funktioniert type-punning
-
Thread
Gesucht: Sehr schnelle hex2bin Routine
Kleiner Nachtrag: Der einfachste Weg bezüglich Assembler wäre, diese Funktion vom GCC mit -O3 compilieren und sich das Ergebnis als Assembler Listing ausgeben zu lassen. Vorrausgesetzt Du verwendest GCC nicht schon als C-Compiler.
Pointers und der Zählvariable, der Registerbreite etc. evt. sogar langsamer. Wobei ich auch diese Optimierung dem Compiler überlassen würde. Den tatsächlichen Unterschied dieser Optimierung wird man nicht merken und nur schwer messen können.
-
Thread
AVR-Studio 5
: > Johann L. schrieb im Beitrag #2085030: >> Stattdessen gammeln einige Bugs seit Jahren im avr-gcc rum. > > Ist halt Open-Source Frickelkram und keine professionelle Software. Es gibt ja auch keine profesionellen (bezahlten) avr-gcc Entwickler. Das ist nicht dem GCC-Projekt anzulasten. Atmel
dass Alf-Egil Bogen und Vegard Wollan damals wohl noch nicht einmal eine Ahnung hatten, dass man GCC für einen Controller als Compiler benutzen kann, falls sie den Namen GCC denn überhaupt kannten. Dass ein GCC mal für den Erfolg ihres "Babys" mit verantwortlich sein könnte, war gewiss außerhalb
-
Thread
Globale Variablen brauchen mehr Speicher als lokale?
alleine überlassen. /register/ und /atuo/ haben heutzutage keinen Effekt mehr, zumindest nicht be gcc. Der weiß was gut ist... Lokale Variablen versucht er in GPRs zu halten. > Beim GCC kann man mit dem ASM-Dingen eine Variable fest an ein > selbstgewähltes Register binden, näheres dazu im Tutorial
Beispiel der Teil mit dem Eeprom Wie auch immer, vielleicht kann der Autor ja eine Anpassung an den gcc und das Jahr 2009 vornehmen
-
Thread
Suche CRC16
spricht nichts gegen eine Optimierung des Codes. Grüße Oliver
kenne zumindest einen (kommerziellen Anwender), der beim Umstieg von Keil MCS51 Compiler auf avr-gcc von einem Sprung um mehr als eine Größenordnung bezüglich der Qualität der Codegenerierung (Optimierung, Bugfreiheit) gesprochen hat... Ich kann es selbst nicht beurteilen, der letzte Keil-Compiler
-
Thread
Code unleserlich schreiben um Zeilen zu sparen.
-Bitter gibt. Ich habe meine eigene Realisierung, die bestimmte Optimierungen bzgl. der intern verwendeten DT macht. > Wobei gcc7.3 komplett C++17 kann, man also nicht wirklich Angst vor > Alpha-Versionen haben muß, wenn man ganz up TO Date sein will, > z.B. mit "
MinGW / CygWin hat gcc-8.1 (C++2a)
-
Thread
GCC Codeoptimierung: Probleme
Hallo, ich bin langsam am Verzweifeln. Vieleicht kann mir ja jemand von euch helfen. Ich habe ein Projekt für einen AtMega644p mit dem AVR Studio 4.19 in cpp geschrieben. Es sind einige Variablen mit "extern" in einer Header Datei deklariert, die ich in mehreren cpp Dateien einbinde. So haben alle Cpp Dateien Zugriff auf diese Variablen. In der Cpp datei mit der main() Funktion sind die Variablen auch implementiert worden. In den Variablen können Werte von 0 bis 255 gespeichert werden. An Hand dieser Werte wird mit einem Timer0 in einer ISR ein PWM Signal auf angeschlossene RGB LED generiert
-
Thread
C Inhalt von 2 Variablen tauschen ohne zwischen speichern
Ich habe gerade etwas Interessantes festgestellt: Der GCC erzeugt bei eingeschalteter Optimierung für alle drei Varianten des folgenden Codes [c] #include <stdint.h> #define METH 1 void sub2(uint8_t a, uint8_t b); void sub1(uint8_t n, uint8
^ x; > -> x = 0 Leider seh ich nicht was Du genau meinst. Vielleicht liegt es auch an der Optimierung des GCC, allerdings glaube ich das (noch) nicht. #include<stdio.h> [c]int main() { int x=25; int y=25; printf("\n x = %i y = %i ", x, y); x ^= y; // x=0 printf("
-
Thread
Geschwindigkeit eines ARM9 mit 180MHz (UDP Checksum-Berechnung)
Mist ;-) (Ich hatte zu dieser Zeit noch nicht die Idee mit dem 64bit Akkumulator, die sowohl von GCC als auch von RVCT sehr effizient umgesetzt wird) Gruß Marcus
gemessen. Dabei ist mir aufgefallen, dass ich bei der letzten Messung vergessen hatte die compiler optimierung wieder einzuschalten. Die genannten 35us bezogen sich also auf ohne cache und ohne compiler optimierung. Mit compiler opt. und cache komme ich jetzt auf etwa 8us für UDP checksum erzeugung.
-
Thread
AVR GCC: Problem mit Variable in Main und ISR
keine ISR's, die sind gewissermaßen ein "Hack". Daher geht bei der automatischen Optimierung gerne mal was verloren, was für ISR's wichtig wäre, nämlich diese Zuweisung. Mit "volatile" wird diese Optimierung verboten. Globale Variablen landen beim GCC übrigens immer im RAM, nicht (nur)
Register-Zuordnungen sind aber tatsächlich ziemlich > unüblich. Kennst du einen Compiler der so etwas macht? Der gcc kann es: https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Global-Reg-Vars.html Ist aber schon ein exotisches Szenario.
-
Thread
Geschwindigkeit IO-Zugriff
Bild. ich habe selbst noch keinen Arm und keine vergleichbare Umgebung zum AVR mit Make, Avrdude, Gcc.
Sprung der Schleife ist halt "langsam". Deine Ergebnisse sind etwas komisch, hast du die Compiler Optimierung an?
-
Thread
Speicherplatzbedarf des Programms
Peter II schrieb im Beitrag #3471873: > welche Version von GCC hast du? Wenn ich bei den Infos zum AVRStudio nach den installierten Packages schaue und GCC Project auswähle, steht da 5.1.0.0. Ist das die Angabe die Du brauchst?
den gcc (avr-gcc oder so) auf der Kommandozeile mit dem Parameter --Version startet. Denn das mit dem Flash geht erst ab 4.7.
-
Thread
Konstante in C verändern möglich? (mit Tricks oder so)
einfach gehts dann wohl doch nicht. Naja, das, was wir hier treiben, ist auch undefined behavior. Der gcc-4.6.3 x86 gibt brav "3" und "1" aus, ob mit oder ohne Optimierung, wenn ich bei meinem Code printfs einfüge. Wichtig: Das es irgendwie "geht", heißt nicht, dass das legaler Code ist!
von Peter II gibt´s dann auch keine Warnung. Ich verwende CodeBlocks unter Linux mit dem Compiler GCC.
-
Thread
AVR Studio 5 meckert sehr viel
Warum ist Atmel so eine ungeheure Bastelbude was das angeht? Ist es nicht. Das ist der benutzte GCC und vermutlich die von der IDE per Default benutzten Optionen. Wenn Du das wirklich abstellen willst: Projektoptionen im AVR Studio und die Doku zu den GCC-Optionen ansehen. Hinweis: Du willst die
counter; ISR: counter++; main: counter = 0; while(counter > 100) { counter = 0; } Ohne Optimierung steht der Code noch im erzeugten Object-File. Aber mit Optimierung (-Os) wird der Code der while Schleife "brutal" gelöscht - weil die Bedingung sonst nie erfüllt worden wäre. Adib.
-
Thread
128 Bit Risc
der doku auch klar wird. z.B. http://www.felixcloutier.com/x86/PADDQ.html Ausserdem ist der AVR-gcc assembler ziemlich ungeeignet für etwa mov edi, [ebp+16] oder umgekehrt. oder mov rax, qword ptr [rbp+rdx*4] Wenn ich wüsste, wie man masm code in gcc einbindet, wäre ich schon weiter.
#4831334: > Dieses gas schau ich mal an. der GAS ist sicherlich der Assembler, der beim g++ bzw. gcc mit dabei ist!
-
Thread
STM32F4 FPU Problem mit EM:Blocks 2.20
Das könnte sein. Optimierung ist aber übrigens aus, damit der GCC nicht auf die Idee kommt was weg zu lassen. Ich habe das ganze auch mal zwischen anderen Codezeilen dazwischen gepackt, mit dem selben Ergebnis. Hier im
ich denke der gcc schmeißt den Code raus. Das hat nicht mal was mit Optimierung zu tun. Da die Variablen nicht gebraucht werden sind sie überflüssig. Versuch die mal als volatile zu deklarieren. Oder mach ein printf
-
Thread
Welche STM32 sind interessant?
Wenn man mit dem GCC ohne Optimierung kompilliert, dann werden sogar die Konstanten in #define 1:1 samt hinterlegter Formel im ausgeführten Programm gerechnet. Schlussendlich kann man damit sauber debuggen und alles sehen
braucht doppelt so viel Code im Flash. Meine Heizungssteuerung braucht 110KB Flash-Code ohne Optimierung und 60KB mit Optimierung. Ausserdem ist das SDIO-Interface erst ab der 256KB Variante drin. Einfach mal die beiden Datenblatter vergleichen (STM32F103x8-B.pdf / STM32F103xC-D-E.pdf) Also für
-
Thread
Optimierung bei AVR-GCC 3.3
Hallo! Ich habe mal ne Frage zur Optimierung von AVR-GCC 3.3 20021209: Es geht dabei um eine Funktion zur Ansteuerung eines LCDs. Dabei wurde immer nur ein Befehl umgeschrieben, die Funktion blieb aber gleich und trotzdem gab's große Codeunterschiede
-
Thread
msp430 GNU Debugging Tools
Code Composer verwendet und bin nun an das Code Size Limit gekommen. Hab dann gestern versucht den GCC mit Eclipse zu installieren. Hat auch wunderbar geklappt. Der gdbproxy findet mein Device und Eclipse/GCC übersetzt mein Programm perfekt. Wenn ich dann Debuggen will, kommt nach kurzer Zeit eine
Funktionen in Unterprogrammen ist der Debugger manchmal überfordert. Ebenso bei eingeschalteter Optimierung....
-
Thread
Welche Ausdrücke werden wann ausgewertet?
Hallo, nur eine kurze Frage zur Auswertung von Ausdrücken in AVR-GCC: Wenn ich nun z.B. folgenden Ausdrück auswerten lasse: » PORTA |= _BV(PORTA1) | _BV(PORTA2); Sollte mein Pin A1 und A2 auf hi gehen (Wenn als Ausgang eingestellt). Intern muss GCC ja im Assember
sagen: Rechne das selber aus und gib dem AVR nur eine Konstante weiter oder macht der das bei Optimierung automatisch? MfG Christian
-
Thread
WIZ750SR von Keil nach Eclipse
geschrieben wurde und es zu groß für die freie Version ist. Nun hätte ich versucht es nach Eclipse und GCC zu konvertieren. Jedoch ohne Erfolg. Was ich bis jetzt gemacht habe: Eclipse und JAVA installiert gcc-arm-none-eabi-10.3 heruntergeladen und im Projekt verlinkt GnuWin32 installiert und den
Habe jetzt noch herausgefunden, dass ich das gcc_W7500.ld Linker Script nicht eingebunden hatte. Jetzt komme ich mit Optimierung auf 90kB gegenüber der 39kB der Originalversion. Einspielen kann ich die Firmware jetzt (per wizconfig), jedoch läuft
-
Thread
C arithmetic promotion Fallstricke
eine Variable herunterzählt bis sie 0 ist. Vorteil: sehr simpel, Nachteil: ungenau und speziell beim GCC offenbar verhaßt und automatisch eliminiert, wenn man nix dagegen tut - jedenfalls nach diversen Beiträgen von GCC-Benutzern. 2. ein dediziert dazu benutzter Timer. Vorteil: recht genau, Nachteil:
Variable > herunterzählt bis sie 0 ist. Vorteil: sehr simpel, Nachteil: ungenau und > speziell beim GCC offenbar verhaßt und automatisch eliminiert, wenn man > nix dagegen tut - jedenfalls nach diversen Beiträgen von GCC-Benutzern. Die ist nicht "verhaßt", sondern fällt halt dem Optimizer zum Opfer
-
Thread
AVR-GCC Bug? if (uint16_t-Typ == 0).
Hallo, ich habe ein Problem mit dem AVR-gcc und seiner Optimierung. Angenommen sei folgender Ausschnitt aus einem C-Code: [c] volatile static uint16_t readBytes; if ( (readBytes) == 0 ) { PORTD = 0x01; // Beispiel } [/c] Ohne irgendeine Optmierung (-Ox weggelassen) erzeugt gcc diesen Code: [avrasm] lds r24, 0x0060 lds r25, 0x0061 sbiw r24, 0x00 breq .+2 rjmp .+244 [/avrasm] der für mich auch ok aussieht. Mit Optimierung (-O, -O2, -Os) erzeugt
-
Thread
Leistungsstarker Microcontroller
SH-Serie (z.B. 7145F50) oder aber auch Coldfire von Freescale (z.B. MFC52xx). Zu beiden gibt es m.E. GCC und beide haben internes RAM, was auch als Cache verwendet werden kann. Der GCC-Code für die SH-Serie ist sehr gut.
Leseoperationen nicht wegoptimiert werden dürfen. Das ist zwar nicht streng ANSI, aber sinnvoll. Der GCC kann das nicht und wirkt deshalb oft unnötiger Weise bevormundent. Besonders ärgerlich beim GCC ist, das kein Cast auf (volatile) möglich ist. D.h. volatile wirkt immer auch auf die Funktion, die
-
Thread
GCC 7.2.0, -Os auf armv7e-m target -> unaligned access
Guten Abend Ich bin heut Abend über einen möglichen Bug in der aktuellen GCC Version 7.2.0 gestolpert. Und zwar erzeugt mir ein Build mit der Optimierung -Os einen "Double Word Store (STRD)" mit einer ungeraden (!%4) Adresse. Die (wichtigen) Flags sind jene hier: [c] arm-none-eabi-g
die ja nicht sein dürfen) einfach wegoptimiert. Wenn Du das verhindern willst, kannst/musst Du bei gcc mit -fno-strict-aliasing arbeiten und damit auf das letzte Quäntchen Optimierung verzichten.
-
Thread
AVR GCC Code Size - Projekt passt nicht mehr auf den Ateml
Hallo, ich habe den neuen AVR-GCC geladen und wollte jetzt mal ein Projekt übersetzen. Der alte GCC (20070122) lieferte .text = 7270 bytes, jetzt wird es 8604 (und passt nicht mehr in den Chip :-( ). Ich habe darauf den Code mal angesehen, hier und auch bei Tante Gugel gesucht und bisher folgende Optimierungen gefunden und durchgeführt: a) Eine Wrapperfunktion um eeprom_read_byte (hat 300 Byte gebracht) b) Zwangweises Inlinen von Portzugriffen (der alte gcc hat das von selber gemacht), wieder 160
-
Thread
schnelle dezimale Division auf AVR & Co.
a *= 2' in 'a <<= 1' übersetzen, je nach dem, was die jeweilige CPU besser kann - aber solche Optimierungen scheint der AVR-GCC nicht zu machen. Also bleibt für die optimale Lösung wohl wirklich nur ein paar Assembler-Routinen ... ... da werd ich mich bei Gelegenheit mal dran machen ... Gruß - Karl
selbst diese Kapriolen brauch man in neuen Compilerversionen wie gesagt nicht mehr zu machen weil avr-gcc sie beherrscht.
-
Thread
IAR kooperiert (?) mit QT
"In v8 verrutschen sogar Breakpoints im IAR." := "Ich bin zu doof die Optimierung auszuschalten."
Die Optimierung is aus ;) Der BP verrutscht nicht beim debuggen. Es verrutscht der BP wenn du in der IDE Codezeilen hinzufügst. Zudem der GCC kann mit leichter Optimierung debugbaren Code erzeugen -> -Og
-
Thread
volatile cast: GCC Bug oder gültige Optimierung
besten man kompiliert das immer nur mit einer Schleife, dann sieht man im Listing was ich meine. Optimierung ist -Os mit GCC 4.7.2 von Launchpad Plattform ist ein STM32 [c] #include <stdint.h> static char m_cRecBuffer[23]; void __attribute__((noinline)) uart_read_async(uint8_t* pa_pcBuffer
Also beim AVR-GCC läßt sich volatile nicht direkt casten. Nur über den Umweg als Pointer: [c] // force access of interrupt variables #define IVAR(x) (*(volatile typeof(x)*)&(x)) uint8_t blub; int main
-
Thread
For-Loop wird nicht richtig ausgeführt
Kommt drauf an, was in der Schleife steht. GCC kann da auch eine ganze Schleife wegoptimieren wenn es den Schleifeninhalt auch ohne Schleife in einem Rutsch ausführen kann. Mal als Beispiel: [c]unsigned int test(unsigned int n) { unsigned
direkt 20 addiert. Wenn du alles wie im Quellcode ausgeführt sehen willst, musst du die Optimierungen ausschalten. Mit Optimierungen wird es auch auf andere Weise unübersichtlich im Debugger, z.B. kann die Reihenfolge der Anweisungen umgestellt werden.
-
Thread
if(a) oder besser if(a == 1)
Optimierungsziels Platz/Zeit. Die Praxis sagt leider manchmal etwas anderes. So kann es bei avr-gcc manchmal nützlich sein, die tabellengestützte Implementierung explizit auszuschliessen.
CLR X nur syntaktischer Zucker für EOR X,X. Dito LSL X für ADD X,X. Das einzige, was nicht von gcc kam, sind meine #-Kommentare
-
Thread
union mit Struktur und Array gleicher Größe?
Kommunikationsanwendungen dann explodiert einem die Programmgröße. Ich habe vor ein paar Jahren dahingehend eine Optimierung machen müssen, das hat bei uns gut 100 kB Code gespart (bei etwa 500kB Codegröße) ...
liegt ja schon der Haken... was passiert wenn du das Programm mal für > x86, mal für AMD64, mal mit GCC, mal mit MSVC kompilierst? Das passiert definitiv nicht. Warum sollte ich ein solches Programm, das nur ein einziges Mal benötigt wird auf unterschiedlichen Architekturen mit unterschiedlichen Optimierungen
-
Thread
GCC Präprozessor macro '__FILE__' abkürzen
Da würd ich eher mich in der gcc-help@gcc.gnu.org Mailing-Liste anmelden und dann dort fragen. http://gcc.gnu.org/lists.html Falls es nicht geht — absehbar — dann ist __FILENAME__ vielleicht eine sinnvolle Erweiterung. Gibt
An gcc bzw. __FILE__ liegt es nicht: [code] leo@cb:/tmp$ cat file.c const char *s = __FILE__; leo@cb:/tmp$ gcc -E file.c # 1 "file.c" # 1 "<command-line>" # 1 "file.c" const char *s = "file.c";
-
Thread
STM32: Bitbanding für Arrays?
Optimierungen eingeschaltet?! Die Division sollte eigentlich wegoptimiert werden.
Stimmt! Läuft! :-) Kotmäßig erheblich kürzer als das maskieren, nur 4 Befehle pro Bitsetzen, ohne Optimierung.
-
Thread
Gibt es einen Formelparser für C (Arduino)
Beitrag #5570538: > TC-EXE ist gerade mal 1234 KB > groß. Kennt es auch all die hochkomplexen Optimierungs-Algorithmen, welche der bei Arduino integrierte GCC unterstützt? Alle aktuellen Sprachstandards (C++17, C11)? Unterstützt die Plattformen AVR und Cortex-M? Liefert Bibliotheken und Beispiele für
Dr. Sommer schrieb im Beitrag #5570544: > Kennt es auch all die hochkomplexen Optimierungs-Algorithmen, welche der > bei Arduino integrierte GCC unterstützt? Alle aktuellen Sprachstandards > (C++17, C11)? Unterstützt die Plattformen AVR und Cortex-M? Liefert > Bibliotheken und Beispiele
-
Thread
RIP AtmelStudio
Wegen Microchip und avr-gcc nochwas. Nachdem Microchip 5000,- Dollar für die avr-gcc Backend Modernisierung gespendet haben, werden die sicherlich "etwas wieder" haben wollen. So schnell wird das also nicht sterben.
(von Keil?) und seitdem kann XC8 bis PIC18 aber eben mit eingeschränkter Optimierung. PIC sind im wesentlich 3 grundverschiedene Architekturen. Wenn man AVR dazu zählt, sogar 4. Johann L. schrieb im Beitrag #6591318: > XC8 für AVR ist doch auch ein avr-gcc? Haben die
-
Thread
Zeitkritisch und Speicherkritisch programmieren in C
Und im Debug-Code ist intensive Optimierung ohnehin wenig hilfreich.
>> Und im Debug-Code ist intensive Optimierung ohnehin wenig hilfreich. > > Das stimmt so nicht. Dann gilt also umgekehrt: In Debug-Code ist Optimierung hilfreich??? Weiter unten schreibst du dann selber: > zumal der optimierte Code
-
Thread
Flash Speicher sparen
#2600618: > Aus dem Bauch heraus können das aber keine 8KB sein. Bist du sicher, > dass du die Optimierung eingeschaltet hast? Optimierung ist eingeschaltet (-Os). Ok, es waren nicht ganz 8kB.
Christian F. schrieb im Beitrag #2600633: > Optimierung ist eingeschaltet (-Os). Ok, es waren nicht ganz 8kB. Also bei mir sind das ohne Optimierung: Program: 6786 bytes (82.8% Full) (.text + .data + .bootloader) Data: 18 bytes (1.8%
-
Thread
WinAVR, AVR Studio und cof-File
mglw. garnichts, ueberspringen von Zeilen kann daran liegen, dass es aufgrund der Compiler-Optimierung keine Debug-Symbole fuer die entsprechende Quellcode-Zeile gibt. Vielleicht auch mal mit dem neuen elf-Parser ausprobieren (neustes WinAVR, neustes AVRStudio) naeheres dazu im wiki (avr-gcc-tutorial
wohl an volatile gewöhnen, ... Nein, um Himmels Willen! Gewöhn' Dich bitte lieber an die Optimierungen und schreibe keinen Code, der am Ende nicht benutzt wird, von dem Du aber erwartest, daß der Compiler ihn umsetzt... Wenn Du die Optimierung ganz oder teilweise (volatile) abschaltest, erzeugst
-
Thread
Zeiger auf Objekt weitergeben
Programmierung und hat noch wenig mit Optimierung zu tun. Warum sollte der OP sich hier mit Mirco-Optimierungen bereits das Design versauen, wenn jeder vernünftige Compiler die nötige Optimierung implementiert? "Premature Pessimism" führt
Solange du nicht irgendwelchen ganz skurrilen Kram benutzt, was der TO sicherlich nicht tut. MSVC, gcc, clang und vergleichbare machen das seit Jahrzehnten. Wie gesagt: die Optimierung ist so offensichtlich und so wichtig und die Designer der Sprache wollen so sehr, dass sich ihre Anwender darauf
-
Thread
Optimierung -Os versus -O1
ein, warum -Os pauschal bevorzugt wird. Kennt >jemand den Grund? Es gibt keinen. Wähle die Optimierung die dir am besten passt.
Unterprogrammen nennt sich "Code Factoring" oder beim Keil C51 "Common Block Subroutines". Der GCC macht kein Code Factoring (und wenn doch, gäbe es ganz sicher eine Option, um es unabhängig von anderen Optimierungen abzuschalten). Es gab zwar vor vielen Jahren einen Anlauf in diese Richtung, die
-
Thread
If Abfrage in C - Frage zu Verkürzung
Michael schrieb im Beitrag #3720531: > Und der gcc ist natürlich - wie so ziemlich jeder Compiler der letzten > zwanzig Jahre - clever genug, das zu optimieren. Die Welt besteht nicht nur aus gcc. Du hast leider keine Ahnung, wie (teilweise
Ausschliesslich für kleine Mikrocontroller bestimmte Compiler sind bei Optimierung nicht annähernd auf dem Standard von GCC. Einerseits weil hinter GCC 3 Jahrzehnte Optimierung für Highend-Maschinen stecken. Andererseits weil zu viel unerwartete Optimierung im Kundenkreis unerwünscht
-
Thread
Bascom - UART / Channel auswählen im Programm
echten" Ausdrücken der Unterschied zu dem Luna? Macht der Compiler überhaupt eine Flussanalyse mit Optimierungen wie z.B. der GCC oder ist das auch nur ein aneinander kopiertes Zeugs?
> Macht der Compiler überhaupt eine Flussanalyse mit Optimierungen > wie z.B. der GCC oder ist das auch nur ein aneinander kopiertes Zeugs? Der kann noch nicht mal Ausdrücke mit mehr als 2 Operanden. Wo bitteschön sollen der/die Entwickler je die Begriffe
-
Thread
TIPP: Atxmega DFU-Bootloader auf eigenen "Boot-Pin" verbiegen (direkt im Hex-File)
nachdem ich vergeblich versucht habe den DFU-Bootloader so abzuspecken, dass man ihn auch mit AVR-GCC kompilieren kann damit er in den 4KB Bootbereich des Xmega32A4U passt (weniger als 6K schafft man offensichtlich mit avr-gcc nicht), habe ich einen anderen Weg gefunden den Boot-Port für meine Ansprüche
Die Optimierungen habe ich eingeschaltet. Siehe Anhang.
-
Thread
optimiert der Compiler so etwas weg?
Sowas wirft GCC auch ganz ohne eingeschaltete Optimierung raus.
Entschuldige bitte, ich war etwas zu schnell mit meinen Gedanken. Du hast natürlich Recht. Denn der GCC bekommt das ja mit eingesetzter Konstante (nach dem Präprozessor) geliefert. Damit ist das Beispiel mit FCPU das gleiche wie if (0) . Warum gibts denn da keine Warnung vom GCC? ;-)