Forum: Compiler & IDEs Endian Formate


von Udo (Gast)


Lesenswert?

Hi

Im Manual stehen die Nummerierung der Bits der Register genau 
andersherum wie ich es vomAtmel kenne. Links ist die 0te Position, 
rechts die letzte:

 0 1 2 3 ...31 32
[                ]

Kann ich da jetzt wie gewöhnlich draufschreiben?

Reg = 0xA1;

Wie steht es dann drin. Eine dieser Möglichkeiten gibt es:

 0 1 2 3 ...31 32
[A 1             ]


 0 1 2 3 ...31 32
[           1  A ]

von Skua (Gast)


Lesenswert?

Welches Manual?

von na ich (Gast)


Lesenswert?

Der AVR verwendet die 'little endian' Byteorder.
http://de.wikipedia.org/wiki/Little_Endian

Bei einem 32Bit Speicherzugriff würde dein 0xA1 im ersten
Byte stehen. Die anderen sind 0.
Ein Beispiel für eine 32Bit Variable:

Byte          1.   2.   3.   4.
0xAABBCCDD -> 0xDD 0xCC 0xBB 0xAA

von Klugscheisser (Gast)


Lesenswert?

@ Udo

Deine Frage hat nichts mit Endianess zu tun. Endianess sagt etwas 
darüber aus, in welcher Reihenfolge die Bytes im Speicher stehen. 
Nicht aber darüber wie die Bits nummeriert sind.

Im übrigen spielt die Nummerierung selbst auch keine Rolle. Es kommt 
vielmehr darauf an, ob das niederwertigste Bit links oder rechts steht.

Üblicherweise ist das nullte Bit rechts positioniert und das 
niederwertigste, aber das muss nicht so sein.
Das ist eigentlich auch der Knackpunkt bei Deiner Frage, denn Du willst 
ja wissen wie die Bits die Du in Form ein Hexadezimalzahl eingibst dann 
im Byte oder Wort oder Doppelwort der Maschine angeordnet werden.
Das Manual (welches ist es denn?) sollte darüber Auskunft geben. 
Entweder in dem es die Bitnummer einer Wertigkeit zuordnet oder in dem 
es die Position des LSB oder MSB im Byte, Wort oder Doppelwort angibt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

na ich wrote:
> Der AVR verwendet die 'little endian' Byteorder.

Jein.  Er weiß nicht genau, welchen "Byte sex" er gern möchte. ;-)

Größtenteils ist er ja erst einmal ein 8-Bit-Prozessor, hat mithin
gar keine endianess.

Er hat ein paar Befehle, die mit 16-bit-Worten umgehen.  Einige
davon (ADIW & Co.) sind little-endian: das Register mit der kleineren
Zahl belegt das niederwertige Byte.

Andere wiederum besitzen eine implizite Endianess: das Ablegen des
PCs auf dem Stack beim CALL und Interrupt, entweder als 16- oder
24-bit-Wort.  Diese Operationen sind big endian.  Damit muss man
aber gewöhnlich kaum Rechenoperationen durchführen, sodass diese
Tatsache eher wenig auffällig ist.  Außerdem sind bei den Rücksprung-
adressen auf dem Stack (die AVR-typisch in 16-bit-Adressierung
arbeiten) die oberen, nicht benutzten Bits nicht notwendigerweise
gleich 0.  Das ist der CPU ja egal, einen menschlichen Beobachter
mit einem Debugger kann es dagegen schon einmal verwirren, wenn er
sich den Inhalt des Stacks anguckt...

Für die restlichen Zahlenformate jenseits der genannten Operationen
impliziert der Compiler eine bestimmte endianess, die ist beim
AVR-GCC little endian.

von Klaus (Gast)


Lesenswert?

Danke, für diese schöne Erklärung :)

von (prx) A. K. (prx)


Lesenswert?

Jörg Wunsch wrote:

> Größtenteils ist er ja erst einmal ein 8-Bit-Prozessor, hat mithin
> gar keine endianess.

Es gibt nicht viele 8bitter gänzlich ohne endianess. Fast haben 
deutliche Präferenzen. Was bei AVR allerdings dabei erheblich mitspielt: 
Das Flash-Mem als Datenspeicher lässt sich mit den bestehenden binutils 
nicht in big endian Anordnung verwenden.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

A. K. wrote:

> Das Flash-Mem als Datenspeicher lässt sich mit den bestehenden binutils
> nicht in big endian Anordnung verwenden.

