Diskussion:Byte-Reihenfolge

aus Wikipedia, der freien Enzyklopädie

Inhaltsverzeichnis 1 IEN 2 durcheinander 3 hex 4 Speicherung von Strings? 5 Shift-Operatoren 6 BSD Socket-API 7 true little endian <-> bi-endian 8 Irrelevanz der Bit-Order? 9 Byte und Bytes 10 Zahlen im Arabischen 11 Testprogramm 12 Bezeichnungen irreführend? 13 Unverständlich-Baustein

[Bearbeiten] IEN

Der Link am Ende heisst "Internet Experiment Note" soweit ich auf der en.wikipedia gesehen habe. Zwar gefällt mir Engineering auch besser, doch würde ich es korrigieren, falls es falsch ist. Kann jemand was dazu sagen? Lnxnt 21:54, 25. Jan 2006 (CET)

[Bearbeiten] durcheinander

der abschnitt mit durcheinander scheint dort völlig fehl am platz. was hat die sprechweise von zahlen und datum dort zu suchen ?

Dem stimme ich vollkommen zu, dieser Abschnitt verwirrt sehr... -83.236.20.241 14:17, 5. Mär 2006 (CET)

Ich war mal einfach mutig und habs entfernt... -83.236.20.241 16:59, 7. Mär 2006 (CET)

Ich finde diese Seite nicht nur sehr informativ sondern auch nett formuliert und gut leserlich. Danke fuer die Aufklaehrung.

[Bearbeiten] hex

Ich finde es ziemlich unglücklich hier die Hexadezimale Darstellung zu benutzen, wo es sich anhand der Binären doch viel logischer und Maschinennäher erklären lässt.

Ich finde gerade die hex-darstellung sinnvoll, weil man bei der verwendung von 1's und 0's schnell durcheinanderkommt, welcher block wo hingekommen ist. Aber man sollte anmerken, dass man ein Hexzeichen (16 Zeichen) mit 4 Bit darstellen kann (2 hoch 4 = 16 Zeichen). Und dann: 32 Bit / (4 Bit pro Hex) = 8 Hex

Ich vestehe aber noch nicht, warum der Little Endian in so einer komischen reihenfolge gespeichert wird. Insbesondere die Aussage:

In der Little-Endian-Form können die Bytes für einen Befehl nacheinander abgerufen werden; ob 2, 3 oder mehr Bytes gelesen werden müssen, sie werden in der gleichen Reihenfolge abgerufen: 1, 2, 3, 4. Aufgrund der 1:1-Beziehung zwischen Adresse und Offset sind mathematische Routinen für Berechnungen einfach zu schreiben.

Ich habe das mit der Mathematik mal rausgenommen. Stattdessen habe ich (auf Verdacht) auf die RISC-Architektur verwiesen. Der Text hat dadurch einen Bruch erlitten, ich glaube aber trotzdem an eine Verbesserung. Den nächsten Absatz fasse ich vielleicht an, wenn ich ihn verstanden haben ;). Das ganze verdient noch etwas Vereinfachung. Oma soll's ja auch verstehen. --00:05, 24. Dez 2005 (CET)

kann ich nicht verstehen. Adresse und Offset, was haben die denn hier zu suchen? Danke, --Abdull 10:54, 16. Mär 2005 (CET)

Naja, wenn du eine CPU hast, die mit verschiedenen Datenbreiten auf den Speicher zugreifen kann (z.B. x86), dann kannst du einen 32-Bit-Wert (z.B. 0x12345678) an eine Adresse A schreiben und einen 8-Bit Wert von der gleichen Adresse A lesen. Je nach dem, welche Byte-Reihenfolge die Maschine benutzt, bekommst du dann den Wert 0x12 oder 0x78 zurück. So kann man z.B. in C zur Laufzeit ermitteln, welche Byte-Reihenfolge die Maschine benutzt, auf der das Programm gerade läuft, wenn man sich nicht auf gesetzte Makros in irgendwelchen System-Headerdateien verlassen will. ;-) --RokerHRO 08:38, 29. Dez 2005 (CET)

[Bearbeiten] Speicherung von Strings?

Also wenn der String "UNIX" in Big-Endian gespeichert wird und in Little-Endian gelesen wird, dann wird "XINU" daraus und nicht NUXI. NUXI wäre es auf einer "Mittle-Endian"-Maschine, welche aber – Gott sei dank – inzwischen als ausgestorben gelten können. --RokerHRO 15:54, 30. Aug 2005 (CEST)

