-
Thread
Parity mit AVR-ASM: Stimmts, gehts schneller?
avr-gcc verwendet in der libgcc Code, der den Weg zu einer 9-Tick Version zeigt: http://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/config/avr/lib1funcs.S?revision=219188&view=markup#l2976 [avrasm] ;; r24 =
machen > können! Frag Moby, der kann das. Oder den Autor fragen, das Patch ist da: https://gcc.gnu.org/r175097
-
Thread
Gibt es CPU Architekturen in dem ein signed int nicht überlaufen kann?
sehr effektiv bei Overflow eine Exception erzeugen. Standard-C ist eben etwas anderes, obwohl dem GCC die Idee nicht ganz fremd zu sein scheint: https://codeforces.com/blog/entry/73183
einfach ist, überhaupt ein konsistentes Verhalten zu > implementieren. Insbesondere auch bei Optimierungen. Wenn sich der Compiler auf ein bestimmtes Verhalten festlegen muss, dann muss dieses auch unabhängig von jeglicher Optimierung immer gleich sein. Das kann das Potenzial für Optimierungen deutlich
-
Thread
kurze Frage zur Optimierung
> Aber was macht der Compiler? Werden diese 4 Zahlen zur Laufzeit > verodert? Nicht wen Optimierungen an sind. > Oder sieht der Compiler, dass es sich um Konstanten handelt > und verodert sie gleich wärend des Kompilierens? Ja. Aber wie Joachim schon schreibt: Schau doch einfach selber
lex schrieb im Beitrag #2583668: > Aber was macht der Compiler? Der Compiler (GCC) faltet diese Konstante, und zwar auch bei ausgeschalteter Optimierung (-O0).
-
Thread
Doku für Warning / Error messages?
Problem hast, dann frage konkret (sinnvollerweise auch mit dem zugehörigen Quellcode-Schnipsel) hier im GCC-Forum.
Compiler bleiben. Es gibt absolut keinen Grund, warum du selbst solche vermeintlichen Low-Level Optimierungen von Hand machen musst oder sollst. Im schlimmsten Fall, so wie hier, trickst du dich damit nur selber aus. Im besten Fall hast du eine Optimierung erzielt, die der Compiler auch ohne dich hinkriegen
-
Thread
Linux auf dem Rückmarsch
Maschinensprache übersetzt, ist das eine Abkürzung für "Assemblersprache". Zum Beispiel arbeitet der GCC meines Wissens mit maschinenunabhängigem Zwischencode, auf dem er Optimierungen durchführt, bevor er maschinenspezifischen Code generiert. Natürlich kannst Du nun hingehen und z. B. die "Register
das eine Abkürzung für > "Assemblersprache". Ja, das ist so. > > Zum Beispiel arbeitet der GCC meines Wissens mit maschinenunabhängigem > Zwischencode, auf dem er Optimierungen durchführt, bevor er > maschinenspezifischen Code generiert. ..auf dem er wiederum Optimierungen durchführt und
-
Thread
Tangens sprengt die Codemenge
Bezüglich AVR-GCC ist für float ein 2kB-Chip völlig untauglich, ein 4kB absolutes Minimum und erst ab 8kB wirklich sinnvoll. Ich war es vom 8051 her gewohnt, float auch auf MCs mit 2kB Flash (AT89C2051) einzusetzen
Bisher hat es noch keinen interessiert aber ich sag es dir gerne: Compiler: AVR Studio 4.14 mit AVR GCC plugin Controller: AT90S2313 ja ich weiß den gibt es nicht mehr aber ich habe halt noch welche rum liegen.
-
Thread
(No)-Aliasing for fun and performance
all-alias-typen char (und Typaliase dafür) und std::byte verwenden. Für die Spielfreudigen: https://gcc.godbolt.org/z/QMQW2c Oder die Datei im Anhang verwenden.
> im char*. Mehrstellige Funktionen sind böse, aber Output-Parameter sind ok? Und fehlende Optimierungen aufgrund von aliasing ist das kleinste Problem mit char*.
-
Thread
Avr-gcc Bitshift 32bit Variable geht nicht
return 1; }[/c] Ich habe mir ein Testprogramm geschrieben: Atmel Studio 6.2 im Simulator. Optimierung ausgeschaltet, aber keine Änderung bei aktivierter Optimierung. [c] for(uint8_t i=0;i<30;i++) { if((i%2) == 0) { ret[i] = RinoBus_Fifo_Write(&f,i|(1<<8)); }else {
[[AVR-GCC-Codeoptimierung]]
-
Thread
Arduino Bit Shifting Problem
OK: AVR-GCC9.2.0, Optimierung = Os [avrasm] uint8_t MirrorByte ( const uint8_t ToMirrorByte ){ 52: cf 93 push r28 54: df 93 push r29 56: 30 e0 ldi r19, 0x00 ; 0 58:
AVR-GCC9.2.0, Optimierung = O3 [avrasm] uint8_t MirrorByte ( const uint8_t ToMirrorByte ){ uint8_t MirroredByte = 0; for (uint8_t BitNr = 0; BitNr < 8; BitNr++){ cc: 83 2f mov r24, r19
-
Thread
Kürzungsmöglichkeiten?
Optimierung nach (Code)Größe
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html#Optimize-Options
-
Thread
Wurzelfunktion für 16bit Fixed Point Werte
erwischt habe. 50 Ticks für ne 16-bit signed-Multiplikation ist immer nocht stolz. Du hast Optimierung aktiviert? > Johann L. schrieb im Beitrag #2256412: >> Ich hab nicht auf's Interface geschaut, ist das avr-gcc ABI? >> Wär sinnvoll... > > Als Neuling kann ich damit auch net so viel anfangen
Beitrag #2257503: > 50 Ticks für ne 16-bit signed-Multiplikation ist immer nocht stolz. Du > hast Optimierung aktiviert? Nein Optimierung ist nicht aktiv. Die Multiplikation ist allerdings auch eine Assembler Routine (32bit = 16bit*16bit). Die Zeit zum Aufrufen (Registerzuweisungsgeplänkel von gcc) ist
-
Thread
eigene "printf-Funktion" mit variabler Argumenten Liste
Da wirst du wohl den Hersteller /deines/ Compilers fragen müssen (der ja ganz offensichtlich kein GCC ist).
in dem Header stdarg.h abgearbeitet. Kann es sein das ein Complier nur in der von dir genannten Optimierung darüber fällt und sich etwas ungeschickt ausdrückt.
-
Thread
AVR-GCC: Compilerfehler?
Hallo erstmal, ich hab jetzt mit dem AVR-GCC angefangen, aber wenn ich mir so das Ergebnis anschaue, dann kommen mir Zweifel. Ich hab mir 2 Warteschleifen geschrieben, in der .lst-Datei sehen die dann so aus: void lcd_delay_5ms() { uint16_
Danke. Solche "Optimierungen" hätte ich nicht erwartet. mfg werner
-
Thread
SWAP in GCC
Geht mit inline Assembler: http://www.roboternetz.de/wissen/index.php/Inline-Assembler_in_avr-gcc#swap_Nibbles
in den Fällen zur Laufzeit durchgeführt wird, in denen es eigentlich nicht nötig wäre. Es gibt bei gcc einen Trick, um auch diese Optimierungen zu ermöglichen. Der geht so: [C] static inline unsigned char swap (unsigned char x) { if (__builtin_constant_p(x)) x = (x << 4) | (x >> 4)
-
Thread
Optimizer Warnung bei SDCC
Code mit eingeschalteter Optimierung nicht läuft, dann ist er fehlerhaft (= verstößt gegen den Standard).
Rabe schrieb im Beitrag #3731765: > Wenn Code mit eingeschalteter Optimierung nicht läuft, dann ist er > fehlerhaft (= verstößt gegen den Standard). Bei korrekt arbeitenden Compilern muss das so sein. Bei GCC wohl keine Frage. Bei SDCC würd ich das aber nicht unterschreiben
-
Thread
Compilieren mit anderer AVR-GCC Version liefert "falsches Ergebnis"
neuen Rechner gekauft - AMD 64 - und habe ein aktuelles Ubuntu laufen. Mit dem Ubuntu kam der avr-gcc 4.5.3 Vorher hatte ich den avr-gcc 4.3.5. Mit dem neuen Rechner, neuen Ubuntu und dem neuen avr-gcc habe ich mein Projekt wieder compiliert. Es gibt keine Fehlermeldungen und das hex, elf usw
du hast zu 99% einen Fehler im code und durch neue Optimierungen wirken sie sich jetzt aus. immer schön auf volatile und atomic operationen geachtet?
-
Thread
Mikrocontroller Auswahl C++ Unterstützung, CAN, I2C, Open Source Compiler
diese einfach aus dem Quelltext entfernt: https://github.com/chipKIT32/chipKIT-cxx/blob/master/src48x/gcc/gcc/config/pic32/mchp.c
Compiler ohne > Einschränkungen gibt. Copy and Paste von oben... Der PIC32-Compiler ist der gcc. http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html Quelltext downloaden, patchen, übersetzen. https://github.com/chipKIT32/chipKIT-cxx/blob/master/src48x/gcc/gcc/config/pic32
-
Thread
printf-Alternative für AVR
setzen: [c] buf[INT_MAXWIDTH]='\0'; [/c] Aber bei AVR GCC ist das meines Erachtens nach immer überflüssig, auch wenn man nicht mit der Arduino-IDE programmiert und diverse Parameter und Optionen für Compiler und Linker anders setzen kann. Daher habe ich es
y); break; case 3: printf("PLOP %d\n", z); break; } } while(0); } [/c] Mit AVR-GCC 4.7.2 ist sub1 228 Bytes und sub2 112 Bytes groß. Die vermeintliche Optimierung hat die Codegröße also mehr als verdoppelt. Das liegt u.a. daran, dass in sub1 die Variablen x, y und z, die in Registern
-
Thread
Welche 32-Bit uC-Familie ist empfehlenswert?
mir vor vielen Jahren mal Microchips Compiler für deren 16-Bitter angesehen. Der war zwar auf Basis GCC, hatte aber eine spezielle Optimierung drin, die nicht Teil des veröffentlichten Quellcodes war. Die war in ein separates Programm ausgelagert. Obendrein hatten sie jenes Programm, das die diversen
(prx) A. K. schrieb im Beitrag #7389478: > Der war zwar auf Basis GCC, hatte aber eine > spezielle Optimierung drin, die nicht Teil des veröffentlichten > Quellcodes war. Die war in ein separates Programm ausgelagert. Selbst wenn das nicht mehr so ist, und selbst
-
Thread
Assembler und gcc
überhaupt schlägst, dürfte an den teilweise für den AVR nicht mehr so guten ,,besonders schlauen'' Optimierungen liegen, die GCC 4.3 offensichtlich vorrangig für unsere Desktop-Maschinen mit ihren registermäßig verkrüppelten Prozessoren vornimmt: um die Variable i nicht in einem Register führen zu müssen
movw r30, r24 _SCAN(SCAN_SIZE) ret [/avrasm] Übersetzt wird das dann zB per [pre] avr-gcc -mmcu=atmega8 -c -Os scan.c -DSCAN_SIZE=100 -o scan.o avr-gcc -mmcu=atmega8 -c scan-asm.S -DSCAN_SIZE=100 -o scan-asm.o avr-gcc -mmcu=atmega8 scan.o scan-asm.o -o scan.elf avr-objdump -d scan.elf
-
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
Optimierung des neuen AVR Studios schlechter
eigentlich 2) Assembler und die übersetzen genau das, was im Source steht. Womit compilierst Du also? GCC (WinAVR)? Gleiche Version wie damals? WinAVR ist nicht Bestandteil des AVR-Studio. Gruß aus Berlin Michael
Hast du überhaupt unter Projekt die Optimierung angeschaltet? Das hat bei mir dann auch erstmal für Erstaunen gesorgt... Mit freundlichen Grüßen, Valentin Buck
-
Thread
Unterschied JAVA & C++
Das kann man keineswegs so pauschal sagen. Die Laufzeitumgebung von Java ermöglicht diverse Optimierungen, von denen C++ nur träumen kann; zB dass das Java Programm immer für den CPU des Nutzers optimiert (just-in-time kompiliert) wird und diesen somit optimal nutzt, während die meisten C++ Programme
Das kann man keineswegs so pauschal sagen. Die Laufzeitumgebung von Java > ermöglicht diverse Optimierungen, von denen C++ nur träumen kann; zB > dass das Java Programm immer für den CPU des Nutzers optimiert > (just-in-time kompiliert) wird und diesen somit optimal nutzt, während > die meisten
-
Thread
Assembler Code in Cprogramm
Joachim B. schrieb im Beitrag #4115605: > Die Compiler Optimierung -OS ist mir da nie begegnet oder wo ich sie > einstellen kann -Os ist standandmäßig aktiv.
^= 1<<PB0; [/c] Wenn die Lesbarkeit oder Portierbarkeit drastisch leidet, hat bei mir die Optimierung ihre Grenzen.
-
Thread
uC führt Code nicht aus, wenn in if-Abfrage zuvor zu viel Code ist?
bisschen größer ist, es funktioniert! Aber warum verhält sich ein Programm bei unterschiedlichen Optimierungen komplett anders? :O
K. schrieb im Beitrag #3615789: > Aber warum verhält sich ein Programm bei unterschiedlichen Optimierungen > komplett anders? :O Häufigstes Problem: du hast ein "volatile" vergessen und der Compiler optimiert anders...
-
Thread
Einstieg 32Bit µC - Welche "Familie"
aber leider limitiert. Soweit ich weiß, schon in der Größe, aber auf jeden Fall, was sowas wie Optimierung angeht. Das ist wohl für die meisten Hobbyisten ein großes Manko. Der M3 wird offiziell vom GCC unterstützt und weiterentwickelt, daher keine Abhängigkeit vom Hersteller. Für mich wäre das ein
@Andreas K.: Probier mal: arm-none-eabi-gcc -o hello hello.c -T arm.ld -Wl,--gc-sections
-
Thread
SOUNDRX - Datenübertragung/Bootloader PC -> µC über PC-Soundkarte
unbedingt merken. Ich werde das mal hier hinzufügen: http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung
Neue Version 1.4.0 ist online. Änderungen: - Optimierung der Schaltung: Pullup-Widerstand am Transistor wegoptimiert, übernimmt nun der ATmega. - Optimierung des Bootloaders: Der Bootloader wurde von der Größe her auf unter 1KB reduziert
-
Thread
i7-9850H oder i9-8950HK
das *restrict* Keyword in C. Das brachte ca. 10% an Performance, aber nur wenn die Link Time Optimierung nicht verwendet wird. Mit der Link Time Optimierung (/GL bei MS oder -lto bei gcc) braucht man das restrict nicht, der Compiler/Linker erkennt das dann automatisch. Ok, das war ein kurzer
kann, um die Muliplikationen und Additionen *parallel auszuführen. >> >> In der Praxis war der Gnu gcc Compiler der einzige, der es halbwegs >> schaffte, das brachte auch einen Faktor 3 an Geschwindigkeit. > > Der aktuelle Intel Compiler (icc 19.0) macht da bei mir auch AVX Code > draus. Clang 9
-
Thread
AVR-GCC: Was ist denn an diesem Code so schlimm?
delay.h: 1.: Parameter müssen konstant und zur Compiler-Laufzeit bekannt sein. 2.: Die Compiler-Optimierung muss eingeschaltet sein. Steht alles auch in der libc-Dokumentation. Übrigens: Falsches Forum...
www.nongnu.org/avr-libc/user-manual/index.html Warteschleifen http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 Die Idee mit der mehrfachen Schleife ist prinzipiell OK. Eine andere Lösung statt Zeitvertrödeln wäre ein Timer.
-
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
C++ auf einem MC, wie geht das?
://gcc.gnu.org/wiki/LinkTimeOptimization
Anspruch ist ja, daß meine Bibliothek eine ebenso effiziente Programmierung ermöglicht wie C mit dem GCC als Referenz. Daher konzentriere ich mich bei Feinheiten wie der Optimierung auf den GCC. > Ich sehe 3 möglichkeiten: > 1) die klassen nicht Instanzieren > 2) als constexpr declarieren > 3)
-
Thread
Frage zur Bitmanipulation
O-Registeren als Bitnummern statt als Bitmasken zu definieren. Dann kam der C-Compiler in Form des GCC 3.0. Anfang machte der noch keine CBI/SBI/SBIC/SBIS-Optimierung. Diese Instruktionen waren nur per Inline-Assembler verfügbar, deswegen hat man auch hier die Bitnummern gebraucht, da auch der C-Compiler nicht ohne weiteres in der Lage ist, Bitmasken in Bitnummern umzurechnen. Dann kam der GCC 3.3 mit CBI/SBI/SBIC/SBIS-Optimierung. Nun brauchte man keine Bitnummern mehr. Da sich aber schon alle an den Umgang mit den Bitnummern gewöhnt hatten und keiner Lust hatte, bestehenden Code von
-
Thread
Debbuging Modus funktioniert nicht wie er sollte (AMTEL Studio 7)
hi, ... gcc optimization/simulation - das verhalten kenne ich. ist eigentlich ganz logisch, weil wenn der gcc rum optimiert, wie soll dann der c source code noch dazu passen?! da stimmt dann auch kein breakpoint
" zu gehen. majortom schrieb im Beitrag #5202682: > ist eigentlich ganz logisch, weil wenn der gcc rum optimiert, wie soll > dann der c source code noch dazu passen?! Mal ausprobiert - für das Beispiel? Ja, ich kenne die Optimierungs-Probleme auch, deshalb habe ich mal gespielt.
-
Thread
C-Compiler selbstgeschrieben.
Maschine) nicht wirklich schwer. Das ist straight-forward. Richtig schwer wird es dann, wenn Optimierungen gemacht werden sollen, die über die einfachsten Formen der Optimierung (Constant-Folding, Common Subexpression Elimination, Multiplikationen durch Shift ersetzen, Divisionen durch & u. dgl.) hinausgehen. Sobald Optimierungen über mehrere Statements bzw. mehrere Funktionen hinweg greifen sollen, wirds aufwändig. Mehrere Statements gehen noch, indem man eine Funktion als ganzes als einen Baum darstellt, aber darüber
-
Thread
Zeta SBC V2 Z80 mit Floppy Disk
K. schrieb: >> freies Unix für Z80, das mit SDCC kompiliert wird. > > Ich warte lieber bei der GCC mal den Z80 unterstützt. Keine Ahnung wieso > das nicht gemacht wurde. > > Der SDCC ist schnarch langsam, wenn man die Anzahl "Nodes" auf eine > vernünftige Zahl einstellt, […] Der GCC verwendet
anders funktioniert als gewohnt. Das fängt schon damit an, dass es keine einzelne Objektdatei wie bei gcc oder cc65 gibt. Philipp Klaus K. schrieb im Beitrag #6855866: > Der aussichtsreichste Weg, diese Optimierung zu ermöglichen, dürfte > sein, in SDCC die Unterstützung der GNU binutils als Assembler
-
Thread
Blinklicht zu hohe Frequenz
- Optimierung beim Compiler aktiviert? - Wie viel schneller ist denn eine "viel höhere Frequenz"?
Das Ganze gibt es hier auch auf deutsch: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29
-
Thread
Tiny2313 Probleme beim Compilen
Exception caught (code = 0xc00000fd, addr = 0x4217b3) Build succeeded with 0 Warnings... Message: gcc plug-in: make() Target successfully built gcc plug-in: PlugInUtility::getExternalHeaderFiles Dependency directory does not exist (F7) Build: Build started 9.11.2008 at 12:55:23 make: Interrupt
Exception caught (code = 0xc00000fd, addr = 0x4217b3) Build succeeded with 0 Warnings... Message: gcc plug-in: Error: Object file not found on expected location C:\Users\Tollerteppich\Desktop\AVR-Studio\Servotester\default\Servotester.elf gcc plug-in: PlugInUtility::getExternalHeaderFiles Dependency
-
Thread
C ohne if() - in einzelnen Fällen möglich?
Bei komplizierteren Bitpermutationen: __builtin_avr_insert_bits https://gcc.gnu.org/onlinedocs/gcc/AVR-Built-in-Functions.html
der Prozessorhersteller aber bis heute immer noch auf seine mistigen proprietären Compiler statt auf GCC oder LLVM setzt und immer noch damit kämpft, überhaupt mal den Standard einzuhalten, gehe ich nicht davon aus dass er übers simpelste hinausgehende Optimierungen hinbekommt. EAF schrieb im Beitrag
-
Thread
WinAVR vs. Atmels Toolchain
Jörg Wunsch schrieb im Beitrag #1924050: > AVR-GCC ist ein GCC, der für das "target" AVR konfiguriert worden ist. Ist was über die Atmel-Strategie bezüglich avr-gcc bekannt? D.h. werden sie, wie es bisher mit WinAVR war, auf (gepatchte) FSF-Quellen
Aus der Unwissenheit heraus gefragt ... Würde es Sinn machen nur einen aktuelleren Compiler bzw. GCC einzusetzen. Ich habe allerdings trotz Hinweise auf der GCC-Webpage keine GCC binaries für Windoof gefunden...
-
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
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
gcc 4.0.0 erzeugt schlechteren Code
Hallo! Ich hab einen Codevergleich zw. gcc 3.4.1 und 4.0.0 gemacht. Hier zuerst der Code aus 3.4.1: void wait (uint16_t zeit) { f6: 9c 01 movw r18, r24 f8: 01 c0 rjmp .+2 ;
Sieht nach Optimierung für Laufzeit statt Codegrösse aus. Schon mal nach einem Schalter dafür gesucht - immerhin hat der gcc davon eine ganze Menge?
-
Thread
Basic und/bzw. vs - C Erfahrungsumfrage
dazu bringen an AVR's angepasst zu sein, aber nicht umgekehrt. Nenn' doch mal ein paar der "C-Optimierungen".
... und die Optimierung dem Compiler überlassen. Ich halte es auch so.
-
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
SDCC 3.6.0 RC1
bisher keine Files hinterlegt. https://sourceforge.net/projects/z80gcc/
Christian J. schrieb im Beitrag #4974581: > Hier steht was davon, dass der GCC für Z80 portiert werden soll, Die Chance, dass der gcc jemals ein Z80-Backend bekommen wird, schätze ich als äußerst gering ein. Für den LLVM stehen die Chancen ein wenig besser, siehe z.B. https
-
Thread
Einfache Simulation klappt nicht richtig (AVR Studio)
Optimierung eingeschaltet. Oliver
Zuordnung zwischen Source- und Assemblercode mehr. Ich debugge im Simulator eigentlich immer ohne Optimierung, bis alles passt. Erst dann mit Optimierung. Oliver
-
Thread
struct list_head Funktionalität auf Cortex-M4 nutzen
play-with-kernel-list_head-three-examples-of-super-cattle.html Absatz: Example 1 Das offsetof() habe ich im arm-gcc compiler.h
awesome-c#data-structures Adam P. schrieb im Beitrag #6897700: > Das offsetof() habe ich im arm-gcc compiler.h offsetof ist ein Standard-Makro und in <stddef.h> definiert, wozu braucht es da noch arm-gcc-compiler.h ? Adam P. schrieb im Beitrag #6897662: > Niklas Gürtler schrieb: > >> Oder
-
Thread
AVR clock prescaler (CLKPR) und gcc-Codeoptimierung
Bit (CLKPCE) auf 1 alle anderen auf 0, im zweiten Zugriff stellt man den Teilungsfaktor ein. Mit avr-gcc code sieht das etwa so aus: [c] CLKPR = (1<<CLKPCE); CLKPR = 1;[/c] Sofern man Code-Optimierung benutzt (gcc Schalter -Os), funktioniert das auch wie erwartet, verwendet man keine Optimierung
prescalers wird einfach nicht geändert. Den Grund dafür kann man im Assemblerlisting finden. Mit Optimierung erhält man: [avrasm] ldi r24,lo8(-128) ; tmp44, out 70-32,r24 ; ,, tmp44 ldi r24,lo8(1) ; tmp46, out 70-32,r24 ; ,, tmp46[/avrasm] Ohne Optimierung wird daraus: [avrasm]
-
Thread
Benutzt hier jemand die Cortex-M4-FPU?
Bauform B. schrieb im Beitrag #6150758: > # DO NOT USE Mit -march=armv7e-m+fp baut der GCC FPU-Befehle auch in > reine > # DO NOT USE Integer-Funktionen ein. Also evt. auch in > Interrupt-Routinen! Nur wenn man ohne Optimierungen kompiliert. Du kannst die FPU auch beim Betreten der
r7 streut der GCC überall hin, selbst wenn r7 nicht verwendet wird. Weiss der Geier wieso. Aber das stört ja nicht, bei dem CPU Takt können die paar ns nichts ausmachen.
-
Thread
ab welchem AVR lohnt sich C statt asm?
bestimmte AVRs von vorn herein ausschließen? Kommt darauf an, welchen Compiler du benutzt. Der gcc unterstützt nur AVRs mit SRAM, d. h. einen AT90S1200 kannst du nicht verwenden. Von Imagecraft gibt es einen Compiler, der auch für AVRs ohne SRAM geeignet ist. Klar ist, dass du in diesem Fall aber
den vom C-Compiler erzeugten Code angesehen. Ich stimm dem oberen Zitat zu... Wenn man die Optimierung im AVR-GCC einschaltet, dann kommen da doch manchmal Sachen raus, die man selbst nicht bemerkt hätte. Gerade bei größeren Projekten mit vielen Variablen und so zeuch ist man mit einem Assembler-Projekt