Den Satz verstehe ich nicht.  Was haben die binutils hier zu tun?
Da der Flash beim AVR nicht so ganz genau weiß, ob er mit 16-bit-
Adressierung (Befehlslesezugriffe) oder 8-bit-Adressierung
(Datenzugriffe) arbeiten möchte, ist die Endianess für Datenzugriffe
komplett Sache der Tools bzw. der Programmierung.

Dass die GNU binutils und der AVR-GCC sich (genauso wie offenbar
andere Compiler) für little endian entschieden haben, ist eine
Tatsache, aber man hätte diese auch für big endian konfigurieren
können.  (Die 16-bit-Befehle wie ADIW etc. sind erst später zum
Kern hinzu gefügt worden und haben sich dann am little-endian-
Konzept der existierenden Compiler orientiert.)

von (prx) A. K. (prx)


Lesenswert?

Jörg Wunsch wrote:

> Den Satz verstehe ich nicht.

Ok, blöd formuliert. Es hat aber schon einen gewissen Charme, wenn man 
im Flash mit
   dw 0x1234
gleichermassen einen Befehl mit dem Code 0x1234 als auch ein Datenwort 
mit dem Wert 0x1234 im Flash unterbringen kann. Der LPM Befehl legt nun 
aber fest, dass an Z+0 das rechte Byte des Befehlswortes liegt und an 
Z+1 das linke.

von Udo (Gast)


Lesenswert?

danke ich schau nochmal genauer.
Leider ist das Manual nicht komplett.
Ach ja..Es ist ein PowerPC den ich hier habe.

von (prx) A. K. (prx)


Lesenswert?

Yep, PowerPC nummeriert Bits von links nach rechts, viele andere 
Architekturen von rechts nach links. Was ursprünglich recht konsequent 
war, denn anfangs anno IBM war diese Architektur big endian.

Zwar kann man die Bit- und die Byteorder unterschiedlich handhaben, das 
hat aber unangenehme Nebeneffekte, wie Motorola bei den 68000ern 
irgendwann feststellen musste.

Heutigerdings sagt der Begriff "PowerPC" aber nichts über die Byteorder 
aus, denn die Architektur selbst erlaubt beides. Was der konkret 
verwendet Chip davon hält sagt dessen Datasheet.

Aber
  Reg = 0xA1;
ist in allen 32bit Architekturen identisch mit
  Reg = 0x000000A1;
und wenn ein Byte in ein Register geladen wird, dann landet es darin 
stets rechtsbündig. Einzige mir bekannte Ausnahme: TI 990/9900/99000, 
aber die sind schon seit langem mausetot.

von gast (Gast)


Lesenswert?

In C ist es im Prinzip egal ob little- oder big-endian.

Der einzigste punkt an dem aufgepasst werden muss ist bei der verwendung 
von unions.

Zu beginn sieht es auf dem Papier verwirrend aus, wenn die zahl anders 
drin liegt aber sonst ändert sich nicht viel.

Hier mal ein beispiel an einem 16 bit wert
wert 0xaabb

little endian:
Adresse/Byte  1    0
inhalt        aa   bb

little endian
Adresse/Byte  0    1
inhalt        bb   aa

big endian
Adresse/Byte  1    0
inhalt        bb   aa

big endian
Adresse/Byte  0    1
inhalt        aa   bb


Ich hoffe das verwirrt jetzt nicht mehr als es hilft ;-)

von Falk B. (falk)


Lesenswert?

@ gast (Gast)

>Der einzigste punkt an dem aufgepasst werden muss ist bei der verwendung
>von unions.

Aber auch ur dann, wenn man sie als Datenkonverter missbraucht, was vom 
Ansatz her eigentlich nicht zulässig ist, auch wenn es praktisch oft 
verwendet wird ;-)

MFG
Falk

von (prx) A. K. (prx)


Lesenswert?

Bischen mehr als unions ist schon zu beachten. Bei Umgang mit externen 
Datenstrukturen wie Netzwerkprotokollen oder SD-Cards spielt das ggf. 
auch eine Rolle.

von Udo (Gast)


Lesenswert?

> und wenn ein Byte in ein Register geladen wird, dann landet es darin
> stets rechtsbündig.

also behandle ich es wie gehabt und brauche nicht umdenken?

von (prx) A. K. (prx)


Lesenswert?

Korrekt.

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
Noch kein Account? Hier anmelden.