-
Thread
OHNE(!) Optimierung gehts nichts mehr
Es gibt C-Konstruktionen im GCC, die ohne Optimierung einfach nicht laufen. Beispielsweise inb() und outb() und Konsorten unter Linux.
Ich kann mir auch nict vorstellen, das Inline oder Makro nicht gehen soll wenn man keine Optimierung eingeschaltet hat. Normalerweise debuggt man ja code ohne Optimierung und dabei ist mir noch die etwas untergekommen was ohne optimierung nicht geht. Da die Header datei ja eh durch das include
-
Thread
while-Schleife
Stefan schrieb im Beitrag #2582813: > Selbst gcc macht das, und das auch noch zurecht [c] #include <stdio.h> void x() { while(1); printf("Hallo Welt"); } [/c] macht der gcc zu: [code] .file "x.c" .text
borg schrieb im Beitrag #2586938: > Alle Warnungen bekommt man zumindest bei gcc weg, indem man vor main() > noch die Zeile einfügt:[c]volatile fn puts;[/c] Bei mir gibt es dann die folgende Warnung mit gcc Version 3.4.5 (sowohl bei Übersetzung mit -Wall als auch ohne):
-
Thread
pointer struct parameter übergabe / fehler?
Ist die Compiler-Optimierung ausgeschaltet? (-O0 für gcc)
damit zusammen, dass der Optimizer über einige Funktionen Bescheid weiss und dieses Wissen zur Optimierung benutzen kann. Jörg: Sind das beim gcc nicht die intrinsischen (intrinsic) Funktionen? Wie ich den gcc kenen, gibt es da sicher einen Compilerswitch mit dem man das abschalten kann. Nur
-
Thread
Übersicht Controller und Einstiegskosten (Debugger, Compiler)?
Soll natürlich: M32C, gcc -02, KPIT heißen!
: 79,50 µs Cortex-M3, armcc -O2, Keil Arm: 49,80 µs Mit 32 Bit Double ATmega128, gcc -O2, AVRStudio5: 656,75 µs M32C, gcc -O2, KPIT: 296,90 µs RX610, gcc -O2, KPIT: 284,90 µs -nofpu RX610, gcc -O2, KPIT: 24,90 µs Cortex-M3
-
Thread
AVR GCC Codeoptimierung selektiv ausschalten für CLKPR Zugriffe
aber nicht umgesetzt, weil die erste Anweisung nicht angekommen ist. Gibt es eine Möglichkeit den GCC anzuweisen selektiv keine Optimierung durchzuführen. Grüße STB
wegoptimiert. Wenn jemand mit den obigen beiden Zeilen Probleme hat, dann deshalb, weil er die Optimierungen *nicht* eingeschaltet hat. Dann wird das nötige Timing nämlich nicht eingehalten.
-
Thread
avr-g++: external linkage von const/PROGMEM Symbol.
PS: Ich habs mit zwei Compiler Versionen versucht, der 7.3.0 und zuletzt der 4.9.2: $ avr-gcc --version avr-gcc (GCC) 4.9.2 $ avr-g++ --version avr-g++ (GCC) 4.9.2
lrwxrwxrwx 1 root root 5 Sep 14 11:03 g++ -> g++-8 lrwxrwxrwx 1 root root 5 Sep 14 11:03 gcc -> gcc-8 [/pre] gcc und g++ sind Ein und das Selbe.
-
Thread
Schnelle Bitmaske in AVR-Assembler
häufig vorkommt und dabei z.B. Latenz wichtig ist, dann gibt es andere Stellen im Code, deren Optimierung deutlich weniger als eine Verdopplung bringt.
Effizienz der "Jim-Beam-Routine" erreichen. Und Leute wie du sind wesentlich verantwortlich für den avr-gcc? Da wundert es echt niemanden, dass der so Scheiße ist, wie er halt ist...
-
Thread
Funktionsaufruf aus Interruptroutine OK?
aber praktisch nur große Variablen oder aber den Fall ausgeschalteter Optimierung. Kleine Variablen (bzw. daraus berechnete Teilausdrücke) werden bei eingeschalteter Optimierung in Registern abgelegt, und der Compiler weiß genau, wie lange er ein Register für einen bestimmten
Gehört der GCC dazu ?
-
Thread
Warum verbraucht eine Variable so viel Speicher?
; } [/c] Compiliere ich ihn nun ohne Optimierung, gibt's eine Warnung: [pre] /usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:94:3: warning: #warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as
ignoriert, ich glaube, dem ist nach menschlichem Ermessen nicht mehr zu helfen. Schalte ich die Optimierung ein, dann bekomme ich: [pre] /usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h: In function 'delay': /usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:152:28: error: __builtin_avr_delay_cycles
-
Thread
Kompilieren mit Fehler darf nicht sein
Füge im "AVR-GCC"-Fenster die (richtigen) Header- und Sourcedateien ein, stell unter Project->Configuration Options den AVR-Typ und -Takt und die Optimierung ein, und /schon/ kompiliert das ganze. (brauchen wir vielleicht
> Füge im "AVR-GCC"-Fenster die (richtigen) Header- und Sourcedateien ein, > stell unter Project->Configuration Options den AVR-Typ und -Takt und die > Optimierung ein, und schon kompiliert das ganze. tip: rechtsklick
-
Thread
mehr als drei Speicherstellen bei inline-assembly (avr-gcc)
Assemblercode einfügen ohne irgendwelche unleserliche Syntax. Daß auf Assembler keinerlei Optimierungen vorgenommen werden, dürfte klar sein.
Peter D. schrieb im Beitrag #6630035: > Daß auf Assembler keinerlei Optimierungen vorgenommen werden, dürfte > klar sein. Nö. Es werden vielmehr alle Optimierungen angewendet, zu denen der Asm-Programmierer in der Lage war... Blöd nur, dass die C-Gülle, mit der der Kram
-
Thread
WINAVR + make
mittlerweile vorhanden. -ffreestanding unterdrückt nicht nur diese Warnung, sondern auch alle internen Optimierungen, bei denen der gcc eine Standardfunktion bekannter Funktionalität durch einen äquivalenten Konstrukt ersetzt. Beispielsweise kann ich im Code schreiben: foolen = strlen("foo"); und er
reines freestanding environment. Es wäre andernfalls ein Leichtes, -ffreestanding zum Default für avr-gcc zu machen (das Gegenteil heißt -fhosted).
-
Thread
Kann keinen String zuweisen wieso ?
> libgcc würde das noch angehen. Mag sein, daß es von der libc unabhängig ist. Jedenfalls hat gcc die Funktion sprintf (und so gut wie jede andere libc-Funktion) zu Optimierungszwecken schon selbst eingebaut und ruft nur dann die libc-Implementation auf, wenn er keine Möglichkeit für die Optimierung
Optimierung > findet. Das geht aber nur, wenn sich die C-library nicht dagegen wehrt. Standard "Bezeichner" (da wir grad beim Thema waren...) werden mit #defines umgebogen, damit gcc sie nicht als solche
-
Thread
Multiplikationen = Performancefresser?
3; } draus gemacht? Das is ja geschickt. Macht er das immer oder nur bei eingeschalteten Optimierungen? Gast.
erkannt :-) > Das is ja geschickt. Gelle. So ein Compiler hat heutzutage schon eine Menge Optimierungen drauf. Manchmal haut er gcc-Optimizer auch ein bischen daneben. Das liegt aber daran, dass der gcc nicht nur für µC gebaut ist, sondern eine breite Palette von Prozessoren, bis hin zu Grossrechnern
-
Thread
Wie man volatile optimiert
sondern es ist für eine Variable immer generell. D.h. auch im Interrupthandler wird damit die Optimierung ausgeschaltet, also da, wo es am meisten wehtut. Peter
auch const. Das heißt man kann > volatile genauso casten wie const. Und warum geht es dann im AVR-GCC nicht? Peter
-
Thread
wie variablenadresse in einer eff datei ändern?
aber 0x810712, was > eine Adresse im EEPROM darstellt. Und dann haben wir da auch noch die Optimierung des GCC. Wenn eine Variable einen file-static scope hat und außer der Intialisierung in der Deklaration nur gelesen wird, dann ist GCC so schlau, das Ding in die readonly-Sektion zu verfrachten,
0x810712, was >> eine Adresse im EEPROM darstellt. > > Und dann haben wir da auch noch die Optimierung des GCC. Wenn eine > Variable einen file-static scope hat und außer der Intialisierung in der > Deklaration nur gelesen wird, dann ist GCC so schlau, das Ding in die > readonly-Sektion zu
-
Thread
bitte Hilfe, interner Compiler Fehler
Beim Compilieren von Hit1270.c kommt bei mir ein interner Compiler Fehler, wenn ich als Optimierung "o3" wähle. Mit Optimierung "os" ist die Welt in Ordnung. Umgebung: WindowsXP, AVR Studio 4, aktuelles WinAVR (GCC 4.3.3). Der Fehler kommt aber auch, wenn ich dem WinAVR einen GCC 4.7.2 unter
Ich habe hier gerade einen GCC-4.3.3 unter Cygwin am laufen. [c] $ avr-gcc --version avr-gcc (Memsic 20120521) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions
-
Thread
eigene memcpy Funktion mit 2 Zielen
Hast du mal getestet, was gcc mit -Os tut? Ist das wirklich nicht gut genug? Das sollte man ausprobieren, bevor man sich die ganze Arbeit macht. ;)
ich sagen muss, dass der Compiler aus deinen Ansätzen wieder 2x memcpy(..) macht... die einzige optimierung dabei ist dann, dass es nicht mehr inline ist (was eigentlich schon 90% der Optimierung ausmacht). Wäre vollkommen ausreichend, aber irgendwann kommt einfach der Punkt da will mans wissen. in C
-
Thread
GCC: code funktioniert bei -O, funktioniert nicht bei -Os
bei -O auf. Was sagt denn -v? Ich kann den Fehler mit 4.3.3 unter Linux nicht nachvollziehen. avr-gcc hab ich erzeugt aus svn gcc_4_3_3_release mit gcc = 4.0.2 gmp = 4.2.2 mpfr = 2.3.1 Johann
Wird nicht genauer, sorry. gcc -v sagt 4.3.3 und sonst nix, apt sagt 4.3.3-1 (http://packages.debian.org/en/sid/gcc-avr).
-
Thread
AVR-GCC Array(Pointer) einer Funktion übergeben
volatile sein? Wer weiss? Gibt es denn Potential, dass der COmpiler in diesen beiden Members mit der Optimierung daneben hauen kann?
irgendwie weiter } break; } [/c] Ich weiß eben nicht genau, ob der Compiler sowas per Optimierung zerwürgt...
-
Thread
externe Deklaration in anderem C-File; so richtig ?
Wert_A' is 00403000 (5) foo: location of 'Wert_A' is 00403040 (5) Kompiliert auf Windows2000 mit gcc 3.4.2: gcc -g -O2 -Wall -o static.exe static.c static2.c
wenn kein Sourcecode der Library vorliegt. Natürlich kann in diesem Falle der Compiler die Optimierungen, wie sie oben angesprochen wurden, nicht durchführen. Das gcc-Verhalten sprach Patrick an (http://www.mikrocontroller.net/forum/read-1-286669.html#288169), welche Compileroption zu verwenden
-
Thread
memcpy vs for-loop bei AVR
memcpy gibt es unter Umständen so allgemein nicht. Der Compiler kann (und der gcc wird, bei eingeschalteter Optimierung) den memcpy Aufruf durch äquivalenten Code ersetzen und den Gegebenheiten entsprechend optimieren. Also die eigene Implementierung vergleichen mit einer Implementierung
den/ Sourcecode von memcpy gibt es > unter Umständen so allgemein nicht. Der Compiler kann (und der gcc wird, > bei eingeschalteter Optimierung) den memcpy Aufruf durch äquivalenten > Code ersetzen und den Gegebenheiten entsprechend optimieren. Aus [c] #include <string.h> #include <stdint.h
-
Thread
LCD ansteuern, fragen zu tutorial in assembler
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#LCD-Ansteuerung ...
für dich ja kein problem sein, nach der Ampelsteuerung) Dann noch was zum Thema for-Schleifen optimierung: Den Grad der Optimierung kann man in der Regel einstellen. Wenn du Wartezeiten mit for-Schleifen programmierst, ist es ratsam ohne Optimierung zu arbeiten, da diese sonst wegoptimiert werden.
-
Thread
AVR braucht 7us-12us bis in Interrupts ausgelöst wird??
Push- und Pop-Orgien des gcc bei all den vielen Registern. Schau dir mal das disassembly an.
wenn die ISR sie selbst verwendet. Aufgerufene Funktionen sichern diese Register selbst. https://gcc.gnu.org/wiki/avr-gcc#Register_Layout
-
Thread
Compiler Error von WinAVR als Plugin zu AVRStudio
Hallo an alle. Ich möchte ein Projekt kompilieren, dass ich als GCC Projekt im aktuellen AVRStudio angelegt habe. (installiert ist auch das neueste WinAVR). Nun bekomme ich leider de Meldung: gcc plug-in: Error: Object file not found on expected location F:\projects
http://www.mikrocontroller.net/articles/WinAVR#gcc_plug-in:_Error:_Object_file_not_found_on_expected_location
-
Thread
Keil, IAR vs GCC
für Argumente sprechen dafür einen Keil oder IAR Compiler zu verwenden, anstatt einem kostenlosen GCC. Im Speziellen würde mich GCC für ARM für Industrieelektronik interessieren. Lors
Bedacht und nutzt gegebenfalls eigene Funktionen (Atmel macht das z.B. bei stdio in Beispielen für arm-gcc so), sind die Unterschiede in Bezug auf Codegröße sehr viel geringer. Stöbert man durch die Quellen der newlib, findet man auch einige Änderungen zur Optimierung, die von Leuten mit arm.com-E-Mail
-
Thread
AVR ATMega - Zugriff auf Struct im Speicher mittels Offset
Compiler im Laufe der Jahre und kenne halt einige auswendig und bei anderen schlage ich nach. http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html#Structure_002dPacking-Pragmas
den verschiedenen Aussagen dazu das ein Struct > im Speicher optimiert abgelegt wird ? Beim avr-gcc lautet diese "Optimierung" eben "auf Byte-Grenzen legen".
-
Thread
AVR GCC: Funktion wird weg optimiert... warum?
_ oder so änhlich -attribute und enstprechende GCC-Parameter, um die zu nutzen müsstest du allerdings das GCC-Manual lesen ... hth. Jörg
Knackpunkt ist das inline, das wußte ich nicht. Der Knackpunkt ist nicht das inline, sondern, daß der gcc, genauso, wie andere Compiler auch, bei eingschalteter Optimierung Code erzeugt, der nicht mehr 1:1 rückwärts dem C-Quelltext zugeordnet werden kann. Das macht der nicht nur durch inlining, da gibt
-
Thread
C-Frage zu einem Warning in einer if-Anweisung
nicht unbedingt offensichtlich), daß sich Zeiger überlappen können. Das verhindert bessere Optimierungen, weil der Compiler dereferenzierte Werte nicht in Registern halten, sondern immer aufs Neue lesen muß. Leider sind nicht alle gcc Versionen mit einer gleich guten Erkennung gesegnet, wann das
ein Aliasing zu übersehen (insbesondere bei Code für performante De/Serialisierung) ist hoch. Und GCC warnt quasi nur bei den (offensichtlichen) Fällen, wo es keine Probleme gibt. Die wirklichen Probleme sieht er aber nicht, wie auch. Mein Empfehlung: Bei Optimierungen (-O2 und mehr) immer -fno-strict-aliasing
-
Thread
AtmelStudio 6 - Bug oder Feature ?
32Mhz stabil sind und erst dann umschalten weil die Hardware das sonst ignoriert. Mit 'Size' optimierung läuft das wie erwartet. Schalte ich die Optimierung jedoch aus, funktioniert das nicht. Die Schleife wird durchlaufen, es bleibt aber beim 2Mhz Systemtakt. (code siehe unten) Keine Compilerwarnung
Michael Knoelke schrieb im Beitrag #2748100: > Mit 'Size' optimierung läuft das wie erwartet. > Schalte ich die Optimierung jedoch aus, funktioniert das nicht. > Die Schleife wird durchlaufen, es bleibt aber beim 2Mhz Systemtakt. Dann tippe ich mal, daß mehr
-
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
HSV->RGB-Methode: Speicherplatz optimieren
merklich beeinflussen. Ebenso die gemsichten 42/43 kommen mir komisch vor. Kompilierst du auch mit Optimierung auf Platz?
noch tunen. Eventuell erlaubt die Anwendung: CFLAGS += -mtiny-stack #Stack auf 256 begrenzt (GCC 4.3.0)
-
Thread
Gleiche Funktion. 23 cycles anstelle von 6?
Ein exzellent optimierender Compiler ... ist das in diesem Fall jedenfalls nicht - oder die Optimierung war abgeschaltet. Denn der ASM2 Code ist für optimierten Code wirklich unter aller Sau. Ich meine mich zu erinnern, dass Microchips freie Compiler-Version bei Optimierung eingeschränkt ist. Intern ist der Compiler von Microchip der GCC plus etwas proprietärem Kram. Und der GCC sollte sich nicht so doof anstellen. Wenn man ihn lässt.
-
Thread
Codegröße WinAVR vs. AVR Studio (mit gcc)
angepasstem Makefile) programmiert. Aus Neugierde habe ich ein bereits getesteten Quellcode direkt in ein GCC-Projekt kopiert und compiliert. Wie zu erwarten, gabs keine Probleme. Beim Vergleich der Hex-Files ist mir aufgefallen, dass das WinAVR-Hex-File nur ca. halb zu groß (5,47kB) ist, wie das GCC-AVR-File
Jörg, vielen Dank für die schnelle Antwort. Mir war schon klar, dass ich unter AVR-Studio mit dem GCC kompiliere. Und gerade deshalb fande ich es "sonderbar", dass unterschiedliche Dateigrößen des Hex-Files auftraten. Die Optimierung hatte ich aber richtig eingestellt. Dein "Blau-Schuss" traf
-
Thread
AVR: Ausgangsport Togglen leicht gemacht
das nicht. Vielleicht schnappt das ja der eine oder andere Compilerbauer auf und kann das als Optimierung implementieren
in den kürzesten oder schnellsten, je nach eingeschalteter Optimierung. Aber was soll so ein Universalcompiler, wie der gcc noch alles berücksichtigen? Schau dir mal den erzeugten Assemblercode an und überlege wieviele weitaus nützlicheren Optimierungen dir auf den
-
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
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
Probleme bei atan2() mit volatile
Zumindest der gcc kennt die Funktionen der Standard-Library und arbeitet auch mit diesem Wissen.
die > Parameter überprüft werden können). Ja. So gut wie alle Funktionen aus der math.h sind im gcc als built-in-Funktionen vorhanden. Hier eine Liste: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Other-Builtins.html#Other-Builtins
-
Thread
Pic-C-Compiler
Dadurch kannst du auch erst mal einen Compiler machen, der C-Code in Assembler wandelt und die Optimierung des Assemblers und das Linken kannst du fürs erste einem bereits vorhandenen Assembler und Linker überlassen... Wenn das dann mal laufen sollte kannst du die Stufen Assembler und Optimierung einbauen
"Zu AVR-GCC / WINAVR: Wo gibts die? Freeware?" Geh diese Seite ganz nach oben und lies mal links davon, da sind 2 Links "AVR-GCC". Zum Ladgerät: Ich weiß jetzt nicht, mit wieviel MHz Du pulsen willst,
-
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
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
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
WinAVR 20070525 Optimierung
Hallo! Gibt's beim Upgrade von WinAVR irgendwas zu beachten? Ich hatte bis vor kurzem WinAVR 2006 installiert. Jetzt hab ich auf WinAVR 2007 upgedated und meinen Webserver neucompiliert. Leider funktioniert nun die Checksummenberechnung nicht mehr. [c] WORD checksum( BYTE * buffer, WORD count ) { WORD sum; asm volatile ( "clr %A0 \n\t" "clr %B0 \n\t" "sbiw %A2, 1 \n\t" "brcs 2f \n\t" "1: \n\t" "ld __tmp_reg__, %a1+ \n\t" "add %A0, __tmp_reg__ \n\t" "adc
-
Thread
SRAM schonende Optimierung beim gcc?
Template-Mechanik zur Produktion von mehr Code (im Flash) führen. Allerdings sind teilweise die Optimierungen des Clang / gcc bei template-code geradezu "atemberaubend", und andererseits tun ein paar (k)Byte mehr Flashverbrauch weniger weh als beim SRAM.
-
Thread
Interrupt / SREG / Priorität
Johanns Arbeit (ich glaube, es war ab GCC 4.9) die Optimierungen für AVR deutlich besser geworden.
allem durch Johanns Arbeit (ich glaube, es war ab GCC > 4.9) die Optimierungen für AVR deutlich besser geworden. Johanns Arbeit ist unbestritten wertvoll, und ich weine dem 3er gcc auch nicht nach. Den Codegrößenvergleich müsste man aber doch mal richtig
-
Thread
AVR-GCC: PUSH-/Pop-Orgie verhinern
https://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Function-Attributes.html#index-g_t_0040code_007bOS_005fmain_007d-AVR-function-attribute-2653
Kevin schrieb im Beitrag #5270366: > Welche avr-gcc-Version setzt du denn ein?? Das sollte schon lange kein > Thema mehr sein. Eine entsprechende Optimierung ist ab avr-gcc v8 verfügbar (PR83738).
-
Thread
GCC Preprozessor Berechnungen und Forced Errors
hat, >> was erst der Compiler weiss. Und sizeof kennt erst der Compiler. > > Zumindest bei dem GCC weiss ich nicht, ob das so stimmt. Beim GCC ist der Präprozessor mit im Compiler eingebaut, aber dadurch darf sich dessen Verhalten natürlich nicht ändern. > In func2() (per const Variable) wird
Präprozessor nichts damit zu tun hat. Jupp, der ist raus. Die Operation sieht der nicht als Optimierung.
-
Thread
WinAVR 20030913 veröffentlicht
wenn sich das bisherige bereits glänzend bewährt hat" Bestimmt würden sich auch umgekehrt ne Menge GCC-Gurus mit dem Keil schwer tun. Das ist ja nur menschlich. Und mit meinem GCC-Patch bin ich auch voll zufrieden. Peter
C -- wenn Du denn einen findest, der gut genug ist, auch sonst das nötige sinnvolle Maß an Optimierungen zu bieten, an die man sich bei guten C-Compilern eben gewöhnt hat. . Du kannst versuchen, einen Kompromiß zu finden. Das soll natürlich keineswegs heißen, daß die Optimierungen des avr-gcc
-
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
Bug im avr-gcc bei Behandlung von SFRs als Bitfields?
Variante ein zweites Mal wiederholt. Kann dazu vielleicht Johann (oder Jörg oder ein anderer avr-gcc-Experte) was sagen? Achja, Compiler ist avr-gcc 4.7.2, Optimierung Os. Gruß und Dank, Frank
Frank M. schrieb im Beitrag #3748189: > Du hast einen neueren avr-gcc 4.7.2? gcc version 4.10.0 20140629 (experimental) (GCC) > Könntest Du den Code aus dem > Ausgangposting da mal durchschicken und hier den Auszug aus der > lss-Datei angeben? lss mag ich