-
Thread
Probleme bei Debugging von GCC mit AVR Dragon
Möglichkeit, die DWEN-Fuse wieder zurückzusetzen. Scheinbar gibt es ein Problem mit dem Objektfile beim GCC. Ich habe die Option -gdwarf-2 gewählt. Dann sollte doch das generierte .elf File verwendet werden, oder? Ich habe das Makefile und die Compiler-Meldungen für ein kleines Testprogramm angehängt.
Ich findeschon das er verwandt ist: Ich habe Probleme beim debugging von GCC mit AVR Dragon - Kommunikation wird nicht mehr aufgebaut
-
Thread
Wie Array-Size bekannt machen
Problem mit AVR-GCC: Ich hab ein Array in einem Objekt. Nun müssen aber auch andere Objekte wissen, wie groß das Array ist. Gibt es dafür ne andere Lösung, außer daß ich die Einträge immer abzählen muß und dann ins
en.wikipedia.org/wiki/Const_correctness#Loopholes_to_const-correctness Aber keine Ahnung, wie der momentane GCC das handhabt...
-
Thread
Interrupts beim LPC2138
Funkioniert das? [c] void wait(unsigned long zeit) { while (zeit > 0) zeit--; } [/c] GCC neigt ja dazu, solchen Code komplett wegzuoptimieren.
@Andreas Ja, das tut, ist GCC v4.1.1 Aber die Optimierung des GCC kann manchmal schon zu bösen Überraschungen führen.
-
Thread
lpc23xx und GNU Compiler
Hallo, ich möchte für den lpc2388 zu entwickelnden C-Code mit dem kostenlosen GCC Compiler unter Windows kompilieren. Könnt ihr mir hierfür weiterhelfen, was ich dabei alles beachten muss ? - Gibt es unterschiedliche Implementierungen des GCC Kompilers ? Falls ja unterscheiden
aber gut leben, zumal ich praktisch nichts davon verwende. Codesourcery baut ARM spezifische Optimierung in den GCC ein. Diese Verbesserungen landen früher oder später aber auch im regulären GCC. Das jeweils neueste Relase des GCC zu verwenden ist vielleicht keine so gute Idee. Aktuell ist derzeit
-
Thread
Preprozessor / Rechnen
berechnet > oder im Programm?? Weder noch. Sie wird im Compiler berechnet. Eingeschaltete Optimierung vorausgesetzt. > 2 Wozu wird 0.5 adierrt ?? Rundung zum nächstliegenden ganzzahligen Wert. Konvertierung von Fliesskommawerten zu Ganzzahlen rundet nicht sondern schneidet den Nachkommaanteil
Konstante ist -- wovon ich mal ausgehe -- dann wird der Ausdruck vom Compiler ausgewertet. Zumindest macht GCC das so, nennt sich dann "Faltung der Konstanten". AFAIK gehört die Konstantenfaltung zu den Optimierungen, die auch bei deaktivierter Optimierung gemacht werden. Falls XTAL nicht zur Compilezeit
-
Thread
Error 2 R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in.
avr\lib\avr51\libc.a(cmpsf2.o)||In function `__lesf2':| c:\winavr-20100110\bin\..\lib\gcc\avr\4.3.3\avr51\libgcc.a(_lt_sf.o):c:\avrdev\gcc\build-avr\avr\avr51\libgcc\..\..\..\.\gcc\fp-bit.c|1287|first defined here| ||=== Build finished: 1 errors, 1 warnings ===| [/code] Mfg Philipp
/avr/bin/../lib/gcc/avr/4.4.4/avr5/libgcc.a(_mul_sf.o) [..]/x-chains/avr/bin/../lib/gcc/avr/4.4.4/../../../../avr/lib/avr5/libc.a(fp_powsodd.o):../../../libm/fplib/fp_powsodd.S:69: relocation truncated to fit: R_AVR_13
-
Thread
24 Bit signed effizient verarbeiten
> verwenden oder ist das ganz viel zu unausgereift/böse/nicht portabel? Geht das auch mit avr-gcc? ich hab mal alles unter /usr/lib/avr nach int24 gegrept, aber nix in der Form int24 gefunden...
hunderte oder tausende Datensätze verarbeiten will. http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
-
Thread
Welche Programmiersprache soll ich lernen?
unbekannten Programmiersprache anfangen wollen. In der zweiten Zeile steht dann: "It uses the GCC AVR tool chain and will be compatible with GCC regarding calling conventions etc." Aus offensichtlich pragmatischen Gründen orientiert sich FPC an der GCC-AVR-Tool-Chain. Dagegen ist ja im Prinzip nichts zu sagen, aber dann kann ich doch genau so gut direkt bei *allen* GCC-Werkzeugen, einschließlich des C-Compilers, bleiben. rhf P.S.: Die Art und Weise des "Inline-Assemblings" finde ich allerdings deutlich schöner gelöst als im GCC-C-Compiler. http://wiki.freepascal.org
-
Thread
rechnet der preprocessor in C gcc (AVR) multiplikation aus?
Peter II schrieb im Beitrag #4120985: > Joachim B. schrieb: >> rechnet der preprocessor in C gcc (AVR) Multiplikation aus? > > nein, dafür ist er nicht zuständig In BASCOM ist das mal wieder super einfach: Const Mul = Const1 * Const2 / Const3 ... Ich wollte schon mit GCC anfangen, weil
0; } [/c] der Präprozessor macht daraus [c] ... int a = 3 * 4; ... [/c] und der gcc, ganz ohne Optimierungen [code] ... 400535: c7 45 fc 0c 00 00 00 movl $0xc,-0x4(%rbp) ... [/code] 3*4 wird also ausgewertet zu 12, bzw. 0xc
-
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
Float anschauen
2. noch der 3. Vorschlag sind standardkonform, wobei die Verwendung einer Union wie im Vorpost mit GCC funktioniert, aber nicht unbedingt mit anderen (standardkonformen) Compilern.
kriegt ist das > außerdem extrem ineffizient. Dann ist aber auch der Compiler extremer Murks. gcc muß es noch nicht mal wegoptimieren, da es eh komplett im Compiler implementiert ist. Das heißt, daß es selbst bei ganz ausgeschalteten Optimierungen nicht zu einem Funktionsaufruf kommt. Ich habe
-
Thread
Long(Int) -> ASCII Umwandlung
(ulong2ascii dann natürlich). sonst für leute die noch an anderen sachen zum thema coding/optimierung interresiert sind kann ich nur die vorher schon erwähnte seite http://www.df.lth.se/~john_e/ und noch www.hugi.de (bes. coding constest und die special edition) empfehlen! marcel
programmierung eines z.b. komprimierungsalgorithmus ist es schon nicht schlecht hier und da ein paar gute optimierungen selbst zu schreiben. da kann man schon etwas zeit sparen. also ich finde das bringt auch was bei 'großen' cpus, also die von pcs, auch schon gut was
-
Thread
ATmega48 Programmspeicher zu klein?
Peter Dannegger schrieb im Beitrag #3570763: > Dann hast Du die falsch Math-Lib gelinkt oder Optimierung aus. Das bei dir nur 49.4% belegt sind ist sehr wunderlich. Wie kann ich den überprüfen welche Math-Lib ich gelinkt habe bzw. wie kann ich sie dann ändern? Mit der Optimierung habe ich auch
Welches AVR-Studio benutzt Du denn? In den Compileroptionen muß ein -lm stehen. Die Optimierung sollte -Os sein.
-
Thread
Speicherverbrauch bei Funktionsaufrufen (Funktion in Funktion)
Compiler eine verschachtelte Schreibweise der Aufrufe "entschachtelt". Bei einem simplen Test rief avr-gcc beispielsweise mit Optimierung verschachtelt auf, ohne nicht.
push, pop, call, ret) nur auf > den SRAM möglich, also nicht auf MMIO. Dummerweise liegen bei AVR-GCC auf dem Stack nicht nur die Return-Adressen, sondern auch die lokalen Daten. Und die werden ganz normal geschrieben.
-
Thread
winavr und das RAMPZ Register bei XMegas
Mechanismen dafür sorgt, daß Objekte nicht über Segmentgrenzen hinweg liegen. Das einzige, was avr-gcc für dich erledigt, ist daß das ganze IRQ-sicher ist: Im Prolog/Epilog der ISRs wird RAMPZ gesichert/restauriert falls Z verwendet wird. Ich seh auch nicht, daß sich das in absehbarer Zeit in avr-gcc
] Die Optimierung rechnet damit, dass Z bei einem Überlauf wieder auf 0x0000 steht. Soweit sogut, aber bei einem XMega führt dieser Überlauf halt zu einem Inkrement des RAMPZ Registers (alles in hardware) und damit
-
Thread
Optimale Auswertung von Rückgabewerten
unterschiedlichen Dateien stehen (das Ganze ist ein rudimentärer Scheduler). Bei meinen Versuchen mit gcc und switch hat er nie eine Tabelle angelegt - vielleicht liegt das daran, dass meine Einträge nicht bei 0, sondern meistens erst bei den ASCII-Zeichen "0" oder "A" anfangen. Unter welchen Optimierungs-Einstellungen
ijmp .data .section .progmem.gcc_sw_table, "ax", @progbits .p2align 1 .L11: .data .section .progmem.gcc_sw_table, "ax", @progbits .p2align 1 rjmp .L3 rjmp .L4 rjmp .L5
-
Thread
Warum sind nicht verwendete Funktionen im Build enthalten?
welche Sections weggelassen werden und erhalte folgende Ausgabe: [code]... c:/winavr/bin/../lib/gcc/avr/4.3.3/../../../../avr/bin/ld.exe: Removing unused section '.text.test1' in file './trunk/FR_CONTROL.o' c:/winavr/bin/../lib/gcc/avr/4.3.3/../../../../avr/bin/ld.exe: Removing unused section '.text.test2
nimm halt -O0 statt -Os oder -O1, -O2, -O3. Oder besser: Wenn du debuggen willst schalte die Optimierung komplett ab.
-
Thread
Atomic-Variable etc. - ich verstehe fast nur Bahnhof
dass man sie auf Single-Core Systemen *ohne* Cache (also Cortex-M3/4) weglassen könnte, das weiß der GCC nur anscheinend nicht.
den Compiler klar, dass sich die Variable jederzeit ändern kann und er kommt nicht auf die Idee Optimierungen durchzuführen, die zu beschädigten Daten führen. "Volatile" garantiert aber keinen atomaren Zugriff. Ob der Zugriff atomar ist, hängt von einigen Randbedingungen ab. Am besten schaut man ins
-
Thread
AVR gcc: Funktionsparameter werden überschrieben
mitverfolgen, wie der Wert kaputt geht. (von 0x0795 über 0x07ab zu 0x00ab) Kompiliert wurde mit [code]avr-gcc -funsigned-char -funsigned-bitfields -O3 -fpack-struct -fshort-enums -g2 -DDEBUG -Wall -c -std=gnu99 -MD -MP -MF "$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -MT"$(@:%.o=%.o)" -mmcu=atmega88 [/code] Ich bin
stets mit der Option -O0 zu debuggen. Es sei denn, das Problem tritt nur bei einer bestimmten Optimierungs-Stufe auf.
-
Thread
Stack Überschreiber beim Rechnen mit uint64_t
Das ist http://gcc.gnu.org/PR29524
GCC ist freie Software. Jeder der möchte, und dem das Thema wichtig genug ist, kann dort mit Bugfixes, Optimierungen und Erweiterungen beitragen. Wem __udivdi3 nicht zu pass ist, kann sich auch selbst
-
Thread
womit füllt atmel bit shift (>>) die neuen bits auf?
lss-file > postest? Genau, zeige uns den generierten Assembler-Code und nenne uns die verwendete GCC-Version.
[code] ..... -O1 .... [/code] und da wunderst du dich, dass der gcc nicht vernünftig optimiert?
-
Thread
Memory Usage in Data Segment by __clz_tab??
habe ich mal einen Blick ins .map File geworfen. .data 0x00800060 0x0 /usr/lib/gcc/avr/4.2.1/avr5/libgcc.a(_pac$ .data 0x00800060 0x100 /usr/lib/gcc/avr/4.2.1/avr5/libgcc.a(_clz$ 0x00800060 __clz_tab .data 0x00800160 0x0 /usr/lib/gcc/avr/4.2.1/../../../../avr/li$ .data 0x00800160 0x0 /usr/lib/gcc/avr/4.2.1/../../../../avr/li$ Ohne wirklich etwas zu verstehen, sieht es so aus, als würde etwas das __clz_tab heisst
-
Thread
Ist Linux das Richtige für mich?
gibts zwar auch verschiedene Compiler. In der Regel verwendet dort aber jeder C/C++-Programmierer den gcc. Dieser gehört bei jeder bekannten Distribution zum Lieferumfang.
aber gewaltig im Irrtum. Ohne Anpassung der Modezeilen ging > da gar nichts (ich rede hier von Optimierung und nicht von 'mir genügt > ein Bild'; ich bin da pingelig ;)). Ich dachte, wir reden hier von der Erstinstallation eines Anfängers. Optimierung kommt später, wenn das System schon läuft.
-
Thread
unter C die Funktion Sleep() nutzen
Deklarier i als volatile, dann darf der compiler nix wegoptimieren. Der GCC lässt leere Schleifen stehen, der icc macht sie öfters mal weg. Compiler speziell für uC dürften bei weitem nicht so gut optimieren.
I_ H. wrote: > Der > GCC lässt leere Schleifen stehen, ... Schon ein ganzes Weilchen nicht mehr. Die sind schneller weg, als man gucken kann.
-
Thread
ARM, GCC, Linker-Skripts
nur dann, wenn Du damit im Betrieb das Flash beschreiben willst. Readonly-Phänomen: Wenn man beim GCC Variablen deklariert, die man aber nur lesend verwendet, dann schnallt GCC das und setzt die automatisch als read-only, auch ohne const. Das ist lästig, wenn man sie ganz bewußt nicht als const markiert
nicht nutzt (oder nicht sichtbar nutzt), die aber nicht wegoptimiert werden sollen. Da hilft beim gcc dann das __attribute "used".
-
Thread
Würde gerne Assembler in C umschreiben, aber ich blick's net
könnte? "Application Binary Interface" Erste und einzig Sichere Referen sind die Compiler-Quellen $GCC_SOURCE/gcc/config/avr/avr.* Ein bissl steht bestimmt auch im avr-gcc Tutorial hier und in http://www.roboternetz.de/wissen/index.php/Avr-gcc/Interna#Registerverwendung >> Das T-Flag könnte
, alte SIGNAL oder INTERRUPT mit dem guten, alten > avr-gcc 3.4.6. Zu GCC 4 kann ich keine Tipps geben. Das hat nichts mit der GCC-Version zu tun, wohl aber mit der avr-libc-Version. Ist generell keine gute Idee, neu hinzu kommenden Nutzern die Verwendung
-
Thread
Arithmetik in C
drauf. Als letztes könnte ein Blick auf den erzeugten Assemblercode noch hinweise auf mögliche Optimierungen bringen. PS: Irgendwie sind 2KB Flash fast immer zu wenig :-D
"PS: Irgendwie sind 2KB Flash fast immer zu wenig :-D" Volle Zustimmung, zumindest beim AVR-GCC. Deshalb nehme ich eigentlich immer den ATMega8, der kann sogar schnell multiplizieren. Ich weiß jetzt nicht, wie das bei den kommerziellen Compilern ist. Durch den 16Bit-Befehlssatz und
-
Thread
Überlauf geht verloren
reinen Betrachtung auf C Ebene. Oder muss er sich an den Auswirkungen orientieren? Dann dar er die Optimierung nicht durchführen, weil sie ja nicht den identischen Effekt hat. In der Tat eine gute Frage.
Betrachtung auf C Ebene. > Oder muss er sich an den Auswirkungen orientieren? Dann dar er die > Optimierung nicht durchführen, weil sie ja nicht den identischen Effekt > hat. > > In der Tat eine gute Frage. Darauf wollte ich eigentlich nicht hinaus. Der GCC wird REG |= (1 << const) als sbi übersetzen
-
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
Laden des Hexfile in VMLab schlägt fehl.
:0A86CE0000000D0A0D0A00740400FC :00000001FF Im GCC Output steht: Webserver_MEGA32.elf : section size addr .text 34174 0 .data 346 8388704 .bss 1056 8389050 .debug_aranges
die Version 1.14 bei Ulrich gezogen und compiliert. Hier die Adressen aus meinen HEX Files AVR-GCC 4.1.2 0x7B9C passt ACR-GCC 4.3.0 0x843E passt nicht Gewaltiger Unterschied. Compiliert mit dem gleichen makefile.
-
Thread
ATmega8 und LCD HD44780 nur erste Zeile leuchtet
Problem mit HD44780kompatiblen LED. Ich habe auf meinem ATmega8 das Beispielprogramm aus dem AVR GCC-Tutoial laufen lassen. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung Leider zeigt das LCD nur in der erste Zeile voll angesteurte Balken. Wenn ich das Programm aus
Es ist auch egal welches meiner baugleichen LCDs ich verwende. Angeschlossen ist es genau wie im GCC-Tutorial beschrieben --> an Port D?
-
Thread
Timeout über Zeitkritische Funktion
routine zugreift und es ggf. ändert). Aber das wird wohl daran scheitern, dass man keine register in C (GCC) reservieren kann, oder?
Daniel G. schrieb: > Wie kann ich denn ein Register reservieren in C mit GCC? [c]register uint32_t myflag asm("r2");[/c] Dummerweise funktioniert register...asm nicht zusammen mit volatile. Kann also sein, dass der Optimizer die Zugriffe dann wegoptimiert. Dann solltest
-
Thread
Atmel MC; ATTiny45/85 Alternative mit mehr Flash - 16kByte, Rest möglichst gleich, stromsparend,.
jede Bitvariable long long verwenden, die Optimierung einschalten (-Os) und keinen Copy&Paste-Monstercode, sondern Unterfunktionen mit Parametern.
AVRStudio zeigt doch nach dem Build immer an, wieviel Flash und SRAM belegt werden. Bzw. für den AVR-GCC macht das avr-size.exe.
-
Thread
Taster abfragen UND dann.
Björn wrote: > noch jemand da?? RTFM! [[AVR-GCC-Tutorial]]...
ja bringt auch nix, kompilieren hat es sich ja vorher gelassen. jetzt kommt dauernd dieser GCC-plugin-error wegen dem *.elf
-
Thread
Funktionen in mehrere c files auslagern funktioniert nicht
machen. Aber es klappt einfach nicht, egal wie ich es mache. Ich nutze das aktuellste AVR-Studio mit gcc(WINAVR). Ich habe etliche Forumsbeiträge dazu gelesen und auch den Artikel in der Sammlung, aber irgendwie scheine ich auf dem Schlauch zu stehen. Klappt bei mir alles nicht. Auch habe ich im AVR-Studio
problem, aber sowas "void delay_x10ms(uint16_t count);" brauchst nicht mehr. In der neuen Version von GCC wird das automatisch gemacht, sobald die übergebene Zahl zu groß ist.
-
Thread
Arduino Uno R4: Besonderheiten und Abhilfen
nützt die schnellste CPU nichts. Wie immer gilt. https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
nein - ist sie nicht > > Wie immer gilt. > > https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung Vielen Dank für den Link, lese ich ersteinmal. Viele Grüße Kai
-
Thread
Arduino - Speicheroptimierung?
> Speicheroptimierung Vor Optimierung erfolgt erst mal Profiling um rauszufinden, wo wann warum wieviel Speicher verbraucht wird. Darauf basierend kann dann u.U. Optimierung erfolgen. Als erstes findest du also heraus, selche Komponenten
Binäre Sketchgröße: 29.376 Bytes 48 Byte im flash verloren und 2 Byte im data verloren, tolle Optimierung.
-
Thread
[avr-gcc]. post-increment Version von avr/pgmspace.h
); k = pgm_read_byte (p++); v = pgm_read_byte (p++); [/c] Und freu dich an dem Code, den avr-gcc daraus macht. Der Königsweg neuer (Target-abhängiger) Qualifier wie "flash" oder "pgmspace" wird gcc -- wenn das überhaupt jemals unterstützt wird -- nicht in absehbarer Zeit liefern. Damit gingen
}; char bar (const pgmspace mytype_t * p) { return p->c + p->string[4]; } [/c] und gcc könnte die passenden Dereferenzierungen erzeugen. Zurzeit gibt es nur ein Attribut, keinen Qualifier.
-
Thread
MCU (ds30F6012A) defekt?
im Beitrag #1743588: > Will ich wohl meinen, der aktuelle dsPIC Compiler von microchip ist ein > GCC ;) Wer da den CCS nutzt, dem kann man nicht helfen :D ?? Microchip hat einen GCC für die dsPIC? Wie sieht bei dem die Code-Optimierung aus? generiert er aus einem Switch MIT defualt-cases und beliebigen
goto end_switch; end_switch: [/c] Und ja, es müssen doppelte '&&' sein. Doku dazu: http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Labels-as-Values.html Andreas
-
Thread
msp430 einsiteg
spricht nichts gegen IAR. Manche ziehen das ressourcenhungrigere, aber etwas modernere CCE vor. Der GCC für MSP430 (MSP-GCC) ist eine gute Wahl, wenn man große Projekte realisieren will oder bereits Erfahrung mit dem AVR-GCC hat. Allersings weiß ich nicht, ob der eZ430-Stick unterstützt wird, im Zweifelsfall
verschiedene Voreinstellungen, was den Optimierungsgrad betrifft. Meistens ist bei Release eine höhere Optimierung eingestellt, wie Rufus schon sagte. Aber auch da sollte man erst prüfen, ob der Code noch wie gewünscht läuft. Es gibt durchaus Konstellationen, wo hoch optimierter Code nicht so läuft, wie man
-
Thread
AVR: Delay Time stimmt nicht
eingestellt, dadurch wird eine andere Taktquelle benutzt. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 Die Optimierung im Compiler muss eingeschaltet sein.
8.0- MHz; Start-up time:1k + 4.1ms ) Falk Brunner schrieb im Beitrag #3033875: > Die Optimierung im Compiler muss eingeschaltet sein. Steht auf -Os
-
Thread
Problem bei Erweiterung des ARRAY_SIZE(x) Hilfsmakros
durchziehst! Als Compiler bzw. Entwicklungsumgebung verwende ich gerade meinen Arduino. Ansonsten immer GCC der mit dem Atmel Studio mitgeliefert wird. Ich weiß aber nicht genau ob diese das "const" als Optimierung ansehen? Fakt ist, dass beim Kompilieren (Arduino) die größe des Programms mit den "const
> Als Compiler bzw. Entwicklungsumgebung verwende ich gerade meinen > Arduino. Ansonsten immer GCC der mit dem Atmel Studio mitgeliefert wird. > Ich weiß aber nicht genau ob diese das "const" als Optimierung ansehen? Dann sparst du durch das const erst mal kein RAM ein. Hier wird const so
-
Thread
for Loop in C / die 10000ste dumme Frage
HW-Loop nutzen. Nutzt man den Schleifenzähler für Operationen in der Schleife, werden solche Optimierungen aber verhindert.
#Oliver S. schrieb im Beitrag #6157343: > Im Falle eines mingw-x86_64-gcc auf Windows 10 z.B. ein unsigned char. Da > ist es also schonmal nichts mit einem schnelleren 32-Bit-Typ. Ich glaube, auf x86 ist 8 Bit auch nicht langsamer als 32 Bit. Bei 16 Bit sieht's wohl anders
-
Thread
Merkwürdige Compileroptimierung, wo liegt (mein) Denkfehler
laufen, wird der Code um 20Byte länger und alles scheint zu stimmen. Was ist hier los? Compiler: AVR-GCC-4.8.0, Optimierung -s, Target ATMEGA8 Harald
In http://gcc.gnu.org/gcc-4.8/changes.html steht geschrieben: "GCC now uses a more aggressive analysis to derive an upper bound for the number of iterations of loops using constraints imposed by language
-
Thread
Look-Up Table wie speichern
Konstanten gefaltet werden (ok, bei volatile eh kein Thema mehr). > Dafür muß du aber keine frühere GCC haben, die unbedingt PROGMEM braucht > und __flash nicht versteht. Mit progmem kann man das gleiche Interface implementieren wenn man denn will. __flash gibt's seit avr-gcc v4.7. Ohne __flash-Support
schrieb im Beitrag #5938616: > Auf den Thread neulich wurde ja schon verwiesen. Konkret für avr-gcc > lässt sich get_mem_unused() von hier nutzen: > > https://rn-wissen.de/wiki/index.php?title=Speicherverbrauch_bestimmen_mit_avr-gcc#Dynamischer_RAM-Verbrauch Ich hab das eben überflogen und
-
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
Klarstellung fuer Anfaenger
Beim AVR ist der einzige wesentliche Unterschied der fehlende MUL-Befehl bei den ATtiny. Aber der AVR-GCC weiß das. > Da > ich Assembler ehrlich gesagt vermeiden wollte soweit es geht, sprach > mich der AVR mit der (angeblich) guten Unterstuetzung durch gcc an. Ja, der AVR-GCC ist uneingeschränkt
Versuch wert sein. Wie gesagt, so hab ich angefangen. Als Software noch WINAVR (hat den avr-gcc Compiler und das IMHO sehr gute programmers Notepad dabei) und zum Flashen Ponyprog. Wenn du keinen Assembler willst und ein bisschen C kannst ist das perfekt. zu den PICs sag ich nix ;-)