-
Thread
Optimierung Soft-PWM
Global Global = tmp;[/c] Also temporäre Variablen verwenden. Datentyp natürlich anpassen. avr-gcc optimiert Operationen mit globalen Variablen meist nicht wirklich oder zumindest sehr unzuverlässig.
volatile sind dem Compiler auch die Hände gebunden. Das darf er gar nicht anders. Trotzdem optimiert avr-gcc auch normale nicht-volatile globale und auch static(!) Variablen nur sehr unzuverlässig. Da kommt man oft nicht um temporäre Variablen herum. Einfach mal in größeren Projekten testen.
-
Thread
Virtual Function Elimination ARM GCC
> dieser Option, da sie wohl Bugs haben soll (oder mal gehabt hatte in > früheren Versionen von GCC). Wenn ich den Inhalt von derivedClass.cpp in main.cpp kopiere, klappt es. Dann gibt es derivedClass gar nicht mehr im Binary. Vollte Optimierung bekommt man leider erst mit Amalgation. Soll der
blöd zum googlen bin :/ Biste halt. Sonst hättest du den passenden Kommentar zu der Frage auf gcc.org gefunden. Ich zitier mal für dich: >> So what can I do? > Nothing (well, improve GCC!). In diesem Sinne… Oliver
-
Thread
Debug Optionen -G mit Optimierungen -O
Meine Erfahrung ist, dass -g3 mit -O3 bei heutigen gcc-Versionen einwandfrei funktioniert, aber der Nutzwert aufgrund der Optimierungen begrenzt ist. Da werden einzelne Assemblerbefehle den wildesten Quelltextzeilen zugeordnet und scheinbar chaotisch hin
Wie Jörg schon schrieb wird GCC *niemals* die Codeerzeugung vom gewählten Debug-Level oder -Format abhängig machen -- falls doch, ist das ein GCC-Bug. Neurer GCC-Versionen unterstützen -Og, was nur Optimierungen einschaltet, die
-
Thread
Wann wird eine Variable zurueckgeschrieben / volatile
sollte man diese Optimierung auch mit volatile verhindern? Sie kann doch während der ISR im Register gehalten werden.
rausfliegen! int a; main() { a=1; } Ja das mal durch deinen Compiler mit aktiver Optimierung und staune ;-)
-
Thread
Atmega8 GCC: Bitmanipulation an einer Variablen
Du auf "Optimization" 6. Im Optimization Level stellst Du None ein Ab jetzt werden keine Optimierungen mehr seitens GCC unternommen und nur übersetzt. Somit kannst Du in alle Variablen, Strukturen usw. reinschauen. Viele Grüße Stefan
Die meisten Leute wollen, auch wenn sie es nicht wissen, die Optimierung auf Codegrösse. Ich würde dieses Problem nicht durch drehen an der Optimierung "lösen". Volatile oder eine dummy-use Funktion für die Variable einbauen. Dass sowas wegoptimiert wird ist
-
Thread
[avr-gcc] "undefined Reference" bei inline Funktionen
. Gründe, eine Funktion nicht zu inlinen, können u.a. sein: • Inlining ist zu teuer • Optimierung oder Inlining ist deaktiviert • Es wird die Adresse der Funktion genommen • Die Funktion nimmt die Adresse lokaler Labels "inline" gibt es erst seit C99. GCC akzeptiert "inline" auch bei
int main() { foo(); return 0; } [/C] Und das steht alles in _einer_ Datei. Wenn Optimierung ausgeschaltet ist, bringt gcc im C99-Modus beim Aufruf von foo() die Fehlermeldung, dass diese Funktion nicht definiert sei. Wie schon gesagt wird _keine_ non-Inline-Version generiert. Compiliert
-
Thread
Simulationsproblem über Konsole
Optimierung an? Der Compiler könnte die Schleife entfernen, da das Ergebnis von c vorrausgesagt werden kann.
Eigentlich willst du die Optimierung beim realen Programmieren nicht abgeschaltet haben. Aber seis drum. Welche Entwcklungsumgebung verwendest du? Im AVR-Studio stellst du die Optimierung bei den Projekt-Optionen auf -O0 (das ist
-
Thread
AvrStudio 5 Programm zu groß für Attiny 13
Beitrag #5006022: > Die .lss Datei lade ich hoch. Wurde offensichtlich mit abgeschalteter Optimierung übersetzt.
AVR Assembler. Für Windows. Mit AVRASM. Oder AVRASM2. Ohne GNU. Und wieso geht es damm um Optimierungen?
-
Thread
AVR-C: Funktionen aufrufen
Oder hast du das Programm nur im Simulator/Debugger laufen lassen? Da können je nach verwendeter GCC- bzw. Debugger-Version und je nach Debug-Option unerwartete Dinge passieren, da die Funktionen bei eingeschalteter Optimierung geinlinet werden.
test(); while (1) {} } [/c] lg und nochmals vielen Dank ps: [alle@foo ~]$ avr-gcc --version avr-gcc (GCC) 5.2.0
-
Thread
Makro Funktionen avr-gcc
ausgerechnet). So steht da einfach nur: [c] printf("%d\n", (2+3)); [/c] Das kannst du mit gcc -E mein_file.c sehen. Für die Optimierung ist der Compiler zuständig.
Vorteile, bei gleich guter Lesbarkeit. Ganz Klar schrieb im Beitrag #6420590: > aber mit Optimierung hat das nichts zu tun. Ja! Da sind Makros weder förderlich, noch hemmend. Auch schient mir hier nicht die Optimierung als ganzes gemeint zu sein, sondern nur der Teilbereich "Ausführung zur
-
Thread
Inline Assembler- Bits spiegeln
Optimierungen erkennt ;-)
die vier Takte schaffen können, theoretisch könnten die nämlich natürlich ganz genau dieselben Optimierungen vornehmen. Die Sache ist nur: ich kenne keinen, der das packt... Der GCC jedenfalls kann's definitiv nicht. Selbst mit genauso viel Nachhilfe durch den Programmierer wie in Assembler packt er's
-
Thread
Laufzeiten und GNU/Watcom C
Compiler Optimierungen (-O2) sind eingeschaltet?
http://www.x-hacker.org/ng/wcppug/ng1963c.html Wie machst du die globale zp1 entsprechung beim GNU gcc? Lokal geht es so: https://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Structure_002dPacking-Pragmas.html Welche Watcom version verwendest du 1.9 oder die V2 variante? Gcc version? Moeglichkeit unter
-
Thread
ganz einfache c frage (break, verschachteltes for)
Ist das nicht C++? Der gcc übersetzt das.
Schleifen schon etwa eine Verzehnfachung des Durchsatzes erreichen! Und mit ein paar anderen Optimierungen zusammen ergab sich nochmals eine Steigerung um 10%. Auch heute gibt es Simulationen und andere Berechnungen mit einem gigantischen Rechenleistungsbedarf, so dass auch dort schon minimale Optimierungen
-
Thread
_delay_ms Faktor 13 zu langsam
> Ah richtig, das hatte ich vergessen zu erwähnen: -Os wird verwendet. Das ist die falsche Optimierung.
Die richtige Optimierung ist, kein delay zu verwenden.
-
Thread
C typecast array nach struct
. So modern muss der Compiler dafür übrigens auch nicht sein. gcc macht das schon seit mindesten 25 Jahren.
Development Kit ist erst 15 Jahre alt, > kann aber den memcpy Hack nur mit voll aufgedrehten Optimierungen - was > schlecht ist wenn ich kleine Programme möchte. Das ist kein Hack, sondern eine Optimierung. > Ich weiss Linuxer verwenden überall und immer -O3 :-). > Wenn du in einer Freestanding
-
Thread
AVR: ISR mit internal linkage: keine Linker-Fehlermeldung
könnte. Erweiter ./gcc/config/avr/avr.cc::avr_set_current_function() oder ähnliche Stellen, die dafür geeignet sind. https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/avr/avr.cc;h=c193430cf073b00238c250f9a690b1a97c62f87a
Wie gesagt, alle globalen Optimierungen: -flto, -fwhole-program. oder wie die heißen mögen, z.b. bei clang/llvm. Prinzipiell ist es keine gute Idee, die Korrektheit eines Programms von Optimierungen abhängig zu machen. Für vanilla
-
Thread
Funktionsaufruf
nach der optimierung drin bleibt werden alle Register gesichert.
http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
-
Thread
Optimierung im code ein- und ausschalten
Ein gangbarer Mittelweg ist u.U. -O1. Auf Funktionsebene lässt sich Optimierung mittels Pragma/Function-Attribut umstellen -- entsprechende GCC-Version vorausgesetzt. http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas
Danke für die Tips! Ich habe die Funktion mit #pragma GCC optimize("-Os") übersetzt, jetzt geht es. Was ich mich nur frage, warum GCC ohne Optimierung einen so extrem umständlichen Code produziert?? Registerverschwendung und Codegröße maximal!
-
Thread
Atmel ist unter "Profis" nicht gerade beliebt - Warum?
&t=44588 GCC leidet zuweilen darunter, dass der AVR bei den GCC-Entwicklern eine relativ untergeordnete Rolle spielt. Insbesondere gibt es immer noch keinen so weit etablierten Simulator, dass es den GCC-Leuten
Eric Weddingtons erklärtes Ziel ist es, einen Simulator so zu etablieren, dass das AVR-Target bei GCC aus der dritten (,,ferner liefen'') in die zweite Kategorie wandert. Damit würden kritische Bugs bei der Codegenerierung für AVR zum Blocker für ein GCC-Release, und schlechtere Optimierungen durch
-
Thread
Größenunterschiede (output) avr-gcc zwischen linux und win
2344 0 .data 0 0 .bss 0 0 .progmem.gcc_sw_table 836 0 Total 3180 [/pre] Dann ohne Optimierung: [pre] $ avr-gcc -mmcu=atmega8 -O0 -c calculate.c $ ll calculate.o -rw-r--r-- 1 ich users 4328 Oct 14 21:
genug gepflegt ist, opensource ist, und für den sich jemand die Arbeit machen würde, ihn an die GCC-Testumgebung dranzustricken. Dadurch können die GCC-Entwickler Seiteneffekte für den AVR nicht selbst testen, d. h. wenn bei einer grundlegenden Umstrukturierung der Optimierung (wie sie von GCC
-
Thread
GCC v14 Release
Seit einer Woche gibt es die neue GCC Release v14 Änderungen: https://gcc.gnu.org/gcc-14/changes.html AVR-spezifisch: https://gcc.gnu.org/gcc-14/changes.html#avr
ja kein Sprachfeature. Das wurde speziell > für den AVR eingebaut. [...] Irgendwelche neuen Optimierungen. Wie gesagt bessere indirekte RAM-Zugriffe bei Reduced Tiny (PR114100) Veit D. schrieb im Beitrag #7670327: > eine Frage zum avr-gcc 13.3. In "Change" wird AVR nicht erwähnt. Die Release
-
Thread
AVR DB - oder doch ein Compiler-Fehler?
aber keine Ahnung von asm hat, kann es auch einfacher veranschaulicht werden, als nur um asm Optimierung zu diskutieren, oder?
der man sich letztendlich wundert, warum es überhaupt funktionierende Programme gibt. https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html Oliver
-
Thread
Könnte der gcc mich evt. warnen?
nicht der Fall. eagle user schrieb im Beitrag #5189658: > Und die Leute sagen, mit dem aktuellen gcc bekommst du Lint gratis. ja, natürlich steckt hinter gcc mehr manpower als hinter PC-Lint, so dass gcc immer besser wird. Aber zum einen ist Lint m.E. noch immer besser individualisierbar, zum anderen
hat? Oder würdest du sagen: "Damit gebe ich foo den Wert 0"? > Der Compiler darf auch ohne Optimierung das ganze if wegschmeißen, da > foo by value übergeben ist und *foo nicht volatile. Wieso "ohne Optimierung"? Wenn er das wegschmeißt, ist das ganz klar eine Optimierung. > Hat eine Anweisung
-
Thread
STM32: Timer-ISR löst 2x aus - Fehler im Flag-Reset bei Optimierung O3
Ich möchte euch ein sehr merkwürdiges Problem schildern, welches bei Optimierungen > O0 auftritt: Eine Timer-ISR ist so konfiguriert, daß sie jede Millisekunde auslöst. Ohne Optimierung funktioniert dies wie erwartet. Beim Optimierungslevel O3 findet eine doppelte Auslösung
#3372931: > Wie wäre dieser Fehler einzuordnen - müßte der Compiler bei > entsprechenden Optimierungen nicht ein zusätzliches NOP zur Sicherheit > einfügen? (-> da es ja eindeutig nur bei best. Optimierungen auftritt) Das ist nun aber definitiv nicht Sache des Compilers. Das ist auch kein
-
Thread
blutiger anfänger in GCC
Schalt die Optimierung ein.
Mit Optimierung (-OS) sind es auch beim AVR-GCC bloss noch 156 Bytes! Gruss Peter
-
Thread
Spaßig: "% 16" vs. "& 0x0F"
2^n" entspricht "x & 2^n" (und nicht "x & 0x0F")... @Owz: > ...ich schau mir den Code ohne Optimierung an... Wieso ohne Optimierung? Sehe ich so keinen Grund für. Was der Compiler sich denkt, kann ich bei den o.g. Beispielen auch sehen. Ich sehe z.B. dass der Compiler bei "%" an 8 Bit denkt und
...GCC kennt -mint8, damit ist sizeof(int)==sizeof(char). Die avrlib kannst du dann allerdings vergessen.... Was ist damit gemeint??
-
Thread
flash-Fehler mit ATtiny2313, compile ok
elimination, etc. Um eine genaue Antwort zu geben, könnte man die GCC-Dumps lesen. Wenn es dir den Aufwand wert ist: Die Dumps bekommst du mit -fdump-rtl-all-details -fdump-tree-all-details > Ich dachte, die Optimierung mittels "-Os" im Makefile veranlasst > zu haben
auf Mikrocontrollern möglichst vermeiden, stets mit möglichst kleinen Integertypen arbeiten und die GCC-internen Optimierungen in Anspruch nehmen. Außerdem schlage ich vor, im AVR-GCC-Tutorial ein Kapitel "Tipps für Anfänger" oder "häufige Fehlerquellen" hinzuzufügen, mit Ratschlägen der o.g. Art.
-
Thread
Code zu groß für AtTiny45
Keine Ahnung, was du als Compiler benutzt. Ich bekomme mit einem GCC 4.7.2 schon Code, der in den ATtiny45 passt: [pre] $ avr-gcc -DF_CPU=8000000 -mmcu=attiny45 -Os -o test.elf -I includes *.c -lm main.c:14:9: warning: built-in function ‘index’ declared as non-function
[/pre] GCC 5.3.0 spart noch ein paar Bytes ein: [pre] $ avr-gcc -DF_CPU=8000000 -Dasm=__asm -std=c99 -mmcu=attiny45 -Os -o test.elf -I includes *.c -lm $ avr-size *.elf text data bss dec
-
Thread
Warum ist die USB/CDC Implementierung der Cube HAL so groẞ?
? Nick schrieb im Beitrag #8007084: > Sicherlich gibts auch eine komplett freie Toolchain. Der gcc sollte ja > wohl arm können. Also der GCC kann die CubeHAL kleiner kompilieren als der GCC der bei Arduino oder STM32CubeIDE mitgeliefert ist?
Niklas G. schrieb im Beitrag #8007090: > Also der GCC kann die CubeHAL kleiner kompilieren als der GCC der bei > Arduino oder STM32CubeIDE mitgeliefert ist? Quatsch. Hör endlich auf dir so wirres Zeug zusammen zu fantasieren. Ich habs schon mal
-
Thread
Eclipse Kompilierung LCD Buchstabensalat
probehalber ruhig großzügig gewählt) ersetzen. Beutzen eigentlich beide 'Versionen' den gleichen gcc?
am WE mal versuchen - bin für jeden Tip dankbar. Und ja beide Versionen benutzen den gleichen gcc. Ist ja auch nur einer auf dem System installiert. Jörg
-
Thread
Warum bekomme ich keinen Überlauf?!
Das Verhalten ist mit GCC/Linux 4.7.3 reproduzierbar und tritt nur bei eingeschalteter Optimierung auf, nicht aber bei fwrapv. Das Verhalten des Compilers ist völlig in Ordnung, da - wie schon erwähnt wurde - das Überlaufverhalten
A. K. schrieb im Beitrag #3365837: > Das Verhalten ist mit GCC/Linux 4.7.3 reproduzierbar und tritt nur bei > eingeschalteter Optimierung auf, nicht aber bei fwrapv. > > Das Verhalten des Compilers ist völlig in Ordnung, da - wie schon > erwähnt wurde -
-
Thread
AVR Float Geschwindigkeit
lang. Welchen AVR und welche Taktfrequenz verwendest du? Hast du die Option -lm angegeben (bei AVR-GCC 4.8 nicht mehr nötig)?
libm (also -lm) sowieso, da diese Funktionen in der GCC_Bibliothek nicht vorhanden sind. Ab AVR-GCC 4.8 werden die FP-Routinen defaultmäßig aus der AVR-Libc genommen, weswegen hier das -lm nur dann benötigt wird, wenn man zusätzlich zu den Grundrechenarten
-
Artikel
AVR-GCC-Codeoptimierung
wo's nur geht. Wirklich zeitkritische Funktionen und Interrupts als Assemblercode in separater Datei GCC-Optionen. Optimierungs-Level. avr-gcc kennt mehrere Optimierungsstufen: -O0 : Keine Optimierung des erzeugten Codes. Diese Optimierungsstufe optimiert den Resourcenverbrauch des Hostrechners und die
diese zu schieben, das ist meist deutlich schneller. Gute Beispiele findet man hier und hier. Optimierung der Ausführungsgeschwindigkeit. Hierzu gibt es schon eine Application-Note von Atmel. Diese AppNote bezieht sich auf den IAR-Compiler. Die darin genannten "Optimierungen" sind für avr-gcc größtenteils
-
Thread
Funktionsaufruf in C
es wo auch immer hin? Ähm, ich /vermute/ eher nicht. Aber du schriebst ja auch: Link-Time Optimierung und *ggf*
schrieb im Beitrag #7064231: > Schon viele hat das korrekte > aber eben sehr flexible Verhältnis des GCC zum Quellcode aus der Kurve > geworfen. Umordnung und weglassen von Code kommt in der Branche nicht > immer gut an. Nu ja, die Diskussion ist so alt wie „ohne Optimierung läufts, mit nicht“.
-
Thread
USART-ISR mit mega8515
Ich werde das Resultat bei mir uppen (es kamen auch schon Anfragen deswegen) und hoffe auf Optimierungen von Leuten, die mehr von avr-gcc verstehen... Für meine eigenen DMX-Projekte bin in Assembler effizienter. Ich werde gerne noch diesen Thread und ähnliche weiterverfolgen, da die Idee eines Baukastens
Diskussion auf der AVR-GCC- Mailingliste wert.
-
Thread
Bitfeld zuweisen: Warum optimiert der Compiler nicht?
Kannst ja beim GCC Bugtracker ein "missed optimization opportunity" Bug einstellen. Hab ich vor 10 Jahren mal für eine Byte Permutation für x86 gemacht. Hat keine Woche gedauert, dann war das im GCC drin.
gleichen zwei Adressen. Da hätte ich eher erwartet, dass da ein Penalty-Faktor draufliegt, der eine Optimierung erst anstößt.
-
Thread
Problem mit avr-gcc und Optimierung
Hallo, die Funktionen in der angehängte Datei werden vom Hauptprogramm aufgerufen (erst Init, und dann die anderen zyklisch). Compiliere ich das ganze mit -O2 landen beim Aufruf von BmpInit() max 9 Bit in den einzelnen Feldern von _C[]. Verwende ich dagegen eine andere Optimierungsstufe, schreibe: [c]volatile uint16_t _C[MS561101BA_PROM_REG_COUNT];[/c] oder greife innerhalb der Funktion auf _C[] zu, wie zB im auskommentierten Teil, funktioniert alles wie es soll. Ich compiliere mit [code]avr-gcc -c -mmcu=atmega644p -I. -gstabs -O2 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
-
Thread
GCC (Backend) an eigene Architektur anpassen
Hallo, ich bin aktuell auf der Suche nach Informationen den GCC an eine selbst entworfene Architektur anzupassen (Backend), finde bislang aber nur sehr wenig darüber. Hat eventuell jemand ein paar Informationen darüber für mich? Also die Basics (GCC Source besorgen
Tim T. schrieb im Beitrag #5757315: > LLVM hab ich schon durch, diesmal gehts mir nur um GCC. Hab ich auch mal versucht, habs aber aufgegeben weil ich nichts vernüftiges gefunden habe und der Code vom GCC nicht gerade der schönste und aussagekräftigste ist. LLVM ist da wesentlich besser.
-
Thread
unverständliche Optimierung beim Schreiben von PORTs
Vorschläge. Kann gern auch noch mehr Code posten - bin aber irgendwie sicher, dass es an der Optimierung liegt. Vielen Dank schonmal Benni
gemacht. Ich hätte ja gesagt - Tiny / Programmiergerät / Schaltung selbst kaputt. Aber ohne Optimierung ging es zuvor immer. Jetzt hab ich grad mal meine avrgcc Version gecheckt - bin etwas erstaunt über das prerelease.. "gcc-Version 4.8.0 20130502 (prerelease) (GCC)" Fehler dort zu suchen
-
Thread
Künstliche Intelligenz soll den GCC beschleunigen
Änderungen vorzunehmen. Quelle: http://www.heise.de/newsticker/Kuenstliche-Intelligenz-soll-den-GCC-beschleunigen--/meldung/110378 Weiterführender Link: http://gcc-ici.sourceforge.net/papers/fmtp2008.pdf
ein bissl finde ich die Neuigkeiten wie bei heise...misleading. Soweit ich das verstehe wird am GCC selbst nichts geändert. Vielmehr geht es darum, anhand der Characteristika eines Programmes die besten Optimierungsoptionen zu finden und gcc damit zu füttern. Die in gcc intergrierten Optimierungsalgorithmen
-
Thread
ARM GCC Problem Größe übergeordneten struct bestimmen
Beitrag #3472885: > Doch, tun sie. Und es ist kein Zeiger. Und "legal" sind sie auch: http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
Feldelement und: Warnung: Initialisierung eines flexiblen Feld-Elements Lies mal: http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Zero-Length.html
-
Thread
Mega8 vollprogrammiert?
Verrate mal, welche "toolchain" Du benutzt, dann bekommst Du eine treffende Antwort! Falls es sich um GCC+AVRStudio handelt, findest Du die Optimierung unter Projects/Configuration Options/Optimization. Gruß Fred
Fred S. wrote: > Falls es sich um GCC+AVRStudio handelt, findest Du die Optimierung unter > Projects/Configuration Options/Optimization. ...und wenn AVRStudio nicht beteiligt sein sollte, dann im Makefile...
-
Thread
AVR-GCC seit 2007 verschlechtert (Speicherbedarf)
Operatoren verhunzen) Auf den ersten Blick sehe ich auch sonst keine besonderen Verbesserungen in der Optimierung im .s File. Frage: Was ist der Hauptgrund warum der neue AVR-GCC scheinbar ohne Gegenleistung soviel mehr Speicher statt weniger frißt? Was kann man tu Per anschauen des generierten Assembler-Code
Feinheiten (Compiler-Schalter und Codeorganisation) dazu http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Optimierung_der_Gr.C3.B6.C3.9Fe http://www.mikrocontroller.net/topic/66690 das meiste wie hier hatte ich schon selbstverständlich gemacht. Der Autor kam aber auch schon damals (
-
Thread
Unerklärbares Verhalten
R_AVR_13_PCREL against symbol `__addsf3' defined in .text section in e:/winavr 20070525/bin/../lib/gcc/avr/4.1.2/avr5\libgcc.a(_addsub_sf.o) e:/winavr 20070525/bin/../lib/gcc/avr/4.1.2/../../../../avr/lib/avr5\libc.a(modf.o): In function `modf': (.text.fplib+0x42): relocation truncated to fit: R_AVR
kommen wenn man den Controller Rechenzeit mässig an seine Grenzen bringt. Dann reicht mit hoher Optimierung die Geschwindigkeit aus, um zur Abbruchbedingung eine Aufgabe in der Schleife schon erfüllt zu haben.Mit niedrigerer Optimierung dann unter Umständen nicht mehr.
-
Thread
R_AVR_13_PCREL allerdings auf eigene Datei
aber macht nichts. Ich habe sie jetzt einfach mal mit -mmcu=atmega16 -std=c99 compiliert, ohne Optimierung (damit sie möglichst groß werden). Ich kann das Problem leider in keiner Weise nachvollziehen, weder mit einem ältlichen GCC 4.3.4 noch einem halbwegs aktuellen 4.5.1. Hast du dir diesen
akzeptablel ist, d.h. ist die Priorität A: Codegüte oder B: Interlinkfähigkeit zwischen verschiedenen avr-gcc Versionen. B würde bedeuten, Optimierungen wie die obige nie machen zu können/dürfen. A wird zum Problem, wenn eine Library unabhängig von avr-gcc distrubutiert wird. Hier müsste dann eine Versionierung
-
Thread
Welche Arm-Entwicklungsumgebung? - kommerzielle Nutzung
allerdings niemand -- auch nicht Robert. > evtl. könnte es sein das IAR oder Keil etwas besser als GCC > optimiert, aber selbst dabei wäre ich mir nicht sicher, könnte man mal > untersuchen. Getan. Das Ergebnis ist zwar schon älter, aber immerhin haben sich /beide/ toolchains (Keil bzw RVCT, GCC
eine echte Alternative und dann gibt's noch ein paar mehr. Ausser Keil und IAR bauen fast alle auf GCC auf und haben somit in der Compiler Optimierung keine echten Unterschiede. Jetzt kommts noch darauf an wie gut der Debugger ist, wie gut hardware U-Link / J-Link mit den Compilern arbeiten. Die IDE
-
Thread
Code von Bascom nach C
>2466 Byte kommen nur ohne Optimierung zustande, mit sind es nur 1490. ... >sind es auch ohne >Optimierung nur noch 1790 Byte. Umpf, oder so ähnlich. Alle Zahlen sind falch. 2344 mit Optimierung 4066 ohne Optimierung 2834 ohne Optimierung, ohne delay WinAVR 2009313 Oliver
-
Thread
Vorteile memcmp memcpy
Jörg W. schrieb im Beitrag #5842004: > S. R. schrieb: >> Die vier Funktionen … mit gcc speziell. > > Nein. Nicht nur diese, und nicht nur mit GCC. Die Aussage von S.R. war ein andere, nämlich: Der GCC darf, wenn er den Code des TO sieht, memcpy aufrufen obwohl der TO es nirgends
erlebt habe. Steht in der Manpage: https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Link-Options.html dort unter z.B. -nostdlib oder -nodefaultlibs: "The compiler may generate calls to memcmp, memset, memcpy and memmove." Wenn man größere Strukturen
-
Thread
AVR einlesen und in C Code umwandeln
diesem Beispiel vielleicht noch relativ gut gehen könnte. Man kennt den Compiler, man kennt die Optimierungen, man hat noch einen Teil des Codes (es sei denn es wurde sehr viel geändert). Jemand der sich gut mit dem Code-Generierungteils des AVR-GCC auskennt wäre wohl in der Lage ein Tool zu schreiben
return func1(p, q); } Habe gerade keinen AVR-Compiler hier, deshalb mal mit x86. Das macht der gcc ohne Optimierung aus dem Source: .file "test1.c" .text .type func1, @function func1: pushl %ebp movl %esp, %ebp subl $4, %esp
-
Thread
memtest.c - sollte Schreib/Lesezeiger nicht volatile sein?
Na ja, die "abstrakte virtuelle Maschine" ist der gcc, und der ist nicht allwissend... Wenn du die erste Schleife in die zweite einbaust, dann checkt gcc das, so aber nicht. Schreib doch eine Patch?
gerne auch Interrupts. Vergessenes volatile führt erwartunggemäß dazu, daß das Programm ohne Optimierungen noch geht, aber mit Optimierung aktiviert eben nicht mehr. Sehr beliebter Anfängerfehler.