-
Thread
Arduino Bit Shifting Problem
OK: AVR-GCC9.2.0, Optimierung = Os [avrasm] uint8_t MirrorByte ( const uint8_t ToMirrorByte ){ 52: cf 93 push r28 54: df 93 push r29 56: 30 e0 ldi r19, 0x00 ; 0 58:
AVR-GCC9.2.0, Optimierung = O3 [avrasm] uint8_t MirrorByte ( const uint8_t ToMirrorByte ){ uint8_t MirroredByte = 0; for (uint8_t BitNr = 0; BitNr < 8; BitNr++){ cc: 83 2f mov r24, r19
-
Thread
Problem mit STM32F103 und RAM-Größe
erstmal schauen, was er mit Compiler-Optionen erreichen kann. Da helfen zum Beispiel entsprechende Optimierung-Flags wie zum Beispiel -Os. Auch FLTO (in Verbindung mit gcc) kann einiges an RAM-Bedarf optimieren. Natürlich ist es sinnvoll, String-Konstanten auch als solche zu definieren, das wurde oben
Dazu kommt das der gcc den M0 grob vernachlässigt und deutlich schlechter optimiert als bei >= M3. Der Keil Compiler holt da mehr raus, bis 32k Codesize lief der auch in der kostenlosen Testversion.
-
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
Atmel Studio: uralter AVR-GCC?
#5999150: > Habe mir das "aktuelle" Atmel Studio von Microchip geladen. Was mir > auffiel, der GCC ist uralt. Das Studio meldet: "AVR/GNU C Compiler : > 5.4.0". > > Hier ist man bereits bei Version 9: https://gcc.gnu.org/ Die v8+ willst du verwenden wegen http://gcc.gnu.org/PR81268 Die v9 willst du nicht verwenden wegen http://gcc.gnu.org/PR91189
-
Thread
ARM-Assembler-Tutorial
chris_ schrieb im Beitrag #6692459: > Genau an dem Punkt liegst du ziemlich falsch. Optimierung findet auf der > konkreten und nicht der abstrakten Ebene statt. Es gibt konkrete Optimierung auf Befehls- und Registerebene. Es gibt abstrakte Optimierung der Algorithmen (Theorie, à la Knuth
Strategie aufs falsche Gleis gesetzt, sitzt man vielleicht so tief in der Tinte, dass konkrete Optimierung für die Katz ist. Und es gibt dazwischen eine Optimierung der Algorithmen unter Berücksichtigung von Speicherzugriffszeiten und -Strategien aktueller Prozessoren (z.B. ist sequentieller Zugriff
-
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
Neue IDE und Programmiersprache zur FPGA Programmierung
deutlich besser dran, dank ihres wirklich extrem reduzierten 8-bit-Opcode-Sets. Allerdings ist deren gcc-port nicht auf dem neuesten Stand, und der Unterhalt koennte irgendwann aufwendig werden. Ansonsten ist die Architektur sehr robust und frei von dreckigen Hazards, dazu kommt eine hohe Opcode-Dichte. Da allerdings macht der RV32IC-Support inzwischen mit -Os Optimierung recht Boden wett. Auch muss man bei der ZPU wissen, dass die kleingekochten Varianten dank 'Emulation' einiger Befehle in manchen Implementierungen langsam sein koennen. Den groessten Spass werdet
-
Thread
C++ Mc gcc Object löschen
nicht vollständig spezifiziert. Es wird aber in der Praxis nicht genutzt. Ist auch egal, denn der GCC für ESP kann das bestimmt nicht.
für > verschiedene MCUs zu analysieren: Mit objdump geht das auch lokal. Schalte mal die Optimierungen ein!
-
Thread
Lazarus Pascal / Delphi /FreePascal aktiver als viele denken? EADS, Sony etc
winkt das der Compiler bei Verwendung der Defaultoptionen anstandslos durch. In C schmeißt einem der GCC für diesen groben Unfug mindestens eine Warnung entgegen. Wo ist denn die einst so vielgepriesene Typsicherheit von Pascal geblieben?
niemand als wichtig genug (oder als Problen überhaupt) eingestuft, um eine entsprechende Warnung in den gcc einzubauen.
-
Thread
Zeta SBC V2 Z80 mit Floppy Disk
K. schrieb: >> freies Unix für Z80, das mit SDCC kompiliert wird. > > Ich warte lieber bei der GCC mal den Z80 unterstützt. Keine Ahnung wieso > das nicht gemacht wurde. > > Der SDCC ist schnarch langsam, wenn man die Anzahl "Nodes" auf eine > vernünftige Zahl einstellt, […] Der GCC verwendet
anders funktioniert als gewohnt. Das fängt schon damit an, dass es keine einzelne Objektdatei wie bei gcc oder cc65 gibt. Philipp Klaus K. schrieb im Beitrag #6855866: > Der aussichtsreichste Weg, diese Optimierung zu ermöglichen, dürfte > sein, in SDCC die Unterstützung der GNU binutils als Assembler
-
Thread
AT91SAM7X512, womit programmieren?
Gibt es Gründe, warum es ausgerechnet Atmel Studio (-ähnlich) sein muß? Intern läuft das doch eh auf GCC raus... Ich bin sehr glücklich beim kleineren 7x256 mit Eclipse, arm-gcc+gdb und einem mittlerweile recht betagten Olimex-Adapter (OpenOCD-kompatibel, basierend auf FT2232) Und wer Eclipse nicht
anderen Sourcefile des > Projektes Das ist normal (bei allen Debuggern!) wenn die Compiler Optimierung eingeschaltet ist. Kompiliere im Debug Modus (GCC Option -O0) um Debuggen zu vereinfachen, dafür im Gegenzug aber das Programm langsamer zu machen. Ein Mittelweg ist -Og. Habt ihr nichtmal ansatzweise
-
Thread
Kann man diesen C-Code vereinfachen?
t inout[9] = { 0, 1, 2, 0, 3, 0, 0, 0, 4 }; Output = inout[Input]; Ansonsten würde ich die Optimierung dem Compiler überlassen.
https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung "Die goldene Regel lautet: 90% der Rechenleistung werden in 10% des Codes verbraucht. Diese 10% muss man finden und zum richtigen Zeitpunkt optimieren
-
Thread
C (MinGW): Unerwartete Bool-Auswertung
Ich kann dein Ergebnis mit dem GCC ("gcc (Debian 8.3.0-6) 8.3.0") *nicht* nachvollziehen (Minimalbeispiel): [code] #include <stdint.h> #include <stdio.h> #include <stdbool.h> volatile bool r; volatile bool s; int main(
schrieb im Beitrag #5974140: > clang schafft es es bis Version 8 nicht, eine Warnung zu generieren. > GCC 5 ebenfalls nicht, GCC 8 wirft eine Warnung Danke fürs Gegentesten. Dann kann ich das Problem wohl auf meinen GCC 5.1.0 zurückführen. Es wird wohl mal Zeit für ein Update. Ich werde mich künftig
-
Thread
ATMega Flash wird langsam knapp. Upgrade o. Plattformwechsel?
machen. Apollo M. schrieb im Beitrag #5968393: > nd wenn noch nicht geschehen tausche auch die gcc version, gute > erfahrung habe ich mit v8.3 bzgl. optimization. Nein ich benutze die GCC Version 5.4.0 die Version 8.3.0 kann ich nicht finden habe nur die AVR-GCC 9.2.0 gefunden zum Downloaden:
Felix N. schrieb im Beitrag #5968537: > Nein ich benutze die GCC Version 5.4.0 die Version 8.3.0 kann ich nicht > finden habe nur die AVR-GCC 9.2.0 gefunden zum Downloaden: > > http://blog.zakkemble.net/avr-gcc-builds/ ... die gcc v8.3 findest du auch bei
-
Thread
Hilfe, Interrupt flags lassen sich mit 'typedef union' nicht einzeln löschen
SFR zu benutzen, empfehle ich Dir, den Code einmal mit -mbig-endian und einmal mit mlittle-endian (gcc / g++) zu kompilieren. Schau mal: https://godbolt.org/z/XBqt4A Hinzukommt natürlich die schon angesprochene Umsetzung der Zuweisungen zu RMW-And/Or-Sequenzen.
gibt es tausende solcher Bitfelder für hunderte von PICs, sowohl für den XC8 als auch für den XC16/gcc, die sicher auch von den Programmierern genutzt werden. Das klappt natürlich nicht bei queeren Prozessoren, die spontan ihre Endianess ändern. MfG Klaus
-
Thread
Lokale Variable statt static, aber optimiert. Wie?
Ich glaube, du übertreibst es da mit Optimierung. Ist es wirklich nötig?
/avr-gcc-list/2012-05/msg00044.html
-
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
for Schleife in C
von einem Compiler anno 2019 erwarten Warum sollte die Jahreszahl daran etwas ändern? Der AVR-GCC ist von Grund auf relativ, naja, eigenwillig aufgezogen worden. Soweit ich Johann (Lay) mal verstanden habe, muss man ihm daher alle entsprechenden Optimierungen einzeln als Mikrooptimierungen beibringen
Nutzen stellen), werden sich solche Dinge folglich nicht rein zufällig durch eine allgemein kluge Optimierung ergeben. Andere von GCC bediente Architekturen als AVR wiederum haben das Problem sowieso nicht. Bei denen ist das Reduzieren eines "int" auf einen 8-Bit-Typ eher teurer als billiger.
-
Thread
STM32 Profiling: Barriere gegen Optimierung?
den Inhalt der Funktion vor oder hinter das Auslesen des > Zyklenzählers verschiebt. Stichwort: gcc memory barrier leo
Walter T. schrieb im Beitrag #5939171: > Gibt es eine Möglichkeit, solche Optimierungen zu > verhindern Nimm einfach so eine Compiler-Barrier jeweils vor und nach Deiner zu messenden Funtion: [c]#define CMPBAR __asm__ volatile("" : : : "memory")[/c]
-
Thread
Look-Up Table wie speichern
Konstanten gefaltet werden (ok, bei volatile eh kein Thema mehr). > Dafür muß du aber keine frühere GCC haben, die unbedingt PROGMEM braucht > und __flash nicht versteht. Mit progmem kann man das gleiche Interface implementieren wenn man denn will. __flash gibt's seit avr-gcc v4.7. Ohne __flash-Support
schrieb im Beitrag #5938616: > Auf den Thread neulich wurde ja schon verwiesen. Konkret für avr-gcc > lässt sich get_mem_unused() von hier nutzen: > > https://rn-wissen.de/wiki/index.php?title=Speicherverbrauch_bestimmen_mit_avr-gcc#Dynamischer_RAM-Verbrauch Ich hab das eben überflogen und
-
Thread
GCC: Variable wird trotz 'KEEP' im Linkerscript wegoptimiert?
Hallo, für die Programmierung eines STM32 verwende ich Atollic Truestudio, also GCC drunterliegend und bastle mir gerade die Option Bytes direkt ins ELF bzw. HEX File. Hierfür habe ich das Linkerscript wie folgt modifiziert: [c] ... MEMORY { ... OPT_BYTES (r) : ORIGIN
belegen muss, wenn ich doch > im Linkerscript die Sektionen schon mit KEEP markiert habe Davon weiß GCC aber nix. "used" wirkt auf Compiler-Ebene. "KEEP" wirkt auf Linker-Ebene. Wenn globale Optimierungen aktiviert sind, dann kann GCC nicht referenzierte Objekte / Funktionen entsorgen. Gleiches
-
Thread
Auf element außerhalb array zugreifen
> > int main(void) { > array[42] = 5; > 42[array] = 5; > *(array+42) = 5; > } GCC 7.3.0 (MingW) warnt übrigens mit -Wall sehr wohl "subscript out of bounds", das nur der Vollständigkeit halber. Daß er ohne -Wall nicht warnt, bedeutet nicht, daß er es nicht für unerwartete Optimierungen
eine GCC-Erweiterung ist.
-
Thread
Warum quälen sich so viele Hobbyprojekte noch mit ASM-Code ab?
wirds ganz furchtbar ätzend… Auf der anderen Seite verstehe ich aber auch das Gejaule über die Optimierungen des Compilers nicht. Ich habe lange genug Crashdumps analysiert und weiß ganz gut, was da auf Maschinencode-Ebene so gespielt wird: der Compiler kocht auch nur mit Wasser und wenn man die Tricks
darf der Compiler machen, wenn es nicht sehr sehr gute Gründe für ASM gibt. Der Inline-Compiler des GCC ist jedenfalls zum abgewöhnen.
-
Thread
Funktionspointer als Parameter
Ja, mit C++. GCC bringt dafuer g++ mit.
optimiert wird, ermöglicht das Inlining über Modulgrenzen hinweg. Mit Funktionszeigern ist diese Optimierung i.d.R. nicht möglich, weil der Wert so eines des Zeigers wesentlich schwerer zu eruieren ist als ein Symbol. Allerdings könnte weak hier dem Compiler / LTO reingrätschen und solche Optimierungen
-
Thread
C: Prüfen, ob Variable in Intervall
...tatsächlich ist es genau der Code, den GCC für folgende Vergleiche erzeugt: [c]void f (void); void test (int c) { if (c >= 50 && c <= 100) f(); }[/c] Hier avr-gcc: [avrasm] test: sbiw r24,50 sbiw r24,51 brsh
Dinge verfügbar wären, von denen niemand außer Wilhelm weiß, wo sie herstammen. Mit dem aktuellen GCC-Release (9.1) hast du jedoch kein Chance.
-
Thread
cannot read spec file 'device-specs/specs-atmega4808'
" ignoring duplicate directory "c:/avrtoolchain/avr-gcc-9.1.0_mingw32/lib/gcc/../../lib/gcc/avr/9.1.0/include-fixed" ignoring nonexistent directory "c:/avrtoolchain/avr-gcc-9.1.0_mingw32/lib/gcc/../../lib/gcc/avr/9.1.0/../../../../avr/sys-include"
\Atmel\ATmega_DFP\1.3.300\include c:\avrtoolchain\avr-gcc-9.1.0_mingw32\bin\../lib/gcc/avr/9.1.0/include c:\avrtoolchain\avr-gcc-9.1.0_mingw32\bin\../lib/gcc/avr/9.1.0/include-fixed c:\avrtoolchain\avr-gcc-9.1.0_mingw32\bin\../lib/gcc/avr/9.1.0
-
Thread
UPDI Programmer bauen - alias "El Tangas"
Das Problem hier ist nachgelagert. Vielleicht kannst du mir helfen wie ich AS7 mit aktuellen avr-gcc-9.1 überredet bekomme C++ für die neuen µC kompilieren zu können?
abzielst, der soll leider nicht in Atmel Studio funktionieren. [/c] Ja, aber funktioniert in MPLABX, GCC für AVR gibt es dafür auch.
-
Thread
frage zu sizeof() in c
oder weil der ganze String nicht verwendet wird, sondern nur Ausschnitte, dann wären viele Optimierungen in C nicht möglich. Im Prinzip wird hier das String mit 4 Konstanten gecheckt bevor ein strcmp angewendet wird. Bei einer Variablen ist es auch optimiert. Strings mit nur einem Zeichen werden
kompilierbares minimal beispiel von deinem parser posten? Wuerde das gerne mal durch einen aktuellen gcc oder clang jagen
-
Thread
Taktiken zum Debuggen bei Release Builds
ReleaseWithDebugInfo-Builds erstellen. Das ist genau das was du hier willst, einen Release-Build (mit Optimierungen, ohne Asserts), der Debug-Symbole hat sodass du einen Stacktrace bekommst. Ich denke das ist hier die erste Strategie.
aber nicht sagen. Evtl. verbessern sich auch die Ausgaben, wenn Debug-Infos aktiviert sind. Beim GCC etwa ist garantiert, dass bei Aktivierung / Deaktivierung von Debug-Info der gleiche ausführbare Code generiert wird. Wenn das bei deinem Compiler nicht der Fall ist ist das natütlich blöd... Evtl
-
Thread
Ada oder MISRA-C, aktuell und in Zukunft
mit der > Compilerunterstützung aus? Gemischte Projekte sind kein Problem. Compilermäßig sind GCC und Clang/LLVM voll unterstützt. Standardmäßig nutzt Rust den LLD, also den LLVM-Linker, wobei der GCC-Linker ebenso unterstützt wird und ursprünglich für Cortex-M sogar der Standardlinker war. Wie
Strubi schrieb im Beitrag #5900480: > Müsste eine gcc 3.x gewesen sein. Also vor ewigen Zeiten... Strubi schrieb im Beitrag #5900480: > Ich hätte auch erwartet, dass der > Compiler erkennt, dass das mit genau einem Wrapper (index -> Pointer) >
-
Thread
Tipps und Tricks zum Thema Rechnen in ganzen Zahlen?
kann [c] pos = (lines << 6) + (lines << 4); [/c] durchaus schneller sein. Wermutstropfen: der gcc ist so schlau, dass er bei einer solchen Multiplikation das bereits automatisch macht. Bei entsprechender Optimierung muss man also gar nicht erst zu solchen Tricks greifen. Aber für Assembler-Programmierer
man nur an einer Stelle eine Multiplikation optimieren will... Asm rules... Gerade bei der Optimierung von fixed point Arithmetik gibt's wohl nix besseres...
-
Thread
High Level Synthese aus C Code Spielerei oder ernste Anwendungen?
Es ist halt immer schwierig, die Industrie von bestehenden Frickellösungen wegzukriegen, und Optimierungen sind auch oft gar nicht erwünscht (könnte ja eine Stelle wegfallen).
Vektor-ALU besser gleich manuell programmiert anstatt trial&error in C, und darauf hoffen, dass die Optimierung richtig greift. Mit GCC hätte man ja ansich die Möglichkeiten, wenn die RTL/gimple-Geschichte so flott von der Hand ginge, sich seine HLS selber zu bauen und Datentypen und Arithmetiken in Abhängigkeiten
-
Thread
Raspberry Pi 4 vorgestellt
war gefuehlt so schnell wie ein Raspberry mit heutiger > Software. :-D Auf einem 368sx hat ein gcc-build 1-3 Tage gedauert.
http://erste.de/latency_PI4_to_PI4-GPIO.png Gut, das ist jetzt ohne Last - aber auch ohne Optimierungen. Raspi I gibt eine 5kHz-Square aus, Raspi II liest sie ein und setzt den GPIO-Output entsprechend. Ich werde mal versuchen die maximalen Abweichungen unter Last zu messen....
-
Thread
überflüssiges extern?
verwenden. Was Prototypen betrifft, z.B. -Wstrict-protoypes -Wmissing-prototypes aktivieren falls GCC zum Einsatz kommt.
Funktionsdefinitionen. In C gibt es diese Möglichkeit allenfalls als Spracherweiterung, wie bspw. beim GCC.
-
Thread
Neue MCU familie gesucht
Vergleiche mit SDCC 3.7.0 und ein paar Benchmarks gemacht. stdcbench 0.4 c90base Score. Jeweils mit Optimierung auf Geschwindigkeit kompiliert (damit liegt die Codegröße bei MCS-51 etwa beim doppelten von STM8): C8051F120@98Mhz: 95 STM8AF5288@16Mhz: 109 STM8S208MB@24Mhz: 147 zum Vergleich: Weitere µC mit SDCC 3.7.0 bzw. GCC 6.3.1: CY7C68013A@48Mhz: 12 STM32L073RZ@32Mhz: 717 STM32F051R8@48Mhz: 1141 STM32F103RB@36Mhz: 1158 STM32F302R8@64Mhz: 1693 Bei stdcbench 0.4 erhält man für den STM8 mit Cosmic und Raisonance
-
Thread
AVR: Ist PORTx |= atomar?
avr-gcc.) Alternativ kann PORTC eine Deklaration mit Attribut io_low sein. * xx ist zur Compilerzeit bekannt, und xx ist exakte 2-er Potenz von 0x1..0x80 (Fall |=) oder das 1-er Komplement einer solchen 2-er Potenz (Fall &=). * Optimierung ist nicht -O0 oder -Og. Es gibt jedoch ältere Compilerversionen, wo dies _nicht_ hinreichend ist, z.B. wird bei 2× hintereinander SFR &= 0x7f das 0x7f erst in ein Register geladen, was dann zu
-
Thread
XMEGA Hardware-Bug (Kritisch) Gesperrt
main+0x116> 702: f4 cf rjmp .-24 ; 0x6ec <main+0x108> [/avrasm] avr-gcc --version: avr-gcc (GCC) 8.2.0 Leider sorgt der Optimierer hier für etwas Chaos. Ausschalten ist aber leider nicht ohne weiteres möglich, wg. Initialisierung des Oszillators. Falls der TO
Ausführbares; zusätzlich muss gelinkt / lokatiert werden. Am einfachsten geht das, indem man avr-gcc als Treiber verwendet, z.B.: [pre] $ avr-gcc -x assembler rjmptest.asm -o rjmptest.elf -mmcu=atxmega32e5 -nodefaultlibs -nostartfiles [/pre]
-
Thread
Arduino Uno: Optimiert der Compiler sich im Loop wiederholende Befehle?
Arduino Compiler intelligent genug, das zu erkennen und > die Zuweisung nur einmal vorzunehmen? Der GCC ist bei Optimierung recht gut aufgestellt. > Frage 2) Ist er sogar intelligent genug, die Variable im Flash statt im > RAM zu speichern? Er ist intelligent genug, Variablen ganz wegzulassen
A. K. schrieb im Beitrag #5858804: > Der GCC ist bei Optimierung recht gut aufgestellt. > Er ist intelligent genug, Variablen ganz wegzulassen offensichtlich, man unterschätzt die Fähigkeiten! Ich habe gerade wieder ein Putz- & Aufräumphase
-
Thread
C++ / Threads
implementiert (hat/oder noch immer macht) daß da automatisch Memory Barries gesetzt werden was z.B. GCC nicht tut.
das es klar ist. Wohlgeordnet in C muss nicht so in Maschinencode übersetzt werden. Gerade mit Optimierung darf der Compiler da auch umsortieren.
-
Thread
arm-none-eabi-gcc unterschlägt ein case 0 im switch?!
grösser als 6. Da der Compiler weiss, dass ein 16 Bit IDR >> 13 nur den Wertebereich 0..7 hat, passt es. GCC versucht den möglichen Wertebereich von Daten zu erfassen, um daraus Optimierungen abzuleiten.
Peter schrieb im Beitrag #5849676: > Aber wieso das jetzt eine Optimierung sein soll? Wenn der bekannte Wertebereich exakt mit der Anzahl Fällen übereinstimmt, geht es besser. Es schien wohl nicht lohnend, nur dafür ein separates Schema im GCC vorzusehen.
-
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
Wie verarbeitet der GCC die Speicherklasse extern?
Variable. Selbst wenn der Programmierer das selber nicht so gedacht hatte. Das ganze funktioniert beim GCC nämlich auch ohne das "extern" vor der Deklaration. Hier sind die erwähnten Dateien: [c] /*main.c*/ #include <stdio.h> #include "erste_datei.h" int ersteVariable = 13; /*<- 1*/ int zweiteVariable
(.comm) "überlagert" werden — zumindest wenn der Compiler das implementiert, was zum Beispiel bei GCC der Fall ist (-fcommon ist immer noch Default). Wenn man das nicht möchte, compiliert man mit -fno-common, und erst dann meckert der Linker "multiple definition of" an. Definitionen (nicht tentative
-
Thread
Aufwandschätzung für Cross-Assembler
absolut nicht vollwertig), denn er kannte keine > bedingte Assemblierung, er kannte keine Makros GCC-Preprozessor :)
vollständige Kontrolle über den Code zu haben. > Auch wenn er vielleicht nicht optimal ist. Eine Optimierung muss nicht eine der "verrückten" Transformationen sein, die der GCC bei -O3 macht. Z.B., der MSP430 hat Konstantengeneratoren, die, je nach Adressierungsmodus -1, 0, 1, 2, 4 und 8 erzeugen können
-
Thread
10x mehr Speicherbelegung bei Array von main in Funktion verschieben
. Was aber auch bedeuten würde, dass ich die gesamten Zeichensätze umstrukturieren muss :-( ARM GCC, Eclipse, CubeMX, STM32 wird verwendet.
long myIdx; myIdx = MyCharToLCD; myIdx = 5 * myIdx - ' '; zu schreiben und den Rest an Optimierung dem Compiler zu überlassen. Bedenke mal, was in C aus einer mehrdimensionalen Felddefinition wird. W.S.
-
Thread
XC32 Inline Funktionen
files. [/pre] Ich empfinde das als höchst unsauber und habe zum Vergleich mal in den Abschnitt der gcc Dokumentation geguckt (https://gcc.gnu.org/onlinedocs/gcc/Inline.html). [pre] By declaring a function inline, you can direct GCC to make calls to that function faster. One way GCC can achieve this
count_b (void) { return fun(); }[/c] > [...] und habe zum Vergleich mal in den Abschnitt der gcc > Dokumentation geguckt > (https://gcc.gnu.org/onlinedocs/gcc/Inline.html). Im Endeffekt das gleiche in Grün: Um Inlinen zu können, muss gcc die Definition kennen: Entweder klassisch, indem er
-
Thread
C++ - Warum gibt es hier einen SegFault?
Bei x86-64 GCC Version 7.3.0 funktionierts, bei Clang 6.0.0 auch. Beim ARM-GCC 8.2.1 hingegen nicht - auch hier wird das "pop {r4, pc}" weggelassen. Im C++-Standard Draft (n4659) heißt es in 9.6.3 2: "Flowing
diesem UB (also das vom Anfang) kann man m.M.n. sehr schoen erkennen, warum UB so gefaehrlich ist: GCC ohne Optimierung: kein SegFault GCC mit Optimierung: SegFault Clang ohne Optimierung: SIGILL Clang mit Optimierung: kein SIGILL Wenn man mal mit valgrind reinguckt: Mit gcc compiliert (mit
-
Thread
Am besten C lernen
klappte war aber doof zu pflegen, also die *.c in *.ino umbenannt, klappt auch. Jedenfalls kommt der gcc klar damit und ich auch.
für ein Aquarium halt doch. Übrigens: Es finden sich auch STL Implementierungen für den AVR-GCC. Unmöglich, sie zu verwenden, ist es also nicht.
-
Thread
Interrupt ATtiny45
werden? > Vielleicht mal i>0 versuchen. In der Tat, das ist eine Endlosschleife, wie auch der gcc -Wextra schildert: [pre] $ gcc -Wall -Wextra a.c a.c: In function ‘main’: a.c:5:20: warning: comparison is always true due to limited range of data type [-Wtype-limits] for(byte i=255; i>=
einzigen Aufruf kann man > sich den overhead für einen Funktionsaufruf sparen. Wenn man die Optimierung nicht abschaltet, macht der AVR-GCC das schon von selbst. Laß also alle einmal aufgerufenen Funktionen als Funktion. Lesbarkeit geht vor und kostet hier nichts. Sogar Funktionen in verschiedenen
-
Thread
AVR: UART + ADC, Feinheiten und Fragen
ich damit gut arbeiten kann. Ich habe mich jetzt durch diverse Tutorials (hier vor allem das AVR-GCC) und Bücher gewurstelt und habe 2 ADC-Kanäle am laufen die über UART an meinen PC gesendet werden. Der Quelltext dazu ist oben als Anhang eingefügt. Da ich diesen Text zu Übungszwecken verwende habe
Strukturierte Programmierung auf Mikrocontrollern]] https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung "Verfrühte Optimierung ist die Wurzel allen Übels!" > sind grobe Fehler drin die man als > "erfahrener" C-Programmierer nicht machen sollte? >#
-
Thread
PIC Port C vor Variablen initialisieren
> kommt das Zitat? ... aus aktuellem mplabx help. hat mich auch gewundert, dass sieht nach avr/gcc aus und funktioniert sogar in xc8 - im simulator überprüft. mt
Apollo M. schrieb im Beitrag #5810219: > ass sieht nach > avr/gcc aus und funktioniert sogar in xc8 Auch für PIC16? Muss ich gleich testen...