Diskussion:Byte-Reihenfolge

message: 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)
replies: text: 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)
thread_title:  Testprogramm 

message: Am Anfang des Artilel steht, dass die Byte-Order "in erster Linie" für Integer-Zahlen gilt. Was passiert denn mit Fließkommazahlen und Zeichenketten? Sind die von der Byte-Order betroffen? Und geht es bei 64 Bit um Blöcke von 8 Byte Länge statt 4 Byte bei 32 Bit?
OnkelSchuppig 20:14, 7. Sep. 2007 (CEST)
replies: text: Für Fließkommazahlen spielt "Endian" wohl auch eine Rolle (siehe IEEE 754, wusste ich allerdings auch nicht und habe es durch diesen Artikel gelernt). Ob das für alle Fließkommaformate gilt, weiß ich nicht. Bei 64-bit Integerwerten ist das Prinzip analog 32-bit. Interessant ist ja auch, dass Speicheradressen selbst (in C Pointer) ja auch dieser Reihenfolge unterliegen. Bei Zeichenketten allerdings spielt "Endian" keine Rolle. Könnte man vielleicht noch im Artikel ergänzen.--Cactus26 07:45, 10. Sep. 2007 (CEST)

text: Für Gleitkommazahlen (sic!) gilt das gleiche wie für Integerzahlen. Bei 64-Bit-Werten, egal ob IEEE-double oder 64-bit-Integer sind es eben acht Byte, die entweder in der Reihenfolge 12345678 oder 87654321 gespeichert werden.  --RokerHRO 12:17, 10. Sep. 2007 (CEST)
thread_title:  64 Bit, Zeichenketten, Fließkommazahlen 

message: Einige ältere Systeme oder moderne CPUs der x86/x64 Architektur (wenn sie sich im Realmode befinden) speichern die Daten auch in der Reihenfolge 3C 4D 1A 2B oder auch 2B 1A 4D 3C (letzteres gilt für x86/x64 CPUs im Realmode), beides wird heute als Middle Endian bezeichnet.
Stimmt das wirklich für x86- und x64-CPUs? --212.114.205.149 12:25, 14. Jan. 2008 (CET)
replies: text: Nö. Wo hast du das denn her? --RokerHRO 14:43, 14. Jan. 2008 (CET)
replies: text:  steht so im Artikel! --89.60.26.178 21:10, 14. Jan. 2008 (CET)

text:  korrigiere: stand so im Artikel! Danke für die Klarstelliung. --89.60.26.178 21:12, 14. Jan. 2008 (CET)
replies: text: Ich habs ja eben rausgenommen. :-) --RokerHRO 13:55, 15. Jan. 2008 (CET)
thread_title:  "Mittle Endian" bei x86/x64? 

message: "Im folgenden Beispiel wird die Ganzzahl 439.041.101 als 32-Bit-Integer-Wert gespeichert (Binär: 00011010 00101011 00111100 01001101, hexadezimal: 1A 2B 3C 4D)."
Also entweder das ist ein Fehler oder ich habe gerade das berühmte Brett vor'm Kopf. Die Binär und hexadezimale Zahl stimmt doch mit der ganzzahl, die sicherlich in Dezimal gegeben ist, gar nicht überein. So ist doch z.B. 1A in dezimal 26, wie ja auch in der Tabelle rechts daneben steht und nicht 439. Davon abgesehen, dass man ja in 8 Bitt auch nur bis max. 255 speichern kann.
Ist das jetzt ein Fehler oder übersehe ich was? Mit bitte um aufklärung bzw. änderung
--84.161.203.249 20:27, 26. Nov. 2008 (CET)
replies: text: Die Dezimalzahl 439041101 wird nach WP:SVZ mit Punkten zur Zifferngruppierung geschrieben: 439.041.101. --Fomafix 20:35, 26. Nov. 2008 (CET)
replies: text:  Argh, jetzt hab ich es kapiert. Finde das aber total verwirrend, hier die Tausendertrennzeichen zu benutzen, macht es doch den Eindruck, es handelt sich um in der IT übliche Trennzeichen zur Trennung von Blöcken. Die von dir verlinkte Wiki-Richtlinie würde ich in diesem Fall nicht anwenden, da es sich ja um ein IT-spezifisches Problem handelt. Ich persönlich fände es zumindest deutlich verständlicher, wenn die Tausendertrennzeichen nciht da wären (obwohl ich das auch vom ästhetischen Gesichtspunkt nicht die optimale Lösung finde) --84.161.203.76 09:53, 27. Nov. 2008 (CET)
replies: text:  Genauso ging es mir gerade jetzt beim ersten Betrachten. Ich habe deshalb mal den Beginn des Zahlwortes in Klammern dahinter gesetzt. Zwar sind IP-Adressen viergliedrig wobei jedes Glied nicht größer als 255 sein kann, aber die optische Wahrnehmung rastet eben doch falsch ein. Grüße --213.23.174.67 12:05, 25. Okt. 2011 (CEST)
thread_title:  Fehler bei Dezimalzahl 

