Hi, irgendwo hab ich mal gelesen, dass bei einem Typedef eine ungerade
Speicherzuordnung
z.B.
char, int
durch so genannte stopfbits gefüllt werden, jetzt wollt ich wissen wie
man das Compilermäßig abstellt, und welche Nachteile ich mir da
einfahre,...
Leider find ich diese Quelle nicht mehr wo ich das gefunden hab, daher
meine Frage hier in die Runde.
Gerne auch eine Verlinkung, ich dachte nähmlich die Info hätt ich von
hier, aber nach stundenlangem Suchen gebs ich langsam auf,...
Hoffentlich weiß es jemand oder kennt die Quelle/Link
Gruß
mx
> Typedef eine ungerade Speicherzuordnung ... durch so genannte stopfbits gefüllt
werden
Können, nicht müssen. Da hängt vom Compiler und der CPU auf der das
Programm laufen soll ab.
> jetzt wollt ich wissen wie man das Compilermäßig abstellt
Handbuch des Compilers lesen.
> und welche Nachteile ich mir da einfahre,...
Im schlimmsten Fall Alignment-Probleme (dann sollte der Compiler
allerdings gar nicht erlauben das abzustellen). Ansonsten eventuell
Performance-Probleme.
Nein, das hat nichts mit typedef zu tun.
Was Du beschreibst, ist das sogenannte alignment, das auf 16- und
32-Bit-Architekturen für eine korrekte Ausrichtung von Variablen im
Speicher sorgt.
Viele 32-Bit-Architekturen können nur auf 32-Bit-Variablen zugreifen,
wenn sie an einer durch 4 teilbaren Adresse im Speicher liegen.
Sind in einer Struktur aufeinanderfolgend 32-Bit-Variablen und kleinere
Variablen angeordnet, werden vom Compiler "Füllbytes" an die kleineren
Variablen angehängt, damit die nächste 32-Bit-Variable wieder an einer
korrekt ausgerichteten Speicheradresse abgelegt wird.
Je nach Compiler und Rechnerarchitektur lässt sich das aber auch
deaktivieren, so beispielsweise bei MS-Compilern durch #pragma pack, und
beim gcc durch _attribute_ ((_packed_)).
Ich habs grad wieder gefunden,...
Stand im Buch "C-Programmierung für Embedded Systeme, Jörg Wiegelmann".
Jep Prformenceprobleme könnte es geben:
Vorteil der Füllmethode ist, dass Variablen immer bei geraden Adressen
starten, und so der Zugriff optimal für die Architektur ist. Wenn das
nun abgestellt wird, kann sich die Performance verschlechtern, da der
Controller evtl. umständlich auf die ungeraden Adressen zugreifen muss.
Und danke nochmal,...
Gruß
mx
Hallo MX,
das, was Du da tun willst, tut man nicht. Es ist nämlich inherent
unsicher.
Immer, wenn der Compiler mehrere Werte im Speicher hintereinander
platzieren muss, dann hat er alle Freiheiten dazu. Er kann also z.B. an
beliebigen Stellen Lücken lassen, er kann aber genauso gut auch die
Reihenfolge der Werte hintereinander beliebig vertauschen. Er macht
dies, um den besten und schnellsten Code zu generieren.
Wenn Du also einen ganz bestimmten Aufbau im Speicher erzwingen willst,
dann musst Du dem Compiler die Reihenfolge und den Lückenaufbau
vorschreiben. Bei manchen Compilern kann man das einstellen (die pragmas
order und packed werden häufig verwendet). Leider ist diese
Einstellmöglichkeit von Compiler zu Compiler unterschiedlich.
In der Regel tritt dieses Problem nur auf, wenn man mit Hilfe dieser
Strukturen mit anderer Hardware oder Software kommunizieren will. Dabei
ist es fast immer besser, die Daten als Bytearray aufzufassen und beim
Lesen/Schreiben mit einem Pointer und entsprechenden Parserfunktionen zu
arbeiten. Dann braucht man solche Krücken nicht, und der Code läuft
immer und überall.
Eine eigene Frage?
Dieser Thread ist über 18 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.