-
Thread
[C] Struktur ist zu groß
gcc 4.7.2 x86-64: 14 gcc 4.8.1 ARM: 14 gcc 4.7.2 AVR: 14
Es gibt in GCC eine Warnung -Wpadded.
-
Thread
C++ für Mikrocontroller
vorhanden und getestet ist und der Vorteil durch C++ den Aufwand nicht wettmacht. Das ist z.B. bei gcc anders.
und zuletzt mit > avr-strip die Symbole entfernt. Wie bist Du zu Deinem Ergebnis gekommen? arm-gcc, nicht avr-gcc! Ist es nicht so, daß der avr-gcc gar keine Exceptions und keine RTTI unterstützt? arm-gcc hat diese beiden Dinge sicher mit dabei, weshalb das Abschalten dieser sich auch bemerkbar
-
Thread
static inline in Projektorganisation
, wo die Funktion mit einer Variablen anstelle einer Konstanten aufgerufen wird, macht mir die Optimierung -S einen Strich durch die Rechnung und auch an allen anderen Stellen keinen einfachen SBI/CBI mehr. Diese und ähnliche Funktionen sind allerdings auch die einzigen "static inline" im ganzen Projekt
sondern in *.inc-Dateien. Nimm -Os -flto sowohl als Compiler- als auch als Linkerflag. Dann kann der gcc sogar modulübergreifende Funktionsaufrufe "inlinen", wenn er das für sinnvoll hält.
-
Thread
Attiny 2313A - ROM am Limit? Probleme mit Optimierer
mit doppelter Belegung des Speichers zu tun hat. Leider bemerkte ich dann auch, dass schon Optimierung "-Os" aktiviert war. AVR-GCC meldet auch ca. 98% ROM-Auslastung. Ich habe versucht mit "-O1" zu kompilieren, was jedoch mit Fehler abbricht ("Program memory 114% Full"). Ich habe schon alle
lokale. Denn 8-Bit relativ zu SP ist einen Takt langsamer ('08). Für die 12er gibts übrigens eine GCC Implementierung. Wobei GCC für Akku-Architekturen alles andere als ideal ist. Darin finden sich einige Pseudo-Register im RAM. GCC wird vorgegaukelt, als hätte der einige Register. Auch in einer Version
-
Thread
C versus Assembler->Performance Gesperrt
noch lange nicht gesagt. Du kämpfst gegen Windmühlen. https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
Kannste beim GCC auch, ist aber nicht portabel: https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html
-
Thread
STM32-Code geht nicht, Compilerproblem?
nur nicht warum, da i2cDirectionWrite permanent "1" ist. Ich verwende CooCox Version 1.7.7 und gcc-arm Version 4_8. Code-Optimierung ist auf -O0 (None). Es scheint wohl ein Compilerproblem zu sein. Weiß jemand Rat?? Schonmal Besten Dank!! [c] #include <stdint.h> #include "stm32f10x_i2c.h
Hab nun CooCox 1.7.8 installiert und arm-gcc 4.9 ... Jetzt gehts...
-
Thread
Unterschied zwischen int i; in while und vor while
gleiche Register verwendet werden. Freilich war das früher wichtiger als heute, denn Compiler wie GCC kriegen selber raus, in welchen Codebereichen eine Variable verwendet wird und in welchen nicht. Früher war es üblich, dem Compiler mit "register int x;" einen entsprechenden Tipp zu geben - da konnte
Register zu landen, oder auch im Speicher. Folgen hat das für Debugging mit eingeschalteter Optimierung: Compiler und Debugger haben dann recht viel Mühe, die notwendige Information so zu erzeugen und auszuwerten, das der Debugger stets an der richtigen Stelle nachsieht. Einmal mehr die "as if
-
Thread
Eclipse Luna & STM32F407 & vorhandenes CooCox-Projekt
Compiler-Error - aber wenns ans Linken geht, läuft noch was schief. Wie binde ich das Linker Script arm-gcc-link.ld ein? Ich habe unter "Properties -> C/C++ Build -> Settings unter "Cross Arm C Linker -> General" das Script eingetragen. Keine Ahnung, ob das so richtig ist... Und wie sage ich dem Linker
Das Release-Binary ist nun 254kB groß (CooCox: 316kB) Bei keinem der beiden ist irgendeine "Optimierung" aktiviert Und nicht nur dass das Binary kleiner ist - es ist auch spürbar weniger prozessorlastig in der Ausführung als das CooCox - Produkt. Die Mühe hat sich gelohnt :) Danke für deine
-
Thread
C Übergabe mit Zeiger
es ein Bug von AVR Studio? Wenn dann wäre es ein Bug im Compiler (und nicht in der IDE), also dem GCC, und das ist (wenn auch nicht ganz ausgeschlossen) eher unwahrscheinlich. Such mal hier im Forum nach Bug und GCC. Fast jeder behauptet erstmal, das muss ein Bug im Compiler sein,... und praktisch
jedes Mal stellt > sich raus, das es doch kein Bug im GCC ist. Ja klar im Compiler. Ich weiß garnicht das AVR-Studio gcc nutzt. Ehrlich gesagt kann ich es mir auch nicht vorstellen, aber an was liegt es dann? > Mit welchen Compiler flags compilierst
-
Thread
Wie feststellen in C, ob Zahl grade oder ungrade?
Mach das bitte. Mich interessiert jetzt nach der Diskussion hier doch jetzt auch was GCC so aus den Vorschlägen macht.
call 0x406a ; 0x406a <printf> [/a] bei -Os. Sehr interessant die sehr unterschiedliche Optimierung.
-
Thread
AVR-gcc: Optimierungslevel lokal ändern?
A. K. schrieb im Beitrag #4229727: > https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html > und unter "optimize": > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes Die Beschreibung
Ich glaube, der AVR-gcc kennt so ein Attribut nicht: https://gcc.gnu.org/onlinedocs/gcc/AVR-Function-Attributes.html#AVR-Function-Attributes
-
Thread
AVR-GCC: Code wird totoptimiert
Mikrooptimierung Karl K. schrieb im Beitrag #4229190: > folgendes Codefragment optimiert mir der AVR-GCC kaputt: Wenn du kaputten Code schreibst, brauchst du dich nicht beschweren, wenn das, was dabei rauskommt, nicht funktioniert. Den GCC trifft da keine Schuld. Wenn du eine Funktion (den GCC) mit
machen musst und dich jenem Code näherst, denn du auch mit "volatile" erhältst. > Wie kann ich den GCC davon abhalten, den Codeteil kaputtzuoptimieren? GCC passend für deine Interpretation von C umschreiben.
-
Thread
[AVR-GCC - AtTiny2313] Schwierigkeiten mit modularer programmierung
Verzweiflung. Kurze Infos im Voraus: - Ich arbeite unter Linux (eOS Freya - Ubuntukern 14.04) - gcc version 4.8.2 (GCC) - Ich verwende zum kompilieren ein eigenes makefile (siehe Anhang) das hier angebotene diente als Vorlage und wurde auch getestet. - Ich besitze keinen ISP Adapter. Hierfür
implizit global. Nur mit LTO kann er das. Jede CompUnit wird "Vorübersetzt" und die eigentliche Optimierung/Codegenerierung findet im Linker statt. Der kennt ALLES zu dem Programm, kann also das unbenutzte f() rausschmeisen.
-
Thread
STM32: externer ADC 400 kHz - Timer+SPI+DMA Optimierung
absolut nicht möglich ist. Mit den Interrupts habe ich nochmal geprüft. Ich hatte vergessen die Optimierung zu aktivieren. So komme ich jetzt auf ca. 150 ns bei 168 MHz. (Gemessen mit einer PWM-Ausgabe und einem Interrupt mit getoggeltem Ausgang) Wenn ich den DMA im Interrupt aktiviere um am SPI etwas
Konverterplattform) pumpt der STM32F405 mit über 1MHz Daten in die GPIOs, getriggert durch externen Interrupt. GCC 4.8 -o3 168MHz. Wenn der Interrupt selbst in -o3 zu viel Overhead hat, bieten sich ein paar Zeilen Maschinencode an. Sollte aber nicht notwendig sein.
-
Thread
avr-gcc 5.2 für Windows
--param ggc-min-heapsize=131072 COMPILER_PATH=c:/program files (x86)/gcc-5-avr-mingw32/lib/gcc/../../libexec/gcc/avr/5.2.1/;c:/program files (x86)/gcc-5 -avr-mingw32/lib/gcc/../../libexec/gcc/;c:/program files (x86)/gcc-5-avr-mingw32/bin/../libexec/gcc/avr/5.2.1/;c:/progra
lib/gcc/avr/5.2.1/../../../../avr/lib/avr5/;c:/program files (x86)/gcc-5-avr-mingw32/bin/../lib/gcc/avr/5.2 .1/;c:/program files (x86)/gcc-5-avr-mingw32/bin/../lib/gcc/;c:/program files (x86)/gcc-5-avr-mingw32
-
Thread
C: Programm mit Textanzeige für mehrere Sprachen
speicher optimierung: du könntest dann mit dynamischer speicherverwaltung arbeiten, und zur laufzeit und bedarfszeit mit malloc() / calloc() realloc() arbeiten, und dabei immer wieder den alten speicher entweder
über ein array of struct vorhalten > > Nö. hast ja recht, bin doch schon bei der speicher optimierung, eins nach dem anderen ;-) ..
-
Thread
STM32 korrekte Interrupt-Handhabung
normalerweise nur die Deklaration => extern fehlt Du hast zweimal definiert == zwei Variable angelegt. Beim gcc dürfte dies gut gehen, da er nach meiner Erfahrung diese zusammenlegt. Header: [c] extern volatile uint32_t TriggerValue; [/c]
volatile unterbindet einfach gesagt nur die Optimierung. Das merkst Du speziell, wenn Du innerhalb einer Schleife auf die Veränderung der Variablen wartest. Ohne volatile würde der Compiler meinen, dass der Wert im Register immer aktuell ist. Der Interrupt
-
Artikel
FAQ
selbstgeschriebene Funktion zur Stringausgabe auf LCD - die Funktion lcd_string() - aus dem LCD-Teil des AVR-GCC-Tutorials verwendet: Um also eine Zahl (numerische Konstante oder Variableninhalt) auszugeben, muss von dieser Zahl zunächst ihre String-Repräsentation ermittelt werden. Hier geht es aber nur darum,
Maschinensprache übersetzen Version, Anweisungen einzusparen. Das dürfen sie auch. Der C-Standard erlaubt Optimierungen, solange die 'As-If'-Regel eingehalten wird. Das bedeutet: Der Compiler darf das Programm umstellen und verändern, solange die Programmergebnisse dieselben bleiben. Eben "As-if" die Optimierung
-
Thread
Unterschied JAVA & C++
Das kann man keineswegs so pauschal sagen. Die Laufzeitumgebung von Java ermöglicht diverse Optimierungen, von denen C++ nur träumen kann; zB dass das Java Programm immer für den CPU des Nutzers optimiert (just-in-time kompiliert) wird und diesen somit optimal nutzt, während die meisten C++ Programme
Das kann man keineswegs so pauschal sagen. Die Laufzeitumgebung von Java > ermöglicht diverse Optimierungen, von denen C++ nur träumen kann; zB > dass das Java Programm immer für den CPU des Nutzers optimiert > (just-in-time kompiliert) wird und diesen somit optimal nutzt, während > die meisten
-
Thread
Projekt: SerialComMeasurement
so einen 1-Mann-Compiler nicht > schlecht. Aber auch nicht vergleichbar mit Mannjahrhunderten des GCC. Ist kein GCC, aber LunaAVR ist besser und moderner als alles andere was sonst so angeboten wird und dabei kostenlos. Ich mag kein C, daher war es für mich die 1. Wahl. Hans-Georg L. schrieb im
so einen 1-Mann-Compiler nicht > schlecht. Aber auch nicht vergleichbar mit Mannjahrhunderten des GCC. der assembler-output kann generiert werden. ich hätte nur gerne den luna-source gehabt (verwende auch luna), da wäre sicher noch optimierungspotential gewesen. Die Optimierungen des Compilers sind
-
Thread
avr >> int oder char
Eigenmächtigkeit" des GCC ;-)
> so eine "Eigenmächtigkeit" des GCC ;-) Der gcc kann da nichts dafür. Das liegt am avr.
-
Thread
C-Code optimieren (passt nicht in Attiny2313) :( Gesperrt
Probier mal -mcall-prologues Damit optimiert der GCC die Pushs/Pops von Funktionen, indem er sie mehrfach nutzt. Kann helfen.
C-Compiler in einem 2nd-Pass auf. Wenn man hier kein -Os angibt, wird im zweiten Durchgang ohne Optimierung übersetzt)
-
Thread
Unterschiedliches Verhalten zwischen "Debug" und "Release" Modus
Ich nutze Eclipse mit dem GCC und den GNU ARM Eclipse Plugins zur Software-Entwicklung für STM32(L151). SWD-Probe ist ein ST-Link V2 vom F4Discovery über openOCD. Jetzt habe ich den DFU Bootloader (HAL Version) von ST für meine
danach den Input liest, man noch den vorherigen Zustand im Latch liest. Im Debug sind oft die Optimierungen aus, d.h. der Code braucht länger und dadurch kann ein anderer Wert eingelesen werden.
-
Thread
[C] Tiny 44 - Rundungsfehler?
schneller ist als / ob ich spassenshalber mal Ports setzte in beiden Fällen und die Zeit messe ob der gcc deiner Meinung ist?
Links-Schieben. > ob ich spassenshalber mal Ports setzte in beiden Fällen und die Zeit > messe ob der gcc deiner Meinung ist? Assembler Listing ansehen reicht.
-
Thread
Compiler optimiert einfach Bitmanipulation nicht
OMG! https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung Das gilt nicht nur für Software, auch für so ziemlich alles anders. Mal eine Überlegung. Bei 10 MHz dauert ein Takt = 1 ASM Befehl beim AVR 100ns. Bei
Compiler? Ohne testfall ist das lesen aus dem Kaffeesatz. Evtl. eine Änderung analog zu https://gcc.gnu.org/r192198
-
Thread
Erfolgreich AVR Dragon + AVARICE + GDB verwendet unter Linux
www.mikrocontroller.net/articles/DebugWIRE Jetzt aber zur Verwendung: Ich erkläre jetzt nicht wie man avr-gcc/gdb usw installiert, das setzte ich mal voraus (oder siehe hier: https://gergap.wordpress.com/tag/avr/) Man muss die folgenden Tools installiert haben: * avr toolchain: avr-gcc, avr-gdb, avrdude
gdb Script:" Was gibt es noch zu beachten? 1.) Natürlich sollte man mit "-O0 -g" bauen. Die Optimierung erzeugt schwer nachvollziehbaren Code. Man sollte höchstens O1 verwenden. -g erzeugt die Debug Info. 2.) Der Debugger will das ELF file mit der Debug Info. Mit dem HEX file, welches man zum Flashen
-
Thread
canbus mit SN65HVD230D und FlexCan
nötig. mag sein, aber aktuell ist der teensy so schnell das der can-bus aufgibt ... also speed-optimierung noch garnicht nötig ... im übrigen reicht es aller 6 (mit CANbus.write(msg)) gesendeten messages ein delay(3) rein zu machen und alles funktioniert ... also scheint mir das doch irgendein
zu tun, ein teensy ist kein arduino, ich kann das auch mit nem vi schreiben und zu fuß durch den gcc-avr treten ... das wird das problem auch nicht lösen ...
-
Thread
AVR Timer 1 Normal/CTC Mode ?
des Systemtaktes, die beiden anderen dementsprechend 1/128 und 1/256. Wie gesagt: ohne weitere Optimierungen. Mit Optimierungen sind noch deutlich höhere Frequenzen erreichbar. Wie oft bei kurzen und sehr häufig durchlaufenen ISRs ist das Reservieren von Registern die Optimierung, die mit Abstand am meisten
straightforward-Routine braucht, vielleicht sogar wirklich exakt diese 32. Müßte ich direkt mal probieren, ob der gcc das schafft... Bloß die ultimative Optimierung, Register exklusiv zu reservieren, die nötig wäre, um die Sache nochmals merklich schneller zu machen, die kannst du in C halt nur sehr eingeschränkt
-
Thread
IDE für ESP8266 mit vielen Example
verlangt -std=gnu90 in den CFLAGS Changelog: v2.0.7 (09.07.2015): * Updated compiler xtensa-lx106-gcc and xtensa-lx106-g++ up to version 5.1 (big thanks jcmvbkbc); ATTENTION! For correct build of your firmware, you must add the option -std=gnu90 in directive CFLAGS in Makefile du benutzt die neue
einigen STM32 LCD-Ausgaben wird ein Datenstream fortlaufend von einem *.raw File gelesen; Da keine Optimierung, Kompression, vorangestellte Farbtabellen oder irgendwelche Header! -rohe Daten eben .. .. die dann, so mein Gedankengang, 1:1 fortlaufend in den IRAM-Bereich kopiert werden;
-
Thread
Funktion mit gleichbleibender Ausführungszeit
hohem Aufwand mit einem Timer machbar. Moegliche Alternative: Funktion in eigene Datei und ohne Optimierung nur diese Datei kompilieren.
Beitrag #4177562: > Linker optimieren nicht. Tun sie sehr wohl. Und nicht erst seit gestern. Die gcc Toolchain kann's seit 2005: http://hubicka.blogspot.de/2014/04/linktime-optimization-in-gcc-1-brief.html Aber auch das dürfte bei diesem Beispiel keine Rolle spielen, da gibt's nach dem Compilieren
-
Thread
"Neue" CPU-Architektur-Aspekte (FPGA softcores)
ZPU. Die Diskussion SPARC/Windows vs MIPS/harte Registerfiles ist natürlich längst hinfällig bei GCC, nur ging es mir primär ums Aufbohren des GCC-Supports von Stack-Machine zu sliding windows (die ZPU ist mit ihren sp-relativen ops wie STORESP/ADDSP schon nah dran). GCC hat so seine Mühe mit Stackmaschinen
mal den J1 Forth im Vergleich zur ZPU anschauen. > Yurkowsky hat dazu auch ein paar nette Optimierungen dokumentiert, und bremsende Hazard-Logik gibts da nicht, ergo kann man sie recht hoch clocken, aber da reine Stackmaschine (nur Push/Pop), ist GCC-RTL dafür nicht praktikabel. Haben sich schon
-
Thread
Welchen Controller für C++ Programmierung? Gesperrt
ähnlich (Touch, TFT, USB > ...) Man korrigiere mich, wenn ich flashc liege, aber ich glaube, der GCC unterstützt den PIC32 nicht (ich habe zumindest auf die Schnelle nix in der Dokumentation https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/ gefunden).
Fall war das von g++ erzeugte Binary sogar minimal kleiner als das von gcc. Die große Ausnahme, für die ich bislang noch keine Lösung gefunden habe, betrifft globale Variablen, die in einer ISR() und anderen Funktionen wie main() verwendet werden. Da scheint der GCC nicht
-
Thread
Zukunft des GCC-Forums
GCC-Unterforum (https://www.mikrocontroller.net/forum/gcc) zusammengefasst. Heute sieht die Situation etwas anders aus: andere Controllerfamilien spielen eine größere Rolle; es gibt viele kostenlose Entwicklungsumgebungen, manche basierend auf GCC, manche nicht, und oft bekommt der Nutzer das gar nicht mit; nur in den wenigsten Fällen kommt man mal in die Verlegenheit, einen GCC selbst kompilieren zu müssen. Entsprechend ist der Traffic im GCC-Unterforum
-
Thread
cast auf 32 Bit Cortex
Code stehen hat keinen Einfluss auf die Kodierung im Maschinencode. Dafür sind Compiler Flags zur Optimierung zuständig (zB -Os vs -O3 im GCC).
-
Thread
Überlauf klappt nicht wie vorgestellt
Auch da bleibt er stehen. Wobei ich die Variable noch nicht volatile gemacht hab. Ich hab die Optimierungen ausgeschaltet, von daher sollte dass dann in dem Fall doch egal sein? Ich erlaube dem Compiler somit doch garnicht, irgendwelche Annahmen zu machen?
GCC schrieb im Beitrag #4167676: > oder S1 = !!(PINB & (1 << PB5)); oder S1 = (PINB>>PB5) & 1;
-
Thread
Taschenrechner - Algorithmen
wusste ich schon, ich denke nur an den Topic vor ein paar Wochen, bei dem es um die schlechte Optimierung des gcc's bei 32bit ging. Ich glaube nicht das 64bit effizienter sind. Ich denke sowieso, dass ich einen externen Quarz mit 16MHz oder ~18MHz hinhänge (Baudratenquarz, hab der Wert grad nicht im
Dingern hat man eben kein double - > > Natürlich hat man doubles, in Software, vom Compiler. AVR-GCC kann kein double. https://gcc.gnu.org/wiki/avr-gcc >> was ich zwar selber als ärgerlich und unsauber empfinde, >> aber zumindest ICH werde dort nix nachrüsten. > > Du hast den Thread offenbar
-
Thread
volatile Variablen
bei nur lesendem Zugriff auf das volatile verzichtet werden kann. Ich verwende hier übrigens den AVR-GCC für einen ATmega-Controller.
extern unsigned char x; void f (void) { while (1) x++; }[/c] Das übersetzt avr-gcc korrekt zu [avrasm]f: .L2: rjmp .L2[/avrasm] Wenn also in einer ISR auf x geprüft wird, wird sich der Wert nie ändern.
-
Thread
For schleife in c ausprogrammieren
habe ich genung, jedoch soll die Ausführung möglichst schnell von statten gehen. Die Compiler Optimierung habe ich schon auf höchster stufe, jedoch sehe ich im Disassamble, dass die Schleife nich ausprogrammiert wurde. Bsp: for(int i = 0; i < 10; i++){ a[1][i] = b[1][i] + c[1][i]; } soll
Stichwort: Loop unrolling Google: "Loop unrolling gcc" Ergebnis: https://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Optimize-Options.html
-
Thread
[ASM] Unbenutzte Symbole entfernen
einfach mal an, was für Unterschiede der Compiler mit und ohne -ffunction-sections erzeugt (mittels "gcc -S" Assembler-Output erzeugen).
auch auf Assembler-Programme anwendbar. M.W. gibt bzw. gab es optimierende Assembler, die diese Optimierung implementiert haben. Der GNU-Assembler gehört aber nicht dazu.
-
Thread
Suche Hilfe bei Optimierung Bootloader
mein Platz Problem erledigt. Bisher war mein Code 28700 Byte groß, nach einfügen der fehlenden Optimierung 15002. Das hätte ich nicht erwartet. Die Frage ist, ob noch alles geht :-) Irgendwann muss ich mein UrMakefile mal die Optimierung entfernt haben. Jetzt wieder drin. Aber eventuell bekommt
Ich benutze auch: -fno-inline-small-functions Der AVR-GCC ist etwas zu übereifrig, kleine häufig aufgerufene Funktionen zu inlinen.
-
Thread
C++ Problem mit Threadsicherheit und std::queue<std::string>
) ab. Mir leuchtet allerdings nicht ein weshalb. OS: Arch Linux Kernel 3.18.14/4.0.4 Compiler: GCC 4.9.2/5.1.0 Einschraenkungen: - *Kein* Boost - muss mit -std=c++98 compilieren [c] #include <queue> #include <string> #include <pthread.h> class FooBar { public: FooBar();
oder mal sogar eigene qualifier definieren könnte), aber das volatile unterbindet im besten Fall Optimierungen.
-
Thread
Linux auf dem Rückmarsch
Maschinensprache übersetzt, ist das eine Abkürzung für "Assemblersprache". Zum Beispiel arbeitet der GCC meines Wissens mit maschinenunabhängigem Zwischencode, auf dem er Optimierungen durchführt, bevor er maschinenspezifischen Code generiert. Natürlich kannst Du nun hingehen und z. B. die "Register
das eine Abkürzung für > "Assemblersprache". Ja, das ist so. > > Zum Beispiel arbeitet der GCC meines Wissens mit maschinenunabhängigem > Zwischencode, auf dem er Optimierungen durchführt, bevor er > maschinenspezifischen Code generiert. ..auf dem er wiederum Optimierungen durchführt und
-
Artikel
Entwicklungsboard mit AT91SAM7Sxxx - selbstgemacht
Programmieren zuwenden. Die Softwareseite. Die ARM-Prozessorkerne werden von der Gnu Compiler Collection (gcc) voll unterstützt. Der ist gut und gratis, wie hier allgemein bekannt sein sollte. Der gcc Compiler ist in der Lage, sowohl 32Bit Code als auch 16-Bit Thumb Code sowie Mischcode zu erzeugen. Es gibt
Auswahlmöglichkeiten [0, 1, 2, 3, s] stellt den Optimierungsgrad des Compilers ein. 0 bedeutet keine Optimierung und sollte beim Debuggen verwendet werden. Im endgültigen Programm kann man 3 (schnellstmöglicher Code) oder s (kleinstmöglicher Code, in einigen Fällen daher sogar schneller als 3) verwenden. Debuggen
-
Thread
Compiler für dsPic33FJ64
Rudolph R. schrieb im Beitrag #4138113: > Wenn der Unterschied so gross wäre wie dem GCC für AVR bei dem der Code > zwischen -O0 und -O3/-Os ganz erheblich anders ist, das würde mich schon > stören. Du bekommst in der freien Version -O1. Schön sieht das ganze in Assembler allerdings
. Vergleiche machen erst ab -O1 Sinn. Nebenbei: Wenn Du flink bist, kannst Du die volle Optimierung nutzen. 60 Tage Evaluierung der PRO Version ist möglich.
-
Thread
Codename Brillo: Googles /besonders/ kompaktes Betriebssystem für das Internet der Dinge
und natürlich auch den verrücktesten video-codec erwartet. Im übrigen schau dir an was z.B. der GCC so alles optimiert... das schaffst du NIE und in ASM... habe da gerade so ein Stück software bei dem's auf Speed ankommt... Auf das loop-unrolling das der gcc sich überlegt hat wär ich nie gekommen.
Compilerbau. Viele tausend Softwareexperten haben sie gelesen, verstanden und Wunderwerke wie den GCC entwickelt. Man kann auf diese gesammelte, geballte Know-How der Compilerbauer zugreifen oder das Rad Tag für Tag immer wieder neu erfinden. Erfindest du auch Bohrmaschine und Säge jedes Mal neu?
-
Thread
'var' may be uninitialized
denn dann würde das tool > die fallunterscheidung in deiner main beachten. Unterschätze niemals den GCC! > Vieleicht hat das aber auch was mit optimierungen zu tun, aber es wäre > mir neu, wenn ein compiler über mehrere c-files hinweg optimieren würde. Such mal nach "LTO", der GCC kann das schon
Michael Reinelt schrieb im Beitrag #4125648: > andere, schöne Alternative? [c] #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wuninitialized" ... #pragma GCC diagnostic pop [/c] ;-)
-
Thread
Aus '\n' wird '\0'
hier 2 Beispiele: [c] #pragma GCC push_options #pragma GCC optimize ("O0") your code #pragma GCC pop_options [/c] und [c] void __attribute__((optimize("O0"))) foo(unsigned char data) { // unmodifiable compiler code
Compilieren >> konvertiert und das \n entfernt. >Genauer gesagt, ist es eine eine Built-In-Funktion des GCC. Aber das normale printf() im avr gcc schmeißt das \n doch nicht raus, oder?
-
Thread
Bosch BMP280: Umrechnungen vereinfachen?
Implementierung. Das ist ist nun nicht soo wild. > > Und falls doch, gibt es etliche mögliche Optimierungen für den Fall, daß > die Zahl der Schiebebits>1 ist, so daß eigentlich nur selten wirklich > geschoben wird. Leider optimiert der GCC bei Schiebeoperationen mit >16 bit schlecht bis gar nicht
ist deine Formulierung falsch. Es ist nicht auf dem AVR langsam, sondern in C, zumindest wenn der GCC als Compiler verwendet wird. Daraus kann man ganz zwanglos den logischen Schluß ziehen, daß C im Allgemeinen oder zumindest der GCC im Besonderen schlicht die falsche Wahl ist, wenn man einen AVR8
-
Thread
rechnet der preprocessor in C gcc (AVR) multiplikation aus?
Peter II schrieb im Beitrag #4120985: > Joachim B. schrieb: >> rechnet der preprocessor in C gcc (AVR) Multiplikation aus? > > nein, dafür ist er nicht zuständig In BASCOM ist das mal wieder super einfach: Const Mul = Const1 * Const2 / Const3 ... Ich wollte schon mit GCC anfangen, weil
0; } [/c] der Präprozessor macht daraus [c] ... int a = 3 * 4; ... [/c] und der gcc, ganz ohne Optimierungen [code] ... 400535: c7 45 fc 0c 00 00 00 movl $0xc,-0x4(%rbp) ... [/code] 3*4 wird also ausgewertet zu 12, bzw. 0xc
-
Thread
mit µC Sinus erzeugen + Amplitudenmodulation
Programmiert, leider bekomme ich nur eine sehr geringe Frequenz hin (maximal 315Hz ohne Compiler-Optimierung, mit höchster Optimierung 1,1kHz).. glaub mein Porgramm ist nicht das effektivste (siehe unten).. Jetz schlagt ihr sicher die Hände überm Kopf zusammen ^^ Ich frage mit einer if-Anweisung jedes
Kanonen auf Spatzen schießen - imho ;) Die letzten Controller-Projekte hab ich nur noch mit dem GCC gemacht und fand eigentlich ganz gut, was da an kompilierten Code herausgekommen ist ...