Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
script-fehler
im script sind bei der abbildung zu little bzw big endian die bits ebenfalls umgekehrt, also für eine 16 bit zahl:
BIG 15 14 13 12 11 10 9 8 | 7 6 5 4 3 2 1 0
LITTLE 0 1 2 3 4 5 6 7 | 8 9 10 11 12 13 14 15
richtig ist aber imho:
BIG 15 14 13 12 11 10 9 8 | 7 6 5 4 3 2 1 0
LITTLE 7 6 5 4 3 2 1 0 | 15 14 13 12 11 10 9 8
Little bzw. Big Endian beschreibt die BYTE-Order (im Speicher). Wie dann intern ein Byte wirklich “physikalisch” gespeichert wird ist eigentlich nie ersichtlich und von CPU-Sicht her auch egal - kleinste “Einheit” mit der man arbeiten kann ist immer ein Byte. D.h. die Bits in einem Byte könnten, wenn das u.U. physikalisch sinnvoller wäre durchaus auch in einer Reihenfolge wie: 4 7 2 0 1… ‘angeordnet’ sein.
Auf Register-Ebene, wo es ja auch durchaus Bit-Operationen gibt (shift, etc), ist die “Ordnung” (relativ zum Befehl) immer klar & L/B Endian spielt hier ja auch keine Rolle.
das is mir schon klar, nur mußte ich sie ja irgendwie nummerieren damit der unterschied klar wird.
der Unterschied liegt eben allein darin, dass zB bei einem 16 bit Wert eben zuerst die 8 höherwertigen Bits und dann die 8 niederwertigen kommen (bzw. umgekehrt), wie die Bits innerhalb dieser beiden Bytes jeweils angeordnet sind ist wie gesagt völlig egal, deshalb sind “0 1 2 3 4 5 6 7”, “7 6 5 4 3 2 1 0” & “4 7 2 0 1 …” alle völlig gleichwertig wenn es nur um Byte-Order und Little/Big Endian geht.
Was dich vielleicht gestört hat ist, dass er anscheinend nicht 100% konsistent war - insofern, dass er die versch. Bits in einem Byte nicht immer entsprechend ihrer Wertigkeit an die gleiche Stelle geschrieben hat. Naja- als falsch würd ich das aber nicht unbedingt bezeichnen. 
:rolleyes:
wir können nicht auf die bitreihenfolge schliessen sagst du weil wir byte das kleinste ist was wir haben, dann müssten wir ja chars beim senden/empfangen übers netzwerk in verschiedene bit-reihenfolgen wandeln, oder beim lesen/schreiben auf die platte… was hör ich, du sagst daß wird die hardware schon selbst machen… warum bleiben wir nicht einfach bei der darstellung der bits wie mans mathematisch erwarten würde damits auch mit der vorstellung des shiftens übereinstimmt und fangen nicht an alles unnötig zu verkomplizieren.
Das Byte ist das kleinste was von einem Prozessor aus zugreifbar ist (einige 4 Biter und ganz perverse gibts zwar auch noch, aber die bleiben mal aussen vor). Darum wie dieses Byte dargestellt wird kuemmert sich die Hardware und sie tut das immer gleich.
Bei groesseren Speicherwoerten kommt eine Unstimmigkeit, weil man sich im Gegensatz zu dem Byte nicht einig war, wie man das intern darstellt. Erstmal ist das gar kein Problem, weil die Hardware das schon richtig abbildet, dass wenn man Byte[0] von dem Wort will auch das niederwertigste bekommt.
Problematisch wirds erst wenn man mehr als diese eine Hardware einsetzt, zum Beispiel in Netzwerken, oder auch innerhalb eines PCs, wenn ein Controller Daten aus dem Speicher liest und interpretiert, die vorher der Prozessor mit anderer Byteorder da reingeschrieben hat.
Dabei hat jede Byteorder seine Vorteile und nicht zuletzt aus Kompatibilitaetsgruenden sind nicht alle auf eine Byteorder uebergegangen. Das ist zwar aus Programmierersicht erstmal ein bisschen laestig, aber wenn man saubere Abstraktionsfunktionen benutzt, dann bekommt man davon gar nichts mehr mit.