Durch inline kleinerer Code?

[FoCus]

wenn du einmal den winavrc-hexcode im AVR studio anschaust, kanst du sehen das dieser hex-code 99% eines assemblercodes ist.

Ähm kannst du mir ein Beispiel deiner restlichen 1% sagen!?
Bin eigentlich der Meinung dass das direkt in Maschinencode umgewandelt wird. Warum sollte da was wegfallen?

Aber irgendwie werden bei mir die Dateien dadruch kleiner?

Klar kann er dadurch kleiner werden. Da die Funktionen wie Makros direkt in den Code eingefügt werden, fallen eine Menge Befehle, die Für den Aufruf, bzw beim Aufräumen, einer Funktion nötig sind weg. Dadurch wird der Code kleiner.
Die Borland Hilfe sagt dazu:

C++-spezifische Schlüsselwörter

Syntax

inline <datentyp> <klasse>_<funktion> (<parameter>) { <anweisungen>;*}

Beschreibung

Das Schlüsselwort inline dient zum Deklarieren oder Definieren von C++ Inline-Funktionen.

Zu Inline-Funktionen macht man am besten nur kleine, sehr häufig aufgerufene Funktionen.

Allerdings ist ein Verhältnis von 2:1 schon recht heftig. Ein bisschen Code wäre klasse.


Gruss
Michael

[OldBug]

Die Größe der Hex-File kannst du als Maßstab nehmen

Das ist Falsch! Im .hex-File sind Angaben wie Adresse und Checksumme enthalten, deshalb ist das .hex-File wenig Aussagend, was die Größe im Flash betrifft. Im aktuellen WinAVR gibt es ein Script, welches die Auslastung des Memories durch statische Variablen und die des Flashs berechnet und Anzeigt.

[PicNick]

Das ist Falsch! Im .hex-File sind Angaben wie Adresse und Checksumme enthalten, deshalb ist das .hex-File wenig Aussagend, was die Größe im Flash betrifft

Was du nicht sagst.
Wenn du die Hex-files mal liest, wirst du sehen, daß alle Zeilen, außer der letzten (u. EOF), die größe 16 haben.
also filesize / 45 * 16 und ein paar zerquetschte, auf die wir aber pfeifen, weil's da um Programme geht und nicht um "Hello, world"
Wenn du die letzte adresse liest, kannst du es auch noch genauer sagen
Außerdem geht's hier um relative Vergleiche(standard, inline, optimizer, Compiler, etc) und dafür reicht's allemal.

[luma]

Also das ist komisch. Ich generier keine .HEX-Dateien sondern .BIN-Dateien...

[PicNick]

Na, noch besser. da hast du die Größe pur

[SprinterSB]

Zur Grösse: Bei WinAVR gibt's auch ein avr-size, das macht genau was ihr wollt

GCC 3.4.1 inlinet kleine Funktionen von selbst, auch grössere Funktionen werden geinlinet wenn sie nur 1x benutzt werden.
Ich compiliere mit -Os, und ein Blick auf den generierten asm-Code schadet nie...
Soll eine Funktion geinlinet werden, so kann das ein Kompiler nur dann gescheit machen, wenn sie als static deklariert ist. Daher ist es sinnvoll, die direkt im Header zu deklarieren, wenn sie in mehreren Modulen benutzt werden soll.
Eine Funktion als extern inline zu deklarieren ist nicht sinnvoll, denn der Compiler kann den Code einer solchen Funktion nicht kennen (es sei denn, er steht im gerade compilerten Modul).

Damit Funktionen, die inline stehen, nicht nochmal im .o auftauchen, gibt es den Schalter -fno-keep-inline-functions
Wird eine Funktion nicht geinlinet, obwohl man das will, warnt GCC bei -Winline.
inline generell deaktivierten sollte mit -fno-inline gehen und für eine Funktion mit __attribute__((noinline))

GCC hat übrigens eigene Kriterien, um zu entscheiden, ob eine Funktion es "wert" ist, geinlinet zu werden, so daß inline bzw __attribute__ ((inline)) nicht immer greifen. Drehen kann man an dieser Entscheidung mittels -finline-limit=<n>

Gruß, Johann

[luma]

Aha und wie mach ich ne .hex??

[pebisoft]

focus , schau dir die beispiele in winavr-c an, die als avrlibc-manual beiliegen, sind schöne vergleich drin. c++ verschwendet auch teilweise den asm-code. winavr-c ist kein c++.
mfg pebisoft

[lekro]

c++ verschwendet auch teilweise den asm-code.

Immer diese Vorurteile...
Prinzipiell ist kompilierter C++-Code erstmal nicht größer als gleichwertiger C-Code.

winavr-c ist kein c++.

Den Satz versteh ich nicht ganz. Natürlich ist "C" kein "C++". Aber C ist C, "winavr-C" gibt es in dem Sinne überhaupt nicht.

Man kann mit WinAVR auch C++ kompilieren (siehe FAQ, mal von einigen Einschränkungen und der fehlenden Standardbibliothek abgesehen).

[pebisoft]

man sollte dieses gute winavr-c nicht durch eingebaute c++ schnitzel versauen. ihr interpretiert in winavrc immer sachen hinein, da staune ich nur.
winavrc ist ein ganz normales standart c , da gibt es kein wenn und aber.
mfg pebisoft