-
Thread
Was heisst das bitte : --max-allocs-per-node 100000
--max-allocs-per-node 100000: Gibt an, wie viele Teilergebnisse in Berechnungen in manchen Optimierungen berücksichtigt werden sollen. Größere Werte führen üblicherweise zu besserem (schnellerem, kleinerem) Code, aber SDCC braucht mehr Zeit und Speicher während des Kompilierens. 3 Optimierungen sind
Erfahrungswerte interessieren, um wieviel schneller ein (Alltags-) C-Code durch gute Registerwahl/-optimierung wird. Mich wundert etwas, das der Akku A mit bei der Optimierung betrachtet wird, weil dessen Verwendung bei den Arithmetikbefehlen 'unausweichlich' ist. > statt die > Register af, bs, de
-
Thread
TIPP: Atxmega DFU-Bootloader auf eigenen "Boot-Pin" verbiegen (direkt im Hex-File)
nachdem ich vergeblich versucht habe den DFU-Bootloader so abzuspecken, dass man ihn auch mit AVR-GCC kompilieren kann damit er in den 4KB Bootbereich des Xmega32A4U passt (weniger als 6K schafft man offensichtlich mit avr-gcc nicht), habe ich einen anderen Weg gefunden den Boot-Port für meine Ansprüche
Die Optimierungen habe ich eingeschaltet. Siehe Anhang.
-
Thread
For-Loop wird nicht richtig ausgeführt
Kommt drauf an, was in der Schleife steht. GCC kann da auch eine ganze Schleife wegoptimieren wenn es den Schleifeninhalt auch ohne Schleife in einem Rutsch ausführen kann. Mal als Beispiel: [c]unsigned int test(unsigned int n) { unsigned
direkt 20 addiert. Wenn du alles wie im Quellcode ausgeführt sehen willst, musst du die Optimierungen ausschalten. Mit Optimierungen wird es auch auf andere Weise unübersichtlich im Debugger, z.B. kann die Reihenfolge der Anweisungen umgestellt werden.
-
Thread
volatile cast: GCC Bug oder gültige Optimierung
besten man kompiliert das immer nur mit einer Schleife, dann sieht man im Listing was ich meine. Optimierung ist -Os mit GCC 4.7.2 von Launchpad Plattform ist ein STM32 [c] #include <stdint.h> static char m_cRecBuffer[23]; void __attribute__((noinline)) uart_read_async(uint8_t* pa_pcBuffer
Also beim AVR-GCC läßt sich volatile nicht direkt casten. Nur über den Umweg als Pointer: [c] // force access of interrupt variables #define IVAR(x) (*(volatile typeof(x)*)&(x)) uint8_t blub; int main
-
Thread
GCC [STM32] -> wie sehen wie ein struct realisiert wird?
Abhängigkeit des Optimize?) > Stuffing-Bits einführt, etc. Wenn das Layout von Datentypen von Optimierungs-Optionen abhängt, dann ist das ein Compiler-Bug. Bzw. das Layout von Strukturen ist nicht von Optimierungs-Einstellungen abhängig. Optionen wie -f[no-]pack-struct, -f[no-][un-]signed-char etc
als Optimierung. Zur Frage: GCC-Schalter zur Ausgabe des Layouts (in welcher Form auch immer) kenne ich keine.
-
Thread
Assembler bleibt weiterhin aktuell & wichtige Programmiersprache
Patrick L. schrieb im Beitrag #6940707: > Schallte Alle Optimierungen ab Das ist albern.
Patrick L. schrieb im Beitrag #6940707: > Schallte Alle Optimierungen ab und Ohhh was da raus kommt ist ja echt > ein schönes wiederholtes Muster..... ja klar das gilt aber nicht mehr wenn Optimierungen im Spiel sind. Ich gebe dir aber Recht, jeder Compiler
-
Thread
Prüfungsfrage
Beitrag #3497942: > Basierend auf was wird eine Reihenfolge festgelegt? Auf Basis vom Quellcode des GCC. Es kann sich aber in der nächsten Version wieder ändern. Im schlimmsten fall ist es sogar abhängig von den Speicheradresse der internen GCC Strukturen - ist aber auch egal. Das das verhalten nicht
schrieb: >> Basierend auf was wird eine Reihenfolge festgelegt? > > Auf Basis vom Quellcode des GCC. Es kann sich aber in der nächsten > Version wieder ändern. Im schlimmsten fall ist es sogar abhängig von den > Speicheradresse der internen GCC Strukturen - ist aber auch egal. Das > das verhalten
-
Thread
GCC Präprozessor macro '__FILE__' abkürzen
Da würd ich eher mich in der gcc-help@gcc.gnu.org Mailing-Liste anmelden und dann dort fragen. http://gcc.gnu.org/lists.html Falls es nicht geht — absehbar — dann ist __FILENAME__ vielleicht eine sinnvolle Erweiterung. Gibt
An gcc bzw. __FILE__ liegt es nicht: [code] leo@cb:/tmp$ cat file.c const char *s = __FILE__; leo@cb:/tmp$ gcc -E file.c # 1 "file.c" # 1 "<command-line>" # 1 "file.c" const char *s = "file.c";
-
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
7-Segment-Ansteuerung
Gerhard O. schrieb im Beitrag #7335374: > Der gcc 5.4.0 braucht übrigens nur 498 bytes > Der gcc 7.3.0 braucht 586 bytes für das selbe Programm Mit gcc-12 (oder 13) und etwas Kosmetik in C++ (was Du ja oben verwendet hast: Arduino) sind es dann
Wilhelm M. schrieb im Beitrag #7335477: > Gerhard O. schrieb: >> Der gcc 5.4.0 braucht übrigens nur 498 bytes >> Der gcc 7.3.0 braucht 586 bytes für das selbe Programm > > Mit gcc-12 (oder 13) und etwas Kosmetik in C++ (was Du ja oben verwendet > hast: Arduino) sind
-
Thread
GCC Codeoptimierung: Probleme
Hallo, ich bin langsam am Verzweifeln. Vieleicht kann mir ja jemand von euch helfen. Ich habe ein Projekt für einen AtMega644p mit dem AVR Studio 4.19 in cpp geschrieben. Es sind einige Variablen mit "extern" in einer Header Datei deklariert, die ich in mehreren cpp Dateien einbinde. So haben alle Cpp Dateien Zugriff auf diese Variablen. In der Cpp datei mit der main() Funktion sind die Variablen auch implementiert worden. In den Variablen können Werte von 0 bis 255 gespeichert werden. An Hand dieser Werte wird mit einem Timer0 in einer ISR ein PWM Signal auf angeschlossene RGB LED generiert
-
Thread
LPC2103 63MIPS?
sondern die Einfachheit der Programmierung von größter Bedeutung. Langsammer Prozessor -> viel Optimierung erforderlich -> viel Zeit erforderlich Schneller Prozessor -> weniger Optimierung erforderlich für gleiche Performance -> weniger Aufwand bei gleichem Endergebnis und weiteres Potenzial bei Bedarf
Compiler (Version) angegeben werden. 2. Dann sollte sichergestellt werden, daß immer die beste Optimierung für Geschwindigkeit gewählt wird. 3. Da der C32 teilweise sehr "wild" optimiert, sind Memory Barriers (asm volatile ("":::"memory"); // in GCC) nützlich, damit man auch wirklich sicherstellt, daß
-
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
C Programm zu langsam
- Alternativ manuelles Loop-unrolling etwas mehr bringen - Vielleicht auch mal die Code-Optimierung auf max. einstellen.
der Compiler, wenn Optimierungen einschaltet sind.
-
Thread
ATTINY 2313 - Passt da überhaupt ein Programm drauf?
Boris B. schrieb im Beitrag #1859331: > PS: Als Optimierung habe ich Os gewählt, das sollte ja eigentlich > kleinen Code produzieren, oder? "0" ist gänzlich ohne Optimierung "s" sollte gute Ergebnisse liefern Gruß, Magnetus
@Magnus Müller das ist ein O keine 0 -Os benutzt er, also Optimierung s, nicht -0s bzw. -O0s
-
Thread
optimiert der Compiler so etwas weg?
Sowas wirft GCC auch ganz ohne eingeschaltete Optimierung raus.
Entschuldige bitte, ich war etwas zu schnell mit meinen Gedanken. Du hast natürlich Recht. Denn der GCC bekommt das ja mit eingesetzter Konstante (nach dem Präprozessor) geliefert. Damit ist das Beispiel mit FCPU das gleiche wie if (0) . Warum gibts denn da keine Warnung vom GCC? ;-)
-
Thread
String besteht nur aus 0xFF - Linkerproblem? AVR Studio 7
nicht) in uint8_t. Schalte in der Compiler-Konfiguration die Warnings auf -Wall und die Optimierung auf -O0 (keine Optimierung). Jetzt solltest Du das Programm noch einmal compilieren und testen. Sollte funktionieren.
\ATmega_DFP\1.0.90\gcc\dev\atmega2560" Finished building target: UART-Test.elf "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock
-
Thread
Mikrocontroller in C++ oder C Programieren
sein liebstes syntaktisches Konstrukt in C++ sei: "}" Zum Experimentieren ist übrigens http://gcc.godbolt.org/ wirklich gut geeignet. Wer dort allerdings den neueren avr-gcc (> 6.2) drin haben möchte, muss sich das lokal aufsetzen. VG
daher kann es gut sein, dass der Compiler es doch nicht ohne weiteres frisst. Die Info war aus dem GCC Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171#c13 Bei GCC Version 4.7 funktioniert es aber noch reibungslos bei mir. Ist aber zugegebenermaßen auch hoffnungslos veraltet. Eventuell
-
Thread
Double gegen Integer
Dennis H. schrieb im Beitrag #6167517: > macht gcc/cc von sich aus Gebrauch von AVX/SSEx ? Muss er halt nachschauen, wie sein gcc configuriert ist. Üblicherweise erstellt der generischen (ARM64)-Code. Wer aber auf dem level optimiert, soellte
auf einer HP Z440 Workstation mit 8 > Kernen. > (deshalb auch unter PC Programmierung gepostet). GCC ist mit 7.4.0 schon > etwas altbacken ist halt bei der LTS dabei Mach mal das Ubuntu nicht schlechter als es ist: gcc in Version 8.3 ist auch bei der 18.04 LTS als Paket zu haben.
-
Thread
Assembler Schleifen Tricks
Optimierung überhaupt lohnend ist...
Als Lektuere, was man so machen kann, wuerd' ich auch mal in die Beschreibung der verschiedenen Optimierungen, die der gcc kann, gucken. Da gibts ja nicht nur -Os, -O[0..n] sondern einzelne Gimmicks. Gruss WK
-
Thread
inline vs -O0
Mit meiner Lösung bin ich sehr zufrieden. Wollte allerdings noch testen wie sich das Ganze ohne Optimierung verhält. Allerdings compiliert mir mein Code mit -O0 garnicht erst: undefined reference to *** Aktueller avr-gcc. Hab auf die schnelle nichts gefunden. Aber inline müsste doch auch ohne
muss sich dieses Hinweises nicht annehmen (so, wie früher auch "register" nur ein Hinweis war). GCC inlinet die entsprechende Funktion, sofern sie seiner Meinung nach klein genug ist, /und/ sofern die Optimierungen zugelassen sind. Die Idee dabei ist einfach, dass jemand, der ausdrücklich keine
-
Thread
PIC32MZ vs. Atmel
gibt es, und die Compiler kannst du auch kommerziell nutzen, > natürlich hast du dann keine Optimierung. Wie siehts denn bei dieser ominösen Optimierung überhaupt aus? Bei den PIC30/33 verwendet Microchip ja den GCC und glaub irgendwie nicht recht, dass das beim PIC32 anders ist. Insofern sollte das Thema Optimierung wohl nicht so zentral sein. Weil man unter Linux in der Lage sein sollte, ggf. auch direkt den offiziellen GCC zu verwenden.
-
Thread
Atmel Studio 7 Simulator Debug
Probiere es halt aus. Und ansonsten empfiehlt sich für alle AVRs eher die Option s zur Optimierung. Oliver
GCC 5. Hier mal ein ganz knappes Beispiel mit einem GCC-ARM: https://godbolt.org/g/yEku3P Das Beispiel ist natürlich etwas konstruiert und in der Realität hat man eher nicht so knappe (und überflüssige
-
Thread
Programm von mega32 auf mega328P convertieren
installiert wurde?) Das Ergebnis ist gleich (riesig). Ich habe die *.C-Datei mal in das Verzeichnis von 'avr-gcc' kopiert und den Aufruf von diesem Verzeichnis gestartet. Ergebnis: avr-gcc: error: CreateProcess: No such file or directory Warum kann man im AVR-Studio unter Custom Options/External Tools/avr-gcc
4.5er Version! Also: direkten Verweis auf 'avr-gcc-4.7.2' -> jetzt geht's!
-
Thread
Speicherfresser Atmega
Hallo Markus, wie sieht den dein Makefile und die optimierungs Optionen aus ? CFLAGS += ... _
richtig, ich hatte nicht auf den Namen geschaut. Mehr ist dann auch nicht mit automatischen Optimierungen machbar. Evtl. spielt man mal mit dem avr gcc 4.7.
-
Thread
C Best Practice für konstante globale Variablen
config.h nenne. Das sind keine Variablen, und zwar mit Absicht, damit sie kein RAM belegen. Beim arm-gcc sorgt das Schlüsselwort const schon dafür, dass kein RAM belegt wird. Aber beim avr-gcc geht das nicht so einfach, deswegen #define. Was nicht konstante Variablen angeht: Diese vermeide ich wo immer
sollte aber Wartbarkeit sein. Code zu warten, bei https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
-
Thread
Optimierung bei AVR-GCC 3.3
Hallo! Ich habe mal ne Frage zur Optimierung von AVR-GCC 3.3 20021209: Es geht dabei um eine Funktion zur Ansteuerung eines LCDs. Dabei wurde immer nur ein Befehl umgeschrieben, die Funktion blieb aber gleich und trotzdem gab's große Codeunterschiede
-
Thread
switch Case läuft nicht im AVR Simulator
Kalkulation ist allerdings alles andere als perfekt. Zumal er diese Entscheidung möglicherweise vor der Optimierung trifft.
Arr[i]() müssten in direkte umgewandelt werden -- ggf. Arr[i] inlinen -- weiter optimieren GCC 4.3 ist noch nicht so weit. Johann
-
Thread
Warnung / Fehler nach casten von char a[] zu uint_32*
attribute versehen, dass es an die richtige Bytegrenze gelinkt wird. Näheres verrät die Doku zum GCC
Doku zum GCC > > Falsch. Minimalbeispiel ist angehaengt! Standarteinstellung verstehe ich als: [code]gcc main.c[/code]. Damit läuft der Compiler mit Warnung durch. Kein Abbruch (-Werror fehlt ja...) und vor
-
Thread
llvm für avr
und hat bei den Dependencies herumgezickt.) Unten ein besserer Vergleich des Codes von oben. GCC 4.9.3 entfernt ein unnötiges Compare im Vergleich zu GCC 4.8.1 (-2 bytes). Interessanterweise erzeugt LLVM für die erste Schleife besseren Code, während GCC bei der zweiten SChleife besser ist. GCC
r24,1 sbiw r24,0 brne .L5 ldi r24,0 ldi r25,0 ret .size main, .-main .ident "GCC: (GNU) 4.8.1" [/code] GCC 4.93 > avr-gcc -Os -c -S hello.c -std=c99 -o hello_gcc_t85.s -mmcu=attiny85 [code] .file "hello.c" __SP_H__ = 0x3e __SP_L__ = 0x3d __SREG__ = 0x3f __tmp_reg
-
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
Macht GCC 4.2.1 fuer AVR hier einen Fehler?
richtiges Ergebnis auf dem AVR. Die Funktion fällt also nur im Verbund der gesamten Applikation und GCC 4.2.1 auf die Nase. Was kann denn sowas sein? Problem mit dem Stack? Zu viel Optimierung von Seiten GCC? Gruß Jürgen
> Was kann denn sowas sein? Problem mit dem Stack? Zu viel Optimierung von Seiten GCC? gcc 4.2's Verhalten bei undefined behavior (UB) ist anders als bei der 3er Serie. So werden signed int operation jetzt defaultmässig so optimiert als ob es keinen Überlauf gäbe
-
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
Wieso gibt es keine gute Programmiersprache?
nicht zu Potte kamen hats schonmal eines meiner Projekte verzögert. Da ist es mir lieber was zum GCC zusammenzugoogeln. Und GCC Supportfirmen gibts wie Sand am Meer, musst nur mal gidf.de aufrufen.
Daniel A. schrieb im Beitrag #4786453: > Das passt nicht Zusammen. avr-gcc ist soweit ich weiss gratis. Wenn man > auf einer noch supporteten Version ist, [...] Das war einfach ein reales Beispiel, in diesem Fall mit dem GCC. GCC ist gratis, der Bug war schon längst gefixt
-
Thread
Schiebeoperation mit int16_t-Variable
> ich möchte eine Division durch 4 mittels Schiebeoperation durchführen, > da der Compiler (Optimierung -Os), das wohl nicht automatisch macht, Was, zumindest beim gcc, im Übrigen nicht stimmt. Der Compiler achtet nur darauf, nicht den gleichen Fehler zu machen und bei negativen Zahlen in die
erhebt sich die Frage, warum sie dann ein int16_t ist und kein uint16_t. Denn dann klappts beim gcc auch wieder mit dem einfachen Schieben. Ich bleibe dabei: Solche Low-Level Optimierungen überlässt man sinnigerweise dem Compiler. Der kann das besser.
-
Thread
Code optimieren ?
schneller sein? Wie oft wird die Funktion aufgerufen? https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
avr-gcc kennt auch 24-Bit Typen wie __int24.
-
Thread
Optimierung bei delay.h
Nabend Ich habe auch ein Problem bezueglich der Optimierung der Schleifen. Habe nun gut ne Stunde gesucht, bis ich rausgefunden habe, dass meine Delayschleifen beim Initialisieren des LCD's vom Compiler wegoptimiert werden. Nein, ich verwende keine eigene
Prinzipiell der Code aus dem LCD AVR-GCC Tutorial lcd.h: [code] #ifndef F_CPU #define F_CPU 16000000UL /* Quarz mit 16 Mhz */ #warning "F_CPU not defined. Define default Value 16Mhz" #endif //Default Port Definitions #ifndef
-
Thread
Ersatz für XC32-Compiler?
Zonk schrieb im Beitrag #6081858: > Irgend einen schönen GCC oder so? Das ist ein GCC! Geh zu Microchip und bring uns den Quelltext. http://ww1.microchip.com/downloads/en/DeviceDoc/xc32-v2.20-full-install-release-notes.html PS: Dann versuch auch ich
Im "chipkit core" ist ua. eine uneingeschränkte pic32 gcc toolchain enthalten.
-
Thread
In ISR Inlining einer selten benutzten Funktion vermeiden um pushs zu sparen
er es aber in "offensichtlichen" Fällen nicht. Und die nächste Frage, ob gcc so implementiert ist, dass er das tut; offenbar nicht. Leider kann ich die letzte Frage nicht beantworten. Aber hier treibt sich doch einer herum :-) der am gcc zugange ist. Interessant wäre mal
vor die ISR zu setzen. Dazu musst du Shrink-Wrapping im AVR-Backend implementieren. Diese Optimierung gibt es bislang nicht bzw. entsprechende Hooks sind für avr nicht implementiert, d.h. wenn du wirklich darauf angewiesen bist, dann bleibt dir nur Assembler (oder C++ für die GCC-Quellen).
-
Thread
WinAVR Bug: Crash wegen Codegrösse
Hallo Zusammen, Hallo GCC-Compiler-Experten, Ich habe wohl einen Bug am avr-gcc entdeckt: Ich arbeite an einem grösseren System (Atmega 2560 / WinAVR 20071221). Die Codegrösse (binär) liegt bei ca 135kB. Bisher lief über
immer wieder Probleme damit. Ich habe auch Festgestellt das es auch von Version zu Version des AVR-GCC anders ist :-), ja nach dem wie gepatcht wurde. Bosonders ärgerlich ist dieses Problem wenn man viele "Daten" im Flash hat die mehr als 64Kbyte belegen, da bekommt der AVR-GCC dann Probleme. CA Dirk
-
Thread
debuggen in Codeblocks klemmt
Auch mal ohne Optimierung kompilieren.
Dumdi D. schrieb im Beitrag #4338540: > Auch mal ohne Optimierung kompilieren. unter dem Menüpunkt "Settings compiler" compiler flags ist eine größere Liste möglicher Einträge. Angehakt ist da momentan nichts. Was sollte da ggf. angehakt werden? "Produce
-
Thread
Eigener Bootloader stm32f103
Test zeigt eine um 25% reduzierte Größe für ein gerade hier > rumliegendes Cortex-M0 Binary. Mit GCC erstellte Cortex-M Binaries enthalten eine Menge Null-Bytes, d.h. relativ wenig Entropie. Wäre eigentlich mal interessant zu testen ob man durch clevere manuelle Assembler-Optimierung Null-Bytes und
einen Report zu erstellen... Oder bevor ein neuer PR erstellt wird mal die Entwickler fragen in gcc-help@gcc.gnu.org. Vielleicht gibt es ja schon nen PR dazu. Die Internals sagen nicht viel zu MEM_ALIAS_SET und wie die für arm umgesetzt sind. https://gcc.gnu.org/onlinedocs/gccint/Special-Accessors.html
-
Thread
c code optimierung ev. assembler?
Stefan Ernst schrieb: > Du solltest mit den "Optimierungen" als erstes mal bei deinem > Programmierstil beginnen. Warum sind z.B. alle Variablen 16 Bit groß, > obwohl bei den meisten 8 Bit reichen würde? > Damit ist das hier auch wirklich kein Wunder
Entschuldigung angenommen: int auf AVR-GCC sind 16 Bit! Doku lesen.
-
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
Bitmanipulation optimieren
Nein. Es ist Zeitverschwendung und ein großer Irrtum. http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung Die einzige Mikrooptimierung ohne nennenswerten Aufwand ist eine direkte Zählung mit Schrittweite 4. Das spart aber gerade mal zwei Shiftbefehle und damit
Beitrag #3052998: > Sven P. schrieb im Beitrag #3052915: >> PORTC ist volatile, daher ist die Optimierung eigentlich nicht ganz >> legal. > > Genau deshalb besteht an der Stelle ja Optimierungspotenzial von Hand: --> Einfach eine Zwischenvariable verwenden.
-
Thread
Wie lange dauert ein Schleifendurchgang
16-bit access." Ist das für jeden Compiler gleich bzw. funktioniert das auf meinem? (AVR GCC) Vielen Dank im Voraus! Mfg
meinem Oszilloskop nachgemessen, der Wert stimmt weit >> nicht. > > Hast du auch brav die Optimierung eingeschaltet, die richtige > Prozessorfrequenz eingetragen und die richtige Clock-Source ausgewählt?? Die Optimierung ist standartmäßig eingeschaltet oder? Prozessorfrequenz wurde definiert
-
Thread
AVR-GCC nutzt 16 Bit für uint8_t Variable
GCC geht ganz natürlich davon aus, dass die zugrundeliegende Maschine mit "int" optimal umgehen kann. Was bei fast allen Zielmaschinen auch stimmt, nur eben bei AVR nicht. Pech. Dafür hat GCC hundert
im Wörterbuch nachschlagen, trotzdem ist für mich in dem Satz keine Info enthalten, was diese Optimierung nun tatsächlich tut. >> Dass der gcc aber jedes char grundsätzlich erstmal als int behandelt, >> kann ich noch nicht so recht glauben. > > Er muss. So ist Artihmetik in C nun einmal definiert
-
Thread
newlib fuer AVR?
Am einfachsten generiert man die newlib in-tree, d.h. * in GCC_SRC: ln -s NEWLIB_SRC/newlib * Falls libgloss gewünscht: in GCC_SRC: ln -s NEWLIB_SRC/libgloss * configure-build-install GCC Zunächst stellt sich aber die Frage, was du mit newlib überhaupt
, haben, abgesehen vom Host-OS, eine merklich kleinere Bandbreite. > und wörtlich behauptet avr-gcc sei tot, während Microchip/ATMEL Über die Politik der genannten Konzerne kann ich nichts sagen. avr-gcc ist GNU-Software, deren Copyright bei der FSF liegt. Mein Einblick in GCC und avr-gcc beruht
-
Thread
PIC32 RAM löschen
Holli schrieb im Beitrag #2879842: > - Er bietet diverse Optionen zur Code Optimierung Das wäre m. E. das einzige wirklich interessante, da der freie mips-elf-gcc im Vergleich zu den anderen, vom GCC bedienten Plattformen relativ große Kompilate erzeugt.
viel, wenn dahinter tatsächlich der gcc stecken sollte.
-
Thread
Wieso generiert der Compiler Chaos?
wildesten Effekte. Ausserdem verhält sich das Programm unterschiedlich, je nach eingestellter Optimierung, aber auch mit 'O0' funktioniert das Programm nicht richtig. Ich benutze keine delays, die sich ja je nach Optimierung anders verhalten können, der Code wird mit 0 Warnungen compiliert. Ich kann
vermuten: ___________________________________________________ Build started 3.3.2008 at 14:57:38 avr-gcc.exe -mmcu=attiny861 -gdwarf-2 -std=gnu99 -Wall -DF_CPU=8000000UL -O0 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT CD1.o -MF dep/CD1.o.d -c ../CD1.c avr-gcc.exe