-
Thread
wie variablenadresse in einer eff datei ändern?
aber 0x810712, was > eine Adresse im EEPROM darstellt. Und dann haben wir da auch noch die Optimierung des GCC. Wenn eine Variable einen file-static scope hat und außer der Intialisierung in der Deklaration nur gelesen wird, dann ist GCC so schlau, das Ding in die readonly-Sektion zu verfrachten,
0x810712, was >> eine Adresse im EEPROM darstellt. > > Und dann haben wir da auch noch die Optimierung des GCC. Wenn eine > Variable einen file-static scope hat und außer der Intialisierung in der > Deklaration nur gelesen wird, dann ist GCC so schlau, das Ding in die > readonly-Sektion zu
-
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.
-
Thread
AVR-GCC Array(Pointer) einer Funktion übergeben
volatile sein? Wer weiss? Gibt es denn Potential, dass der COmpiler in diesen beiden Members mit der Optimierung daneben hauen kann?
irgendwie weiter } break; } [/c] Ich weiß eben nicht genau, ob der Compiler sowas per Optimierung zerwürgt...
-
Thread
while-Schleife
Stefan schrieb im Beitrag #2582813: > Selbst gcc macht das, und das auch noch zurecht [c] #include <stdio.h> void x() { while(1); printf("Hallo Welt"); } [/c] macht der gcc zu: [code] .file "x.c" .text
borg schrieb im Beitrag #2586938: > Alle Warnungen bekommt man zumindest bei gcc weg, indem man vor main() > noch die Zeile einfügt:[c]volatile fn puts;[/c] Bei mir gibt es dann die folgende Warnung mit gcc Version 3.4.5 (sowohl bei Übersetzung mit -Wall als auch ohne):
-
Thread
Umstieg von Atmega8 auf Atmega168 LCD initialisiert nicht mehr
>Ich nutze avr-gcc (WinAVR 20100110) 4.3.3. Mein Compiler ist noch 4.3.0. >Habe nun make_clean und neu kompiliert. Habe das Verzeichnis geändert >und aus dem neuen Verzeichnis geflasht. >Habe vom festen PC
Optimierungsprobleme in den > Zeitschleifen (Timing). Ganz im Gegenteil, die Delay.h des AVR-GCC benötigt die Optimierung, vorzugsweise -Os. Mit -O0 geht sie total falsch. Peter
-
Thread
pointer struct parameter übergabe / fehler?
Ist die Compiler-Optimierung ausgeschaltet? (-O0 für gcc)
damit zusammen, dass der Optimizer über einige Funktionen Bescheid weiss und dieses Wissen zur Optimierung benutzen kann. Jörg: Sind das beim gcc nicht die intrinsischen (intrinsic) Funktionen? Wie ich den gcc kenen, gibt es da sicher einen Compilerswitch mit dem man das abschalten kann. Nur
-
Thread
bitte Hilfe, interner Compiler Fehler
Beim Compilieren von Hit1270.c kommt bei mir ein interner Compiler Fehler, wenn ich als Optimierung "o3" wähle. Mit Optimierung "os" ist die Welt in Ordnung. Umgebung: WindowsXP, AVR Studio 4, aktuelles WinAVR (GCC 4.3.3). Der Fehler kommt aber auch, wenn ich dem WinAVR einen GCC 4.7.2 unter
Ich habe hier gerade einen GCC-4.3.3 unter Cygwin am laufen. [c] $ avr-gcc --version avr-gcc (Memsic 20120521) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions
-
Thread
Bascom - C Umstieg Teil 1 - IDE-Probleme
optimizations disabled; functions from <util/delay.h> won't work as > designed" [-Wcpp] Und die Optimierung einschalten.
die beiden anderen Fehler bestehen: [code] -------------- Build: Debug in test3 (compiler: GNU GCC Compiler for AVR)--------------- avr-gcc -Wall -mmcu=atxmega128a1u -DF_CPU=2000000UL -g -Os -I/usr/include -c main.c -o obj/Debug/main.o avr-gcc -L/usr/lib -o bin/Debug/test3.elf obj/Debug/fuse.o
-
Thread
mehr als drei Speicherstellen bei inline-assembly (avr-gcc)
Assemblercode einfügen ohne irgendwelche unleserliche Syntax. Daß auf Assembler keinerlei Optimierungen vorgenommen werden, dürfte klar sein.
Peter D. schrieb im Beitrag #6630035: > Daß auf Assembler keinerlei Optimierungen vorgenommen werden, dürfte > klar sein. Nö. Es werden vielmehr alle Optimierungen angewendet, zu denen der Asm-Programmierer in der Lage war... Blöd nur, dass die C-Gülle, mit der der Kram
-
Thread
Kann keinen String zuweisen wieso ?
> libgcc würde das noch angehen. Mag sein, daß es von der libc unabhängig ist. Jedenfalls hat gcc die Funktion sprintf (und so gut wie jede andere libc-Funktion) zu Optimierungszwecken schon selbst eingebaut und ruft nur dann die libc-Implementation auf, wenn er keine Möglichkeit für die Optimierung
Optimierung > findet. Das geht aber nur, wenn sich die C-library nicht dagegen wehrt. Standard "Bezeichner" (da wir grad beim Thema waren...) werden mit #defines umgebogen, damit gcc sie nicht als solche
-
Thread
C (MinGW): Unerwartete Bool-Auswertung
Ich kann dein Ergebnis mit dem GCC ("gcc (Debian 8.3.0-6) 8.3.0") *nicht* nachvollziehen (Minimalbeispiel): [code] #include <stdint.h> #include <stdio.h> #include <stdbool.h> volatile bool r; volatile bool s; int main(
schrieb im Beitrag #5974140: > clang schafft es es bis Version 8 nicht, eine Warnung zu generieren. > GCC 5 ebenfalls nicht, GCC 8 wirft eine Warnung Danke fürs Gegentesten. Dann kann ich das Problem wohl auf meinen GCC 5.1.0 zurückführen. Es wird wohl mal Zeit für ein Update. Ich werde mich künftig
-
Thread
Probleme mit der Case switch anweisung
Und es gibt durchaus auch eigene Fehler, die erst bei eingeschalteter Optimierung auffallen (vergessenes volatile ist da wahrscheinlich der Spitzenreiter). Insofern ist die Geschichte nicht unglaubwürdig, nur die Schlußfolgerung daraus ist falsch ("keine Optimierung einschalten
für solche Funktionen ggf. den Weg wählen, wie er solche Anwendungen dokumentiert ist, z.B. beim AVR-GCC bzw. WinAVR mit ISR() arbeiten.
-
Thread
Timer Interrupt STM32F103
also LEDS usw alles raus. Du kannst das im Debugger gut sehen. Ich arbeite mit Embitz 1.0 und dem GCC. Ich empfehle Dir den Code erstmal mit O0 zu kompilieren und dann schrittweise zu optimieren. In meiner Firma sind Optimierungen per Coding Richtlinien ganz verboten und das aus gutem Grund. Ich
Diesen Zirkus hatte ich auch mal. Es lag letztlich daran, dass ich mit > den Optimierungsstufen des GCC Murks gebaut hatte. Schaltete ich die > alle ab lief es wieder. Das liegt in 99% der Fälle nicht an den Optimierungsstufen, sondern an Fehlern im Quelltext. Die Lösung ist dann nicht, die Optimierung
-
Thread
Wie man volatile optimiert
sondern es ist für eine Variable immer generell. D.h. auch im Interrupthandler wird damit die Optimierung ausgeschaltet, also da, wo es am meisten wehtut. Peter
auch const. Das heißt man kann > volatile genauso casten wie const. Und warum geht es dann im AVR-GCC nicht? Peter
-
Thread
Keil, IAR vs GCC
für Argumente sprechen dafür einen Keil oder IAR Compiler zu verwenden, anstatt einem kostenlosen GCC. Im Speziellen würde mich GCC für ARM für Industrieelektronik interessieren. Lors
Bedacht und nutzt gegebenfalls eigene Funktionen (Atmel macht das z.B. bei stdio in Beispielen für arm-gcc so), sind die Unterschiede in Bezug auf Codegröße sehr viel geringer. Stöbert man durch die Quellen der newlib, findet man auch einige Änderungen zur Optimierung, die von Leuten mit arm.com-E-Mail
-
Thread
externe Deklaration in anderem C-File; so richtig ?
Wert_A' is 00403000 (5) foo: location of 'Wert_A' is 00403040 (5) Kompiliert auf Windows2000 mit gcc 3.4.2: gcc -g -O2 -Wall -o static.exe static.c static2.c
wenn kein Sourcecode der Library vorliegt. Natürlich kann in diesem Falle der Compiler die Optimierungen, wie sie oben angesprochen wurden, nicht durchführen. Das gcc-Verhalten sprach Patrick an (http://www.mikrocontroller.net/forum/read-1-286669.html#288169), welche Compileroption zu verwenden
-
Thread
[rant] Schleifen ohne Seiteneffekte - Jeden Tag steht ein neuer Amateur auf :-(
> > Nein. Tut er nicht. Jedenfalls nicht solange DU ihn nicht durch das > Einschalten der Optimierung dazu zwingst. Es ist nicht garantiert, dass der Compiler erst dann optimiert, wenn Du irgendeine Optimierung einschaltest. Vielmehr muss der Compiler nur ein gewünschtes Resultat erfüllen. Ein Delay über eine sinnlose Zählschleife muss er jedoch nicht garantieren - egal ob irgendeine Optimierung eingeschaltet ist oder nicht. Daher muss ich Dich korrigieren. Richtig ist: Du kannst von Glück reden, wenn er ohne Optimierungs-Option die Schleife tatsächlich in Code umsetzt. Meist ist
-
Thread
GCC: code funktioniert bei -O, funktioniert nicht bei -Os
bei -O auf. Was sagt denn -v? Ich kann den Fehler mit 4.3.3 unter Linux nicht nachvollziehen. avr-gcc hab ich erzeugt aus svn gcc_4_3_3_release mit gcc = 4.0.2 gmp = 4.2.2 mpfr = 2.3.1 Johann
Wird nicht genauer, sorry. gcc -v sagt 4.3.3 und sonst nix, apt sagt 4.3.3-1 (http://packages.debian.org/en/sid/gcc-avr).
-
Thread
C-Frage zu einem Warning in einer if-Anweisung
nicht unbedingt offensichtlich), daß sich Zeiger überlappen können. Das verhindert bessere Optimierungen, weil der Compiler dereferenzierte Werte nicht in Registern halten, sondern immer aufs Neue lesen muß. Leider sind nicht alle gcc Versionen mit einer gleich guten Erkennung gesegnet, wann das
ein Aliasing zu übersehen (insbesondere bei Code für performante De/Serialisierung) ist hoch. Und GCC warnt quasi nur bei den (offensichtlichen) Fällen, wo es keine Probleme gibt. Die wirklichen Probleme sieht er aber nicht, wie auch. Mein Empfehlung: Bei Optimierungen (-O2 und mehr) immer -fno-strict-aliasing
-
Thread
Compiler Error von WinAVR als Plugin zu AVRStudio
Hallo an alle. Ich möchte ein Projekt kompilieren, dass ich als GCC Projekt im aktuellen AVRStudio angelegt habe. (installiert ist auch das neueste WinAVR). Nun bekomme ich leider de Meldung: gcc plug-in: Error: Object file not found on expected location F:\projects
http://www.mikrocontroller.net/articles/WinAVR#gcc_plug-in:_Error:_Object_file_not_found_on_expected_location
-
Thread
AVR ATMega - Zugriff auf Struct im Speicher mittels Offset
Compiler im Laufe der Jahre und kenne halt einige auswendig und bei anderen schlage ich nach. http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html#Structure_002dPacking-Pragmas
den verschiedenen Aussagen dazu das ein Struct > im Speicher optimiert abgelegt wird ? Beim avr-gcc lautet diese "Optimierung" eben "auf Byte-Grenzen legen".
-
Thread
Multiplikationen = Performancefresser?
3; } draus gemacht? Das is ja geschickt. Macht er das immer oder nur bei eingeschalteten Optimierungen? Gast.
erkannt :-) > Das is ja geschickt. Gelle. So ein Compiler hat heutzutage schon eine Menge Optimierungen drauf. Manchmal haut er gcc-Optimizer auch ein bischen daneben. Das liegt aber daran, dass der gcc nicht nur für µC gebaut ist, sondern eine breite Palette von Prozessoren, bis hin zu Grossrechnern
-
Thread
memcpy vs for-loop bei AVR
memcpy gibt es unter Umständen so allgemein nicht. Der Compiler kann (und der gcc wird, bei eingeschalteter Optimierung) den memcpy Aufruf durch äquivalenten Code ersetzen und den Gegebenheiten entsprechend optimieren. Also die eigene Implementierung vergleichen mit einer Implementierung
den/ Sourcecode von memcpy gibt es > unter Umständen so allgemein nicht. Der Compiler kann (und der gcc wird, > bei eingeschalteter Optimierung) den memcpy Aufruf durch äquivalenten > Code ersetzen und den Gegebenheiten entsprechend optimieren. Aus [c] #include <string.h> #include <stdint.h
-
Thread
AVR GCC: Funktion wird weg optimiert... warum?
_ oder so änhlich -attribute und enstprechende GCC-Parameter, um die zu nutzen müsstest du allerdings das GCC-Manual lesen ... hth. Jörg
Knackpunkt ist das inline, das wußte ich nicht. Der Knackpunkt ist nicht das inline, sondern, daß der gcc, genauso, wie andere Compiler auch, bei eingschalteter Optimierung Code erzeugt, der nicht mehr 1:1 rückwärts dem C-Quelltext zugeordnet werden kann. Das macht der nicht nur durch inlining, da gibt
-
Thread
Codegröße WinAVR vs. AVR Studio (mit gcc)
angepasstem Makefile) programmiert. Aus Neugierde habe ich ein bereits getesteten Quellcode direkt in ein GCC-Projekt kopiert und compiliert. Wie zu erwarten, gabs keine Probleme. Beim Vergleich der Hex-Files ist mir aufgefallen, dass das WinAVR-Hex-File nur ca. halb zu groß (5,47kB) ist, wie das GCC-AVR-File
Jörg, vielen Dank für die schnelle Antwort. Mir war schon klar, dass ich unter AVR-Studio mit dem GCC kompiliere. Und gerade deshalb fande ich es "sonderbar", dass unterschiedliche Dateigrößen des Hex-Files auftraten. Die Optimierung hatte ich aber richtig eingestellt. Dein "Blau-Schuss" traf
-
Thread
Funktionsaufruf aus Interruptroutine OK?
aber praktisch nur große Variablen oder aber den Fall ausgeschalteter Optimierung. Kleine Variablen (bzw. daraus berechnete Teilausdrücke) werden bei eingeschalteter Optimierung in Registern abgelegt, und der Compiler weiß genau, wie lange er ein Register für einen bestimmten
Gehört der GCC dazu ?
-
Thread
WinAVR 20070525 Optimierung
Hallo! Gibt's beim Upgrade von WinAVR irgendwas zu beachten? Ich hatte bis vor kurzem WinAVR 2006 installiert. Jetzt hab ich auf WinAVR 2007 upgedated und meinen Webserver neucompiliert. Leider funktioniert nun die Checksummenberechnung nicht mehr. [c] WORD checksum( BYTE * buffer, WORD count ) { WORD sum; asm volatile ( "clr %A0 \n\t" "clr %B0 \n\t" "sbiw %A2, 1 \n\t" "brcs 2f \n\t" "1: \n\t" "ld __tmp_reg__, %a1+ \n\t" "add %A0, __tmp_reg__ \n\t" "adc
-
Thread
Warum verbraucht eine Variable so viel Speicher?
; } [/c] Compiliere ich ihn nun ohne Optimierung, gibt's eine Warnung: [pre] /usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:94:3: warning: #warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as
ignoriert, ich glaube, dem ist nach menschlichem Ermessen nicht mehr zu helfen. Schalte ich die Optimierung ein, dann bekomme ich: [pre] /usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h: In function 'delay': /usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:152:28: error: __builtin_avr_delay_cycles
-
Thread
AtmelStudio 6 - Bug oder Feature ?
32Mhz stabil sind und erst dann umschalten weil die Hardware das sonst ignoriert. Mit 'Size' optimierung läuft das wie erwartet. Schalte ich die Optimierung jedoch aus, funktioniert das nicht. Die Schleife wird durchlaufen, es bleibt aber beim 2Mhz Systemtakt. (code siehe unten) Keine Compilerwarnung
Michael Knoelke schrieb im Beitrag #2748100: > Mit 'Size' optimierung läuft das wie erwartet. > Schalte ich die Optimierung jedoch aus, funktioniert das nicht. > Die Schleife wird durchlaufen, es bleibt aber beim 2Mhz Systemtakt. Dann tippe ich mal, daß mehr
-
Thread
eigene memcpy Funktion mit 2 Zielen
Hast du mal getestet, was gcc mit -Os tut? Ist das wirklich nicht gut genug? Das sollte man ausprobieren, bevor man sich die ganze Arbeit macht. ;)
ich sagen muss, dass der Compiler aus deinen Ansätzen wieder 2x memcpy(..) macht... die einzige optimierung dabei ist dann, dass es nicht mehr inline ist (was eigentlich schon 90% der Optimierung ausmacht). Wäre vollkommen ausreichend, aber irgendwann kommt einfach der Punkt da will mans wissen. in C
-
Thread
LCD ansteuern, fragen zu tutorial in assembler
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#LCD-Ansteuerung ...
für dich ja kein problem sein, nach der Ampelsteuerung) Dann noch was zum Thema for-Schleifen optimierung: Den Grad der Optimierung kann man in der Regel einstellen. Wenn du Wartezeiten mit for-Schleifen programmierst, ist es ratsam ohne Optimierung zu arbeiten, da diese sonst wegoptimiert werden.
-
Thread
OHNE(!) Optimierung gehts nichts mehr
Es gibt C-Konstruktionen im GCC, die ohne Optimierung einfach nicht laufen. Beispielsweise inb() und outb() und Konsorten unter Linux.
Ich kann mir auch nict vorstellen, das Inline oder Makro nicht gehen soll wenn man keine Optimierung eingeschaltet hat. Normalerweise debuggt man ja code ohne Optimierung und dabei ist mir noch die etwas untergekommen was ohne optimierung nicht geht. Da die Header datei ja eh durch das include
-
Thread
GCC Preprozessor Berechnungen und Forced Errors
hat, >> was erst der Compiler weiss. Und sizeof kennt erst der Compiler. > > Zumindest bei dem GCC weiss ich nicht, ob das so stimmt. Beim GCC ist der Präprozessor mit im Compiler eingebaut, aber dadurch darf sich dessen Verhalten natürlich nicht ändern. > In func2() (per const Variable) wird
Präprozessor nichts damit zu tun hat. Jupp, der ist raus. Die Operation sieht der nicht als Optimierung.
-
Thread
AVR: Ausgangsport Togglen leicht gemacht
das nicht. Vielleicht schnappt das ja der eine oder andere Compilerbauer auf und kann das als Optimierung implementieren
in den kürzesten oder schnellsten, je nach eingeschalteter Optimierung. Aber was soll so ein Universalcompiler, wie der gcc noch alles berücksichtigen? Schau dir mal den erzeugten Assemblercode an und überlege wieviele weitaus nützlicheren Optimierungen dir auf den
-
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
Probleme bei atan2() mit volatile
Zumindest der gcc kennt die Funktionen der Standard-Library und arbeitet auch mit diesem Wissen.
die > Parameter überprüft werden können). Ja. So gut wie alle Funktionen aus der math.h sind im gcc als built-in-Funktionen vorhanden. Hier eine Liste: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Other-Builtins.html#Other-Builtins
-
Thread
Probleme mit dem Speichermanagement beim AVR mit GCC
geschrieben werden könnten? oder das ergebnis aufgesplittet? ohne code kann ich keine vorschläge für optimierung geben ^^
Es geht nicht um Optimierungen, es geht darum während der Initialisierung temporär ungenutzten Speicher nutzen zu können. Aber vermutlich ist das wirklich nicht vorgesehen im GCC oder irgend einem C-Compiler...
-
Thread
GCC (STM32) problem mit Optimierer
Hallo miteinander Bei meinem Projekt bin ich bisher im Debug-Build mit Optimierung -Og (Debug) unterwegs und es funktioniert soweit wie erwartet. Kürzlich versuchte ich den Release-Build, bei welchem ich -Os also auf Grösse optimieren möchte. Nun, das Programm funktionierte nicht
tRet = 1; // uint16_t tIdx = 0; // das funktioniert nicht mit Optimierung -Os (size) volatile uint16_t tIdx = 0; // das funktioniert mit Optimierung -Os (size) if (aFlow > 0) { while ((aFlow >= mVxMapUp[tIdx].Flow) && (tIdx < VX_MAP_ELEMENTS ))
-
Thread
WinAVR 20030913 veröffentlicht
wenn sich das bisherige bereits glänzend bewährt hat" Bestimmt würden sich auch umgekehrt ne Menge GCC-Gurus mit dem Keil schwer tun. Das ist ja nur menschlich. Und mit meinem GCC-Patch bin ich auch voll zufrieden. Peter
C -- wenn Du denn einen findest, der gut genug ist, auch sonst das nötige sinnvolle Maß an Optimierungen zu bieten, an die man sich bei guten C-Compilern eben gewöhnt hat. . Du kannst versuchen, einen Kompromiß zu finden. Das soll natürlich keineswegs heißen, daß die Optimierungen des avr-gcc
-
Thread
AVR-gcc und Bitfelder
der GCC is da etwas eigen .. versuch mal [c] typedef union { unsigned char register; struct PMSMflags { unsigned char motorStopped : 1; unsigned char motorSynchronized: 1; unsigned
schrieb im Beitrag #1777955: > Übersetzst du beim AVR mit -Os ? Typelayout hängt nicht von Optimierung ab.
-
Thread
Interrupt / SREG / Priorität
Johanns Arbeit (ich glaube, es war ab GCC 4.9) die Optimierungen für AVR deutlich besser geworden.
allem durch Johanns Arbeit (ich glaube, es war ab GCC > 4.9) die Optimierungen für AVR deutlich besser geworden. Johanns Arbeit ist unbestritten wertvoll, und ich weine dem 3er gcc auch nicht nach. Den Codegrößenvergleich müsste man aber doch mal richtig
-
Thread
Wie avr-gcc starten?
Hallo, kann mir jemand schreiben, wie man unter Windows98 das avr-gcc starten kann? Wenn man es direkt anklickt, huscht des DOS-Fenster über den Bildschirm, wenn man ein DOS-Eingabefenster öffnet und avr-gcc aufruft, kommt eine Fehlermeldung von wegen keiner Inputdatei
auch weiterhin, nach 7 jahren assemblererfahrung) aber die infos kann ich dir geben.... die GCC - Compiler kommen ursprünglich aus der Linuxecke (konsolenfetischisten, sorry) d.h.: der gcc ist ein textbasiertes kommandozeilen-konsolenprogramm, für den es aus der windowswelt noch kaum einer
-
Thread
AVR braucht 7us-12us bis in Interrupts ausgelöst wird??
Push- und Pop-Orgien des gcc bei all den vielen Registern. Schau dir mal das disassembly an.
wenn die ISR sie selbst verwendet. Aufgerufene Funktionen sichern diese Register selbst. https://gcc.gnu.org/wiki/avr-gcc#Register_Layout
-
Thread
Schnelle Bitmaske in AVR-Assembler
häufig vorkommt und dabei z.B. Latenz wichtig ist, dann gibt es andere Stellen im Code, deren Optimierung deutlich weniger als eine Verdopplung bringt.
Effizienz der "Jim-Beam-Routine" erreichen. Und Leute wie du sind wesentlich verantwortlich für den avr-gcc? Da wundert es echt niemanden, dass der so Scheiße ist, wie er halt ist...
-
Thread
HSV->RGB-Methode: Speicherplatz optimieren
merklich beeinflussen. Ebenso die gemsichten 42/43 kommen mir komisch vor. Kompilierst du auch mit Optimierung auf Platz?
noch tunen. Eventuell erlaubt die Anwendung: CFLAGS += -mtiny-stack #Stack auf 256 begrenzt (GCC 4.3.0)
-
Thread
Bug im avr-gcc bei Behandlung von SFRs als Bitfields?
Variante ein zweites Mal wiederholt. Kann dazu vielleicht Johann (oder Jörg oder ein anderer avr-gcc-Experte) was sagen? Achja, Compiler ist avr-gcc 4.7.2, Optimierung Os. Gruß und Dank, Frank
Frank M. schrieb im Beitrag #3748189: > Du hast einen neueren avr-gcc 4.7.2? gcc version 4.10.0 20140629 (experimental) (GCC) > Könntest Du den Code aus dem > Ausgangposting da mal durchschicken und hier den Auszug aus der > lss-Datei angeben? lss mag ich
-
Thread
Pic-C-Compiler
Dadurch kannst du auch erst mal einen Compiler machen, der C-Code in Assembler wandelt und die Optimierung des Assemblers und das Linken kannst du fürs erste einem bereits vorhandenen Assembler und Linker überlassen... Wenn das dann mal laufen sollte kannst du die Stufen Assembler und Optimierung einbauen
"Zu AVR-GCC / WINAVR: Wo gibts die? Freeware?" Geh diese Seite ganz nach oben und lies mal links davon, da sind 2 Links "AVR-GCC". Zum Ladgerät: Ich weiß jetzt nicht, mit wieviel MHz Du pulsen willst,
-
Thread
Gleiche Funktion. 23 cycles anstelle von 6?
Ein exzellent optimierender Compiler ... ist das in diesem Fall jedenfalls nicht - oder die Optimierung war abgeschaltet. Denn der ASM2 Code ist für optimierten Code wirklich unter aller Sau. Ich meine mich zu erinnern, dass Microchips freie Compiler-Version bei Optimierung eingeschränkt ist. Intern ist der Compiler von Microchip der GCC plus etwas proprietärem Kram. Und der GCC sollte sich nicht so doof anstellen. Wenn man ihn lässt.
-
Thread
register
d.h. der Compiler wird es so machen. Sorry, das ist Quatsch. Offensichtlicher Gegenbeweis: der GCC macht aus diesem Stück Code unsigned char foo(void) { register unsigned char foo[24]; return foo[3]; } folgendes (mit Optimierung, ohne Generierung irgendeiner Warnung):
standardgemäße Form der register storage-class, aber darauf hatte ich ausdrücklich verwiesen. Der GCC-ismus des Ablegens in einem bestimmten Register ist beim GCC ordentlich dokumentiert und nicht ganz ohne Pferdefüße.
-
Thread
n++ hier oder dort?
Hängt das Ergebnis beim gcc von der Optimierungsstufe ab?
z.B. für eine andere CPU eine andere Reihenfolge erzeugen, weil der Optimierer dort anders arbeitet. gcc hat z.B. Optimierungen die auf Heuristiken beruhen (-fguess-branch-probability) und bei profile-guided Optimierung ist das Ergebnis im Grunde zufällig, wenn es von nicht vollständig reproduzierbaren