Ich bin mir nicht ganz sicher aber das wäre AFAIK nur auf einer 16bit CPU der Fall. Das Wort UNIX ist ja 32bit gross, eine 16bit CPU würde dann zuerst UN und dann IX verarbeiten, auf einem Little-Endian System würde damit aus UNIX NUXI. Auf einer 32bit CPU würde aus UNIX tatsächlich XINU. Kann dies jemand bestätigen? Wenn ja, könnte man dies eventuell noch zum relevanten Abschnitt hinzufügen.

Ich habe mal die Überschrift des Abschnitts geändert (vorher „NUXI?”). Wie werden Strings im allgemeinen gespeichert? Die Längen sind ja nicht unbedingt vielfache von 2/4/8. --the-pulse 23:33, 23. Dez 2005 (CET)

Das "NUXI"-Problem tritt in der Form tatsächlich nur bei 16-Bit-CPUs auf. Ich hatte vergessen, dass Unix schon sooo alt ist. ;-)) --RokerHRO 08:33, 29. Dez 2005 (CET)

[Bearbeiten] Shift-Operatoren

Ein paar Worte dazu wären toll. Die impliziten Folgen für die Bitreihenfolgen wären interessant. schließlich schreibt man in beiden Fällen immer noch für eins "00000001", obwohl sich die Shift verschieden auswirkt. --the-pulse 00:08, 24. Dez 2005 (CET)

Die Richtung bei "Shift"-Operationen ist immer auf die bei geschriebenen Zahlen üblichen Reihenfolge definiert. Also ist ein Links-Shift ein Verschieben der Bits in die höherwertigen Stellen. Ein Rechts-Shift entsprechend zu den niederwertigen Stellen. So bedeutet etwa in C der Ausdruck x << 1 (Linksshift) das gleiche wie x*2 und entsprechend x >> 1 (Rechtsshift) das gleiche wie x/2. (x ist ein Ganzzahldatentyp und Überläufe lasse ich hier mal außer Betracht) --RokerHRO 08:30, 29. Dez 2005 (CET)

[Bearbeiten] BSD Socket-API

Den Absatz interessiert bestimmt niemanden... und passen tut er finde ich auch nicht. cljk 20:40, 30. Jan 2006 (CET)

Würd ich nicht so sagen. Solche Funktionen gibts in verschiedenen Betriebssystemen und Bibliotheken, da man sowas halt recht oft braucht. Und die BSD Socket API ist nunmal sehr verbreitet (Linux, BSD, Solaris, Mac OS X, und mit Cygwin sogar unter MS Windows). Somit sind diese Funktionen die bekanntesten Vertreter von Byte-Reihenfolge-Änderungsfunktionen. :-) --RokerHRO 21:37, 30. Jan 2006 (CET)

Soagr die Netzwerk-API von Microsoft verwendet BSD code... -- D. Dÿsentrieb ⇌ 22:44, 30. Jan 2006 (CET)

Gut - das wusste ich nicht. Wenn das so ist, sollte man das aber auch dahin schreiben, dass diese Funktionen auf fast allen Systemen verfügbar sind... -cljk 10:22, 31. Jan 2006 (CET)

Hab ich mal gemacht. So besser? --RokerHRO 13:55, 31. Jan 2006 (CET)

yes! ... danke! *gg* -cljk 15:09, 31. Jan 2006 (CET)

[Bearbeiten] true little endian <-> bi-endian

Irgendwie ist mir dieser Abschnitt unklar:

„[...] die als Little-Endian-Systeme konfiguriert werden können (s. u. Bi-Endian) und aus der Sicht des laufenden Programms dann Little-Endian verwenden, Werte im Speicher jedoch weiterhin im Big-Endian-Format ablegen. Bei Lade- und Speicheroperationen wird die Darstellung implizit umgewandelt.“

Wenn die Werte im Speicher in Big-Endian-Reihenfolge abgelegt werden, ist es doch eine Big-Endian-Architektur. Also MSB an kleinster Speicheradresse, LSB an der höchsten. Klar kriegt das Programm davon nix mit, so lange es eben nur Wortweise auf den Speicher zugreift. Sobald Bytezugriffe dazukommen, bekommt das Programm mit, wie die Daten im Speicher liegen. Wie soll eine "implizite Umwandlung" dies verhindern können und ... warum? --RokerHRO 09:34, 18. Mai 2006 (CEST)

[Bearbeiten] Irrelevanz der Bit-Order?