message: Wenn bei der Gegenüberstellung von Little und Big Endian schon die Binärdaten mit aufgeführt werden, so sollte man im Artikel vielleicht auch irgendwo das Stichwort "Bit-Reverse" auftauchen. Der MicroBlaze von Xilinx zum Beipsiel kennt auch ein Little Endian bit-reversed und Big Endian bit-reversed. Und das bezieht sich nicht auf die Art der seriellen Übertragung, sondern hat Auswirkungen bei paralleler Übertragung auf Datenbussen.
Zur Veranschaulichung: 0x01 in der Software wird bei Speicherung in einem 8 Bit Hardware-Register zu 0x80. LSB bleibt LSB, aber hier verweist dann Register-Index 7 auf das LSB! (nicht signierter Beitrag von 93.223.254.169 (Diskussion) 19:37, 17. Dez. 2011 (CET)
thread_title:  Bit-Reversing 

message: Zum Abschnitt Byte-Reihenfolge#Diagramm zur Abbildung von Registerwerten auf Speicheradressen habe ich ein paar Fragen:
# Meines Wissens kann man Registerwerte zum Adressieren von Speicher verwenden. Ist das mit Abbilden von Registerwerten auf Speicheradressen gemeint ?
# Meines Wissens wird ein zusammenhängender Speicherbereich standardmäßig durch seine Anfangsadresse und seine Länge spezifiziert. (Letztere kann auch implizit gegeben sein.) Das durch die Anfangsadresse bezeichnete Ende wird auch linkes Ende des Speicherbereichs genannt. Register haben Längen von 1,2,4 oder 8 Bytes. Laden und Speichern von Registern gehören zu den wichtigsten Instruktionen. Liegt es nicht nahe, dass die Abbildung von Registerinhalten auf Speicherinhalte 1:1 ist ? Genauer: die linke Seite des Registers geht auf die linke Seite des Speicherbereichs und so fort.
# Wenn diese Abbildung 1:1 ist, wie kann sie dann bei der Erklärung der Endianness helfen ?
--Nomen4Omen (Diskussion) 20:41, 17. Mai 2014 (CEST)
replies: text: Ehrlich gesagt würde ich diesen Abschnitt (samt Bild) einfach löschen. ME. bietet er keinen konkreten Mehrwert (vor allem nach deinem Einfügen mit dem Hexdump-Beispiel). Und es suggeriert mir irgendwie, dass eine "Abbildung von Registerwerten nach/in Speicheradressenwerte" irgendwas Spezielles sei.--Plankton314 (Diskussion) 21:01, 18. Mai 2014 (CEST)

text: @Nomen4Ohmen zu 2. Nein es liegt nicht nahe. Es ist sogar irrelevant für die Darstellung im Speicher, denn man kann jederzeit mit interner Verdrahtung die Endianness verändern und es gibt schon gar keine vorschrift, wie die Interne Verdrahtung sein muss. --85.16.71.3 20:07, 10. Jan. 2015 (CET)
replies: text: @85.16.71.3: OK, wir dürfen doch sicher annehmen, dass da irgendwas verdrahtet ist. Dann definieren wir das im Register, was mit der niedrigen Speicheradresse verdrahtet ist, als niedrige Adresse auch im Register. Und entsprechend in den Adressen aufsteigend. Gibt's eine andere Möglichkeit? --Nomen4Omen (Diskussion) 20:30, 10. Jan. 2015 (CET)
thread_title:  Register? 

message: Den einen oder anderen mag es wundern, warum Hersteller von Schaltkreisen (hier Prozessoren) den einen oder den anderen Weg gingen. Beide Wege haben entscheidende Vorzüge.
Denken wir daran, dass jeder Übertrag bei allen arithmetischen Operationen von der niederwertigsten zur höchstwertigen Stelle geht, dann spart es im Pipelining Zeit, Daten genau in dieser Reihenfolge zu lesen und zu schreiben. Wir übertragen vorteilhaft das niederwertigste Bit zuerst. Zu einer Zeit, als CPUs noch mit 2,5 MHz liefen, konnte das Vorteile bringen. Daraus mag Little Endian entstanden sein.
Auf der anderen Seite sind wir es beim Rechnen gewohnt, die niederwertigste Position ganz rechts zu schreiben. Unsere Fehlerquote steigt immens, wenn wir jede Zahl in Gedanken umkehren müssen. So begnügen wir uns damit, alles schriftliche in Big Endian (als Bit- und Byte-Ordnung) zu notieren.
Heinzelmann (Diskussion) 08:42, 3. Mär. 2016 (CET)
thread_title:  Noch ein Wort zur Historie 

message: Zitat: Big-Endian (wörtlich „Groß-Ender“, ...)
Wörtlich ist das doch eher "großendig": big end ist das "große Ende" und -ian macht daraus ein Adjektiv (das könnte natürlich wieder substantiviert sein). Könnte es sein, dass "Groß-Ender" aus "Groß-Endender" entstanden ist? Wobei ich bei "endender" eher an "ending denken würde. Also besser "großendig". Und entsprechend "kleinendig".
--Helmut w.k. (Diskussion) 15:09, 27. Jun. 2018 (CEST)
thread_title:  Deutsches Äquivalent 

message: Hi,
Ich starre jetzt schon eine Weile auf die sehr kompakten zwei Zeilen Text für das BOM-Beispiel und sehe da Passagen die mir nicht verständlich sind oder gar überflüssig.
Das steht:
In einem Hex-Editor sieht ein Text folgendermaßen aus:
 00 44 00 69 00 65 | D i e| BOM 00 44 = FE FF am Dateianfang \Rightarrow UTF-16 Big Endian / UCS-2BE
 44 00 69 00 65 00 |D i e | BOM 44 00 = FF FE am Dateianfang \Rightarrow UTF-16 Little Endian / UCS-2LE
Ich sehe hier folgendes:
* Zwei Zeilen die Zwei unterschiedliche Datei-Anfänge beschreiben
* Nach "\Rightarrow" wird eine Interpretion eines 6-Byte-Abschnitts geliefert
* Vor "\Rightarrow" wird der 6-Byte-Abschnitt unterschiedlich dargestellt und die Darstellungsvarianten sind durch "|" voneinander getrennt
** Hexadezimal (ohne BOM)
** Zeichen (ohne BOM, NUL-Byte wird als Space dargestellt)
** ??? symbolische Darstellung, dass der BOM jetzt hinzugefügt wird ??? und "0x0044"/"D" als partielle Wiederholung ??? "=" gefolgt von der Hexadezimal-Darstellung des BOM in UTF-16 die an den Dateianfang gestellt wird.
Übersehe ich hier irgendwas Relevantes?
Ich würde Vorschlagen:
* Wirklich die Darstellung aus dem Hex-Editor zu übernehmen. Der wird es nicht ohne BOM zeigen, wie hier.
* Die Hex-Editor-Darstellung und die Erklärungen klarer voneinander trennen
D.h. konkret:
Der Text "Die" (drei Zeichen, 6 Byte) mit BOM (ein Zeichen, 2 Byte) als UTF-16-Kodierung, in der Byte-Darstellung von Hex-Editoren (8 Byte) für die beiden unterschiedliche Byte-Reihenfolgen:
* Big Endian:
 FE FF 00 44 00 69 00 65 | þÿ␣D␣i␣e 
* Little Endian:
 FF FE 44 00 69 00 65 00 | ÿþD␣i␣e␣ 
Oder geht hier jetzt was verloren? --Aeroid (Diskussion) 08:13, 28. Okt. 2023 (CEST)
replies: text: --Aeroid (Diskussion) 19:09, 1. Nov. 2023 (CET)
thread_title:  Ist das BOM-Beispiel etwas überladen?