Endian Formate

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.

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.

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.)

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.

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.

@ 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

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

Korrekt.