Im Artikel stand: "Wenn man von wenigen exotischen Spezialfällen absieht, so arbeiten Ein-/Ausgabeschnittstellen von Computern, z. B. Netzwerk- oder Massenspeicheranschlüsse, byteorientiert, sodass es irrelevant ist, in welcher Reihenfolge ein Computer die Bits, aus denen sich die Bytes zusammensetzen, intern speichert."

Nahezu jede Schnittstelle bedarf der Definition, welches Bit zuerst auf die Leitung gelegt wird. Natürlich interessiert man sich i. d. R. ab Schicht 3 nicht mehr dafür, aber jeder, der schon einmal hardwarenah gearbeitet hat, weiß, dass kann man obigen Absatz so nicht stehen lassen kann. Habe ihn freizügig gelöscht. --Mrsurrender 12:50, 27. Jul 2006 (CEST)

Dazu hab ich noch eine Frage: die Bit-Reihenfolge ist relevant, wenn man hardware-nah arbeiten muss. Wenn im Handbuch des Prozessors steht, dass in einem 32Bit Wort das 5. Bit gesetzt werden muss, ist es wichtig zu wissen, von welcher Seite aus gezählt werden muss. Also ob 0x08000000 oder 0x00000010. Fällt die Bit-Reihenfolge auch in die Kategorie Big-/Little-Endian? --AnSc

Naja, in einem Maschinenwort werden die Bits meist (eigentlich immer, oder?) vom LSB aus gezählt, beginnend mit 0. Also ist das 5. Bit halt das mit der Wertigkeit 32, also 0x00000010. --RokerHRO 13:42, 6. Okt 2006 (CEST)

Ich hab derzeit mit einem MPC5553(PowerPC) von Freescale zu tun. Dort gibt es eben genau diesen Fall, dass im Handbuch bei der Beschreibung verschiedener Register das LSB ganz links ist, und nicht wie bei anderen uC üblich ganz rechts. Meine Frage zielte also nicht darauf ab, ob dieser Fall eintreten kann, sondern ob dieser Fall ebenfalls mit Little-/Big- Endian zu beschreiben ist.

[Bearbeiten] Byte und Bytes

