-
Thread
Sind ALLE Rechenoperationen automatisch 16-bit breit?
bestätigen. War ich grad eben drüber gestolpert, als ich den Vektorcode aus deinem anderen Thread durch GCC jagte. Kam cp r30,r22 cpc r31,r23 brne .L2 bei raus, trotz uint8_t als Zähler. avr-gcc 4.3.4, -O1.
wissen hat als der Compiler hat (oder in der Lage ist herauszufinden), ist das Ergebnis suboptimal. GCC schert sich nicht "einen Dreck" um solche Datentypen. Er beachtet deren Semantik genau und setzt das Programm danach um in IL. Die Optimierungen kommen erst danach, und müssen (oder sollen) alles rausfischen
-
Thread
Mal wieder ne Frage zu "volatile"
Hallo zusammen, wie verhält sich GCC bei eingeschalteter Optimierung wenn eine volatile Variable mehrfach hintereinander gelesen wird. Also beispielsweise: [pre] #define REG (*((volatile unsigned int*)0x1234)) unsigned int temp;
variable = irgendwas; if ((int16_t) *variable - signedintegervariable) nochwas(); } Nun kommt GCC mit einer unverständlichen Warnung von wegen "passing argument of funktion discards qualifiers from pointer target type" oder so ähnlich. Tatsächlich scheint GCC den Typ plötzlich komplett zu ignorieren
-
Thread
Compiler-Einstellung im Code erkennen?
Optimierung oder Wegfall von Debug-Infos verändern.
Wurm drin. Zwar kannst du per #ifdef __OPTIMIZE__ oder #ifdef __OPTIMIZE_SIZE__ abtesten, ob Optimierung (auf Größe) aktiviert ist, aber wenn du das brauchst, hast du vermutlich einen Denkfehler im Programm. Erzeugen / Nichterzeugen von Debug-Information wird niemals den von GCC erzeugten Code verändern
-
Thread
C vs. C#: float Performance
dasselbe Objekt bezeichnen. Und das führt dann zu ganz einfach durchzuführenden schlagkräftigen Optimierungen.
32/64 Bit verwenden. Unter 32 Bit kann man das dem gcc mit der Option "-mfpmath=sse" beibringen.
-
Thread
Arrays, Pointer und Schleifen (avr-gcc)
delay.h stimmt! > Warum die Warnug kommt, steht doch in der Meldung: Du hast die > Compiler-Optimierung nicht aktiviert. Ach, okay, danke! Ich hatte zwar den Takt angegeben gehabt und bekam beim compilieren folgende Meldung: avr-gcc.exe -mmcu=atmega32 -Wall -gdwarf-2 -DF_CPU=3686400UL -O0 -fsigned-char
GCC hält sich daran. Ein anderes Verhalten wäre auch nicht ISO-konform.
-
Thread
GCC Compiler + ATXMEGA E = Schrott?
ATXMEGA8E5 mit dem AVR GNU C Compiler in Atmel Studio 7. Nehme eine nacktes (neues) Projekt (file>new: GCC Executable C project). Compiler-Optimierungen schalte ich ab. Dann hacke ich folgenden simplen Code ein: [c] #include <avr/io.h> uint8_t a=1; int main(void) { while (1) { if (
Das ist kein Bug, sondern Optimierung. Benutze volatile für a, dann sieht Dein Ergebnis anders aus.
-
Thread
Code Optimierung (Geschwindigkeit) AVR, C
: Bei den Optimierung 0,1 und s ist das Programm zu langsam. Bei der Optimierung 2 werden irgendwelche Abfragen wegoptimert (wahrscheinlich busy waits) die dazu führen, dass der µC nicht mehr schlafen geht. Als Kandidat
sollte ein Programm mit allen Optimierungsstufen (O0,O1,O2 und Os) laufen. Die Delay Routinen von GCC gehen ohne Optimierung nicht - das ist aber eine Ausnahmen. Wenn es mit Optimierung nicht geht, ist das oft so etwa wie ein Fehlendes volatile oder ein Wartescchleife die abhanden kommt. Bei einem
-
Thread
static global
. GCC hat ja auch den Schwenk zum offiziellen ARM-ABI gemacht.
Yalu X. schrieb im Beitrag #3297389: > Zumindest der GCC scheint dies aber nicht zu tun, nicht einmal > bei 1-Byte-Strukturen. Interessant, ich habe das mal ausprobiert: Auf ARM EABI Thumb2 und AVR übergibt er structs per Register (auch ohne Optimierungen
-
Thread
An alle Echten Programmierer: Fortran lebt!
/könne/, denn der praktische Beweis ist ja da. ;-) Im Gegenzug sind generische Compiler (wie GCC) mit ihrem FORTRAN-Frontend natürlich nicht besser als der äquivalente C-Compiler. Oder anders gesagt: würden sich die genannten Hersteller mit gleichem Eifer an die Optimierung eines Compilers
Ist bei Anweisungen mit arithmetischen Ausdrücken beim GCC denn noch so viel Optimierungspotenzial? Wenn ich zumindest für den AVR-GCC mal gelegentlich in den generierten Assemblercode reinschaue, ist bei solchen Anweisungen auch mit handgeknüppeltem Assembler
-
Thread
Probleme in C - kann kein EEPROM
Datei entfernt), meiner eigenen Historie nach wurde dieser Fehler am 04.06.2013 gefixed. Zur Optimierung von C-Compilern: so ein ganzer Vollidiot, wie er im Buche stehen soll, ist das beileibe nicht (das war es vielleicht mal in den 80ern), der gcc macht da keinen so schlechten Job. Viele Grüße
Hans W. schrieb im Beitrag #6711672: > Ähm... ‘#pragma GCC optimize’ bekannt??? nein, aber danke dafür! https://www.boecker-systemelektronik.de/Seite-/-Kategorie-1/Vorsicht-bei-Compiler-Optimierungen
-
Thread
C - Array Zugriff außerhalb Definition, keine Speicherverletzung?!
Indices fast nie zur Compilezeit bekannt sind und durch Optimierung mehr potentielle Stellen gefunden werden können. Warum im Beispiel keine Warnung ausgegeben wird, da musst du nen GCC-Entwickler fragen... Ohne Optimierung wird jedenfalls auch keine Warnung
schrieb im Beitrag #4610656: > Warum im Beispiel keine Warnung ausgegeben wird, da musst du nen > GCC-Entwickler fragen... Ohne Optimierung wird jedenfalls auch keine > Warnung ausgegeben obwohl außerhalb von array[] zugegriffen wird. Interessanterweise wird gewarnt, wenn man das Array global macht
-
Thread
memcpy auf ARM Cortex A9 & Linaro
wie wäre es mit einem #define #define memcpy memmove oder beim gcc Aufruf gcc -Dmemcpy=memmove
, wieviele Parameter der Programmierer des Compilers bei der Optimierung des Builtins berücksichtigt.
-
Thread
schlechte Optimierung (GCC io.h) ATxmega
Register */ register8_t DATA; /* Data Register */ } SPI_t; [/c] Ich verstehe nicht warum der GCC nicht auf eine statische Adresse Optimiert. Denn die Adresse ändert sich ja nicht sondern nur der Inhalt. z.B. bei: [c] SPIE.CTRL = 0xBB; [/c] Macht der GCC es richtig und setzt dafür eine
Eigentlich gehört das ins GCC-Forum. Das Problem entsteht beim tree→RTL Lowering.
-
Thread
Zu große Daten oder Code
der Code im Anhang Deine selbstgestrickten Verzögerungschleifen funktionieren nicht wenn die Optimierung eingeschaltet ist, nutze _delay_ms() vom AVR GCC. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29
Ja Ich habe einen 20MHZ Quarz. Wenn ich die Optimierung einschalte dann blinkt gar nichts mehr! Ohne Optimierung blinkt es irgendwo im Millisekunden Bereich. Es könnte sein dass der Controller abstürzt. Leider habe ich gerade kein Oszi um zu sehen wie
-
Thread
AVRGCC: Konstanten optimieren
Hallo, ich habe das Problem, dass der GCC 2 Konstanten teilen soll. Diese rechnet er aber nicht vorher aus, sondern will diese während der Laufzeit ausrechnen. Wie bekomme ich den GCC dazu, diese doch bitte vorher auszurechen? ====== void
Ich habe auch GCC 3.4.4: ======================================= avr-gcc (GCC) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty
-
Thread
AVR-C Anweisungsreihenfolge NICHT dem Compiler überlassen..
en.cppreference.com/w/c/atomic http://en.cppreference.com/w/c/atomic/atomic_thread_fence https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
Output-Parameter gelten immer als geclobbert (werden logischerweise immer überschrieben). Lies einfach mal die gcc-Doku zum Inline-Assembler.
-
Thread
Frage zur Code-Optimierung
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Optimierungsgrad Ich weiß nicht in welcher Form das jetzt schon in dem Makefile steckt, aber sowas wie -Os müsste da z.B. noch rein. Einfach mal die Zeiten für die verschiedenen Optimierungsgrade
Wie wäre es mit einer intelligenteren Optimierung? Wenn ich das richtig sehe möchtest du die Drehzahl ermitteln, wahrscheinlich per Interrupt indem du die Ticks pro Zeiteinheit zählst. Die Berechnung ist also NUR NÖTIG wenn du die Drehzahl wirklich
-
Thread
Richtiges C++ hardwarenah
Irgendwer schrieb im Beitrag #3901199: > Da könnte einem schon der Verdacht > kommen das beim Thema Optimierung zumindest beim gcc noch einiges an > Luft für Verbesserungen vorhanden ist. Schau einer an. Aber man kann ja immer noch ein paar Hundert bis Tausend Euro in einen "ordentlichen" Compiler stecken
schrieb im Beitrag #3901199: >> Da könnte einem schon der Verdacht >> kommen das beim Thema Optimierung zumindest beim gcc noch einiges an >> Luft für Verbesserungen vorhanden ist. > > Schau einer an. Aber man kann ja immer noch ein paar Hundert bis Tausend > Euro in einen "ordentlichen" Compiler
-
Thread
lpc1700 - ARM Cortex M3 von NXP: Endlich!
Errata 2.6). Dazu kommt dass diese Limitierung nur nach der Einführung von bestimmten Compiler Optimierung entdeckt werden konnte. Diese Optimierung ist nur im Summer 08 von IAR und GCC entwickelt & implementiert worden, d.h. nur ab dann könnte man die Schweirgkeite sehen (ca 8 Monate nach Produkteinführung
). > > Dazu kommt dass diese Limitierung nur nach der Einführung von bestimmten > Compiler Optimierung entdeckt werden konnte. Diese Optimierung ist nur > im Summer 08 von IAR und GCC entwickelt & implementiert worden, d.h. nur > ab dann könnte man die Schweirgkeite sehen (ca 8 Monate nach > Produkteinführung
-
Thread
String als Parameter übergeben
Die Optimierung hat versehentlich auf -Os (für Size) gestanden weil die Datei später zum Projekt hinzugefügt wurde. Seit die Optimierung am GCC abgeschaltet ist, tut auch der Debugger wieder wie erwartet. Leider
Janvi schrieb im Beitrag #2686205: > Die Optimierung hat versehentlich auf -Os (für Size) gestanden weil die > Datei später zum Projekt hinzugefügt wurde. Seit die Optimierung am GCC > abgeschaltet ist, tut auch der Debugger wieder wie erwartet.
-
Thread
Linker LD Optimierung
Hallo, welche Möglichkeiten gibt es, die Ausgabedatei mit dem GNU Linker LD zu optimieren. Hintergrund: Einige Dateien werden von mehreren Compilern compiliert. In diesen Dateien befinden sich aber Funktionen, die in einzelnen Projekten garnicht gebraucht werden. Wegen den Übersichtlichkeit möchte ich diese Dateien aber auch nicht auseinander nehmen. Auch das Copy und Paste in die einzelnen Projekte kann nicht die Lösung sein. Kann ich das über Bibliotheken machen? Wie findet der Linker heraus, welche Funktionen benötigt werden? In der Dokumentation habe ich leider nichts passendes gefunden
-
Thread
AVR2054 debuggen [erledigt]
Chris schrieb im Beitrag #2990041: > Könntest du den Beitrag bitte ins GCC-forum verschieben. Nein, von daher habe ich ihn hierher geschoben. Du hast, entgegen deiner Auffassung, /kein/ Problem mit dem GCC (daher konnte dir dort auch keiner helfen), sondern eins mit
keinen vernünftigen Grund, warum man das so verkorkst implementieren will, zumindest nicht für den GCC. Man kann die Debuginformationen auch grundsätzlich mit anfordern, ohne dass das die Optimierung beeinflussen würde.) Inwiefern das durch die jeweiligen Atmel-Studio-Projekt-Dateien genauso gehandhabt
-
Thread
unerklärliche Code-Optimierung
Platine: }; [/c] Der Compiler haut mir die 'while-Schleife' komplett raus (auch ohne Optimierung!). Unverschämtheit ;-) Wie bekommt man das weg?
Mit welchem Compiler arbeitest du? Falls mit dem GCC: Wenn du die Option -Wall aktivierst, erhältst du für die Zeile mit dem while eine Warnung, die dich auf deinen Fehler hinweist: warning: comparison is always false due to limited range of
-
Thread
C-Präprozessor: Frgae zum Auflösen von Makros
https://gcc.gnu.org/onlinedocs/cpp/Macro-Arguments.html https://gcc.gnu.org/onlinedocs/cpp/Argument-Prescan.html#Argument-Prescan https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html#Macro-Pitfalls ===
implementieren. Ein "Inlinen" der Funktion hat nicht immer >> zum gewünschten Resultat geführt, In GCC kann mit dem Attribut always_inline zusätzlich zu inline das Inlining erzwingen. > Wenn sonst alles gleich bleibt, sollte die Optimierung -Os > Funktionsaufrufe produzieren, im Gegensatz zu -O2
-
Thread
Test von Gleitkommazahl auf 0 führt zum Aufruf von __cmpsf2
schreiben, da ein typecast auf einen int Typ ja wieder eine Konvertierungsfunktion aufrufen würde. GCC Version ist 4.5.3 unter Kubuntu mit Kernel 2.6.32-34, Optimierung steht auf Level 3.
but not required to implement all (or any) of the unordered bcc operations. */ [/pre] http://gcc.gnu.org/viewcvs/trunk/gcc/optabs.c?content-type=text%2Fplain&view=co Um es einfach zu machen, müsste erst diese Restruktion beseitigt werden. Aber ähnlich Restriktonen gibt es für viele andere Pattern
-
Thread
default von Switch wird nicht abgearbeitt
>Jedenfalls sagt das AvrStudio beim >erstellen eines bookmark das dieser Teil vom Code der Optimierung zum >Opfergefallen ist. Das eine hat mit dem anderen nichts zu tun. Durch die Optimierung kann es schon sein, das der dahinterliegende Asm-Code irgendwo und noch zerfasert herumliegt, so das
Der Code funktioniert mit Optimierung nicht! Um den Fehler zu finden (Crc ist immer Falsch ) ist mir aufgefallen das der Defaultblock nicht erreicht wird. Hingegen ohne Optimierung geht der Code und es wird auch dieser Defaultblock
-
Thread
gcc bug (diesmal wirklich): "shift count is negative" Gesperrt
Schön. Eröffne nen Bug: https://gcc.gnu.org/bugzilla/
Wshift-count-negative] 6 | return x << shift; | ~~^~~~~~~~ $ avr-gcc -v Using built-in specs. Reading specs from /usr/local/lib/gcc/avr/9.1.0/device-specs/specs-avr2 COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/avr/9.1.0/lto-wrapper Target: avr
-
Thread
Stackinitialisierung durch den Compiler
was ein Asembler-Programmierer machen würde. jgdo schrieb im Beitrag #4025726: > Da keine Optimierung an ist, werden alle Variablen als volatile > behandelt [...] NEIN! Diese Variablen sind /nicht/ volatile! Auch ohne Optimierung gibt es Stellen, wo gcc Volatiles und nicht-Volatiles unterschiedlich
eine besondere Rolle, auch wenn der Code nicht optimiert wird, denn Semantik ist unabhängig von Optimierungen. > der Compiler weiß also nicht, was davor war oder danach kommt. Ohne Optimierung (bzw. mit -O0, was auf Host-Resourcen optimiert) kommt das hin. Mit Optimierung wird der Code jedoch von
-
Thread
avr-gcc -mrelax buggy
gefunden. Reporte ihn. Aber aus deinem Post werde ich nicht schlau. Und die Dokumentation von avr-gcc [1] zu -mrelax läßt den Zusammenhang mit dem gesagten zumindest unwahrscheinlich erscheinen. [1] https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html
noch gepflegt? > Aber aus deinem Post werde ich nicht schlau. Und die Dokumentation von > avr-gcc [1] zu -mrelax läßt den Zusammenhang mit dem gesagten zumindest > unwahrscheinlich erscheinen. > > [1] https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html Ich liefere gerne Infos nach.
-
Thread
MC PIC - Warum diese Ungleichbehandlung?
und -Bootloader (20 Einträge) • AVR-Projekte (103 Einträge) • AVR-Tutorial (27 Einträge) • Avr-gcc (12 Einträge) • Avr-gcc Tutorial (10 Einträge) [1] [[Spezial:Kategorien]]
PICs gibt. Die "freien" Versionen werden nach 60-tägiger Testphase > durch die dann wegfallende Optimierung praktisch unbrauchbar. Das ist nicht korrekt. Für PIC32 kann sehr wohl der ganz normale mips-elf-gcc verwendet werden. Es braucht gar nix von Microchip. Es ist nicht bequem, aber es geht. Wer
-
Thread
avr-gcc-10 - "volatile deprecated [-Wvolatile]" Warnungen
// Prescaler 8 TCCR1B = TCCR1B & ~( _BV(CS12) | _BV(CS11) | _BV(CS10) ); [/c] Die Optimierung in ein einzelnes sbi, falls das register im passenden Adressbereich liegt, macht der Compiler trotzdem. (*) ich 'abe gar kein gcc 10 ;) // -----------------------------------------------
Hallo, wenn ich keine Tomaten auf den Augen habe macht der gcc Compiler in mh Bsp. in allen 3 Fällen zuerst eine Addition mit b. Danach erfolgt eine unterschiedliche "Optimierung" in der Zuweisung des Ergebnisses an a. Ich kann da erstmal kein Problem erkennen.
-
Thread
Wertzuweisung Arduino - Kann mir das jemand erklären?
will und keine dazu kompatiblen Erweiterungen, oder -std=gnu99 wenn man GNU-C99 will etc. https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/C-Dialect-Options.html https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/C_002b_002b-Dialect-Options.html Bei Verwendung von avr-g++ sollte man sich auch darüber klar
:-) https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Code-Gen-Options.html#index-fwrapv
-
Thread
_delay_ms() falsches timing
Wall -g2 -gstabs -O3 -funsigned-char -funsigned-bitfields -mmcu=atmega2561 -DF_CPU=14745600UL -avr-gcc version: 4.1.1 (WinAVR 20070122) ist doch alles da : - F_CPU -define (stimmt mit MCU-quarz überein) >> quarz-clk auch nachgemessen - divide clk by 7 fuse-bit ist nicht gesetzt - optimierung
prog´n. >> wär vielleicht auch nochmal was das in dem AVR-Tutorial VERSTÄRKT zu erwähnen ist: Optimierung: WAS?(wird verändert)-WANN?/Optim.-Stufe oder halt verweis aufs GCC manual - dass man sich dazu vorher mal einen kopf macht ... ich hab noch bis 31.1. zeit - dann is projektabgabe - ich
-
Thread
ARM-GCC versteht den Witz nicht.
Walter T. schrieb im Beitrag #6748674: > ARM-GCC 5.4.1 -O3: a ist false > ARM-GCC 5.4.1 -Os: a ist true Mein gcc ist meistens auch humorlos. Mit -Wall kommentiert er es als das, was es ist: a.c:8:33: warning: comparison with string literal
z.B. nethack spielen ;-) https://feross.org/gcc-ownage/
-
Thread
C Programm funktioniert nicht
dann denselben Effekt wie exit(0) haben muss. Ansonsten ist des Pudels Kern sicher die Optimierung; ein optimiertes C-Programm zu debuggen, ist meistens zwecklos. Wenn alle Stricke reißen, schau mal ins Assembly (beim gcc zu erzeugen mit 'gcc -S').
fprintf( "%s Test ist jetzt, \t ", test); }; for(;;); }; [/c] Schlägt die Optimierung mit absoluter Sicherheit zu, da der Text im Körper der if-Anweisung niemals erreicht werden kann. Mit meinem AVR-GCC ergibt das folgendes Assembly: [avrasm] main: /* prologue: frame size=0
-
Thread
Stackproblem ATMEGA128 und GCC
OK, thanks. Ist aber komischerweise nur in diesem 'case 140:' so. Ich schmeiß mal ALLE Optimierungen raus, dann müsste es... vielleicht.... tbc....
Andreas Paulin wrote: > Also... ich hab die Optimierung rausgenommen, daraufhin > bekomme ich geliefert: > "StackDiff: 0 Byte" Logisch, dann wird diese Optimierung ja auch nicht gemacht. > Schön, aaaaaaaaaber, das wars nicht. Kiste schmiert immer
-
Thread
UART initialisieren / gcc
Hallo Leute, ich versuch mit WinAVR ein Programm zu schreiben, das mir über den UART meines ATmega32 ein paar Zeichen zum PC sendet. Dafür hab ich eine Funktion UART_init geschrieben die mir den UART initialisieren soll. Compilieren funktioniert ohne Probleme, beim debuggen spring er allerdings nicht in UART_init. Kann es sein das der Compiler das Unterprogramm wegoptimiert?? WAs kann ich dagegen machen? Bei Gelegenheit vielleicht noch ein Tip ob die Übertragung auf diese Weise funktionieren könnte! Danke, Stefan Hab das Programm mal drangehängt. #include
-
Thread
Wie Assembler einbinden?
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Inline-Assembler -- viel schöner wird's nicht
Compiler manchmal "a bisserl umständlich" > zu Werke geht. Z.B.... Komisch. Hast du etwa die Optimierung ausgeschaltet? Mein AVR-GCC macht aus [c] PINB = (1 << PIN3) | (1 << PIN4); PINB = (1 << PIN3) | (1 << PIN4); [/c] folgendes: [avrasm] ldi r24,lo8(24) out 54-
-
Thread
[c] wie wirft man UART-Daten weg?
ja, dass es sich um eine "besondere Speicherzelle" handelt, für die die üblichen Annahmen, die Optimierungen ermöglichen, nicht gelten. Daher keine Warnung. > Ich kann mir auch nicht vorstellen, dass ein gcc für einen STM32 dümmer > ist als für einen AVR, s.a. Ist es auch nicht, da es eine Frontend-Warnung ist, und das ist für gcc und avr-gcc natürlich identisch.
-
Thread
Allgemeine Codeoptimierung in C für uC
von -3 >> 1 :-) Compiler wissen nämlich auch das: unter welchen Umständen ist eine derartige Optimierung überhaupt möglich.
[[AVR-GCC-Codeoptimierung]] Die allgemeinen Sachen gelten nicht nur für AVR GCC.
-
Thread
Effizienz memcpy
Programmierer schrieb im Beitrag #6714883: > Die meisten memcpy-Versionen (z.B. die in der vom ARM-GCC > verwendeten newlib) benutzen sehr clevere Optimierungen, teilweise auch > in Assembler implementiert, welche sehr wohl 32bit oder mehr auf einmal > kopieren, natürlich unter Beachtung des Alignments
Version von memcpy ist die dein Programm > nutzt? Die meisten memcpy-Versionen (z.B. die in der vom ARM-GCC > verwendeten newlib) benutzen sehr clevere Optimierungen, Newlib ist optimiert, newlib-nano aber benutzt die o.g. Variante mit einzelnen Bytes weil die kleineren Code erzeugt. Da kann man ergo
-
Thread
Wie Assembler ISR in C integrieren ?
gesagt bin ich mir immer unsicher was ich auswählen muß wenn ich ein neues Projket in AS anlege. GCC C Executable GCC C Static Library GCC C++ Executable GCC C++ Static Library Eine gute Erklärung auf deutsch hatte ich noch nicht gefunden. Vielleicht kann das jemand kurz erklären? Danke.
bin ich mir immer unsicher was ich > auswählen muß wenn ich ein neues Projket in AS anlege. > > GCC C Executable > GCC C Static Library > GCC C++ Executable > GCC C++ Static Library Nun, wenn du ein "C++ Executable" anlegst, dann heißt das, dass du in C++ programmieren willst. Kann man
-
Thread
Compiler verhält sich seltsam
Es muss ja nicht immer ein Fehler sein, den man verbessert. Ich sehe sowas eher als eine Art Optimierung.
nur Plan B: gcc-Sourcen besorgen, verstehen, selber verbessern... Oliver
-
Thread
Problem durch Optimierung -Os
handelt und den Speicher reserviert. Dummer Gedanke, der dann durch den Erfolg beim Verzicht auf Optimierung auch noch gefördert wurde. Bezüglich Warnungen war dar Hinweis darauf, dass ohne Optimierung die Funktionen aus dem Header 'delay.h' nicht funktionieren würden das einzige. Beim Compilen mit -Os
interessieren, hätte > der Compiler ein 'Warning' ausgeben müssen? Kompilierst du mit -Wall -Wextra (falls gcc, sonst halt entsprechende Optionen bei deinem Compiler)?
-
Thread
AVR-GCC selbst bauen - Unter Linux für Windows?
gcc\avr\5.3.1\avr25 6.966.108 avr-gcc-5.3.1-win64\lib\gcc\avr\5.3.1\avr25\[Dateien] 3.483.708 avr-gcc-5.3.1-win64\lib\gcc\avr\5.3.1\avr25\tiny-stack 3.482.400 avr-gcc-5.3.1-win64\lib\gcc\avr\5.3.1\avrtiny 3.675.846 avr-gcc-5.3.1-win64\lib\gcc\avr\5.3.1\avrxmega5 3.605.828 avr-gcc-5.3.1-win64\lib\gcc
-
Thread
Probleme mit gdb
was dazu. Ich möchte aber nur mal dumm fragen. Welche Fehler können den entstehen wenn ich die Optimierung wegmache, den Code dann modifiziere und die Optimierung wieder reinmache ? Gruß Martin
Der Compiler könnte Codestellen wegoptimieren, die er ohne Optimierung nicht angefasst hat. Somit ist es möglich, dass sich Dein Programm anders verhält, was natürlich nicht unbedingt sofort sichtbar ist. Wie gesagt ich kenne beim GCC im Zusammenhang mit C++ keine
-
Thread
avr-gcc 4.8.1: Fehler durch Optimierung / inline function
lernen. ;-) Meine Ergebnisse so weit: 1. M.E. stimmt das obige Listing für USI_UART_start mit Optimierung genau mit dem C Quelltext überein, Zeile für Zeile. Das ohne Optimierung dagegen... ist etwas verwirrend. Da müssen wohl noch ein paar andere Programmteile verbacken sein. 2. Im *.lss mit Optimierung
37e - 380 und 392 - 3aa Das sieht eigentlich auch nicht verkehrt aus. In der *.lss ohne Optimierung finde ich jedoch nicht einmal die Schreibzugriffe auf 0x01. Wie wird denn das hier gemacht? Ich habe nun gcc-avr 4.9.2 installiert. Mit Optimierung bekomme ich dasselbe Fehlerbild. Und ohne
-
Thread
Ist x>>16 das Gleiche wie x/65536?
Ich habe es einmal kurz getestet. Selbst ohne Optimierung (-O0) macht der gcc aus (int32_t) /= 65536: [code] 141b asrs r3, r3, #16 [/code] Also einen Shift-Befehl, der das Vorzeichen erhält.
Detlev T. schrieb im Beitrag #5203467: > Ich habe es einmal kurz getestet. Selbst ohne Optimierung (-O0) macht > der gcc ... einen Shift-Befehl, der das Vorzeichen erhält. Das ist prinzipiell falsch, weil in die falsche Richtung "gerundet" wird. Siehe http://codepad.org/s9bcOmkk oder http
-
Thread
Kopieren von 64bit werten unterbrechbar?
Funktion auf den Parameter zuzugreifen. Mit gcc 4.2.4 und k7/pentium4 macht er's jedenfalls nicht so und verwendet klassisch FLD/FSTP. Ich habe hier leider grad keinen gcc 4.4 für x86 rumliegen. Kommt das nur bei -march=core2, oder auch bei anderen
A. K. schrieb im Beitrag #1856322: > Interessant. Intel hat ja ein paar Optimierungen drin, die 2 Mikroops zu > einem kombinieren - ob das hier wohl dazugehört? Eher nicht. Wie gesagt eher ein Bug oder Seiteneffekt einer anderen Optimierung. "-O2" verwendet FLD/FSTP, und der
-
Thread
EEPROM bei Atmega 8
Ernst schrieb im Beitrag #2480651: > Dann hängt das Funktionieren auch noch davon ab, ob die Optimierung > aktiviert ist. Ist sie es? Was denn für eine Optimierung ? > PS: Wieso überhaupt eigene EEPROM-Funktionen? Gibt es denn eine fertige ?
F_CPU 3686400 // Taktfrequenz des myAVR-Boards #include <avr\io.h> [/C] sieht sehr nach WinAVR-gcc aus. Also hast du auch die Optimierungen zur Verfügung. Du musst nur noch die Stelle in deiner Entwicklungsumgebung finden, in der du sie einstellst.