-
Thread
uC Programmiertechniken - Gibt es da Bücher?
Code mit -Os kann man dem Debugger füttern. ;-) Mach ich seit 20 Jahren so. Man muss nur mit den Optimierungs-Artefakten leben lernen.
Pointern. Idealerweise glatte Zahlen, damit aus dem Dividieren ein Schieben wird. Also 2^N Vielfache. Der GCC ist clever genug /4 als N >> 2 umzuwandeln.
-
Thread
Wie Verwendung von Konstanten erzwingen?
Das macht der Compiler bereits für dich, ohne dass du es weißt - sofern du Optimierung eingeschaltet hast.
Beitrag #6653721: > Das macht der Compiler bereits für dich, ohne dass du es weißt - sofern > du Optimierung eingeschaltet hast. Für den gcc ist das korrekt. Fragt sich nur, ob der TO überhaupt gcc verwendet oder gar die Frage ganz allgemein für alle üblichen C-Compiler stellt. Er verrät ja auch nicht
-
Thread
uint8_t cast to int8_t
das Problem doch eher vor dem Computer zu sitzen. Es gibt keine fehlerfreie Software, aber das ein gcc einen einfachen signed-Vergleich versemmelt, ist doch eher unwahrscheinlich. Da du aber keine aussagekräftige Sourcen zeigst, ist die ganze Diskussion müßig. Zeig ein compilierbares Beispiel mit
und den Wert als char plus uint8_t. Da hätte ich jetzt von IAR mehr erwartet. (Selbst VSCode mit GCC zeigt die Datentypen int8_t, uint8_t korrekt an....)
-
Thread
STM32F103 Bluepill mit 128kb lässt sich nicht flashen
1.12 klappt nicht mehr, der Code ist > nicht mehr lauffähig. LTO for STM32 is broken in newer gcc-arm-none-eabi releases.
Frank M. schrieb im Beitrag #6758700: > LTO for STM32 is broken in newer gcc-arm-none-eabi releases. gcc-arm-none-eabi 9 great support for LTO. See if there is a check "Use Link Time Optimization" on the Linker tab for target Release.
-
Thread
C Programmierung ohne Pointer?
Beispiele? Normalerweise sind Pointer eher problematisch in Sachen Optimierung bzgl. Aliasing.
mh schrieb im Beitrag #6651391: > Ok RVO mit nem rvalue macht gcc bei mir auch. Hast du zufällig mal NRVO > also mit nem RVO mit nem lvalue getestet? Ja. Aber ich glaub, ich bin einer Optimierung aufgesessen.
-
Thread
STM32 Embitz: Code optimieren / nano-branch Lib vermeiden
Christian J. schrieb im Beitrag #6641202: > da im Debug Mode keine > Optimierung erlaubt ist. Veraltet. Optimierung -Og existiert schon ewig im GCC.
Jim M. schrieb im Beitrag #6641316: > eraltet. > > Optimierung -Og existiert schon ewig im GCC. Danke,das hilft mir schon weiter! Kann ja nicht alles wissen :-) Hat 9kb eingespart und zur Not muss eben der 64kb F103 einem 128kb Typ weichen.
-
Thread
Vorstellung und erstes Projekt
ein schönes Tutorial für C-Programmierung mit dem µC. https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial Insbesondere das Kapitel https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Zugriff_auf_IO-Ports über die Nutzung der I/O-Pins.
wie#define MeinBit > Portadresse,Bitnummer > tatsächlich zu definieren. Doch. Z.B. der AVR-GCC kann das: https://www.mikrocontroller.net/topic/292251#3113090 Das sollte auch beim PIC gehen.
-
Thread
C - extern - Verständnisfrage
meiner Meinung nach ein paar mal seine Programme selbst 'bauen' (hier am Beispiel von Linux/*nix mit gcc - ich kann nichts anderes): ein oder mehrere .c-Files 'compilieren' zu .o ; mehrere .o zu einer ausfuehrbaren Datei 'linken' evtl. unter Zuhilfenahme von Bibliotheken .a Schau mal da: https://www.cs.utah.edu
Letzt, bekommt der Linker anwendung.o und core.a vorgeworfen und macht seinen Job, incl. diverser Optimierungen, wie z.B. unbenutzte Methoden/Funktion/Variablen zu entsorgen. Das aus der *.elf dann noch eine *.hex und eine *.eep gebastelt wird, geschenkt. ---- Die Arduino Besonderheit: Machst du
-
Thread
Merkwürdiges STM32 Verhalten
Optimierungsflags verwendet werden. Findet sich unter Projekt -> Properties -> C/C++ Build -> Settings -> (GCC oder G++ compiler) -> Optimization Wenn das dort auf -Og steht, probier es mal mit -O0 aus. -Og führt im Gegensatz zu O0 schon Optimierungen durch, versucht aber noch gut debuggbar zu sein, aber
Optimierungen abschalten. Der Kompiler hat die Zeile/den Code wegoptimiert.
-
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
Unbekannte Warnung
Stefan schrieb im Beitrag #6625731: > Johannes S. schrieb: >> Die Warnung kommt ja weil die Optimierung "-fstrict-aliasing" gesetzt >> ist. [...] > > Danke! Ich hatte die Hoffnung schon aufgegeben... Hast du dir überhaupt angeguckt, was "-fstrict-aliasing" genau macht? In der gcc-Doku steht
wieso das, wenn ich fragen darf? Bei memcpy muss man doch erstmal davon ausgehen, dass es (ohne Optimierung) byteweise kopiert, bei der union nicht. Und es erscheint mir etwas lesbarer. Die union wird hier https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/Optimize-Options.html ja sogar als Positivbeispiel
-
Thread
Software Serial für mega644
Ich nutze bisher das Beispiel von https://rn-wissen.de/wiki/index.php/Software-UART_mit_avr-gcc um Daten zu senden und zu empfangen. Beim Wechsel auf einen 644 stoße ich an meine Grenzen. Senden klappt. Beim Empfang ist RX an Pin PB0. Das ist jetzt aber nicht mehr der ICP (InputCapture-Eingang
von TCNT, dann kann man das ja herausrechnen (ist wohl abhängig von der Compiler-Einstellung für Optimierung). Dann bleibt nur noch die (eventuelle) Unwägbarkeit anderer ISRs sowie von Programmteilen mit gesperrtem Interrupt.
-
Thread
1-Wire mit _delay_us: Kann das gut gehen, wie lang ist _delay_us wirklich?
mich langsam ob das überhaupt zu Ziel führt. Ein Interrupt im µs-Bereich ist zu schnell, unter C und GCC ist der Atmega dann nur noch in der ISR und hängt da fest. Vielleicht ist ja auch etwas ganz anderes an meinem Ansatz falsch, hab mal die .c & .h angehangen. Atmega32, GCC, Geany, AvrDude, DS1820
Hey, die Optimierung ist an und ich übergebe an _delay_us() nur Zahlenwerte also weder eine Variable noch sonst irgentwas. Die _delay-Funktion geht bei mir auch sonst, allerdings habe ich damit noch nie ein so genaues
-
Thread
ARM Blue Pill STM32F103 ChanFat StdperiphLib SD Treiber gesucht!
weil das eben eine IDE ist, die eine eigene Umgebung mitbringt. Vermutlich hat er das als normales GCC Projekt geschrieben mit make File, Linker File usw. ohne eine IDE sondern rein Konsole. In Kürze: ChanFatFs Treiber für SD Karten Datei mmc_stm32F1.c kompiliert unter EmBitz IDE 1.1. durch benutz
Zeug läuft langsamer ..... wenn der Compiler nicht optimiert oder wenn er es nicht rafft bei Optimierung da ausreichend Inline-Code draus zu machen.
-
Thread
parallele Prozesse konkurrieren um Peripherals
Ein Softcore ohne gcc oder llvm frontend ist einfach unbrauchbar, viel zu exotisch. Aber das willst du ja nicht hören.
State-of-the Art, was gut verifizierbare Stackmaschinen (Safety...) mit anstaendigem Compilersupport (GCC, LLVM) angeht. Das Rad mit den Tools will man nicht neu erfinden..
-
Thread
C++ in C Umschreiben
überschrieben werden, weil sie abstrakt (ohne Code) sind. Inline hat eher etwas mit Performance-Optimierung zu tun, das kannst du erst mal außen vor lasen.
wo die C/C++ Grenze verlaufen soll. Oder auch das ganze Ardiuno- und Wire-Zeugs portieren. Mit GCC kann man gemischte C/C++ projekte machen.
-
Thread
STM32 USB Übertragungsproblem mit Code von S.F.
dann geht uns jetzt beiden wieder besser :-) Spiel grad mit der Compiler-Optimierung rum: sobald die Optimierung ausgeschaltet ist, läuft die Sache. Bei -Os (size) gehts mit max. 10 chars, bei -O3 enumeriert das device nicht korrekt.
Alex schrieb im Beitrag #6630997: > Spiel grad mit der Compiler-Optimierung rum: > sobald die Optimierung ausgeschaltet ist, läuft die Sache. > Bei -Os (size) gehts mit max. 10 chars, > bei -O3 enumeriert das device nicht korrekt. Das nützt nur leider keinem was,
-
Thread
Eagle noch gefragt?
zwar wieder ein Jahr Wartungsvertrag, aber den will keiner verlängern. Als Compiler wird auch ein GCC benutzt, kein Keil oder IAR. Nur, um mal mit so'n paar Mythen über "Chefs" aufzuräumen.
Stelligen liegt - hat man gewonnen. Bloß keinen Rückfragen dazu, keine Veränderungen, keine Optimierungen, keine Vorschläge (bestellen Sie doch 120 St pro Quartal anstelle wie bisher 10 pro Woche, dann bekommen Sie besseren Preis weil der Mindermengenzuschlag wegfällt... NEIN). einfach Fresse halten
-
Thread
RIP AtmelStudio
Wegen Microchip und avr-gcc nochwas. Nachdem Microchip 5000,- Dollar für die avr-gcc Backend Modernisierung gespendet haben, werden die sicherlich "etwas wieder" haben wollen. So schnell wird das also nicht sterben.
(von Keil?) und seitdem kann XC8 bis PIC18 aber eben mit eingeschränkter Optimierung. PIC sind im wesentlich 3 grundverschiedene Architekturen. Wenn man AVR dazu zählt, sogar 4. Johann L. schrieb im Beitrag #6591318: > XC8 für AVR ist doch auch ein avr-gcc? Haben die
-
Thread
Wird if Schleife ignoriert, wenn sie nie eintritt?
Es würde dich noch mehr wundern, wenn du wüsstest, wieviel Aufwand die Compilerbauer in die Optimierungen gesteckt haben und immer noch stecken, und was die alles können. Ungennutzen Code entfernen ist allerdings eine der Basis-Optimierungen überhaupt, das gibt es schon seit ewigen Zeiten. Oliver
if-Abfrage komplett heraus? Mal was zum Thema: Wenn der Compiler mit einer entsprechenden Optimierungs-Option (-O bzw. -O2) gestartet wurde, kann er solche if-Abfragen schon wegoptimieren- sowohl wenn debug == true oder debug == false gesetzt wird. Allerdings musst Du ihm schon etwas unter die
-
Thread
Code in den Atomic Block verschleppt
tmp[2]; *pI2CBuff++ = tmp[3]; } [/c] Was macht der Compiler (avrgcc 5.4.0, Optimierung -Os) daraus? [code] 16e: 2f b7 in r18, 0x3f ; 63 170: f8 94 cli 172: f7 01 movw r30, r14 174: ee 0f add r30, r30 176: ff 1f adc r31,
Andreas R. schrieb im Beitrag #6588720: > Weiß jemand wie man das verhindern > kann??? Neueren gcc verwenden? Mein kleines Testprogrämmchen mit gcc 10.1 hat das Problem nicht. Wobei es vermutlich sehr vom nicht gezeigten Code drumherum abhängt, was der gcc draus macht. Ich würde es mal so probieren
-
Thread
ARM Cortex M4 Assembler
chris_ schrieb im Beitrag #6586996: > Weiß jemand, wie man aus dem GCC einen Assembler Abschnitt aufruft und > wie die Parameterübergabe aussieht? Mit Inline Assembler kannst du alles so aufrufen, wie es dir beliebt. https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html
Der gcc arbeitet auch mit Assembler Files .s Ich benutze das bei einem Bare-Metal Projekt für den Startup-Code. https://stackoverflow.com/questions/7190050/how-do-i-compile-the-asm-generated-by-gcc gcc
-
Artikel
MCURSES
und myApp.c. Damit nicht verwendete mcurses Funktionen auch nicht im Binary landen bzw. weitere Optimierungen zwischen der mcurses-Bibliothek und der eigentlichen Applikation vorgenommen werden, sind folgende zusätzlichen Compiler-Optionen für den avr-gcc (ab Version 4.7.2) sehr zu empfehlen: -Os -flto
gc-sections Diese Optionen können mehrere 100 Bytes im Binary einsparen. Dabei muss auch dem Linker das Optimierungs-Flag -Os mitgegeben werden - auch wenn das ungewöhnlich erscheint. Dies liegt daran, dass der Linker bei Verwendung von LTO (-flto) auch nochmal im zweiten Durchgang den Compiler aufruft. Fehlt
-
Thread
AVR C Programmierung unter Linux
/gcc.gnu.org/onlinedocs/gcc-7.5.0/gcc/AVR-Options.html "Support" auf Compilerebene bedeutet nur, dass avr-gcc eine Specs-Datei für das Device mitliefert — und natürlich dass die Familie unterstützt wird
vielleicht deren MPLAB X IDE? Soweit ich weiß hat µChip 2 AVR-Toolchains im Angebot: Einen avr-gcc und im XC8 einen verkrüppeltem avr-gcc, wo man für Freischaltung aller Optimierungen blechen muss. Hab ich aber nie verwendet oder getestet oder mir angeschaut, von mir hommt da nichtmal Halbwissen
-
Thread
Linux und avr-libc3 installation
Überblick z.B. hier: https://www.mikrocontroller.net/topic/477852#5917698 Zum Testen [pre]avr-gcc main.c -o main.elf -mmcu=attiny2317[/pre] und dann das ELF mit avrdude o.ö. auf den µC uploaden. Um zu kontrollieren ob die richtigen Tools, Libs, Start-Up etc. genommen werden, zusätzlich -v angeben
Map-File (mit -Wl,-Map,main.map in main.map), ... bewerten. Asm-Ausgebe liest sich besser mit Optimierung (-Os), /ohne/ Debug-Info (kein -g* bzw. -g0) und evtl. mit Quellen als Asm-Kommentar (-fverbose-asm, ab v7).
-
Thread
Probleme in C - kann kein EEPROM
Datei entfernt), meiner eigenen Historie nach wurde dieser Fehler am 04.06.2013 gefixed. Zur Optimierung von C-Compilern: so ein ganzer Vollidiot, wie er im Buche stehen soll, ist das beileibe nicht (das war es vielleicht mal in den 80ern), der gcc macht da keinen so schlechten Job. Viele Grüße
Hans W. schrieb im Beitrag #6711672: > Ähm... ‘#pragma GCC optimize’ bekannt??? nein, aber danke dafür! https://www.boecker-systemelektronik.de/Seite-/-Kategorie-1/Vorsicht-bei-Compiler-Optimierungen
-
Artikel
Zeitgesteuerte Pflanzenbewässerung
= Software = Die Software ist komplett in C geschrieben und mehr auf Einfachheit als auf volle Optimierung ausgerichtet. Das erklärt auch dass die 4K des Atmega48 randvoll sind. Alle Einstellungen ausser der aktuellen Zeit und dem aktuellen Wochentag werden im EEPROM abgespeichet und sind nach einem
Eagle Schema und das PDF sind hier: Bewaesserung_HW_V1.0_2010_04_24 Software. C-Source Code für AVR-GCC und die vorkompilierte HEX Datei für einen ATmega48 sind hier: Bewaesserung_SW_V1.0.3_2010_10_09
-
Thread
STM32: Umstieg von IAR auf den neuen CUBEIDE
also ich würde beim IAR bleiben, da der gcc Compiler ja wohl nicht so optimal ist. Debuggen kanst du das Program ja mit verschiedenen Debuggern wenn du .elf File erstellst. Also ich wundere mich manchmal schon, was für ein Overhead aus dem gcc
embedded-studio/ Sascha schrieb im Beitrag #6576830: > also ich würde beim IAR bleiben, da der gcc Compiler ja wohl nicht so > optimal ist. Die Unterschiede sind was die Compiler Optimierung angeht tatsächlich heutzutage gar nicht mehr so groß.
-
Thread
C Ringspeicher
-Wl,--gc-sections compiler.c.elf.cmd=avr-gcc [/c] PS: Dieses kommt auch zum Einsatz: (bevor noch Fragen kommen) [c] compiler.warning_flags.all=-Wall -Wextra [/c] Andreas M. schrieb im Beitrag #6567561: > "-funit-at-a-time" -funit-at-a-time
ISO C99 Abschnitt 6.5.9.6 Pointervergleiche gilt auch für Funktionspointer. Es gibt darüber in den gcc, clang mailinglisten diverse Diskussionen. Der Compiler wird es bei Optimierung so lösen, dass er an der Symboladresse der zweiten Funkion ein Sprung auf den Einsprungpunkt der ersten legt oder ein
-
Thread
uCTest: unit test framework
1 ), 2 ); }[/c] Das kann dann übersetzt und (bisher) in simulavr ausgeführt werden. [code]$ avr-gcc -o simple.elf simple.c -L ./uctest-master/build -l uCTest -I ./uctest-master/include -mmcu=atmega328 $ simulavr -d atmega328 -f simple.elf -W 0x20,- -e 0x21 ; echo $? Running main [==========] Running
( 1 << 6 ) ), ".*x <= maxRes.*failed." ); EXPECT_LT( sqrt_u16( 24 ), 5 ); }[/c] [code]$ avr-gcc -Os -std=gnu99 -o simple.elf simple.c -L ./uctest-master/build -l uCTest -I ./uctest-master/include -mmcu=atmega328 $ simulavr -d atmega328 -f simple.elf -W 0x20,- -e 0x21 ; echo $? Running main
-
Artikel
Mini2440
, dass man den Compileraufruf anpassen muss. Wenn man eine Cross Toolchain installiert hat und nur gcc auf der Kommandozeile eintippt, wird man höchstwahrscheinlich beim lokalen gcc, keinem Cross-Compiler, landen. Überprüfen kann man das mit $ which gcc Die FriendlyARM Toolchain macht es uns da sehr leicht, sie verwendet aussagekräftige Namen für ihre Programme. Bei ihr wäre der gcc Aufruf der: $ arm-linux-gcc oder $ arm-none-linux-gnueabi-gcc Ich gehe im kompletten Artikel davon aus, dass man eine funktionierende Toolchain installiert hat, welche über arm-linux-... zu erreichen
-
Thread
union verwenden in c
Wert; *Byte = 0xAB; *(Byte + 1) = 0xCD;[/c] Edit: Für mich hört sich das nach verfrühter Optimierung durch den TO oder nicht eingeschalteter Optimierung des Compilers an. Also: 1. Prüfen was der Compiler draus macht => erzeugter Assemblercode 2. Prüfen, ob eine Einsparung an anderer Stelle einfacher
gegenüber einem IN-Befehl. Die PUSH/POP-Arie der zusätzlichen Register nicht mit eingerechnet. Der AVR-GCC ist manchmal auch erstaunlich schlau. Wenn er feststellt, daß alle Variablen schon zur Compilezeit bekannt sind, kann er die ganze Arie durch ein LDS ersetzen.
-
Thread
SDCC Inline Assembler zur Laufzeitoptimierung
besser, wenn es nur 2 oder 3 Fälle gibt. Vielleicht kann man bei deinem Compiler auch eine Optimierung einschalten?? Selbst mein gcc liefert meist besseren Code.
-
Thread
Wann kommt auch IAR EWARM im neuen Jahrtausend an?
Arbeitgebern und Hobbys beim gcc aus. Kann man den da reinbauen? Ist denn der eigene Linker so machtvoll wie der vom gcc oder clang? Der Linker vom IAR ist ja auch eine Zumutung, der kann im Vergleich zum gcc linker fast garnichts
Embedded Studio. > In der Firma kennt man sich dann eher von vorherigen Arbeitgebern und > Hobbys beim gcc aus. > Kann man den da reinbauen? > Ist denn der eigene Linker so machtvoll wie der vom gcc oder clang? > Der Linker vom IAR ist ja auch eine Zumutung, der kann im Vergleich zum > gcc linker fast
-
Thread
ATTINY 433MHz Fuchssender mit akustischem Grillen-Sound
kleiner > geht es nicht So ist es! Welche Compiler version hast du verwendet? Setzt das Optimierung Os voraus, oder macht gcc das bei dir immer? Ich bin echt überrascht ...
version hast du verwendet? Alt. WinAVR20100110. (Never change a running system). > Setzt das Optimierung Os > voraus, oder macht gcc das bei dir immer? Ich bin echt überrascht ... Ob Voraussetzung dafür weiß ich nicht, ich nutze immer Os. Gerade ausprobiert: mit O0 und O1 macht er's umständlich.
-
Thread
c++ 11/14/17?
pin; void write(bool level) { HAL_GPIO_WritePin(&gpio, pin, level); } [/c] Das erzeugt bei GCC mit Optimierung (inkl. LTO) optimalen Code, _wenn_ das Pin Objekt als const angelegt wird. Dies klappt auch, wenn das Objekt in andere Objekte via Konstruktor injiziert wird. Dummerweise failed der
noch keiner das Gegenteil beweisen. interessant schrieb im Beitrag #6543016: > Das erzeugt bei GCC mit Optimierung (inkl. LTO) optimalen Code, wenn > das Pin Objekt als const angelegt wird. Das ist jetzt aber nicht dein Ernst? Und dann HAL_xx Aufrufe? Noch schlimmer gehts nicht. Ich greife
-
Thread
_delay_ms Faktor 13 zu langsam
> Ah richtig, das hatte ich vergessen zu erwähnen: -Os wird verwendet. Das ist die falsche Optimierung.
Die richtige Optimierung ist, kein delay zu verwenden.
-
Thread
Wofür Propeller von Parallax ?
frontends/c/cgram.y frontends/c/cgram.y: Warnung: 3 Schiebe/Reduzier-Konflikte [-Wconflicts-sr] gcc -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/lexer.o -c frontends/lexer.c gcc -MMD -MP -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/symbol.o -c symbol.c gcc -MMD -MP -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/ast.o -c ast.c gcc -MMD -MP -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/expr.o -c expr.c gcc -MMD -MP -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/dofmt.o -c util/dofmt.c gcc -MMD -MP -g -Wall -I. -I./build
-
Thread
ASM-Code und C in einem Programm
Lass das doch vom Compiler erledigen: https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html
können 1000 Jahre alte Steinplatten entziffern aber kaum noch digitale Medien seit 1980. Zur Optimierung gefällt mir immer wieder: https://www.youtube.com/watch?v=7FeqF1-Z1g0
-
Thread
Kosmos CP1 Emulator mit ATmega
dem es um die Befürwortung des Hobbys als Freizeitbeschäftigung ohne Fokus auf wirtschaftliche Optimierung ging, liest sich doch ganz anders: "Und den halben Tag eine Schnur ins Wasser hängen um einen Fisch rauszuholen? Bei meinem Stundenlohn kann ich besser die Metro leerkaufen. Aber irgendwie
Sinn eines Hobbys ein anderer, oder?" O. R. schrieb im Beitrag #6536668: > wirtschaftliche Optimierung ging, liest sich doch ganz anders: Und die Aussage kann man nur mit Referenz auf Deinen astronomisch hohen Stundenlohn machen? Klingt für mich nach Prozerei.
-
Thread
C++, virtual, inline, Fehler wenn ich abstrakte Basis-Klasse entferne
Compiler so alt ist, könnte das daran liegen. Da hat sich in den letzten Jahren schon einiges an den Optimierungen getan. Oliver
so alt ist, könnte das daran liegen. Da hat sich in > den letzten Jahren schon einiges an den Optimierungen getan. > > Oliver ich darf nur C++03, mein Testkompiler ist aber x64 mit aktuellem VS2019
-
Thread
Dateien verschieben in C
Arduino Fanboy D. schrieb im Beitrag #6517085: > Und z.B. bei gcc -O0 gar nicht zur Geltung kommt Benutzt du diese Einstellung??? Arduino Fanboy D. schrieb im Beitrag #6517085: > Der > Optimizer entscheidet das anhand seiner Regeln. Das mag ich nicht, wenn
Code-Instanz eine eigene Inkarnation im Programmspeicher. Das ist (fast) immer schlecht für eine Optimierung auf minimale Codegröße, aber im Gegenzug oft sehr gut für eine Optimierung auf Geschwindigkeit. Das Grundprinzip ist simpel. Verdammenswürdig ist nur, dass der Compiler sich erfrecht, die letzte
-
Thread
Assembler wo sind eigentlich diese ganzen Genies??
emplace() eine Template-Funktion ist und braucht deswegen den extra Hinweis. Die Fehlermeldung von GCC war "expected primary expression instead of >")
volatile uint8_t* pin = &PINB;[/c] usw, was aber kein gültiges C++ ist. Gemeinerweise akzeptiert GCC v5 solchen Code, aber v6+ quittiert ihn mit einer Fehlermeldung. > Manchmal ist C++ aber auch zum Haare raufen +1
-
Thread
warum keine performantes sincos als opcode?
. Ich habe bisher nur die Zeiten von aktuellen VS2017,VS2019 clibs, glibcs nebst aktuelle clang,gcc 10+ und Intel unter Linux,Windows angeschaut, und die Intel IPP, kann ich die Takte irgendwo im Vtune sehen oder muss ich die im Assemblercode abzählen?
Johann L. schrieb im Beitrag #6495890: > * GCC kennt __builtin_sincos Gerade mal folgenden Code compiliert [c] void d_sincos (double x, double *sin_x, double *cos_x) { __builtin_sincos (x, sin_x, cos_x); }[/c] Mit gcc v4.7 -O2 -ffast-math
-
Thread
Welches strlen ist schneller?
der String Länge. - Der Microsoft cl.exe compiler stolpert manchmal über seine eigenen Optimierungen. Die Compiler eigenen Builtin Funktionen sind mit der -O2 Optimierung eingeschaltet. Leider sind diese "Intrinsic" Funktionen langsamer als die Funktionen der MS Runtime MSVCRT...
5_forloop_cl_15.exe 6656 test_6_strlen_scasb_cl_15.exe 6656 test_7_strlen_forloop_gcc_9.exe 43008 [/pre] Der Mingw gcc linkt noch mit seinen eigenen Supportlibs, und die Exe hat 11 (!) Sektionen, keine Ahnung was da der macht... Alle exe sind ohne Debugging Infos, und gestrippt
-
Thread
Welches strcpy ist schneller?
Ich fände einen Vergleich mit strlen interessanter. Weil da mehr Spielraum für Optimierung des Algorithmus besteht. Bei strcpy muss jedes Zeichen kopiert werden. Untere Schranke für die Komplexität ist also O(n). D.h. die Optimierung beschränkt sich allein auf die Details der Rechnerarchitektur
#6489398: > Ich fände einen Vergleich mit strlen interessanter. Weil da mehr > Spielraum für Optimierung des Algorithmus besteht. Bei strcpy muss jedes > Zeichen kopiert werden. Untere Schranke für die Komplexität ist also > O(n). D.h. die Optimierung beschränkt sich allein auf die Details der >
-
Thread
Anfängerfrage AVR GCC
Johann L. schrieb im Beitrag #6488746: > GCC zum Beispiel meckert main ohne finales return ebenfalls nicht an es gibt ja nicht nur GCC, mein Text war eben beispielhaft für alles was mir schon begegnet ist! Es gibt auch noch Compileroptionen
function main shall not be used (3.2) within a program. [...] [/pre] Und was C angeht, hat avr-gcc eine Optimierung, die Aufrufe von main im Endeffekt UB machen, es sei denn man verwendet -mno-main-is-OS_task, siehe http://gcc.gnu.org/gcc-8/changes.html#avr Logischerweise darf main dann auch
-
Thread
Welches memcpy ist schneller?
bis zu 24 Bytes / Takt, die for Schleife gerade mal 0.8 Bytes / Takt (sofern nicht die AVX2 Optimierungen angemacht werden). Mehr Infos zum Timing sind im Anhang. [c] #if SOLUTION == 0 /* dumb C solution */ void* testcpy(void *dst, void *src, size_t len) { size_t n; BYTE *p
Zielarchitektur dann wirklich ASM (in der Implementierung) nutzen? *) Siehe z.B. https://github.com/gcc-mirror/gcc/blob/master/libgcc/memcpy.c
-
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 ))