Das alte Problem. Darf man, soll man oder eben doch nicht im Plural "Bytes" schreiben? Im Artikel zu Byte ist das eindeutig angewendet und in der Diskussion ebenso angesprochen. Einigen wir uns doch darauf, dass in einer Enzyklopädie die Umgangssprache so weit wie möglich unterdrückt wird, solange dadurch der Sinn nicht entstellt wird, und benennen wir (Größen-)Einheiten wie physikalische immer im Singular. Es sollte also heißen: "1 Byte, 2 Byte". (http://www.canoo.net/services/OnlineGrammar/Wort/Nomen/Numerus/Menge.html?MenuId=Word1212) --Mrsurrender 12:50, 27. Jul 2006 (CEST)

[Bearbeiten] Zahlen im Arabischen

Es ist zwar richtig, dass sich Zahlen im Arabischen in gleicher Weise wie in der westlichen Welt schreiben, also mit der höchstwertigen Stelle links, aber es ist nicht richtig, dass sich die Zahl konsequent von rechts nach links liest. So heißt die Zahl 1234 auf Arabisch: 'alf wa-mi'ata:n wa-'arba`atun wa-thala:thu:n, wörtlich "Tausend und-zweihundert und-vier und-dreißig". Anscheinend ist es wenig intuitiv, sehr große Zahlen (ab 100, das ist im wirklichen Leben schon recht groß) erst von ihren vernachlässigbaren Kleinkram her zu nennen. Insofern haben wir Deutschen es leichter: Wir lesen die Zahl in unserer Leserichtung bis auf die letzten zwei Stellen, die Araber lesen ihre Zahlen nur für diese zwei Stellen in der gewohnten Richtung.--Mzapf 20:21, 4. Sep 2006 (CEST)

[Bearbeiten] Testprogramm

Der NUXI-Test in dem Testprogramm geht von einer Vertauschung der Nibbles in einem Byte aus (0x1234 -> 0x2143). „NUXI“ als Zeichen sind aber Bytes, also eine Vertauschung von je zwei benachbarten Bytes (0x11223344 -> 0x22114433). Vertauschung von 16-Bit-Wörtern wird nicht überprüft (0x11223344 -> 0x33441122).

Ist dieses Testprogramm überaupt relevant für Wikipedia? --Fomafix 17:24, 5. Sep 2006 (CEST)

Stimmt, du hast recht. NUXI-Endianess oder "middle endian" tritt nur bei 32-Bit-Werten auf. Ich werde das Programm entsprechend anpassen. Die Frage nach der Relevanz des Testprogramms bleibt davon natürlich unberührt. --RokerHRO 18:07, 5. Sep 2006 (CEST)

[Bearbeiten] Bezeichnungen irreführend?

Habe folgendes aus Etymoligie gelöscht: "Die Bezeichnungen sind für Europäer auch irreführend. Man stellt sich die Speicheradressen von der kleineren zur größeren hin als von links nach rechts angeordnet vor. Den Anfang würde man links, das Ende rechts vermuten. Bei Little-Endian kommt aber das niedrigstwertige Byte am Anfang beziehungsweise links zu liegen, das höchstwertige am Ende beziehungsweise rechts."

Bei Little-Endian bezieht sich 'Little' auf die Byte-Enden und nicht auf den Speicher. Es gibt auch die längere Bezeichnung Little-Endian-first, und 'first' bezieht sich auf die Anordnung der Speicheradressen. Das wird im Artikel gut erklärt.

[Bearbeiten] Unverständlich-Baustein

Ich finde diesen Artikel Mist - wie es dazu gekommen sein mag interessiert mich kaum, vermutlich zuviele Köche. Das absolut schlimmste: Es wird nirgends zentral erklärt, was es nun eigentlich mit Big/Little Endian auf sich hat. Es gibt da dieses Beispiel, da fängt's ja schon an! Solche Sachverhalte sollten erstmal eine Art Definition/Erklärung besitzen, in der glasklar drinne steht, was es ist. Danach kann mna Beispiele nennen.

1. Im ersten Abschnitt steht etwas ähnliches wie ne Erklärung. Ich vermute ja, dass die jemand versucht hat, aus der englischen Wikipedia zu übersetzen. "Wenn wir die 4 Byte in der Reihenfolge D1 C2 B3 A4, also das niedrigstwertige Byte an der niedrigsten Speicheradresse ablegen, spricht man von Little Endian." Was ist denn der Wert eines Bytes? 42? Jemand der nicht weiß worum es geht wird vergeblich versuchen, in dem Artikel irgendwo ne Erklärung des Wertigkeit eines Bytes zu finden. Und wenn man mit Wertigkeit nix anzufangen weiß, ist man absolut aufgeschmissen. Schlimmer noch: man könnte denken es handle sich um dne Zahlenwert des Bytes. Das habe ich damals gedacht, als cih den Artikel zum ersten mal gelesen habe. Da die Erklärung die Wertiggkeit recht oft erwähnt, es aber natürlich keinen Sinn macht, Bytes nach ihrer Größe zu ordnen, bin ich an dem Absatz hängen geblieben und hab mich gewundert warum die Bytes so geordnet werden.

2. Das selbe mit Hex - wer mit Hex nix am Hut hat ist am Ar.... Oben wurde bereits erwähnt, dass sich die Darstellung als Binärzahl anbieten würde, das kann ich nur gut heißen - Zahlen werden intern schließlich nich mit Buchstaben codiert, sondern mit 0 und 1.

3. Wenn man jemandem etwas mit Beispielen erklärt, dann nimmt man zuunächst einfache Beispiele und nicht gleich 4-Byte-Datentypen in Hex-Darstellung Oo

Insgesamt ist der Abschnitt gelinde gesagt ungeschickt gemacht - dabei könnte es so einfach sein:

Es gibt zwei Arten der Byte-Reihenfolge:

1. Die "normale" Reihenfolge Big Endian in der man eine abgespeicherte Zahl auch aufschreiben würde

2. Die umgekehrte Veriante. Beispiel: Die Zahl 2 als Binärzahl mit 16 Stellen (zB unsigned short) (0000000000000010)b = 2

 BigEndian:    Normale Reihenfolge    1.Byte:00000000 2. Byte: 00000010
 LittleEndian: umgekehrte Reihenfolge 1.Byte:00000010 2. Byte: 00000000

Und schon ist ohne Umwege alles geklärt. Jetzt kann man gern das hex-beispiel hinterherschieben.

Im Grunde ist der Artikel vielleicht ok, aber wer es nicht ohnehin schon weiß, wird es mit diesem Artikel auch kaum lernen. Daher fänd ich es toll, wenn da mal jemand aufräumt. Wenn sich hier keiner meldet oder es macht, werd ich ihn mir selbst vorknöpfen. Aber ich dachte ich frag lieber erstmal. :)