-
Thread
Art der if-Auswahl nur Geschmackssache?
Zitat von einem unserer Informatiker: "Code soll für einen selbst übersichtlich und lesbar sein. Optimierung macht der Compiler".
und c auf 32 Bit erweitert werden > und eine 32 Bit Multiplikation ausgeführt werden. Der AVR-GCC macht das schon seit geraumer Zeit besser, zumindest bei Controllern mit Hardwaremultiplizierer. Johann, der auch hier im Forum aktiv ist, hat's gerichtet: https://gcc.gnu.org/ml/gcc-patches/
-
Thread
STM32F103: Problem mit ChanFat und SD karte
abgefragt werden, sondern das RXNE Bit. Dan läuft es wieder. [c] /* Receive multiple byte */ #pragma GCC push_options #pragma GCC optimize ("-O0") static void rcvr_spi_multi ( uint8_t *buff, /* Pointer to data buffer */ uint32_t btr) /* Number of bytes to receive
SPI1->CR1 &= ~(_BV(6) | _BV(11)); /* Set SPI to 8-bit mode */ SPI1->CR1 |= _BV(6); } #pragma GCC pop_options [/c]
-
Thread
STM32Fxxx: Frage zur Initialisierung mit der StdPeriphLib
hilfreiche API's und Funktionen schreiben, welche aber von vernünftiger Optimierung abhängig sind. Die üblichen Unit/Integerations-Tests sollten eventuell scheiternde Optimierung in neuen Compiler-Versionen aufdecken. Nop schrieb im Beitrag #5356027: > Beim GCC verbietet sich
Nop schrieb im Beitrag #5356169: > Da kann man in aller Ruhe auch mit der eher > umständlichen GCC-Methode manuell arbeiten. Oder eben ganz manuell oder mit Stichproben-Tests, und sich über die hilfreiche Compiler-Optimierung freuen.
-
Thread
Arm Compiler performance Linux vs. Windows
komisches aufgefallen. Und zwar ganz egal welche Toolchain Variante und IDE ich verwende, der arm-gcc scheint unter Linux gefühlt mindestens 5x so schnell zu sein, wie unter Windows. Kann das sein, oder spinne ich? Beim avr-gcc und beim gcc für Desktop Anwendungen (also Linux bzw. Windows Targets
W.S. schrieb im Beitrag #5355234: > Aber zum GCC: > Wenn du mal in eine GCC-Distribution für Windows hineinschaust (z.B. > Yagarto), wirst du feststellen, daß sich da von allen ausführbaren > Dateien mehrere binärgleiche Exemplare unter unterschiedlichen
-
Thread
STM32 Kompilat größer als erwartet
startup/startup_stm32.s Building file: ../startup/sysmem.c Building file: ../src/main.c Invoking: MCU GCC Assembler Invoking: MCU GCC Compiler Invoking: MCU GCC Compiler /home/stefan/Programmierung/STM32_Workbench/Blinker/Release /home/stefan/Programmierung/STM32_Workbench/Blinker/Release arm-none-eabi-as
startup/sysmem.c Finished building: ../src/main.c Building target: Blinker.elf Invoking: MCU GCC Linker arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -specs=nano.specs -specs=nosys.specs -T"/home/stefan/Programmierung/STM32_Workbench/Blinker/LinkerScript.ld" -Wl,-Map=output.map -Wl
-
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.
-
Thread
Raspberry Pi 3 Model B+
ist. Aber macht immer noch deutlich mehr Bandbreite als die vorherige Version. Also ein Schritt Optimierung, keine Perfektion. Für mich für ein 08/15 Arbeitspferd absolut valides Upgrade. Kostet auch nicht mehr als der alte, also alles ok.
auf RISC OS eine graphische Oberfläche? Gibt's da > eine API für C++? RISC OS kommt mit dem ARM gcc und damit kann man das ziemlich umständlich machen: https://www.youtube.com/watch?v=ALiMp-GHIX4 Üblicherweise wird aber eine kommerzielle IDE ähnlich Visual Studio verwendet, die allerdings ca
-
Thread
C Source-Code unlesbar machen
ein: 1. das include der Standard-IO Lib kann man sich bei den meisten Compilern sparen (zB beim GCC), da er so "schlau" ist und errät, wo er die printf-Funktion findet 2. Die ASCII-Texte "sinn" und frei könnte man durch eine Mischung aus Hex-/ Dec-/ und Oktalwerten ein wenig schwerer lesbar machen
wirrer machen? Naja, ich würde das als eher mäßig wirr bezeichnen. Falls du Anregungen für eine Optimierung brauchst, dann schau mal beim IOCCC vorbei. Eric B. schrieb im Beitrag #5348647: > Vielleicht so? Der Code hat mindestens 2 Klammerfehler, weswegen er nicht kompiliert. Selbst wenn man die
-
Thread
[STM32] Compiler optimiert Funktion zu stark
alles, siehe Screenshot 04.png. Ich habe schon an einigen Stellen mit volatile versucht die Optimierung zu verhindern, nur leider kein Erfolg. Was macht er Compiler hier? Wie löse ich das Problem? Welche Infos werden noch benötigt? Danke im Vorraus!
zutrauen, Wäre nicht die erste sinnlose Frage im Forum. Er verdächtigt den Compiler der Falsch-Optimierung, schaut aber nicht in die Disassembly. Das sagt schon einiges.
-
Thread
Overhead Funktionsaufruf über Pointer
zu 15% mehr Geschwindigkeit bekommen bei ca. 95% Codegröße. Übrigens, ein e200z4 (PowerPC VLE, GCC 4.8.0) ist bei gleicher Taktfrequenz ca. 1,6x so schnell (bei 1,75-facher Codegröße). Jörg
ineffizienter machen? Passieren kann das m.E. eigentlich nur aus zwei Gründen: Du hast einen Bug gefunden oder gcc kennt deine Cache-Grössen nicht (oder eben falsch). Schon mal mit l1-cache-size=xxx gespielt?
-
Thread
AVR unter Windows in C, welche Toolchain?
ich gesehen das es neuere AVR Tollchain-Versionen gibt. 1) http://gnutoolchains.com/avr/ avr-gcc5.3.0.exe 2) http://blog.zakkemble.co.uk/avr-gcc-builds/ avr-gcc-7.3.0-x64-mingw.zip (51.22 MB) Ist es sinnvoll eine neuere Version zu installieren? Was ist verbessert worden? Ist der generierte
nur dann Sinn, wenn sie gleichzeitig beim Compiler und Linker angegeben wird. Der Umstieg von avr-gcc 4.3.3 auf avr-gcc 4.7.2 bringt also in diesem Beispiel 28% kleineren Code! Es verhält sich so, wie Frank es beschrieben hat. Danke nochmals für die Infos. Gruss, Jan
-
Thread
Geschwindigkeit IO-Zugriff
Bild. ich habe selbst noch keinen Arm und keine vergleichbare Umgebung zum AVR mit Make, Avrdude, Gcc.
Sprung der Schleife ist halt "langsam". Deine Ergebnisse sind etwas komisch, hast du die Compiler Optimierung an?
-
Thread
? zu rekursiven Funktionsaufrufen
Mal 2 konkrete Beispiele, wie ein Compiler das umsetzen kann; hier mit avr-gcc-7 -O2 ... Bei Optimierung auf Codegröße ist der Code fast identisch. Beispiel #1 berechnet die Summe der ersten n ganzen Zahlen >= 0 [c] unsigned sum (unsigned n) { return n ? n + sum (n -
Beitrag #5337189: > Mal 2 konkrete Beispiele, wie ein Compiler das umsetzen kann; hier mit > avr-gcc-7 -O2 ... Bei Optimierung auf Codegröße ist der Code fast > identisch. Beispiel #1 berechnet die Summe der ersten n ganzen Zahlen >>= 0 > [c] > unsigned sum (unsigned n) > { > return n
-
Thread
Optimierung verstehen
Hallo, bin Anfänger auf dem Gebiet, also haut mich nicht gleich. Ich hab das Problem, dass GCC mir das weg optimiert: [c] U08 msg_new[msgSize]; U08 i; uint8_t address = msg[0]; for(i=0; i<msgSize; i++) { msg_new[i] = msg[i+1]; } [/c] Optimierung steht auf: -O0 Wenn ich
AVR Beginner schrieb im Beitrag #5326652: > Optimierung steht auf: -O0 > Wenn ich die Optimierung ausschalte geht es. Kaum zu glauben. Bist Du sicher mit dem O0? Auszug aus: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html -O0
-
Thread
Bits tauschen?!
je nach Architektur bietet der GCC dafür "builtins" an, zB für AVR das __builtin_avr_insert_bits: [c] // reverse bit order static uint8_t mirror(const uint8_t bits) { return __builtin_avr_insert_bits(0x01234567, bits, 0); }
Variante. Wenn ein Compiler ohne passendes Builtin benutzt werden soll, dann kann man ja immernoch gcc's builtin disassemblieren...
-
Thread
AVR Comiler Optimazation Crasht den Controller (ATMEGA328P)
remotepwr ab. Nachdem ich einiges Herumprobiert habe ist mir aufgefallen, dass bei ausgeschalteter Optimierung im Compiler alles super läuft nur dann ist das Programm knapp 200% größer. Ich würde gerne verstehen warum das so ist und daraus lernen. In der Hoffnung hier in dem Forum treibt sich ein Profi
Kaj G. schrieb im Beitrag #5319327: > $ make > gcc -std=c11 -O0 -g3 -Wall -Wextra -Wunused-variable -Wunreachable-code > -Wsign-conversion -Wmissing-braces -Wparentheses -Wsequence-point > -pedantic -o c_test.elf src/main.c > src/main.c: In function
-
Thread
Ungenutzte Bibliotheksfunktionen aussortieren
der Thread https://www.mikrocontroller.net/topic/443383 macht mich ein wenig stuzig. Wenn eine Optimierung dazu führen *könnte*, dass ein leerer, von mir definierter Callback, einen Usercallback überschreibt dann ist das vollkommen inakzeptabel und der falsche weg. Und somit komme ich wieder zu Funktionszeigern
Da meine Funktionen leer sind, würde *__naked* sinn ergeben, aber das ist auf der x86 Architektur (gcc) scheinbar nicht definiert. Bliebe noch die Möglichkeit *__always_inline* Wie würdet ihr das Problem lösen?
-
Thread
GCC: variable may be used unitialized
unbegrenzt, und es hängt auch vom Optimierungsgrad ab. Vielleicht nochmals die Doku studieren: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized Ansonsten kann ich mich nur Felix anschließen.
Abbruchbedingung weniger Unterschied besteht, als es von Nutzersicht aussieht? Oder daß bei der Optimierung das eine in das andere überführt werden kann (in einer Richtung ist das klar... aber in Gegenrichtung? ) ? Oder stehe ich auf dem Schlauch?
-
Thread
Brauche Unterstützung beim OV7670 (bzw. SCCB)
ASM-Listing anschauen, das der Compiler erzeugt. Wenn die Portzugriffe richtig optimiert (kann der GCC eigentlich), sind das jeweils 3 oder 4 Takte. Die Umsetzung von interruptFlag=true; und i++; wird wesentlich ungünster sein, weil der GCC intern C-typisch mit 16Bit-Werten rechnet und das kostet einige
der Debugger - oder genauer: der Typ, der > vor dem Debugger saß. Erst wenn man die Compiler-Optimierungen > ausschaltet, funktioniert das "Durchsteppen" durch den Code so richtig. Ja, das ist das Problem: Debug geht nur zuverlässig ohne Optimierung weil der GCC sonst zuviel umsortiert. Einer der
-
Thread
C-Lehrbuch aus dem Rheinwerk-Verlag schlecht? Alternative?
an. Der hat's bis heut nicht gelernt. Oder der Linux Kernel, dessen Code funktioniert nur mit dem GCC, mit einer bestimmten alten Sprachversion, und nur mit -fno-strict-aliasing aktiviert, d.h. wenn eine bestimmte Art fehlerhaften Codes erlaubt ist. Das verhindert eine Klasse von Optimierungen. Mit
Dr. Sommer schrieb im Beitrag #5311949: > Es ist fehlerhaft im Sinne des Standards. Dass der GCC eine Option > bietet über solche Fehler hinwegzusehen ist pure Nettigkeit. Ich denke das ist falsch. Strict-Aliasing erlaubt dem Compiler weitere Optimierungen. Wenn man mit Option no-strict-aliasing
-
Thread
avr gcc, xmega 128a4, switch-Anweisung
genauer einkreisen / beschreiben, mache ich hier selbst einen Fehler (DAU?) und falls es ein Bug in gcc ist, wo kann ich das melden?
eine Optimierung, behoben in v8: https://gcc.gnu.org/PR81075 [*] Alle Versionen bezogen auf FSF. Wolfgang schrieb im Beitrag #5306849: > Und dann hangelt sich der Compiler halt so durch das switch-Statement
-
Thread
Welche Programmiersprache lernen? (C, Phyton, Lisp, Swift, Smalltalk?)
Datenblatt des uC zu bemühen und die nötigen Detailkenntnisse so zu erlangen und zu ergründen. Der GCC Compiler legt Dir auch bei Arduino keine Begrenzungen auf. Ganz abgesehen davon sind die Bibliotheken offen und studierbar. Auch lassen sich viele Quellen von anderen nicht-Arduino uC leicht portieren
interessiere, z.B. wie Java Bytecode jetzt genau funktioniert oder die C++ Value Semantics und wie die Optimierungs-Algorithmen des Compilers arbeiten... bin ich dann ein Mainstream-Schaf oder hipp und "aufgeweckt"?
-
Thread
C++: <array> als Parameter für Funktion
Microsoft in einer HPC Anwendung ausprobiert habe war dessen Code nicht mal halb so schnell wie unter gcc. Da hat der dicke Xeon mehr als doppelt so lang für die gleiche Berechnung gebraucht wie der i5 im Laptop. Damit ist der Microsoft Compiler für mich persönlich gestorben.
in einer HPC Anwendung > ausprobiert habe war dessen Code nicht mal halb so schnell wie unter > gcc. Du scheinst den C++-Compiler von MS zu meinen? Nur hat der nichts mit der GSL zu tun ...
-
Thread
Bitmanipulation Shiften
Dr. Sommer schrieb im Beitrag #5298580: > Was heute ohne Optimierungen funktioniert, klappt morgen mit > Optimierungen vielleicht unbemerkt nicht mehr weil der Compiler die > Register-Zuordnung geändert hat. Dr. Sommer schrieb im Beitrag #5298580: > Allein schon
innerhalb von GCC portierbar. Beispielsweise erzeugt avr-gcc folgenden Code: [c] #include <stdint.h> int8_t ashr1 (int8_t x) { return x >> 1; } int8_t ashr7 (int8_t x) { return x >> 7; } int8
-
Thread
Antennenanalysator nach EU1KY
17T09:44:28 INFO src/common.c: Flash written and verified! jolly good! Als Compiler habe ich den gcc version 5.4.1 20160609 verwendet. >arm-none-eabi-gcc -v Using built-in specs. COLLECT_GCC=arm-none-eabi-gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/arm-none-eabi/5/lto-wrapper Target: arm-none-eabi
habe. Sobald ich eine Lösung gefunden habe, wie die EMBITZ Spezifika für die ISR Definition auf GCC anzupassen sind, werde ich den RTC teil wieder hinzunehmen. Markus
-
Thread
C Compiler ISR
://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html#ARM-Function-Attributes https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function-Attributes https://gcc.gnu.org/onlinedocs/gcc
Prolog / Epilog wird ausgegeben von "riscv_expand_prologue" bzw. "riscv_expand_epilogue". https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/riscv/riscv.c?view=markup
-
Thread
Variableninitialisierung
ist anders, siehe unten. Mir ist wirklich kein C-Compiler bekannt, der selbst bei ausgiebigster Optimierung ganze Anweisungen, mit denen einer Variable ein Wert (0 oder sonstwas) zugewiesen wird, einfach wegläßt. Selbst der knöselige GCC macht sowas nicht. So. Und nun weswegen das Ganze? Wenn am
Beitrag #5288839: >> Mir ist wirklich kein C-Compiler bekannt, der selbst bei >> ausgiebigster Optimierung ganze Anweisungen, mit denen einer Variable >> ein Wert (0 oder sonstwas) zugewiesen wird, einfach wegläßt. Selbst der >> knöselige GCC macht sowas nicht. > > ACK. Ich wüsste nicht, wie ein
-
Thread
LPC2134 Startup Code bzw. "Blink Beispiel"
hatte ich zwar hauptsächlich mit dem Keil gearbeitet, aber ich hatte dann das Ganze auch noch mit dem GCC (Yagarto, Version hab ich vergessen) durchgezogen. Ein Linkerscript war dazu überhaupt nicht nötig. Guck dir einfach die "cccgcc.bat" an, dazu die zwei "compile_gcc.xcl" und "link_gcc.xcl". Sicherlich
obendrein ist der Code des GCC selbst bei heftigster Optimierung noch immer um 10..20% größer als der vom Keil. W.S.
-
Thread
-
Thread
Assemblerprogrammierung ARM CORTEX
In der GCC Toolchain sind üblicherweise Muster für den Startup Code dabei, in .\share\gcc-arm-none-eabi\samples\startup.
normalerweise" weder as zum assemblen, noch ld zum linken benutzt. Beides übernimmt in der Regel der gcc und zwar mit [code] arm-none-eabi-gcc -x assembler-with-cpp # für den Assembler # und arm-none-eabi-gcc # für den Linker [/code] Dem Linker-Script fehlt quasi der komplette Teil für den RAM,
-
Thread
Arduino const struct
er dein struct-Konstrukt so weit optimieren, dass derselbe Code rauskommt. Muss er aber nicht. gcc macht's so. Allerdings nur, wenn erstens die Optimierung auf mindestens -O1 eingestellt ist und 2. er bei jeder Verwendung die gesamte struct inclusive ihrer Initialisierung zu sehen bekommt. Ich
das nur mit constexpr einigermassen > gesichert. Meiner bescheidenen Erfahrung nach macht der gcc das mit const sehr zuverlässig. Oliver
-
Thread
XMega-Assembler: Welche Register darf ich verwenden?
GCC benutzt man sinnvollerweise dessen Constraint-System, um ihm eine maximale Integration in die Optimierung zu ermöglichen. Dann legst du die Register auch gar nicht mehr selbst fest, die du benutzt
data space Das Rückschreiben hier ist verdächtig. Ich glaub du hast nicht wirklich mit Optimierung übersetzt.
-
Thread
AVR-GCC: PUSH-/Pop-Orgie verhinern
https://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Function-Attributes.html#index-g_t_0040code_007bOS_005fmain_007d-AVR-function-attribute-2653
Kevin schrieb im Beitrag #5270366: > Welche avr-gcc-Version setzt du denn ein?? Das sollte schon lange kein > Thema mehr sein. Eine entsprechende Optimierung ist ab avr-gcc v8 verfügbar (PR83738).
-
Thread
Überlauf bei Multiplikation verhindern
. Walter ist mir bisher nicht als jemand aufgefallen, der exzessiv Zeit in unsinnige Mikro- Optimierung steckt. :) Andernfalls hast Du natürlich Recht.
Headroom" hat bis zum Überlauf. Weiters gibt es compilerspezifische Built-ins, siehe etwa http://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html Allerdings _verhindern_ die keinen Overflow (wie von dir gewünscht), sondern lassen ihn lediglich erkennen. Einen Overflow verhindern geht nur
-
Thread
Arduino Libraries zu STM32 Portieren
aussieht, hast du ja nun selber herausgefunden. > 4.) > Was Seegen und Fluch zu gleich ist, mit den GCC Compiler lassen sich die > verschiedensten CPU Hersteller unterstützen. Was auch immer das mit Arduino zu tun hat. Die Arduino-Leute haben schlicht gar keine Aktie an gcc. Sie nutzen den gcc nur
Somit haben > alle IDE's irgendwelche Probleme. Und wenn es der Compiler ist, der bei > vielen IDE's GCC heißt. Der GCC ist mit Sicherheit die letzte Fehlerquelle - nicht nur bei Ardunio.
-
Thread
ISR Code schneller machen?
ja einfach testen indem die ISR auf ein Servo reduziert wird. Hast du schon mit verschiedenen Optimierungen kompiliert?
Kann man machen. Sollte die Optimierung des avr-gcc aber schon seit Jahren selbst aus einem switch-case-Block machen, wenn es sich lohnt. Und ändert nicht grundlegend etwas an deinen Problemen, vermute ich :) Sieht ungefähr so aus
-
Thread
Dauerspeicherung auf SPI EEPROM mit Wrap-around und Sektorlöschung (avr gcc)
dass sie sehr ineffizient sind und suche deshalb nach besseren Lösungen. Für Ratschläge und Optimierungen wäre ich sehr Dankbar. mfg
bleiben. Also Datensätze anhand CRC oder so auf Gültigkeit überprüfen. Übrigens, was hat das mit avr-gcc zu tun???
-
Thread
GCC -fstack-usage
Servus miteinander, Um den benötigten Stack abschätzen zu können habe ich mich mal mit der GCC-Option -fstack-usage beschäftigt. Der GCC generiert dann zu jeder .o-Datei eine .su-Datei, in der zu jeder Funktion die Stackbenutzung angegeben wird. z.B. bekommt man für ein leicht abgeändertes
printf("The answer to everything is %d\n",i); return 0; } [/c] mit [code] arm-none-eabi-gcc -O0 -fstack-usage -c main.c [/code] eine main.su mit dem Inhalt [code] main.c:3:5:magic_number 24 static main.c:14:5:main 16 static [/code] Mal abgesehen davon, dass der
-
Thread
constexpr in Atmel Studio nicht verfügbar?
probiert doch gleich mal -std=c++17 aus ;-) > > Eine solche Option unterstützt nicht mal der aktuelle gcc 7.2. Aber > -std=c++1z sollte gehen. In gcc 7.2.1. schon ;-) In gcc-8 geht schon c++20a.
MitLeserin schrieb im Beitrag #5249564: > Die Toolchain avr-gcc-8.0_2017-07-19_mingw32 ist verfügbar unter: > https://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20(Win32)/ Das ist nur ein Snapshot, dessen Intention es war, bessere ISR-Optimierung
-
Thread
PIC24 und Bit-Befehler
ich bislang noch nicht gefunden. Wobei das mit Stand vor vielen Jahren eine verzierte Version des GCC ist. Die haben eine Optimierung hinzugefügt, die man auch bei den kleineren PICs findet: gleiche Codesplitter zusammen zu fassen. Aber so implementiert, dass die GPL wohl nicht verletzt wird, Lizenzcheck inklusive. Allerdings ist das nicht die einzige Optimierung, die nur für Geld zu haben ist, denn das Steuerprogramm oben drauf ist auch von denen. Im normalen GCC ist "gcc" nicht der Compiler selbst, sondern ruft bloss den eigentlichen Compiler auf (nebst
-
Thread
if-Anweisungen als Block
du überhaupt, wie man das richtig macht? Und warum? https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung >daher die Frage ob folgende Routine >"legetim" ist; Sie ist OK, optimiert aber nichts wirklich. Dein Programm wird weder kürzer, noch schneller, noch
-
Thread
Tester für Spezialversion des AVR Bootloaders optiboot gesucht!
EEPROM-Unterstützung hat unsere Version nicht und mit AVR-GCC 5.4 sind noch 34 Bytes frei.
ATtiny von Anno 2014 wie t1634, t841 oder t167, die nach meiner Erinnerung nicht alle von älteren arg-gcc Versionen unterstützt wurden. Außerdem unterscheiden sich die avr-gcc Versionen durch unterschiedliche Optimierung, was natürlich für die Assembler-Quelle keine Rolle spielt. Die Optimierung ist aber
-
Thread
AVR GPIOR Bit Verwaltung C++
steckt in den Headern .. https://github.com/KonstantinChizhov/Mcucpp/blob/master/examples/GPIO_GCC_AVR/GPIO_sample.cpp
(&GPIOR0)); return &GPIOR0; } [/c] Übersetzt für einen ATmega168 und _unabhängig_ von Optimierung, erzeugt avr-gcc daraus (hier mit -O0): [pre] .section .rodata addr: .word 62 _Z1fv: ... ; foo.cpp:9: __asm ("; yes"); ; yes ; foo.cpp:12: __asm ("; addr = %0"
-
Thread
Anfängerfrage QuickWatch oder Step by Step
wo findet man die Optimierung?
Michael B. schrieb im Beitrag #5241062: > wo findet man die Optimierung? Ich verwende nicht das Studio 7, aber auch dort müsste es unter 'Project' zu finden sein.
-
Thread
Frage zu IR-Remote+LED-Strips an AVR
offiziellen 50us Maximalpause vorhanden ist. Aus Interesse habe ich mir vor einiger Zeit mal den vom AVR-GCC erstellten Assembler Code (zu finden in der *.LSS Datei im Kopilerordner) für eine ISR angesehen... Je nach Optimierung des Compilers kann man für das Pushen / Pullen der uC Register auf den Stack
50us Maximalpause vorhanden ist. > >>Aus Interesse habe ich mir vor einiger Zeit mal den vom AVR-GCC >>erstellten Assembler Code (zu finden in der *.LSS Datei im >>Kopilerordner) für eine ISR angesehen... > > Und was hast du gesehen? Wieviele Takte wurden benötigt? > >>Je nach Optimierung des
-
Thread
STM32 HAL versus CMSIS
konzentrieren kann. Was > interessiert mich ob die Initialisierung eine µs länger dauert? Habe einen GCC und alle Optimierungen ausgetestet. Weil die performance bei mir das Problem war! Solche Untersuchungen, macht man nur, wenn man muss. Problem war: Alle 15 us kommt ein Interrupt und dann müssen
ein Abstraktionslayer ein und Dank LTO kostet > das exakt 0% Overhead. Du meinst Link Time Optimierung ala Somnium? Wird der mir auch den überflüssigen Timer ISR wegoptimieren? Automatisierte Optimierungen können keine architektonischen Probleme lösen.
-
Thread
Avr Studio - Hex Datei plötzlich zu groß
Problem, dass meine compilierte hex datei auf einmal fast doppelt so groß wird als wenn ich das selbe GCC Projekt auf dem alten PC compiliere. Leider passt das Programm so jetzt nicht mehr auf den Controller. Die eep Datei ist auch 6 mal so groß... Habe schon mit der Optimierungs-Einstellung rumgespielt
, dass meine compilierte hex datei auf > einmal fast doppelt so groß wird als wenn ich das selbe GCC Projekt auf > dem alten PC compiliere. Leider passt das Programm so jetzt nicht mehr > auf den Controller. Die eep Datei ist auch 6 mal so groß... > > Habe schon mit der Optimierungs-Einstellung
-
Thread
Frage an W.S. wegen USB CDC Implementierung STM32F103
eingesetzt, um zu prüfen, dass der µC wirklich in UsbCharOut() hängt. jetzt kommt der Witz: Mit der Optimierung -O0 tritt der Fehler nicht mehr auf! Dafür meldet Windows jetzt bei -O1 und -O2 grundsätzlich bei jedem Anstecken, dass das Gerät nicht ordnungsgemäß funktioniert. Mein eigentliches Problem
aus core_cm3.h hat den Vorteil, dass es je nach Compiler die richtige Implementierung macht. Beim gcc ist das dann: [C] static __INLINE void __NOP() { __ASM volatile ("nop"); } [/C] Damit ist der Code dann auch unter Keil übersetzbar, der mit der gcc Syntax "asm volatile
-
Thread
constexpr Argument-Wrapper
return std::byte{0};}); // constraint not satisfied } [/c] Geht natürlich im Moment auch nur mit gcc (und -fconcepts).
Sry für den Necro, aber mir ist gerade aufgefallen dass GCC (7.3.0) schon jetzt nicht vollkommen Standard-Konform sein dürfte was das "Propagieren" von Constexpr-Ness angeht. Folgendes Schnipsel etwa compiliert mim GCC fehlerfrei durch [c] template<typename
-
Thread
SRAM schonende Optimierung beim gcc?
Template-Mechanik zur Produktion von mehr Code (im Flash) führen. Allerdings sind teilweise die Optimierungen des Clang / gcc bei template-code geradezu "atemberaubend", und andererseits tun ein paar (k)Byte mehr Flashverbrauch weniger weh als beim SRAM.