Folgendes Problem uint_8 aucBuffer[SIZE_6] const uint_16 *puirets = NULL puirets = (uint16 *) &aucBuffer[0]; while (*puirets) { Zugriff Zugriff auf Werte } Ich sehe hier ein Problem mit einer möglichen ungeraden Adresse von aucBuf diese meinem Pointer übergeben werden kann. Bisher gab es keine Probleme jedoch "kann". Wie stelle ich sicher das mein aucBuffer auf einer geraden Adresse angelegt wird? Gibt es eine Pragma Option vom Compiler oder so?
Wie wärs hiermit:
1 | uint_16 Buffer[SIZE_6/2] |
2 | uint_8 *aucBuffer = NULL |
3 | const uint_16 *puirets = NULL |
4 | |
5 | aucBuffer = ( uint_8 *)Buffer; |
6 | puirets = (uint_16 *)Buffer; |
7 | |
8 | while (*puirets) |
9 | {
|
10 | Zugriff Zugriff auf Werte |
11 | }
|
>wiso SIZE_6/2?
Weil du für gleich viel Bytes nur halb soviel uint_16 brauchst, wie
uinT_8!
warum muss ich dann überhaupt den datentype wechseln? Irgendwie komme ich mit der Lösung nicht klar.
>warum muss ich dann überhaupt den datentype wechseln? >Irgendwie komme ich mit der Lösung nicht klar. Du hast hast ja das Beispiel mit dem Typenwechsel gebracht, ich weiss auch nicht wozu Du es brauchst!? Du hattest einen Array mit unit_8 Werten deklariert, definiertest einen uint_16 Pointer auf dies Array und fragtest zurecht, wie man eine gerade Anfangsadresse für den uint_8 Array garantieren kann! Mein Vorschlag ist nun das ganze umzudrehen: Deklariere einen Array mit uint_16 und definiere dann einen uint_8 Pointer auf dieses Array, so hast Du bestimmt gerade Adressen für die uint_16!
weil ich es wirklich nicht weis: Kann denn ein uint16 Zeiger nicht auf eine ungerade Adresse zeigen wenn diese explizit zugewiesen wird? Hab das bisher nie hinterfragt. Grüssle Hauspapa
Hauspapa schrieb: > Kann denn ein uint16 Zeiger nicht auf eine ungerade Adresse zeigen wenn > diese explizit zugewiesen wird? Das kann er, allerdings funktioniert dann eine Dereferenzierung nicht auf jeder Hardwarearchitektur. Auf denen, auf denen das geht, wird's langsam, auf denen, auf denen es nicht geht, kann es zu Hardware-Exceptions/-Traps kommen. Ein Beispiel für eine Architektur, die misalignment erlaubt, ist x86, eine, die es nicht gestattet, sind die verschiedenen ARMe.
Klasse antworten jetzt verstehe ich die Probleme besser. Es handelt sich um einen ARM, anbei. Möchte auf pragma verzichten da ich verschiedene prozessoren unterstüzen möchte und mit das ifdef gehändelt zuviel wird. Gibt es noch andere Lösungen? oder Ratschläge
#pragma hat den Vorteil, das der Compiler die Direktive ignoriert wenn er sie nicht kennt. Da brauchst du kein #ifdef. Wenn der Prozessor Alignment braucht, wird der Compiler das auch unterstützen.
Hauspapa schrieb: > weil ich es wirklich nicht weis: > Kann denn ein uint16 Zeiger nicht auf eine ungerade Adresse zeigen wenn > diese explizit zugewiesen wird? Hab das bisher nie hinterfragt. IM Prinzip kann er das natürlich. Aber wenn es auf einer Architektur wichtig ist, dass derartige Zugriffe ein bestimmtes Alignment aufweisen, dann wissen das die Compiler bzw Linker und platzieren die Variablen so im Speicher, dass genau das nicht passiert. Da dreht sich dann alles um: Dann muss man den Compiler extra dazu überreden, dass er das strikte Alignment aufgibt und keine Ausrichtung auf zb gerade Adressen macht. Wenn das die Compiler nämlich nicht machen würden, dann würde das extrem mühsam sein.
Alle Compiler, die ich kenne, machen es per Voreinstellung für ihre Zielhardware richtig. Sollte das mal nicht stimmen, wären compilerspezifische Anweisungen wie #pragma align (4) oder __attribute__((aligned(4))) angebracht. Das ist aber höchstwahrscheinlich in der Compiler-Doku beschrieben. Um welchen Compiler handelt es sich bei dir?
Heinz schrieb: > IAR Universal Linker V4.61 finde dort kein entsprechendes pragma Wieso Linker? Derartige Dinge sind Sache des COMPILERS! (Auch wenn sie letztendlich vom Linker erledigt werden) Ausserdem muss das nicht unbedingt #pragma heißen. Da gibt es viele Möglichkeiten. Allesamt herstellerspezifisch und somit in der Doku des Herstellers zu finden. Google mit "IAR ALignment" scheint ein guter Ausgangspunkt zu sein.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.