-
Thread
Eclipse Atmelstudio6.2 unterschiedliche Codegrössen ?
mein Projekt ca. 7Kb gross. Das passt noch auf ein Atmega88. Baue ich das Projekt mit Eclipse und avr-gcc sagt mir avr-gcc das mein Projekt um 1052 Bytes zu gross ist. Habe die Optimierung schon geprüft ist in beiden Fällen -Os also Optimierung auf Grösse. Auf den ersten Blick sehe ich bei den Compilerflags
von Atmel hat nichts mit der von AVR-GCC zu tun. Atmel GCC 3.4.5 basiert letztenendes auf GCC 4.8.1
-
Thread
Assembler Grundlagen (einbinden) (ATxmega128A1 + AVR Studio 5)
jetzt in Assembler programmieren, und > irgendwie in meinen jetzigen C Code einbinden. Bei der GCC Toolchain gibt es dafür das AVR GCC Inline Assembler Cookbook. Dein Vorhaben ist aber weit über Anfängerlevel! An deiner Stelle würde ich unbedingt versuchen das Problem komplett in C in den Griff zu
Das bereits erwähnte AVR GCC Inline Assembler Cookbook erklärt das. Das ist allerdings nicht anfängerfreundlich - es ist halt kein Thema für Anfänger. Es kann helfen, aus zwei Quellen gleichzeitig zu lernen. Im Roboternetz-Wiki
-
Thread
Attiny 841 und PRR
Datenblatt) Läge die Adresse im IO Bereich, wäre es nur 1 ASM Statement. Und ja, das kann der GCC erkennen und mit -Os auch soweit optimieren.
rückzusetzen ist. Und wenn die Zieladresse von SBI/CBI adressiert werden kann. Und möglicherweise muß die Optimierung noch angeschaltet sein.
-
Thread
Ideen um CRC-Routine zu beschleunigen? (AVR, gcc)
von Hand in Assembler und optimier die nach bestem Wissen und Gewissen. Dann vergleich mal, was der GCC ausspuckt -- evtl. gibt dir das noch ein paar Anregungen. Wird dann natürlich als Inline-ASM verbaut.
Mach mal ne for-schleife draus und schalt die Optimierung ein, i = 12 würde ich als konstante definieren. dann kann der Compiler da eventuell was besseres draus bauen.
-
Thread
AVR-GCC: Frage zu Constant Folding / Constant propagation
#3247954: > Frage: Kann man sich auf dieses Verhalten verlassen? Der Compiler darf im Rahmen von Optimierung das Ergebnis nur dann ändern, wenn auch ohne Optimierung unspezifizierte oder undefinierte Schritte auftreten. Sind jedoch alle Schritte von der Sprache klar definiert und spezifiziert, dann darf sich das Ergebnis durch die Optimierung nicht verändern.
-
Thread
if-Abfragen verpönt?
ersten Moment könnte man denken, dass das hoffnungslos überkompliziert ist. Vorausgesetzt, size ist GCC wahrend der Kompilierung als Konstant bekannt, dann wird GCC diese Funktion jedoch inlinen und automatisch und korrekt Bitmaskierung oder while-Schleife wählen. Mit etwas mehr Trickserei kann man dann
Sam P. schrieb im Beitrag #2889622: > > Nur mal am Rande, für diejenigen, die GCC's Optimierungsfähigkeiten > nicht kennen: Interessiert eigentlich gar nicht. Nicht alles wird mit dem GCC gemacht und wer portablen schnellen Code schreiben will der verläßt sich nicht auf so etwas
-
Thread
AVR Bootloader in C - Artikel
schreiben. Dein WinAVR ist in ziemlich alt. Ich habe für das kompilieren das AVRStudio 6.2 mit der gcc.Verision: gcc version 4.8.1 (AVR_8_bit_GNU_Toolchain_3.4.4_1162) benutzt. Evtl. wäre es eine gute Idee zumindest den gcc mit der gnu toolchain zu updaten... mein avr-libc ist vermutlich 1.8 (muss
Compiler Optimierung -Os läuft nicht geändertes Programm: 16188 Byte mit Compiler Optimierung -O1 läuft Ich bin da ziemlich ratlos, kann mir vieleicht jemand weiterhelfen? Gruß jan
-
Thread
Speicher des Microcontrollers
Hier auch noch etwas dazu: http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung
anstatt eine Konstante ?!? Weil laufen tut das Programm ja, nur das ich ( vor dem anschalten der optimierung) zu wenig speicherplatz hatte... was sich jetzt ja auch erledigt hat dank eurer hilfe
-
Thread
Lauflicht in C
while(1){ for(;;){ loop_until_bit_is_set(UCSRA, UDRE); UDR = 0x41; } } [/c] gcc version 4.1.1, -O0 (optimierung aus) avr-size output mit for-loop: text data bss dec hex 92 0 0 92 5c mit while-loop: text data bss dec
hmmm... interessant. ich hab mit AVR Studio 498 Build und AVR-GCC bei Optimierung -Os der MCU ist ein Mega8; da hab ich (nur durch Änderung der Schleife) 2 Byte einsparen können. Allerdings muss ich dir Recht geben, jetzt gerade ein kleines Stück Code kompiliert
-
Thread
Vertauschen von drei Variablen
dass der Überlauf niemals stattfindet und den Code denentsprechend optimieren. Aktuell z.B. hat gcc 4.8.0 eine Optimierung, bei der ein SPEC Benchmark wegen undefiniertem Verhalten kaputt geht: http://blog.regehr.org/archives/918
Mac schrieb im Beitrag #3100604: > Aktuell z.B. hat gcc 4.8.0 eine Optimierung, bei der ein SPEC Benchmark > wegen undefiniertem Verhalten kaputt geht: > > http://blog.regehr.org/archives/918 "GCC pre-4.8" - Soweit ich das verstanden habe, hat der
-
Thread
Code wird nicht in richtiger Reihenfolge abgearbeitet
Markus schrieb im Beitrag #5745795: > stell mal die optimierung von -O1 auf -Og, so hats bei mir dann perfekt > funktioniert. Wenn der Code ohne Optimierung funktioniert, aber mit Optimierung nicht, dann ist der Code kaputt.
Kaj schrieb im Beitrag #5745962: > Markus schrieb: >> stell mal die optimierung von -O1 auf -Og, so hats bei mir dann perfekt >> funktioniert. > Wenn der Code ohne Optimierung funktioniert, aber mit Optimierung nicht, > dann ist der Code kaputt. Es ging doch darum daß
-
Thread
Atmega SPI Geschwindigkeit (Arduino schneller als C?)
ist doch Geschmackssache. Jede hat ihre Vor- und Nachteile. @Leo C. "E:\Atmel Toolchain\AVR8 GCC\Native\3.4.2.939\avr8-gnu-toolchain\bin\avr-gcc.exe" -v Using built-in specs. COLLECT_LTO_WRAPPER=e:/atmel\ toolchain/avr8\ gcc/native/3.4.2.939/avr8-gnu-toolchain/bin/../libexec/gcc/avr/4.7.2/lto-wrapper.exe
schreiben sind. Nur, wenn man 32..128kb mit weiterem sinnvollem Code füllen will, dann ist das via GCC einfacher und schneller. Die Optimierungs-Algorithmen mögen viel simpler sein, aber die Geschwindigkeit und Ausdauer mit der der GCC sie runterspult sind manuell nicht erreichbar. Nicht immer nur Einzelteile
-
Thread
ISR effizient verteilen
Endpoint-spezifischen Handler vermerkt sind und verzweige dann nach Bedarf. Ich arbeite mit C (avr-gcc). Kann ich diese spezifischen Handler in die ISR inlinen, auch über Dateigrenzen hinweg? Was muss ich dem gcc dafür mitteilen? Oder muss ich den Preis eines indirekten Funktionsaufrufs in der
Beitrag #4973380: > automatisch? Denn das kann ich mir nicht vorstellen. Ich weiß nicht, ob der gcc das tut. Aber ich halte es nicht für unmöglich. Es müss(t)en halt mehrere Optimierungen zusammenarbeiten. Ich denke aber, dass eher das switch rausfliegen wird und Arithmetik auf die Tabelle angewendet
-
Thread
ISR viel zu mollig
schrieb im Beitrag #2920217: > Was liefert den der Compiler mit aktivierten > Geschwindigkeits-Optimierungen Pro- und Epilog normaler ISRs sichern / restaurieren /immer/ R0, R1 und SREG, unabhängig vom Optimierungsgrad oder sonstigen Optionen, siehe http://gcc.gnu.org/PR20296 Bjorn Haase dazu
back-end does not easily permit to improve this case Zu Deutsch: Es ist sehr aufwändig, diese Optimierung in avr-gcc einzubauen. I.w. bedeutet es, einen Großteil des avr-Backends von GCC neu zu schreiben, nur um eine handvoll Instruktionen zu sparen. Wenn du dir anschaust, wieviel Entwickler dazu
-
Thread
Delay bei ATtiny4
Code nicht optimiere. Aber dadurch braucht PORTB=0x00; auch mehrere Befehle. Wenn ich wieder die Optimierung einstelle, dann wird meine Schleife einfach wegoptimiert...
man diese brainf**ck Architektur abfragen kann... http://distribute.atmel.no/tools/opensource/avr-gcc/gcc-4.5.1/32-gcc-4.5.1-avrtiny10.patch
-
Thread
gcc optimiert zu viel
Hallo zusammen, ich habe folgende (abgespeckte) Zeilen, die einen Dreiecktausch durchführen: [code] uint8_t A[10], B[10]; uint8_t* temp; uint8_t* pA =&A[0]; uint8_t* pB =&B[0]; temp =pA; pA =pB; pB =temp; [/code] Wie schaffe ich es, dass der Compiler mir diese Zeilen nicht wegoptimiert? Die triviale Lösung "Optimierung deaktivieren" gilt aber nicht. Danke und Grüße Jörg
-
Thread
Optimieren von ungenutzter Variable verhindern
optimiert die Variable raus. Wie kann ich dieses Verhalten am besten unterbinden, ohne jedoch auf Optimierungen zu verzichten? MfG Hexfile
main.c:270: warning: passing argument 1 of 'putnum_uh' makes integer from pointer without a cast avr-gcc -mmcu=attiny85 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=10000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT util.o -MF dep/util.o.d -c ../util.c avr-gcc -mmcu
-
Thread
AT91SAM7S: einheitlicher Startup-Code
: single gcc-Version 4.1.0 Wer dazu Informationen hat, bitte bescheidsagen! Schöne Grüße, Clemens
Nutze bisher selbst zwar C++ kaum auf µC, aber man kann nie "zuviel" wissen. Die unzulaengliche Optimierung ist mir bisher nicht aufgefallen. Das Interesse an "C++ mit arm-elf-gcc" ist realtiv gross (Forenbeitraege, e-mails). Am Einfachsten duerfte es sein, "Vorher/schlecht" und "Nachher/gut" an einem
-
Thread
Digikey teurer, Vivado unter Jahresabonnement, kostenlose Compiler von Microchip uvam
Hallo, aha Danke. Mir war nicht bewusst das gcc die PICs nicht unterstützt. Ich dachte immer gcc unterstützt alles, weil jeder mitmachen kann. Vielleicht hätte sich Microchip aus jetziger Sicht lieber im gcc einbringen sollen. Wer weiß.
im Beitrag #8072251: > was ist denn überhaupt der Vorteil vom MPLAB X Compiler gegenüber dem > gcc? Soweit ich weiß gab es nie einen. Im Gegenteil: Die haben einige Optimierungen aus ihrer Kopie des avr-gcc entfernt, um sie gegen Lösegeld zurück zu bringen. Ich fand das schon immer sehr frech.
-
Thread
AVR-GCC: UART mit FIFO
main-Funktionen kommunizieren, müßten die Indexe als volatile definiert werden, damit sie der AVR-GCC nicht wegoptimiert. Dies würde aber in den Interrupts besonders weh tun, da es mehr Code bedeutet. Daher werden nur die Zugriffe in den main-Funktionen als volatile gecastet (per Macro in meiner mydefs.h
als volatile deklariert. Dann funktioniert es auch mit der Optimierung. Was ich nicht verstehe, warum soll der Code bei fixer volatile Deklaration größer werden als bei gecastetem volatile? Dank lg Rudi
-
Thread
Suche Assembler für 32-bit ARM
Da der GCC keinen Binärcode erzeugt, sondern Assembler-Quellcode, wirst du im Gefolge eines auf GCC basierenden Entwicklungsssystems immer auch den passenden Assembler finden.
Einfach die Quelltext-Datei *.S nennen und dem GCC übergeben.
-
Thread
Erweiterte LCD-Ansteuerung Code zu groß!!
Sorry dass ich Frag, aber wie mach ich denn die Optimierung und wo im Programm schreib ich das rein?
> -Os an? Nein aus höchstwahrscheinlich - Ich vermute mal gaanz stark dass er die Optimierungen ausgeschaltet hat. Das ist die einzige Variante bei ders zu groß wird: [code] $ rm *o ; for opt in 0 1 2 3 s ; do for f in *c ; do avr-gcc -Wall -mmcu=atmega8515 -DF_CPU=1000000UL -O$opt -c
-
Thread
avr-gcc: toten Code eliminieren
Wie kann man mit dem avr-gcc toten Code eliminieren? https://stackoverflow.com/questions/14737641/have-linker-remove-unused-object-files-for-avr-gcc empfielt die Linker-Option -gc-sections und die Compiler-Optionen -ffunction-sections
die Nachwelt die Erkenntnisse aus diesem Thread: Um toten Code zu eliminieren, muss man dem avr-gcc folgende Optionen mitgeben: [pre] -flto -fdata-sections -ffunction-sections -Wl,-gc-sections [/pre] -Wl,-gc-sections wird dabei an den Linker durchgereicht. Bei dieser Optimierung werden
-
Thread
gcc Division negative int32 Zahl durch unsigned int32 ->Käse..
Holm T. schrieb im Beitrag #5607286: > auch wenn der gcc (5.4.0) nicht warnt. Mal mit -Wconversion kompiliert?
richtig gemacht. C++ von Borland macht es auch richtig. Ist wahrscheinlich wieder mal ein Feature von GCC.
-
Thread
Schnellere Division
Ich würde halt gerne wissen, ob es im Bezug auf die Optimierung sinnvoller ist, nur durch Zweierpotenzen zu dividieren.
man den ganzen Salat mal irgendwann auf einen anderen Prozessor, dann kann einem solcherart Optimierung ganz schnell auf die Füße fallen, weil sie sich dort dann plötzlich als Pessimierung entpuppt, ganz davon abgesehen, dass sie eine bestimmte Byteorder benötigt. Bei ARM und GCC hat man übrigens
-
Thread
Frage zu Programm Optimierung (Größe)
von mir: http://pastebin.com/BaS1BAEE Und die LCD Lib von hier. Im Makefile habe ich auch die Optimierung auf Größe gestellt, aber erhalte wie erwähnt, die 7,3 Kb.... Daher auch meine Frage ob jemand weiß, wie ich das Programm noch optimieren kann. Weil laufen tut es, aber ich finde es doch sehr komisch
Float braucht etwa 1kB. Beim AVR-GCC: double = float Sprintf ist recht teuer und mit float nochmal deutlich teurer. Peter
-
Thread
Wahnsinn! 3 GB reicht nicht um FF zu compilieren?
PGO sagt mir erst mal gar nichts. Noch dazu klingt das für mich wie ein Hohn "Profile-Guided"-Optimierung". Optimierung ist in diesem Zusammenhang wohl eher ein Witz bzw. was soll an derart viel Speicherbedarf eigenlich "optimiert" sein?
über 3Gb braucht. Naja, ob kleiner... Eher schneller als kleiner würde ich sagen, weil manche Optimierung, die sich aus Profiling ergibt, den erzeugten Code eher vergrössert als verkleinert.
-
Thread
Atiny2313 Problem mit AVR Studio?
Ich hab es grad mal bei mir durchgejagt: Ohne Optimierung: 3932 Bytes Code (Speicher zu 192% gefüllt) Mit -Os: 242 Bytes (11,8% voll), Größe des Hex-Files: < 1KB Also: Schalte die Optimierung ein und es sollte gehen.
ok, Danke lag wohl an der Optimierung ;-)
-
Thread
avr-libc alternativen
Nutzen dieser funktionen in vielen fällen gering ist. @Johann L. >Die aktuelle Release-Serie von GCC (4.8) unterstützt auch den >ATxmega128A3U, ebenso AVR-Libc 1.8.0. Was gcc betrifft kann ich das nur bestätigen. AVR-Libc 1.8.0 http://download.savannah.gnu.org/releases/avr-libc/ Funktionirt
weil diese einige Bugfixes genenüber der 1.8.0 Release enthält, ohne die eine Distribution mit avr-gcc 4.7+ nicht sinnvoll ist.
-
Thread
Drehgeber und Tastenentprellung für Arduino
richtig kompilieren. Weil hier ja die Rede von "Arduino" ist, denke ich, dass es sich dabei um den gcc (avr-gcc ?) handelt. Normalerweise wird der gcc (die Compiler) im Laufe der Zeit immer "standard-konformer" und findet auch mehr Fehler. Insgesamt also ein Indiz dafür, dass nicht der Compiler das Problem
kompilieren. > > Weil hier ja die Rede von "Arduino" ist, denke ich, dass es sich dabei > um den gcc (avr-gcc ?) handelt. Normalerweise wird der gcc (die > Compiler) im Laufe der Zeit immer "standard-konformer" und findet auch > mehr Fehler. Insgesamt also ein Indiz dafür, dass nicht der Compiler
-
Thread
Interupt programmierung eines Atmega8 mit AVR Std. 4.18
Wenn ich das tue,F7 drücken, bekomme ich 3 Fehlermeldungen: c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: Warning: size of symbol `runden_nr' changed from 1 in Kreisel-de.o to 2 in kreisel-de-ct.o c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe
Wie bekomme ich das mit der Optimierung raus?? Und zu Fehler 1 es ist ein unsigned char.
-
Thread
Timer ISR beenden
timer_min = 0; timer_hour++; } } [/c] so sieht die Timer_ISR (AVR GCC mit Tiny 26) bei mir aus. Wie man erkennen kann, soll hiermit ein Stunden-, Minten- und Sekunden-Timer realisiert werden. Mein Frage nun: Muss ich die ISR noch irgendwie beenden, so wie bei normalen
int main(void) { foo(42); bar(42); return 0; } [/c] [pre] % gcc -Wall -Wextra -ansi -pedantic -c foo.c foo.c: In function `main': foo.c:12: warning: implicit declaration of function `bar' [/pre] Wie zu sehen ist, wird foo() ordentlich als Funktion mit "old
-
Thread
Yet another CRC32 Code
Gießkanne Inline-Assembler Hacks verteilen, oder das Übel an der Wurzel > packen. Inzwischen verfügt GCC über die entsprechende Optimierung, die übrigens Änderungen an ganzen 4 Codezeilen erforderte. Den Code von http://www.mikrocontroller.net/topic/225796?reply_to=2560350#2557218 übersetzt avr-gcc
Die Optimierung ging upstream als SVN 184509 von 2012-02-23 GCC-Version ist 4.7.0 (experimental) Über den Atmel-Fork kann ich nichts sage; da musst du Atmel fragen.
-
Thread
Atmega ISR Prolog dauert zu lange - verschieben möglich?
verwenden/ohne Sicherung ändern darf ("call clobbered"), einmal für die ISR sichern muss. https://gcc.gnu.org/wiki/avr-gcc#Register_Layout https://gcc.gnu.org/wiki/avr-gcc#Calling_Convention Variante 3: Du machst eine naked ISR in der du via inline Assembler zunächst nur die Mindestanzahl Register
welche Register er pushen muss Das könnte den Prolog verkürzen. Allerdings würde ich LTO frühestens ab gcc 4.7.2 einsetzen. Wichtig dabei: Auch der Linker muss dann mit derselben Optimierung -O... wie der Compiler aufgerufen werden. Bei späteren gcc-Versionen kann man sich das dann wieder sparen.
-
Thread
[C-Code Optimierung] RDM responder
Parameters Datenfeld additive Checksumme Es gilt dabei MSB first. Leute, die mir bei der Optimierung helfen, werde ich gern mit als Autor aufführen (wenn gewünscht).
das ein Fehler von mir.) Zum indirekten Zugriff: Ich hatte zuvor mit Pointern gearbeitet, der GCC scheint den jetzigen Zugriff aber lieber zu mögen... (Es sei denn, ich habe Denkfehler gemacht und dadurch Overhead verzapft.) Deinen Link habe ich vor meinem Thread schon durchgearbeitet - er
-
Thread
Zukunft von C# Gesperrt
Berechnung (nicht Ein- und Ausgabe) > viermal so lange gebraucht wie C Die Zeiten waren 10s in C mit gcc gegen etwas über 40s in Java mit Eclipse. Dabei machte es fast keinen Unterschied, ob die Optimierung ein- oder ausgeschaltet war. Mit anderen Suchbereichen habe ich das auch probiert und das Verhältnis
i686-apple-darwin9-gcc-4.0.1 Also anscheinend gcc 4.0.1 JavaSE 1.6.0_29-b11-402 Eclipse Indigo Release 1
-
Thread
Wieso funktionieren Decompiler immer deutlich schlechter als Compiler?
W.S. schrieb im Beitrag #5991481: > OK, die Programmierer des GCC waren bislang auch zu blöd, zu kapieren, > wozu das CS:IP-Format und der dazugehörige Blocktyp im .hex eigentlich > gedacht ist Der GCC arbeitet überhaupt nicht mit dem Hex Format. Wenn schon
dieser $10-LCD-„Scopes“ mit einem ATmega64 nach C zurückübersetzt. Das ging, weil der ohne Optimierung übersetzt war. Da war es tatsächlich möglich, mit etwas trial und error einen C-Code zu schreiben, der zu identischem Assembler-Code kompilierte. gcc erzeugt ohne Optimierung ganz gut erkennbare
-
Thread
Anfänger in C Grundlagenfragen
ablen und Labels und dass die Register schnell "verbraucht" waren. Deshalb versuche ich nun auf GCC umzusteigen. Habe winAVR installiert und das erste Beispiel-Programm des GCC-Tutorials compiliert und in den Kontroller geladen. Funktioniert alles prächtig. Anschließend habe ich mir die Dateien
der Debuginformationen den C-Quellcode zwischen das Disassemblerlisting reinzustreuen. Je nach Optimierung klappt das mehr oder minder schlecht, da die Optimierung halt dazu führt, dass der ausführbare Code alles andere als ein lineares Abbild des Quellcodes wird. > In der map-Datei scheinen irgendwelche
-
Thread
Interpretation AVR-GCC *.lss File
sind bei eingeschaltetem Optimierer mehr oder weniger sinnlos im Assemblercode verteilt. Ohne Optimierung passt das, mit nicht. für den Rest: s.o. Oliver
es die meisten Infos enthält. [1] http://rn-wissen.de/index.php/Assembler-Dump_erstellen_mit_avr-gcc
-
Thread
Anfängerfrage zu µC programierung
Mit avr-gcc (GCC) 3.4.6 sieht es mit Optimierung -Os und mit dem if(x) Konstrukt genauso aus, wie von Roland Schmidt beschrieben: 33: if (x) +00000043: 9B82 SBIS 0x10,2 Skip
bit in I/O +00000048: CFF9 RJMP PC-0x0006 Relative jump Leider war die Optimierung der alten gcc Version noch nicht so gut, daher kam ohne Verwendung der Hilfsvariablen x folgendes raus: 34: if(PIND & (1<<PIND2)) +00000043: B380 IN R24,0x10 In
-
Thread
avr-gcc -O3 optimiert Variablen und If-else statements weg
Hallo, ich habe ein Problem, das mit den letzten Nerv kostet... Ich verwende den avr-gcc mit dem -O3 Schalter, also hoechster Code-Optimierung. Das moechte ich prinzipiell auch dabei belassen, jedoch habe ich Stellen im Code, die vom Compiler wegoptimiert werden und somit das Programm falsch
90 pop r1 94: 18 95 reti [/c] Ich würde auch dazu raten, immer Optimierung -Os zu nehmen. Andere Optimierungen erzeugen deutlich größeren Code ohne merkbar schneller zu sein. Hier sieht man z.B., daß der Epilog (16 Byte) verdoppelt wird, nur um ein RJMP (2 Zyklen) zu
-
Thread
Warnungen vermeiden
In der formalen Analyse von Programmstrukturen sind Compiler wie GCC den Programmierern oft überlegen. Er hat nur dann keine Chance, wenn bestimmte Bedingungen nicht auftreten können, also beispielsweise eine Variable immer einen bestimmten Wert hat, aber das nur
war der Code mit Initialisierung um gerade dieses überflüssige LDI länger. Also schadet es der Optimierung in keinster Weise. Peter
-
Thread
Impulse mit Interrupt zählen
fehlen sämtliche Kommentare. Der Rat mit "Assembler neu schreiben" ist natürlich Quatsch. Optimierung kontrollieren; ggf. Listingfile ansehen. Gruss
einer 1 für diesen Pin im PORTx Register eingeschaltet. [[AVR-Tutorial: IO-Grundlagen]] [[AVR-GCC-Tutorial]]
-
Thread
Startfragen zu GPU Programmierung C++
OpenCL ist aber sehr C > ähnlich und besser für GPUs und deren Paralellisierung geeignet. In GCC gibt's eine HSA (Heterogeneous System Architecture), hier als Präsentation von 2015: https://gcc.gnu.org/wiki/cauldron2015?action=AttachFile&do=get&target=mjambor-hsa-slides.pdf Inzwischen ist das im Hauptzweig von GCC gelandet.
-
Thread
Warnung in GCC
Hallo Gemeinde, ich habe ein kleines Problem mit dem GCC. Er spuckt mir die drei Warnungen aus. ../Hupe_GCC.c:2145: warning: passing arg 2 of `Seconds2BCD' discards qualifiers from pointer target type ../Hupe_GCC.c:2149: warning: passing arg 2 of `Int2BCD' discards qualifiers from pointer target type ../Hupe_GCC.c:2150: warning: passing arg 2 of `Int2BCD' discards qualifiers from pointer target type Als globale Variable ist volatile uint8_t tx_buffer[7]; // buffer for data paket to external display
-
Thread
goto verpönt - was dann nehmen?
im Beitrag #4532523: > in ASM umsetzen. Damit gewinnt man > (angesichts der idiotisch miesen Optimierung des AVR-Compilers) mehr. ist das so? hier meinen aber einige assembler Spezis anderes, so schlecht soll der gcc nicht mehr sein! Ich selber staune immer wie gut der gcc optimiert mit -0s
>Heinz L. schrieb: >> in ASM umsetzen. Damit gewinnt man >> (angesichts der idiotisch miesen Optimierung des AVR-Compilers) mehr. >ist das so? Nein. Das ist nur die Meinung eines gesicht, namens- und ahnungslosen Heinz. Das ist modern . . . >Ich selber staune immer wie gut der gcc optimiert
-
Thread
STM32F4 CoOS
. 6 Posts weiter oben) ======================================================================= GCC HOME: C:\CooCox\gcc\bin compile: [mkdir] Created dir: C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\Debug\bin [mkdir] Created dir: C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\Debug
\arch.o ..\obj\misc.o ..\obj\sem.o ..\obj\hook.o ..\obj\usart.o -L..\.. -lm [cc] c:/coocox/gcc/bin/../lib/gcc/arm-none-eabi/4.6.2/armv7e-m\libgcc.a(unwind-arm.o): In function `get_eit_entry': [cc] unwind-arm.c:(.text+0x144): undefined reference to `__exidx_start' [cc] unwind-arm.c
-
Thread
Watchwindow im AVR-Studio
Wie ist denn die Optimierung eingestellt? Bei eingeschalteter Optimierung kann es durchaus sein, dass Variablen wegoptimiert werden. -> Mit Optimierung O0 nochmal probieren!
hattest recht. Bei dem simplen Zähler hat der Compiler die Variable wegoptimiert. Wenn die Optimierung abgeschaltet ist dann gehts. Danke. Gruss, Georg.
-
Thread
Compilerfehler?
Compilerfehler" sitzen vor der Tastatur ;-) Der hier scheint echt zu sein. Mit eingeschalteter Optimierung (-O1 oder -Os) wird die Berechnung von bandwidth in sdram_speed_test() nicht ausgeführt, ohne Optimierung geht es. [c] time = TCD0.CNT; PRINT("DMA transfer time is %u timer clocks.\
Falk B. schrieb im Beitrag #4493858: > Mit eingeschalteter Optimierung (-O1 oder -Os) wird die Berechnung von > bandwidth in sdram_speed_test() nicht ausgeführt, ohne Optimierung geht > es. Die 0 sollte auch bei abgeschalteter Optimierung ausgegeben werden, nur
-
Thread
neu AVRDUDE 5.11
Einen alternativen als den Default-Compiler gibt man einfach beim configure an mit: [code] env CC=gcc-mingw32 ./configure [/code] (mal in der Annahme, dass der Cross-Compiler "gcc-mingw32" heißen würde) > oder war eine komplette Umgewöhnung auf Linux gemeint? das wär ein > bischen heftig für
suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for bison... bison