Big Endian 2 little Endian

https://stackoverflow.com/questions/37304481/endian-swap-in-c-union

Ist auch recht verständlich.

Ach du dicker Vater schrieb:
> Hallo liebes Forum, wie kann ich uint32_t Big Endian nach little Endian
> konvertieren? Meine Lösung hat jede Menge Schiebereien und Masken.

Kommt drauf an, was du unter "jede Menge" verstehst, aber klingt erstmal 
nicht falsch.

> Ich schäme mich dafür.

Warum?

> Gibt es keine elegante Lösung?

Was macht eine Lösung für dich elegant?

Ach du dicker Vater schrieb:
> Meine Lösung hat jede Menge Schiebereien und Masken. Ich
> schäme mich dafür. Gibt es keine elegante Lösung?

Schreib es so hin, dass es leicht zu lesen ist.

Wenn der Compiler optimieren darf, wird er das erkennen.

Ach du dicker Vater schrieb:
> wie kann ich uint32_t Big Endian nach little Endian konvertieren?

Mit GCC: __builtin_bswap32 (var)

Johann L. schrieb:
> Ach du dicker Vater schrieb:
>> wie kann ich uint32_t Big Endian nach little Endian konvertieren?
>
> Mit GCC: __builtin_bswap32 (var)

Viel zu einfach/funktionierend!

;-)

my2ct schrieb:
> Für zwei Vertauschungsoperationen von je zwei Bytes klingt "jede Menge
> Schiebereien und Masken" nicht nach dem direktesten Weg.

Naja, pro Byte einmal schieben und maskieren halt. Daher ja meine Frage, 
was der "dicke Vater" unter "jede Menge" versteht.

Rolf M. schrieb:
> Naja, pro Byte einmal schieben und maskieren halt.

Das muß am Ende nicht unbedingt das Ergebnis sein.

Compiler erkennen z.B., wenn rotiert werden soll. Auch wenn's in C kein 
Statement gibt, um diesen Wunsch direkt hinzuschreiben, wird - so denn 
die Plattform dafür einen Maschinenbefehl hat - im Code aus der 
Maskier-/Schieberei eine Rotate-Instruktion.

Compiler, die schlau genug sind, können genauso gut aus der 
entsprechenden Schiebe- und Maskierkombination eine BSWAP-Instruktion 
basteln (wenn es die auf der Zielplattform gibt).

Markus F. schrieb:
> Rolf M. schrieb:
>> Naja, pro Byte einmal schieben und maskieren halt.
>
> Das muß am Ende nicht unbedingt das Ergebnis sein.

Es ging hier darum, wie der Code aussieht, nicht darum, was nachher der 
Compiler draus macht.

PostalDude schrieb:
> #asm(" REV r0,r0");
> #asm(" bx lr");
>
> Und aus die Maus.

Und für welche Prozessor-Architektur gilt das überhaupt?

Rolf M. schrieb:
> Und für welche Prozessor-Architektur gilt das überhaupt?

Ziemlich sicher ARM.
Aber #asm("bx lr") ist so ziemlich das dümmste, was man machen kann.

Die sinnvollste Lösung ist wahrscheinlich das genannte Compiler-Builtin, 
denn das ist garantiert optimal implementiert.

Niklas Gürtler schrieb:
> Was ist der Vorteil gegenüber Bitshifts?

Und was ist der Nachteil gegenüber Bitshifts:

auf einem Big-Endian System machen diese Funktionen genau nullkommanix.

Wenn man das haben will (network byte order): gut. Wenn nicht, halt eher 
nicht...

Mike schrieb:
> Unbedingt mit den Funktionen: htons(), htonl(), ntohs(), ntohl()

Ach du dicker Vater schrieb:
> wie kann ich uint32_t Big Endian nach little Endian konvertieren?

htonl() wäre dann richtig, wenn der TE geschrieben hätte:

  "wie kann ich uint32_t von der internen Darstellung nach der Network-
  Byte-Order konvertieren?"

Da die interne Darstellung nicht unbedingt Big-Endian und die Network-
Byte-Order nicht unbedingt Little-Endian sein muss, ist hier nach einer
Funktion gefragt, die die Byte-Reihenfolge auf jeden Fall umkehrt.

Niklas Gürtler schrieb:
> Es gibt auch Netzwerk-Protokolle mit Little Endian, z.B. CANopen.

Das mag zwar durchaus so sein, aber htonl usw. stammen aber definitiv 
aus dem POSIX-API. Und selbiges umfasst primär die IP-basierte 
Kommunikation auf UNIX-artigen Systemen.

Auch wenn es vermutlich eher zur Polumkehrung des Erdmagnetfeldes kommen 
mag als zur Änderung der Network Byte Order und somit zur Änderung des 
Verhaltens von htonl usw., finde ich es aber auch semantisch ungünstig, 
auf ein Netzwerk-API zu referenzieren, wenn es überhaupt nicht um die 
Kommunikation mittels dieses API geht. Leider betreibt der TE aber 
natürlich die heute übliche Salamitaktik und nennt nicht etwa den 
Kontext, in dem er die Änderung der Endianess durchführen will/muss.

Generell halte ich es aber aber schon für sehr sinnvoll, die Anpassung 
der Endianess einer Bibliotheksfunktion zu überlassen, für die es ggf. 
je nach Prozessorarchitektur optimierte Implementierungen gibt.

Mike schrieb:
> @Yalu X
>>htonl() wäre dann richtig, wenn der TE geschrieben hätte:
>>  wie kann ich uint32_t von der internen Darstellung nach der Network-
>>  Byte-Order konvertieren?"
>
> Ob der Host-Rechner (CPU) mit Big-Endian oder Little-Endian funzt, hängt
> von der Archidektur ab.

Das ist schon klar.

Leider meldet sich der TE nicht mehr, um uns mitzuteilen, was er mit der
Konvertierung tatsächlich bezwecken möchte. So bleibt uns als einzige
Information, dass er ein uint32_t von Big-Endian nach Little-Endian
konvertieren möchte. Woher das zu konvertierende uint32_t kommt, und
wohin das konvertierte uint32_t geht, bleibt dabei völlig im Dunkeln.
Unter den gegebenen Umständen muss man davon ausgehen, dass der Input
immer Big-Endian und der Output immer Little-Endian ist. Deswegen
ist ein Byte-Swap (egal, auf welche Weise realisiert), der einzig
richtige Vorschlag.