-
Thread
AVR: C-Code Optimierung mit Inline Assembler
statt. Eine weitere Frage wäre noch, ob es eine Möglichkeit gibt, wie ich an den kompilierten avr-gcc Assembler-Code herankommen kann. Bisher habe ich nur die Seite http://gcc.godbolt.org/ genutzt, die jedoch nicht die aktuelle Version des avr-gcc anbietet. Vielen Dank im Voraus, Thomas
Runden-Funktion wirklich der Flaschenhals ist, dann kannst du überlegen, ob sich dort durch manuelle Optimierung wirklich nennenswert was rausholen lässt. Boris P. schrieb im Beitrag #3967728: > Falsches Forum... Verschoben.
-
Thread
8bit Pointer bei großen AVR's
sein. Aus dieser 'Muss' Klausel folgt unmittelbar, dass Optimierungen keine C Regeln ausser Kraft setzen können. Insbesonders können Optimierungen kein illegales Programm plötzlich legal machen. > > Aber ich kann mich täuschen, und jeder Compiler mag es anders
#3963559: > Der Compiler darf nach Lust und Laune optimieren, aber immer nur 'as if' > die Optimierung nicht statt gefunden hätte. D.h. das Endergebnis muss > dasselbe sein. Aus dieser 'Muss' Klausel folgt unmittelbar, dass > Optimierungen keine C Regeln ausser Kraft setzen können. Insbesonders
-
Thread
extern void f(){};
Norbert schrieb im Beitrag #3962889: > // gcc -Wall -Wextra -o x x.c Und jetzt probiere das selbe mal mit -pedantic.
schrieb im Beitrag #3990040: > Der Linker zieht globale Variablen zusammen Habs oft genug beim gcc gehabt, dass er sich eine aussucht und nur einen Teil dorthin verlinkt. Böser Fehler. Manchmal finde ich, dass der gcc zu tolerant ist und selbst meint, was richtig sein könnte. So einige Optionen
-
Thread
AVR Interrupt Flag löschen. Fundamentalismus und Fehler im DB.
interessiert, in welchem Bereich das Register steht. Natürlich unter der Voraussetzung, dass die Optimierung eingeschaltet ist. Aber selbst bei Banalfunktionen wie Delay wird selbstverständlich hingenommen, dass die Optimierung eingeschaltet sein muss. Alle reinen Flag-Register, auch das TIFR3 beim
mehr äquivalent zur Arbeitsweise der "abstract virtual machine" ist. Formal betrachtet war diese Optimierung des Befehls also ein Schuss ins Knie. Ein Problem, dass GCC/AVR nun mit 8051 Compilern teilt, denn deren implizite Unterscheidung der Portverwendung abhängig vom exakten Befehl ist auch nicht
-
Thread
Warum signed int bei delay?
Wert nicht in signed int (bzw. int16_t) darstellen lässt, was hier durchaus der Fall sein kann. Der GCC liefert hier zwar das erwartete Ergebnis, sauberer ist es aber, sich gar nicht erst auf solche implementation-defined Features zu verlassen.
Abfrage erzeugen, ob bei d += TCNT1 ein Überlauf auftritt, und dann sofort zurückkehren. Geniale Optimierung, weil die Funktion dann in einigen Fällen schneller fertig wird...
-
Thread
Deklaration von external memory
Datendefinition. Vergiss diese Erbsenzählerrei! https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung > Ich würde gerne >mal eine Baustelle (hier Datendefinition) endgültig abschließen um mich >dann in Ruhe der nächsten zu widmen, ohne am Schluss des
Thomas P. (topla) > Vergiss diese Erbsenzählerrei! > > https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung Ja, ist vielleicht ein Geburtsfehler bei mir. Ich mag auch vorzeigbares Innenleben, bei Geräten wie bei Software. > Ach was, du malst nur den Teufel
-
Thread
Umrechenfehler bei Float nach int
Ok, ist voll und ganz verständlich, was ihr meint :-) An die Optimierung der Arbeitszeit hab ich dabei wirklich nicht gedacht. Da ich persönlich oft und gerne mit kleineren Mikrocontrollern arbeite, liegt darin vermutlich der Grund zur Speicheroptimierung. Aber klar,
durch zusätzliche Bibliotheken den > Speicher dann noch zusätzlich aufbläht, ist ja klar. Beim AVR-GCC mit libc.a werden rund 1K benötigt. Sobald der µC >= 4K Flash hat, geht float schon mühelos. Aktuell tippe ich ein Programm für ATtiny44 zur PT1000-Auswertung und Anzeige auf einem 4-stell. LCD. Codegröße
-
Thread
ATmega 1284P PA4 geht nicht
Um möglichst viele Fehlerquellen auszuschliessen, habe ich alle includes vermieden und keine Optimierung verwendet. Wir haben es mit mehreren 1284 und einem 644 getestet. Sowohl mit Atmel Studio 5 als auch Atnmel Studio 6 kompiliert. Auf zwei verschiedenen Boards ausprobiert. Mit externem 12 MHz Quarz
flackern > die Ports deutlich sichtbar vor sich hin. Du bist nicht Rainer Z. Er hat die Optimierungen vielleicht an gelassen.
-
Thread
ARM DSP LIB Speicherverbrauch
Die FPU ist aktiviert, dafür spricht auch die Performance. Die Optimierung ist über die Projektoptinen eingeschaltet, im Konsolenfenster ist zu sehen, dass u.a. "-s" an den gcc übergeben wird, damit werden ca. 2kB eingespart, nicht viel gemessen an der Gesamtgröße. Standardeinstellung
/articles/ARM_GCC
-
Thread
Probleme mit dem richtigen setzten des sei() makros bei externem Interrupt ATmega16
optimiert es der Compiler wieder > raus. Nein, das darf er nicht, weil das eine Endlosschleife ist. Gcc macht das auch richtig offensichtlich wenn die Optimierungen an sind: [code] $ cat main.c #include <inttypes.h> int main(void) { for (uint8_t x = 0; x < 1000; x++) {}
es der Compiler wieder >> raus. > > Nein, das darf er nicht, weil das eine Endlosschleife ist. Gcc macht das > auch richtig offensichtlich wenn die Optimierungen an sind: Was für einen Unsinn erzählst du uns hier jetzt? Aber immerhin lieferst du den Nachweis, dass es wegoptimiert wird, gleich
-
Thread
[C++] Code-Optimierung auf AVR
anderes: Wenn ich nur einen Codeteil mit O2 kompilieren will gibts immer einen Fehler: #pragma GCC optimize("O2") SRF05.cpp:124: error: ignoring #pragma GCC optimize
A. K. schrieb im Beitrag #3940487: > N. G. schrieb: >> SRF05.cpp:124: error: ignoring #pragma GCC optimize > > Beitrag "Re: [C++] Code-Optimierung auf AVR" Peinlich, übersehen. Wird direkt ausprobiert. Sorry
-
Thread
avr-gcc optimiert nicht?
war früher nicht da und ich möchte es auch in > Zukunft nicht da haben, was kann ich tun? Optimierung Abschalten. 8-Bit-Schleifenvariable verwenden. Grund: Der GCC hat deine Schleife umgedreht, statt >> for(i=0;i<WLC;i++) macht er >> for(i=WLC;i;--i) warum? 'i' kann er schön im Register-Paar
Macht steht und das ist unterm Strich schon nicht schlecht. An einigen Stellen wird er sogar Optimierungen finden an die hättest selbst Du nicht gedacht, an anderen Stellen hättest Du vielleicht von Hand noch 2 Takte rausgekitzelt oder ein paar Bytes gespart aber unterm Strich ist der gcc schon gar
-
Thread
CPP Code nach C portieren. endet in Stackoverflow.
wenn ich den Header von void matrix... ins h kopiere. Ansonsten bin ich für offen für jegliche optimierungen! Arc Net schrieb im Beitrag #3939803: > Da könnte es helfen die ins Flash zu legen. Wie macht man dies beim STM bzw. beim ARM-GCC?
Claudio H. schrieb im Beitrag #3939820: > Wie macht man dies beim STM bzw. beim ARM-GCC? "const" davor. Nur müssen die dann schon fertig initialisiert sein. Du brauchst also ein Hilfsprogramm, das den Quelltext davon generiert.
-
Thread
Hat jemand diesen Code heruntergeladen?
Dies wird wohl sehr sehr träge sein, aber für den Anfang genügts. Dannach kann dann mit optimierungen gespielt werden :) Die Hauptroutine sieht so aus: [c] loops = 2*820; for(int32_t n=0;n<loops;n++) { matrix(xyz, rgb); rotate(xyz, rgb, angleX, angleY, angleZ
Variable zu groß). Daher ist das große Array als Argument immer noch ein Rätsel, das schluckt mein gcc auch in C Quellen.
-
Thread
Conways Game of Live zu langsam auf Z80
Ohne Optimierung gibts halt keine Optimierung...
A. K. schrieb im Beitrag #3939962: > Ohne Optimierung gibts halt keine Optimierung... Die schalte ich nur bei "release" ein, das dauert 20 Minuten !!!! bis der sdcc fertig ist mit "Optimierung".... AMD 3.8GHZ Quadcore. SDCC nimmt aber nur 1 Core
-
Thread
LCD Display trotz Initialisierung schwarz
die lcd-routines.c und lcd-routines.h zusammen mit einer main.c das erste Beispiel alle samt vom AVR-GCC-Turoial um allgemein mein LCD Display zu testen. [c]http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung[/c] Nun zeigt das Display nach der Initialisierung immer noch schwarze
schrieb im Beitrag #3936496: > Im makefile: > > OPTIMIZE = -O0 Das bedeutet 'keine Optimierung' und ist unsinnig. Die _delay_XX() Funktionen laufen gut mit der Optimierung auf Size, also '-Os'. Man sollte dafür allerdings FCPU *vor* dem '#include util/delay.h' definieren.
-
Thread
Universelle Tastenabfrage nach PeDa in AVR Assembler
/topic/493254#new In Jahrzehnten der Existenz des avr-gcc ist es keinem der C-Fetischisten gelungen, das (oder etwas vergleichbar Anspruchsvolles) umzusetzen, obwohl es durchaus etliche Anfragen und Wünsche nach solchen Lösungen gab. Bei größeren und komplexeren
SOFORT vollumfänglich nutzen will. So waren die neuen AVRs etwa eine lange Zeit nicht adäquat im AVR-GCC unterstützt (und ich weiß gar nicht inwieweit das heute noch zutrifft). Und da sind schließlich noch Formfragen: Nicht jeder findet die kryptische C Darstellung mit hyperkomplex aufblasbaren Ausdrücken
-
Thread
Code langsamer durch Löschen einer Instruktion
tritt sie überhaupt auf? Viele Grüße W.T. P.S.: Die Frage bezieht sich zwar nicht rein auf den GCC, bezieht sich aber vermutlich auf derart tiefe Implementierungedetails, daß die anderswo noch schlechter untergebracht wäre...
falsche Branch-Prediction führt zu Dutzenden von zusätzlichen Takten, etc. Um mal die Kurve Richtung GCC zu bekommen: wenn man so zeitkritische Bereiche hat, dass der ein oder andere Taktzyklus relevant wird, sollte man die Finger vom C-Compiler lassen. Auch wenn der GCC einige der Probleme kennt und
-
Thread
Welches Programmiergerät für AVR und AVR32
sogar freie Software. Die Linux-Unterstützung für die AVRs ist exzellent: Eclipse + AVR-Plugin + avr-gcc + avrdude alles freie Software und alles aufeinander abgestimmt, kein umständliches Gefrickel, keine Einschränkungen, installieren und läuft out of the box.
kostenlosen Versionen, wo nur die höheren > Optimierungsstufen abgeschaltet sind. Ja, komplett ohne Optimierung, also ungefähr das Äquivalent von gcc -O0 wo der Code doppelt so groß und halb so schnell wird weil zwischen jeder zweiten Instruktion erst nochmal ne komplett unnötige Runde Spilling und Filling
-
Thread
Speicherplatzanalyse bei Controllerprogrammen
hab mal wieder einen Mega8, der zu früh voll ist. 8k Programm (flash) und ich verstehe aus den avr-gcc-Dateien lst, map etc. nicht so recht, wo der hin ist. Bischen printf, ein bischen long-division, lcd-matrix und andere Sachen ist drangelinkt aber die tatsächlichen Objektgrößen find ich da auch nicht
Atmega328 ist Pinkompatibel und kann via AVR Dragon debuggt werden. Optimierung aktiviert?
-
Thread
[arm] Kompileroption -flto bewirkt daß der uart (ungefähr) doppelt so schnell läuft
Johann L. schrieb im Beitrag #3930370: > Optimierung nicht aktiviert? -Os denn Optimierung ist ja das Ziel der Übung. > Oder nicht LTO-sicher programmiert? Ich finde nichts im gcc manual zum Themembereich "LTO-sicher programmieren", es liest
nicht compilerseitig, sondern es sind Fehler im Programm, die erst durch diese modulübergreifende Optimierung offensichtlich werden. Welche Kommandos werden denn konkret ausgeführt, d.h. wie wird gcc etc. aufgerufen? /Nicht/ als make-Schnippel, sondern als Kommando, das von make /ausgeführt/ wird.
-
Thread
Auf High-Word eines signed long long int zugreifen
Daumenregel: Wenn man mehr Zeit in die manuelle Optimierung und entsprechend komplexere Pflege eines Programms reinsteckt, als man kumuliert zur Laufzeit wieder rausholt, dann ist man schwer auf dem Holzweg.
Und hier (gcc 4.2) ist f1 besser, mit -O2: .f1: lis 0,0x1233 ori 0,0,65535 cmpw 7,3,0 ble 7,L..8 lwz 9,LC..1(2) addi 3,9,4 blr .f2: lis 0,0x1233
-
Thread
Minimum Struct größe erzwingen
GCC bietet dazu mehrere Möglichkeiten an. https://gcc.gnu.org/onlinedocs/gcc/Structure-Packing-Pragmas.html
dann sollte fast immer die geschickteste Reihenfolge erreicht werden. Ggf. macht das aber je nach Optimierung auch der Compiler, ganz sicher bin ich mir da im Moment aber nicht. Gruß, Stefan
-
Thread
ISR und Atomarer Datenzugriff - ich bin entsetzt !
abhängig davon welche Optimierungsstufe > eingeschaltet ist *und* (bei Optimierung) bei welchen Registern es > sich überhaupt lohnt (wenn sie anderweitig zum Einsatz kommen). Evtl. speichert avr-gcc mehr als nötig, was aber ein Problem der Effizienz ist und nicht der Korrektheit
habe ist mir dieser feine Unterschied nicht aufgefallen. Also stimmt ihr mit mir überein das der GCC in ISRs alle in einem Programm benutzen Register sichert und bei Verlassen wieder restauriert (so "wie es sich gehört")?
-
Thread
Anfänger in C und welcher PIC (evtl. uno32) ist geeignet ?
hilfreich/ ansiehst. Aber ich sehe hier nirgends ein PIC-Äquivalent zum [[AVR-Tutorial]] oder [[AVR-GCC-Tutorial]]. Und Leute wie PeDa oder Johann L. scheint es in der PIC-Fraktion auch nicht zu geben. Ich lese da immer nur Spinner, die jaulen als ob ich sie persönlich beleidigt hätte, wenn ich sage
hilfreich ansiehst. Aber > ich sehe hier nirgends ein PIC-Äquivalent zum AVR-Tutorial oder > AVR-GCC-Tutorial. Und Leute wie PeDa oder Johann L. scheint es in > der PIC-Fraktion auch nicht zu geben. Ja, ein Tutorial vermisse ich auch. Habe selber mal drüber nachgedacht eins zu schreiben. Ich meinte
-
Thread
Zu viele Symbole werden gestrippt (Code zu klein)
auch aus Win-AVR - die spielen beim Kompilieren selbst aber keine Rolle, die relevanten Tools (avr-gcc, avr-as, ...) liegen ja in bin oder avr/bin (dort als gcc, as, ...). Benutzt wird Win7. Es gibt keine Fehler beim kompilieren. Der Build log ist absolut identisch, bis auf die Ausgabe der Größen:
atmega128rfa1.ld -Wl,--section-start=.data=0x800200 -mmcu=atmega128rfa1 [/code] (aufgerufen wird avr-gcc mit o.g. LINKER_FLAGS) Warum in aller Welt verhält sich nun ein neuerer Kompiler/Linker so dermaßen anders? Mit einem selbst kompilierten AVR-GCC 4.9.1 passiert das gleiche... Hat jemand sowas
-
Thread
8 Bit Berechnung schnell, schneller am schnellsten
Aufruf viermal die gleiche Zahl zu berechnen. Möglicherweise nimmt aber schon der Compiler diese Optimierung vor. Weiter kannst du den Computer entweder quälen und für jedes neue "wz" eine neue Reihenentwicklung zur Berechnung von Sinus und Cosinus anstossen, oder, wenn du weisst, dass wz (und somit
noch die AVR-Version mit den 32 Ticks und ohne Restriktionen an die Parameter, wie oben gemäß avr-gcc ABI aber etwas mehr kommentiert. Die Berechnung verwendet [math]ab = \Bigl(\frac{a + b - t}2\Bigr)^2 - \Bigl(\frac{a +b - t}2-\min(a,b)\Bigr)^2 + t\min(a,b) \qquad\text{wobei } t = a + b \mod 2[
-
Thread
Hartnäckiger Heisenbug auch ohne Optimierung, am PC (x86_64)
das sein dass es doch die Programmausführung massiv beeinflußt? Zum Kompilieren verwende ich: gcc -Wall -D_REENTRANT -lm -pthread -O0 -o logger logger.c -lrt
war schlicht Call bei value angewendet wo tatsächlich Call by reference gemacht wird. Da könnte der GCC eigentlich eine Warnung ausgeben weil hier eine Race Condition vorliegt, aber bisher macht er das nicht.
-
Thread
_delay_ms(xxx) Fehler unter Linux-Code::Blocks
avrlibc funktionieren seit Anfang der Zeitrechnung nur mit Konstanten (und nur mit eingeschalteter Optimierung). Oliver
funktionieren seit Anfang der > Zeitrechnung nur mit Konstanten (und nur mit eingeschalteter > Optimierung). Und es gibt auch auf beiden Systemen eine Warnung bei der Kompilierung...
-
Thread
Klassen, Objekte, Struct, Überladen in LUNA AVR
angenehm erscheint. Ob da mit LunaAVR im übersetzten Code dann beispielsweise das letzte Quäntchen an Optimierung rausgeholt ist oder nicht, ist für mich eher sekundär, bzw. eine Gespensterdebatte, die sehr einseitig ist und andere Aspekte unterschlägt. Eine Sprache die C++ an Komplexität noch schlägt brauche
Leute die Fähigkeit haben an einem Compiler bauen zu können, das sieht man ja auch sehr schön am AVR-GCC. Da fummeln höchstens drei Hanseln dran herum, der Rest - mich eingeschlossen - versteht da nur Bahnhof. Seit wann ist Bascom eigentlich opensource? Da kann man höchstens in vereinzelten Bibliotheken
-
Thread
ARM - Probleme mit sprintf (Linkerfehler)
umgeht. Warum das Problem bei sprintf(test, "Hallo Welt"); nicht auftritt, liegt daran, dass der gcc hier schon mit der Optimierung zuschlägt. Der parst das "Hallo Welt" schon und stellt fest: ups, hier ist ja gar kein sprintf nötig, ein strcpy hätte auch gereicht. Und genau das baut er dann ein. Kannst
Der AVR-GCC liefert schlicht und ergreifend eine andere C-Library mit als der ARM-GCC, die kein malloc () und damit kein sbrk braucht. Solche libraries gibt es natürlich auch für ARM, die muss man "nur" dem GCC
-
Thread
Was ein C++-"Guru" so ueber Geschwindigkeit erzaehlt.
Wer lesen kann:-) - Wenn man sich in der x86 Welt mal ansieht welche Unterschiede zwischen dem gcc und dem icc möglich sind. Da könnte einem schon der Verdacht kommen das beim Thema Optimierung zumindest beim gcc noch einiges an Luft für Verbesserungen vorhanden ist.
Irgendwer schrieb im Beitrag #3901199: > kommen das beim Thema Optimierung zumindest beim gcc noch einiges an > Luft für Verbesserungen vorhanden ist. Sicher. Ich würde mich aber doch etwas wundern, wenn der ICC bei der Optimierung des anfänglichen Codes automatisch
-
Thread
Servo an Atmega32 (C)
} [/c] Und am besten nochmal im Forum das hier http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR und das hier http://www.mikrocontroller.net/articles/AVR-Tutorial:_PWM durchlesen. Grüße Thomas
#3895205: > am besten nochmal im Forum > das hier > http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR > > und das hier http://www.mikrocontroller.net/articles/AVR-Tutorial:_PWM > durchlesen. Das mach ich morgen dann auch noch mal. Viele Grüße, Marcel
-
Thread
Variable nicht initialisiert
Aus dem gcc-Manual: [c] #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wuninitialized" foo(b); /* no diagnostic for this one */ #pragma GCC diagnostic pop [/c] Geht
auch schon wieder viel programmspeicher beim initialisieren. Atmel Studio 6.2 (projekt fur AVR), GCC 4.8.1, optimierung ist abgeschaltet Lokal ohne Initialisierung: [c] #include <stdint.h> int main(void) { uint64_t a0; uint64_t a1; uint64_t a2; uint64_t a3; uint64_t a4; uint64
-
Thread
Ansteuerung LCD-Display mit t6369c-Chip und 16Mhz Taktfrequenz
Bist du sicher, dass der Compiler dein delay() nicht weg optimiert? Verwende doch probehalber mal das gcc _delay_us().
Flachband. @spess: Danke, habe es mir mal notiert, das wäre natürlich noch ne Möglichkeit der Optimierung. Allerdings muss ich das Display ja erstmal überhaupt zum laufen bringen... Einen Watchdog habe ich nicht am laufen. Soweit ich das verstanden habe ist das ein Auto-Reset, den ich regelmässig
-
Thread
C++ auf einem MC, wie geht das?
://gcc.gnu.org/wiki/LinkTimeOptimization
Anspruch ist ja, daß meine Bibliothek eine ebenso effiziente Programmierung ermöglicht wie C mit dem GCC als Referenz. Daher konzentriere ich mich bei Feinheiten wie der Optimierung auf den GCC. > Ich sehe 3 möglichkeiten: > 1) die klassen nicht Instanzieren > 2) als constexpr declarieren > 3)
-
Thread
AVR Problem avr/io.h: No such file or directory
deaktivirien. Path zum avr-gcc eintragen, z.B. C:\WinAVR\bin\avr-gcc.exe Path zum make eintragen, z.B. C:\WinAVR\utils\bin\make.exe AVR Studio 4.19
/avr-gcc[/pre]verwendet, dann gehört[pre]/foo/bbar/baz/avr/include[/pre]zu den Standard-Systemincludepfaden. Der Pfad muss nicht extra angegeben werden. Wenn man[pre]/dingens/bummens/bin/avr-gcc[/pre]verwendet
-
Thread
Atmel AVR Frequenzgenerator
vorne an. Messe mit der 1ms Verion nochmal die High- und Low-Zeiten. Und berichte mit welcher Optimierungs-Option du compiliert hast. Die Delay-Funktionalität arbeitet nur korrekt wenn die Optimierung auf -Os eingestellt ist. Abgesehen von der While Schleife (braucht wenige usec, wenn nicht weniger
> > Messe mit der 1ms Verion nochmal die High- und Low-Zeiten. > Und berichte mit welcher Optimierungs-Option du compiliert hast. > > Die Delay-Funktionalität arbeitet nur korrekt wenn die Optimierung > auf -Os eingestellt ist. > > Abgesehen von der While Schleife (braucht wenige usec, wenn
-
Thread
Richtiges C++ hardwarenah
Irgendwer schrieb im Beitrag #3901199: > Da könnte einem schon der Verdacht > kommen das beim Thema Optimierung zumindest beim gcc noch einiges an > Luft für Verbesserungen vorhanden ist. Schau einer an. Aber man kann ja immer noch ein paar Hundert bis Tausend Euro in einen "ordentlichen" Compiler stecken
schrieb im Beitrag #3901199: >> Da könnte einem schon der Verdacht >> kommen das beim Thema Optimierung zumindest beim gcc noch einiges an >> Luft für Verbesserungen vorhanden ist. > > Schau einer an. Aber man kann ja immer noch ein paar Hundert bis Tausend > Euro in einen "ordentlichen" Compiler
-
Thread
Welcher µC ist "der Richtige"
teure Lizenzen nötig Wenn es um die PIC32 geht, gibt es bspw. auch die Möglichkeit den normalen GCC zu benutzen, auf welchem der XC32 bzw. XC32++ basiert http://wise-ware.org/wiki/index.php?n=Pic32.GccPic32 Für die Compiler von Microchip gilt: "No time or memory restrictions", "Unrestricted use—ideal
teuer einzukaufen Sind das nicht ARM Controller von ST? Wenn ja dann kann man doch Eclipse CTD und gcc verwenden oder geht das nicht? Oder verwechsel ich da was?
-
Thread
Downgrade von ATMEL Studio 6.2 auf 6.0 wg GCC Fehler?
so wohl kaum feststellen. > > Also, Thema geschlossen und vielen Dank an euch alle. #pragma GCC push_options #pragma GCC optimize ("O2") // your code #pragma GCC pop_options Damit kannst Du die Optimierung nur für ein einzelnes Codestück ändern und so die Ursache einkreisen.
Frank K. schrieb im Beitrag #3886398: > > #pragma GCC push_options > #pragma GCC optimize ("O2") > > // your code > > #pragma GCC pop_options > > Damit kannst Du die Optimierung nur für ein einzelnes Codestück ändern > und so die Ursache einkreisen
-
Thread
Problem bei Erweiterung des ARRAY_SIZE(x) Hilfsmakros
durchziehst! Als Compiler bzw. Entwicklungsumgebung verwende ich gerade meinen Arduino. Ansonsten immer GCC der mit dem Atmel Studio mitgeliefert wird. Ich weiß aber nicht genau ob diese das "const" als Optimierung ansehen? Fakt ist, dass beim Kompilieren (Arduino) die größe des Programms mit den "const
> Als Compiler bzw. Entwicklungsumgebung verwende ich gerade meinen > Arduino. Ansonsten immer GCC der mit dem Atmel Studio mitgeliefert wird. > Ich weiß aber nicht genau ob diese das "const" als Optimierung ansehen? Dann sparst du durch das const erst mal kein RAM ein. Hier wird const so
-
Thread
Einrückung in Python Gesperrt
nein https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html Anscheinend ist es sogar eine gcc-extension und in gar keinem C-Standard.
vimperator schrieb im Beitrag #3890726: > nein > https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html Da verwechselst du zwei Dinge: W.S. schrieb von /Blöcken/, die mehreren Anweisungen zu einer großen /Anweisung/ zusammenfügen. Die gab es schon in
-
Thread
Welchen µC-Typ für neues Projekt?
und "zeitkritisch". Ich benutze häufig auf AVRs float und 64Bit integer ohne Probleme. Der AVR-GCC unterstützt leider kein double.
jegliche Diskussion über einen Prozessor UNSINN!! https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung >16 bit MUL 16 bit auf einer 8 bit ALU = sehr viele Befehle, da mehr WIEVIELE?!!!! Dein qualitatives Geplapper ist sinnlos. >Und bitte Falk 20
-
Thread
Befehle werden übersprungen
> Offensichtlich werden sie wohl wegoptimiert. Weshalb man fürs debuggen günstigerweise die Optimierung abschaltet.
Hat der GCC mittlerweile eigentlich einen Deppenmodus der die wilkürliche Verwendung von == und = automatisch korrigiert und aus einem Vergleich eine Zweisung und Vice versa macht??
-
Thread
Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?
1>();[/c] Das Timing wird hier in "delaycycles" per asm("..."); korrigiert und die Compiler-Optimierung hat m.E. durchaus einen Einfluss auf das Timing, wenn ich das richtig verstanden habe. Wie wirkt sich denn nun eine Veränderung der Compiler-Optimierung aus? Oder hast Du das noch nicht ausprobiert
der ESP8266-Routinen auf esp8266.c (low-level) und timeserver.c (high-level) - Diverse Optimierungen - u.a. durch Einsatz von uint_fast8_t - Ein paar kleine Bugfixes
-
Thread
strtol Problem (Ergebnis ist immer MAX_LONG)
Sind die Optimierungen ausgeschaltet?
. endptr zeigte hierbei auf einen freien Bereich von temp ("also auf einen punkt"). EDIT2: Optimierungen sind komplett ausgeschaltet.