-
Thread
Byte auf verteilten Ausgängen ordnen
Zum umordnen von bits kann evtl. auch dieses schöne GCC built-in praktisch sein: https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/AVR-Built-in-Functions.html#AVR-Built-in-Functions [c] unsigned char __builtin_avr_insert_bits (unsigned long map,
2*16 Byte reichen und diese Lösung steht auch schon etwas weiter oben, ist aber langsamer als das GCC __builtin_avr_insert_bits bzw. die Bitstore/Load Geschichte...
-
Thread
AVR (hex) reverse engineering (radare2)
#5817970: > Kann ich gewisse Dinge beim programmieren ändern, damit es leichter > wird? Ja, Optimierung abschalten. Dann entspricht das Assemblat eher Deinem Programm.
den glibc C-Code angeschaut hat und mit dem Asm verglichen hat, wird den Asm bevorzugen (mit Optimierungen)
-
Thread
Diskussion: Pi möglichst schnell berechnen
sich mit Mathematik und den eventuellen Vereinfachungen zu beschäftigen. Sich mit möglichen Optimierungen oder Stolpperfallen bei uCs auseinanderzusetzen. Natürlich möchte ich dann auch einen Algorithmus als "Beweis" implementieren. Dies aber mehr als spielerei. Natürlich würde ich bei etwas
und ausführich kommentiert: [[4000_Stellen_von_Pi_mit_ATtiny2313]] Übersetzbar mit einem avr-gcc für ATtiny2313 und Ausgabe via USART, und das Programm lässt sich auch ganz normal für einem Host übersetzen und ausführen :-) Eben mal mit avrtest durchlaufen lassen. Für 100 Nachkommastellen (
-
Thread
C Inhalt von 2 Variablen tauschen ohne zwischen speichern
Ich habe gerade etwas Interessantes festgestellt: Der GCC erzeugt bei eingeschalteter Optimierung für alle drei Varianten des folgenden Codes [c] #include <stdint.h> #define METH 1 void sub2(uint8_t a, uint8_t b); void sub1(uint8_t n, uint8
^ x; > -> x = 0 Leider seh ich nicht was Du genau meinst. Vielleicht liegt es auch an der Optimierung des GCC, allerdings glaube ich das (noch) nicht. #include<stdio.h> [c]int main() { int x=25; int y=25; printf("\n x = %i y = %i ", x, y); x ^= y; // x=0 printf("
-
Thread
Variable volatile auch wenn ISR nur liest?
sichergestellt, dass die Variable zeitnah geschrieben wird. Trotzdem kann der Compiler lokale Optimierungen durchfuehren. Das nur mal als Denkanstoss, kenne mich mit C nicht aus.
Im Falle von gcc sind ziemlich viele Standardfunktionen bereits im Compiler selbst eingebaut. Siehe https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
-
Thread
Problem mit Inline Assembler Routine (es wird zu viel optimiert)
Hallo, IDE: AtmelStudio 7.0.1931 (Optimierung steht auf -Os) MCU: ATXMega128A1U mit ext. SDRAM Ich habe mir ein paar Routinen (Write/Read Byte/Word/DWord/Block, Copy Block, ...) in Inline Assembler geschrieben, um auf den externen Speicher
#5790689: > Wie kann ich den Compiler zwingen hier gefälligst nicht zu optimieren? [c] #pragma GCC push_options #pragma GCC optimize ("O0") your code #pragma GCC pop_options [/c] oder [c] void __attribute__((optimize("O0"))) foo(unsigned char data) { // unmodifiable compiler code
-
Thread
C String einlesen, wieso geht das?!
("Hallo %s",name); getchar(); } int main() { Abfrage(); return 0; } [/c] [pre] $ gcc s.c && ./a.out s.c: In function ‘Abfrage’: s.c:8:11: warning: format ‘%s’ expects argument of type ‘char *’, but argument 2 has type ‘char (*)[1]’ [-Wformat=] scanf("%s",&name); ~^
Stream kann "unbuffered", "line buffered" oder "fully buffered" sein. In der Praxis ist stdout zur Optimierung meist das zweite, und dann kommt genau dieses Verhalten. > Ein \n beim printf könnte helfen. Das fügt aber einen zusätzlichen Zeilenumbruch ein. fflush(stdout) ist schon genau das richtige
-
Thread
ARM Cortex M0+ Startupcode Minimal
denen und sonst niemand nur nie aufgefallen, weil mit CodeWarrior ein historisch wertvoller Uralt-GCC verbundled ist. Löst man das ganze aus CodeWarrior raus um den Mist loszuwerden, compiliert es mit einem aktuellen GCC schon freut man sich über besagte Erkenntnis. (Wie unschwer zu erkennen war ich
UB beim Zugriff über das Ende. Am ehesten rettet einen ein volatile Pointer um dem Compiler die Optimierung zu untersagen, aber streng genommen auch das UB.
-
Thread
Wie viel Prozent des Gehalts sparen und wie anlegen? Gesperrt
https://www.youtube.com/watch?v=sqysmr22gcc
Arno schrieb im Beitrag #6875022: > Wobei das eine Optimierung irgendwo am letzten halben Prozent ist - > lange nicht so kriegsentscheidend, wie einige Schreihälse das hier > machen. Du drückst das mit "nett" und "lieber" schon ganz gut aus. das ist lächerlich
-
Thread
GCC: Konstant oder nicht konstant?
Auf godbolt zeigt auch ein gcc 8.3 das gleiche Verhalten wie der 5.1 (und auch Versionen dazwischen). Oliver
Oliver S. schrieb im Beitrag #5775635: > Auf godbolt zeigt auch ein gcc 8.3 das gleiche Verhalten wie der 5.1 https://godbolt.org/z/l7550g Bei mir zeigt der GCC in beiden Versionen das optimierungsabhängige Verhalten.
-
Artikel
Soft-PWM
stehen damit maximal 312 Takte zur Verfügung. Glücklicherweise ist die Funktion relativ kurz und der GCC leistet gute Arbeit. Der Interrupt benötigt hier 152 Takte, es verbleiben also jeweils 160 Takte zur Bearbeitung anderer Aufgaben. Das entspricht einer CPU-Belastung von ~49%. Das Programm benötigt
Quelltext mit Hilfe von #if . . #endif geprüft. Die +5 Takte sind eine Reserve. Dazu muß aber die Optimierung -Os eingeschaltet sein, sonst stimmen die Zahlen nicht! Achtung: Wenn man für eine PWM aussschliesslich 8 Bit breite Datentypen verwendet, dann steht für den Parameter für die Pulsbreite nur der
-
Thread
[C] Böse Falle: Datentyp korrekt angegeben, falscher verwendet
Man sollte seinen Compiler kennen: Du verwendest wohl einen AVR, da rechnet der gcc intern halt standardmäßig mit 16 Bit ints. Ein gcc für ARM Cortex-M würde hier mit 32 Bit ints rechnen.
Zweifel insofern anmelden, dass es nur noch mit unfairen Mitteln geht. Ich arbeite mit den neusten GCC Versionen für ARM, die optimieren für normale Funktionen unschlagbar gut. Gerade wenn Funktionen dann noch etwas größer sind steigt man mit händischer Optimierung nicht mehr durch. Und schließlich gibt's
-
Thread
BITs Bytes struct
zum Glück sagt die AVR-Gcc Doku, dass dieses unerlaubte Verfahren funktioniert. Andere Kompiler können sich anders verhalten. [c] struct I2CData{ uint8_t RS:1; uint8_t RW:1; uint8_t ENABLE
Arduino Fanboy D. schrieb im Beitrag #5763628: > zum Glück sagt die AVR-Gcc Doku, dass dieses unerlaubte Verfahren > funktioniert. Ich weiß. Aber man sollte sich sowas erst gar nicht angewöhnen.
-
Thread
C Sprungmarken und Sprungtabelle
Kann man die Adresse von Sprungmarken auslesen, um sie in einer > Sprungtabelle zu speichern? GCC kann sowas als Erweiterung: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels-as-Values Mir ist aber in knapp 30 Jahren C-Praxis noch nichts untergekommen, wo ich sowas als vorteilhaft
Jörg W. schrieb im Beitrag #5761908: > GCC kann sowas als Erweiterung: > > https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels-as-Values > > Mir ist aber in knapp 30 Jahren C-Praxis noch nichts untergekommen, wo > ich sowas
-
Thread
Eine weitere Bitumrechnung
aber der TO muss erst mal einen Fuß auf den Boden bekommen. Sonst hätte ich auch schon eine Optimierung vorgestellt.
Tausche deinen GCC mal durch GCC8 aus und mach -Wall -Werror an. Dann lässt er dich das nicht kompilieren, weil du sprintf deinen Buffer überlaufen kann.
-
Thread
GCC (Backend) an eigene Architektur anpassen
Hallo, ich bin aktuell auf der Suche nach Informationen den GCC an eine selbst entworfene Architektur anzupassen (Backend), finde bislang aber nur sehr wenig darüber. Hat eventuell jemand ein paar Informationen darüber für mich? Also die Basics (GCC Source besorgen
Tim T. schrieb im Beitrag #5757315: > LLVM hab ich schon durch, diesmal gehts mir nur um GCC. Hab ich auch mal versucht, habs aber aufgegeben weil ich nichts vernüftiges gefunden habe und der Code vom GCC nicht gerade der schönste und aussagekräftigste ist. LLVM ist da wesentlich besser.
-
Thread
8051 Microcontroller, suche erklärung für quellcode
dass Keil C51 das nicht wegoptimiert. Dennoch sollte man volatile verwenden schon um auf SDCC oder gcc portierbar zu sein.
wenn, dann kann man das über compiler options / controlls, bestimmen, bis zu welchem Grad die Optimierung geht. Fertig! Alle anderslautenden Aussagen sind Quatsch! Allerdings sollte man wissen, mit welcher Taktrate der Controller getaktet wird, bzw. man sollte sich mal den entstandenen Assembler-Code
-
Thread
Zehntel springt von 4 wieder auf 2. Warum?
Jens N. schrieb im Beitrag #5748429: > Optimierungen der Debugger sich nicht 100% an die Reihenfolge hält. Das kann man dem Compiler verbieten. Wenn alles läuft, werden die Optimierungen wieder eingeschaltet.
Philipp M. schrieb im Beitrag #5749059: > Besser noch, -Og: -Og ist relativ neu, hat nicht jede avr-gcc Version.
-
Thread
STM32F767 GPIO Geschwindigkeit hängt an Debug/Release
Der arm-gcc hat dazu die Kompromiss-Option: -Og Damit optimiert er so viel wie möglich, ohne den Debugger lahm zu legen.
passend zum Cortex-M / STM32 und GCC: http://blog.atollic.com/optimizing-code-size-with-the-gnu-gcc-compiler-for-stm32-and-other-arm-cortex-m-targets
-
Thread
Wie viele NOP für 100NS-Clock? (Software-SPI)
Taktfrequenzen portierbar und das Timing kann sich in Abhängigkeit von Compiler und der eingestellten Optimierung ändern.
egon schrieb im Beitrag #5745683: > Disassemble Damit wäre gemeint dem gcc dem Parameter "-S" mitzugeben... 73
-
Thread
Mittelwert aus ca.100 Werten.
anderes steht, in diesem Forum davon ausgehen, daß es sich um einen AVR handelt, dessen C-Code mit GCC bei -Os kompiliert wird.
das selbe (was ich nicht erwartet hätte...) -O2 ist auch nicht gleich. *Viel schlimmer*: avr-gcc 4.5.1/4.6.4 fügen mit "-Os" ein [c]call __divmodhi4[/c] ein, was 245(!) Takte braucht! Hier noch der Link zum AVR-GCC Compiler Explorer http://avr-gcc.senthilthecoder.com/#g:!((g:!((g:!((h
-
Thread
Code wird nicht in richtiger Reihenfolge abgearbeitet
Markus schrieb im Beitrag #5745795: > stell mal die optimierung von -O1 auf -Og, so hats bei mir dann perfekt > funktioniert. Wenn der Code ohne Optimierung funktioniert, aber mit Optimierung nicht, dann ist der Code kaputt.
Kaj schrieb im Beitrag #5745962: > Markus schrieb: >> stell mal die optimierung von -O1 auf -Og, so hats bei mir dann perfekt >> funktioniert. > Wenn der Code ohne Optimierung funktioniert, aber mit Optimierung nicht, > dann ist der Code kaputt. Es ging doch darum daß
-
Thread
Variablen in ISR static - sinnvoll oder nicht?
Hallo, das wird wohl stark von der Laune der GCC-Optimierung und dem Variablentyp abhängen. Er könnte z.B. eine Registervariable nutzen, wenn es nicht static ist, bei static muß er den Wert in jedem Fall irgendwo im Ram sichern. Auch wenn ich im
, die der Compiler in effizienteren Code umsetzen kann. Ein Hauptgrund dafür ist, das solche Optimierungen eher marginale Wirkungen haben im Vergleich zu Optimierungen des Algorithmus. Um ein Gefühl für Optimierung von Algorithmen zu bekommen, kann man sich mal die verschiedenen Varianten von Sortieralgorithmen
-
Thread
Sprung aus Funktion zu Funktion ?
, char*argv[]) { printf("%d\n", (-8) >> (argc > 1 ? atoi(argv[1]) : 0)); return 0; } $ gcc shift.c && ./a.out -8 $ gcc shift.c && ./a.out 10 -1 $ [/c] war dein urspruengliches Problem, i.e. der Shift-Rechts von negativen Zahlen.
argc, char*argv[]) { printf("%x\n", 1 << (argc > 1 ? atoi(argv[1]) : 0)); return 0; } $ gcc shift.c && ./a.out 31 80000000 [/c] Was hiesse also nicht darstellbar? Das Left-Shift ist eindeutig logisch. Das wird generiert und ist eindeutig: [c] shl %cl,%edx [/c] Die Interpretation
-
Thread
delay.h kann nicht eingebunden werden.
die delay.h. Beim compilieren des codes mit Eclipse kommt nun folgende Fehlermeldung: /usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h:95:3: warning: #warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as designed" Building target: Test.elf ../main.c: In
Invoking: AVR C Linker ../main.c:19:9: warning: implicit declaration of function ‘delay_ms’ avr-gcc -Wl,-Map,Test.map -mmcu=atmega32 -o "Test.elf" ./main.o ./main.o: In function `main': ../main.c:19: undefined reference to `delay_ms' collect2: ld returned 1 exit status make: *** [Test.elf]
-
Thread
max. Input Frequenz ATMEGA328
(vom Würgaround um fremde Fehler [eigene behebt man natürlich] bis hin zu einer ungewöhnlichen Optimierung, die im allgemeinen Fall nur Schaden anrichten würde, aber im speziellen Fall den Unterschied zwischen "geht" und "geht nicht" ausmacht). Ein Kommentar ist unnötig, wenn er nur in Prosa das wiedergibt
access!!! [/c] https://www.mikrocontroller.net/topic/366118#4121042 und hier macht es sogar der gcc [c] const uint16_t schaufel_upm_const = 11 * 60 * 8; rpm_1k = schaufel_upm_const / get_period(); // atomic read access!!! [/c]
-
Thread
C - Function / Define / Macro / Obfuscated C ?
weniger gut dokumentierten Optionen ist es > denn nun? > https://www-user.tu-chemnitz.de/~hmai/gcc/Ausarbeitung_1/options.html Direkt an der Quelle wirds genauer als in Chemnitz: https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Optimize-Options.html#Optimize-Options
Sicherheit nicht. Woher nimmst du diese Weißheit? Andreas V. schrieb im Beitrag #5718011: > Bei Optimierung auf Codegröße(/O1) oder Schnelligkeit (/O2) O1 und O2 ist beides auf Geschwindigkeit. Os ist Codegröße, beim GCC jedenfalls.
-
Thread
C Neuling benötigt Schubs in die richtige Richtung Gesperrt
Hinweise. Gruß Torsten Nachtrag: auch wenn ich CodeBlocks verwende, so wird dort von mir der GNU GCC Compiler genutzt.
eher Java und .NET?), C++ hat sich wegen der tollen IDE durchgesetzt (welche soll das nochmal sein, gcc + vim?), etc. pp.
-
Thread
Operatoren verstehen
if (0 & foo()) { puts ("ok"); } }[/c] Dieses Programm gibt "foo" aus, ohne Warnung von GCC oder Clang. UB oder nicht?
garantiert ist genau das Gegenteil erwarten, nämlich daß er auch an dieser Stelle die naheliegende Optimierung durchführen darf (und in diesem Falle sogar ganz dem Charakter der Sprache entsprechend die Optimierung garantiert immer durchführt). Und auch bei anderen Sprachen würde ich mich nicht unbedingt
-
Thread
Rust - ist das hier um zu bleiben?
Rust-Frontend kommt offiziell in die GCC https://www.golem.de/news/programmiersprache-rust-frontend-kommt-offiziell-in-die-gcc-2207-166831.html
Achja, falls das hier manchen nicht klar ist: GCC + Rust gibt es in zwei Varianten. 1) Rust-Frontend in GCC. Darum ging es hier im Gespräch hauptsächlich. 2) GCC als codegen backend von rustc. Beide werden aktiv entwickelt und beide sind wichtig
-
Thread
Code minimieren
Beitrag #5697984: > Ich möchte meine Skills ein wenig erweitern, was C sehr gut! > und die Optimierung und Minimierung anbelangt. Es ist gut, wenn Du Dich mit C, seinen Konstrukten und Möglichkeiten auseinander setzt. Was Du da aber betreibst nennt man Obfuscierung und hat mit Optimierung oder
modifizierten Quelltexte, mit denen der eigentliche Compiler gefüttert wird, kann man sich mit der gcc Option -E ausgeben lassen.
-
Thread
Arduino Librarys - Wer prüft diese ?
wie digitalRead() und Co. 5. ist es der Name einer "IDE", die den Aufruf des Compilers (i.d.R. gcc), des Linkers, des Upload-Tools etc. vereinfacht und auch einen Editor ungefähr auf dem Stand eines HTML <textarea> Feldes enthält. Dürftig ist die "IDE". Aus Performancesicht fragwürdig ist das
fünftel der Zeit rausgeholt, weil ich wusste das mein Bild in den Ram passen wird. Mit noch mehr Optimierung sogar das 20fache, daran hatte nur noch niemand bei der Library gedacht. Ich denke mal Hauptsache das Resultat stimmt dann für die Endbenutzer.
-
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
GIGATRON Emulator im STM32
Taktfrequenz! Der Code ist zwar sehr übersichtlich, aber nicht sonderlich effizient. Mit etwas Optimierung habe ich die C-Variante auf ca. 96 Clocks pro Gigatron-Instruction gebracht, das wären dann min. 127 Clocks, was ungefähr 790 MHz Taktfrequenz bedeutet. Mit einem RasPi sollte das zu schaffen sein
- schlimmstenfalls macht er das als if/elseif/else-Kette. Eine jump table kann man jedenfalls beim GCC aber auch mit computed goto erzwingen, einer GCC-Erweiterung.
-
Thread
Noch ein Taschenrechner auf ATMega Basis
>0 2 11 RCL 8 12 HALT [/code] ich hab mir ein rudimentäres Programm zusammengenagelt (Linux, gcc), welches den obigen Quelltest in den entsprechenden boris4-code übersetzt und auch zurück vom Binärcode in den Quelltext. Bevor man das jedoch auf die Menschheit loslassen kann, muss es mehr als nur
Button für Sleep-Mode - Kleinigkeiten Das Layout ist auch erstellt und bedarf nur noch einiger Optimierungen. Die Platinengröße beträgt derzeit 80mm x 127mm. Mit etwas Rücken kommt man noch auf 80mm x 125mm.
-
Thread
Variablen eindeutig benennen damit der Typ eindeutig ist
(gcc: -flto). Damit funktionieren solche Optimierungen auch über die Grenzen von Übersetzungseinheiten hinweg.
referenzieren könnte. > > In der Theorie ja. In der Praxis gibt es auch link-time-optimization > (gcc: -flto). Damit funktionieren solche Optimierungen auch über die > Grenzen von Übersetzungseinheiten hinweg. Mit switches kann man vieles anders machen und verdrehen, fragt sich nur ob das auch
-
Thread
Technik für zyklisches erhöhen eines Wertes: if versus modulo
veraltet sein. Das hat dann aber mit Hochsprachenprogrammierung nichts mehr zu tun. Solch Optimierungen kann der Compiler.
werden sporadisch auftretende Additionsfehler elegant unter den Teppich gekehrt ;-) Anmerkung: Optimierungen durch den Compiler müssen deaktiviert werden.
-
Thread
Lebensdauer von lokalen Variablen
ist, dass man sich damit eben /nicht/ beschäftigen muss. Es steht dir frei, das Teil direkt mit AVR-GCC und/oder Atmel Studio zu programmieren...
besseren Maschinencode für den avr. Ich vermute nicht. Da der Code klein werden sollte, habe ich die Optimierung direkt eingesetzt.
-
Thread
Struct als Argument (C++)
Die Optimierungs Algorithmen von GCC und G++ sind a auch logischerweise die selben...
Niklas Gürtler schrieb im Beitrag #5666196: > Die Optimierungs Algorithmen von GCC und G++ > sind a auch logischerweise die selben... Besonders die, die mit Templates zu tun haben...
-
Thread
Z80 wie AVT nutzbar? Gesperrt
Wenn es auch C sein darf ... Mit dem Suchterm "GCC Z80" findet man z.B. https://sourceforge.net/projects/z80gcc/ Um die Basis-Routinen für I/O etc. wird man sich, - wie zuletzt von Georg erwähnt -, vermutlich dennoch kümmern müssen und dafür gute
Theor schrieb im Beitrag #5665114: > Mit dem Suchterm "GCC Z80" findet man z.B. > https://sourceforge.net/projects/z80gcc/ Last Update: 2015. Und Dateien gibt's da auch keine. Das war ja mal ein Griff ins Klo. Es gibt zwei nennenswerte offene C-Compiler
-
Thread
Atmel Studio 7 Variablenverwaltung
wird er letzte Wert (11) in die Variable zurück geschrieben. Du hast zwei Möglichkeiten, diese Optimierung zu unterdrücken: a) Durch Deaktivierung sämtlicher Optimierungen (gcc Parameter -O0) b) Indem du der Variable das Schlüsselwort "volatile" voran stellst. > Testweise habe ich in Zeile 48
-
Thread
Auf Arduino erstelltes Programm in C und Assembler anschauen
Entwicklungsumgebung von Microchip kennen gelernt. Dort ist zumindest bei Abschalten der Compiler-Optimierung hinter jedem einzelnen C-Befehl aufgeführt, wie er in Assembler übersetzt wurde. Mit AVR C und Assembler habe ich noch keine Erfahrung.
könnte eventuell auch in der "platform.txt" /pfad/zur/Arduino/IDE/hardware/platform.txt die GCC-Optionen für die Erzeugung der Assembler-List-Files anhängen: https://www.systutorials.com/240/generate-a-mixed-source-and-assembly-listing-using-gcc/
-
Thread
Fertige Bibliothek oder selber schreiben?
en.wikipedia.org/wiki/C_standard_library#Concepts,_problems_and_workarounds schon deswegen sollte man eine Optimierung an das eigene System nicht ausschliessen. Oft lauern die Lücken in Codeabschnitten, die man nicht wirklich braucht.
#5657278: > Erstens besteht die libc aus wesentlich mehr als nur stdio.h. > Zweitens steht es dem gcc immer (und nicht abschaltbar!) frei, Aufrufe > zu mem{cpy,cmp,move,set} zu generieren, und die sind Teil der libc. Meist wird's aber eher umgekehrt sein, dass gcc einen memcpy-Aufruf selber intern
-
Thread
Programmiersprachen jenseits von "C"
fand ich > ganz gut, ist aber aus der Nische Militär/Raumfahrt nie herausgekommen. Ada (gnat/gcc) funktioniert gut für populäre µCs & OSs.
Geschwindigkeit erreicht Wie schafft der das ohne die hochkomplexen Optimierungsalgorithmen welche bspw. der GCC für C und C++ nutzt?
-
Thread
Frage zu Rekursion und StackOverflow in C
Vor allem da die Funktion mit einem ordentlichen Compiler dank tail-recursion keinen Stack benötigt (gcc ab -O2 oder -Os.
Aufrufebene etwas Stack, so dass der bei zu großer Tiefe nicht mehr ausreicht (Sofern die Compiler-Optimierung das nicht auflöst).
-
Thread
avr-gcc nutzt kein "Store Indirect and Post-Inc."
Hallo, ich verstehe gerade den avr-gcc nicht. Ich habe einen Attiny841 und möchte folgendes ausführen: [c] // highest_byte_in_value wird berechnt, ist dann 0 bis 3. switch (highest_byte_in_value) { case 3 : base64_buffer[current_buffer_element
schrieb im Beitrag #5646369: > Erst mal frischen Compiler besorgen: > http://blog.zakkemble.net/avr-gcc-builds/ Gemacht, der Code wird tatsächlich etwas schlanker. Nur das "Store Indirect and Post-Inc." wird immer noch unelegant umgangen. Compiliert habe ich hiermit: [code] avr-gcc-8.2.0-x64-linux
-
Thread
Schach für ARM Cortex
der Compiler eingebaut hat. Beispiel: Im "ARM System Developer's Guide" (2004) sind einige Optimierungen gezeigt, wie man seinen C-Code schneller machen kann, mit Beispielen was der Compiler aus der "langsamen" und "schnellen" Variante macht. Das habe ich mal ausprobiert - ein aktueller GCC produziert
Assembler so viel effizienter kodieren kann, Ich hatte mal dieses Jahr ein Morseprogramm in C auf dem GCC und dem IAR Compiler (Optimierung an) für einen M0+ geschrieben, sollte ein Test sein, dann exakt diesen Algorithmus Zeile für Zeile in Assembler formuliert. Auf Anhieb Faktor 2,5 schneller erreicht
-
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
CubeMX und HAL - I2C hängt sich auf
dem Rechner!! Und so viel Overhead frisst das auch nicht , es sei denn man nutzt nur O0 Optimierung.
genauso ausgeführt wird. Ist bei uns in der Firma übrigens auch Codierungs Richtlinie geworden für den GCC.
-
Thread
Union als Funktionsargument in C
C lernen will, sollte man sich direkt angewöhnen wohldefinierten portablen Code zu schreiben. Optimierungen für Sonderfälle kann man immer noch machen wenn es erwiesenermaßen (!) zu langsam ist.
explizit erwähnt. Wahrscheinlich hat ein Commitee Member festgestellt, daß sie das selber benutzen. Im gcc war es (als Erweiterung) meiner Kenntnis nach immer erlaubt.