Hallo Zusammen, ich habe ein grundlegendes Verständnissproblem, welches ich auch nach Suche im Forum nicht lösen konnte. Es geht darum, wie Daten im Speicher abgelegt werden. Wenn ich bspw. Daten im Little-, big oder mixed-Endian abspeicher wie genau geschieht das? Wenn z.B. folgende Hexadezimalzahlen im 4Byte Speicher (auf Adresse 0001(Hexa) bis 0003(Hexa) ) abgelegt habe: 20 (Hexa) 32 (Hexa) 7A (Hexa) C8 (Hexa) bedeutet das ich habe folgende Zahl gespeichert: 20327AC8 (Hexa) = 540179144 (Dezimal) = 100000001100100111101011001000 (Binär)? Ist das denn im little endian gespeichert, weil das niederwertigste byte auf der niederwertigsten Adresse gespeichert wurde und was bedeutet das genau? Bedeutet niederwertigstes Byte, dass man die Zahl in Bytes aufteilt (bei Hex zwei ziffern pro Byte entsprechend der reihenfolge) und dann mit der niederwertigsten adresse (also geringsten "Zahl") beginnt und dann aufsteigen speichert? Wenn ich die Zahlen jetzt z.B. in einer anderen Reihenfolge abgelegt habe z.B. 32 (Hexa) --> 50 (Dezimal) 20 (Hexa) --> 32 (Dezimal) 7A (Hexa) --> 122 (Dezimal) C8 (Hexa)--> 200 (Dezimal) Dann ist es doch kein Little Endian Format mehr, da 32 (Hexa) auf Adresse 0000(Hexa) gespeichert ist und 32 in dem falle nur die zweiwertige Byte ist und 0000 die niederwertigste adresse, oder? Wenn ja was passiert danach? Muss man die Hexa zahlen nun in Dualzahlen umrechnen und diese entsprechend der reihenfolge bitweise speichern, wobei das erste bit das Sign bit ist, dann die exponenten bits und dann kommen die Mantissen?
Du bist vollkommen neben der Spur... Du hast eine Zahl, z.B. 305419896. Das entspricht 0x12345678. Big Endian: 0x12345678 Little Endian: 0x78563412 Das ist alles.
Das wird eigentlich hier https://en.wikipedia.org/wiki/Endianness#Big gar nicht so schlecht erklärt.
Maren K. schrieb: > bedeutet das ich habe folgende Zahl gespeichert: > > 20327AC8 (Hexa) = 540179144 (Dezimal) = 100000001100100111101011001000 > (Binär)? Das kommt eben darauf an, wie du diese 4 Bytes interpretierst. 20327AC8 wäre die Big Endian-Interpretation. Maren K. schrieb: > Ist das denn im little endian gespeichert, weil das niederwertigste byte > auf der niederwertigsten Adresse gespeichert wurde und was bedeutet das > genau? Du hast das höchstwertigste Byte an der niedrigsten Adresse gespeichert! Die Ziffer ganz links (2) in der normalen Hex-Darstellung hat den höchsten Wert (16^7=268435456). Maren K. schrieb: > Dann ist es doch kein Little Endian Format mehr, Den Bytes an sich kann man nicht ansehen, welches Format das ist. Wenn du die Zahl 20327AC8 so ablegst, wäre das eine sehr unübliche Reihenfolge, die m.W. keinen bestimmten Namen ("xxx Endian") hat. Maren K. schrieb: > Muss man die Hexa zahlen nun in Dualzahlen umrechnen Du musst gar nix, wenn man nicht weiß wozu :-) Maren K. schrieb: > dann die exponenten bits und dann kommen die Mantissen? Plötzlich geht es um Floating-Point? Da ist eh alles anders.
Die Gedanken sind korrekt. Die Byte Reihenefolge wird benoetigt wenn zusammengesetzte Bytes interpretiert werden muessen. Wenn man ein (un)signed 16 oder 32 bit, einzeln angefasst werden muessen. Bei Rechnungen muss man das in der Regeln nicht, der compiler macht das schon richtig. Es wird benoetigt fuer komminikationsapplikationen. Wenn (un)signed 16 oder 32 bit Zahlen ueber UART, oder SPI oder so transportiert werden muessen. Eine Umrechnung von Binaer nach Hex ist nicht noetigt, das ist nur eine Interpretationsfrage fuer den Betrachter. Desgleichen Dezimal. Benoetigt man nicht. Nur wenn man effektiv eine Zahl auf einem Display darstellen will.
Maren K. schrieb: > Wenn z.B. folgende Hexadezimalzahlen im 4Byte Speicher (auf Adresse > 0001(Hexa) bis 0003(Hexa) ) abgelegt habe: > > 20 (Hexa) > 32 (Hexa) > 7A (Hexa) > C8 (Hexa) Dann hast du im Little Endian die 32-Bit Zahl C87A3220 - oder - die beiden 16 Bit Zahlen 3220 und C87A gespeichert. in Big Endian hast die die 32-Bit Zahl 20327AC8 - oder - die beiden 16 Bit Zahlen 2032 und 7AC8 gespeichert. Übrigens: wir benutzten im Westen Big Endian für Zahlen, da in z.B. "2018" mit der grössten Stelle angefangen wird. Im Arabischen tauchte diese Zahl dagegen im Schriftbild zwar genauso auf, würde aber von rechts nach links gelesen! Daher Arabisch=Little Endian!
Hi, auf Seite 12 und 13 wird darauf eingegangen. Dasselbe Dokument ist mit anderem Inhalt jetzt im Netz, da fehlt das. Habe noch das alte gefunden. Da fängt es an: Zitat "...To help understand the difference between Big and Little Endian let's take a closer look at how data is stored in Flash Program Memory..." "...Wait a minute - that looks backward. From reading about the .DB assembly directive can you discover why?..." /zitat ciao gustav
:
Bearbeitet durch User
Angehängte Dateien:
-
Little_Endian.png
5,7 KB
Wäre es so wie ich es mir zusammengereimt habe (Anhang) richtig?
Wenn du wie beschrieben C8, also das an Adresse 3 (ich denke mal die 4 ist ein Tippfehler) gespeicherte Byte als Höchstwertigstes auffasst, wäre das Little Endian, und die Zahl lautet C87A3220. Die Frage ist nun noch was du mit "Byte 1"... "Byte 4" meinst; diese Nummerierung läuft entgegen der Adresse?
Maren K. schrieb: > Wenn ich bspw. > Daten im Little-, big oder mixed-Endian abspeicher Wen du das tust - was in der Praxis eher selten der Fall ist, denn schon die einfachsten Prozessoren haben Lade/Speicherbefehle für 16 Bit-Integer oder mehr, und da ist die Frage, wie der Prozessor selbst die Zahlen im Speicher ablegt. 8080/Z80/8086 benutzen von sich aus Little Endian oder anders gesagt LSB first. Wenn man den Speicherinhalt mit einem Hex-Editor betrachtet, stehen daher längere Zahlen sozusagen verkehrt herum in der Anzeige, aber daran gewöhnt man sich wenn man auf Assembler-Ebene arbeitet. Als Programmierer hat man mit dem Problem nur zu tun wenn man die Bytes einer Zahl einzeln bearbeitet, also wenn man z.B. die Bytes eines 16-bit-Registers einzeln lädt mit LD H,nn und LD L,nn. Nimmt man gleich einen 16bit-Befehl wie LD HL,nnnn macht der Prozessor das automatisch richtig, das gleiche gilt unabhängig von der Assemblerversion für einen C-Compiler. Probleme treten auf wenn man Daten byteweise überträgt, denkt man sich z.B. ein Protokoll für serielle Schnittstellen aus, so muss man auch festlegen, wie Zahlen aus mehreren Bytes übertragen werden. Einfacher und besser prüfbar ist es, Zahlen in ASCII-Darstellung zu übertragen, Funktionenpaare wie printf / scanf interpretieren die Zahlenwerte dann schon richtig (wobei eine lesbare Zahl Big Endian ist, das MSB kommt zuerst). Ist mit der Zeit Routine, als 8086-Programmierer liest man grössere Integer bei einer byteweisen Anzeige schon automatisch von rechts nach links. Georg
Name H. schrieb: > Die Gedanken sind korrekt. Die Byte Reihenefolge wird benoetigt wenn > zusammengesetzte Bytes interpretiert werden muessen. So isses. Fast. Die korrekte Formulierung wäre: "wenn man Wörter korrekt interpretieren will, die aus mehr als einem Byte bestehen". > Eine Umrechnung von Binaer nach Hex ist nicht noetigt, das ist nur eine > Interpretationsfrage fuer den Betrachter. So isses. Intern ist alles binär, jedenfalls bei allen heute praktisch relevanten Rechenknechten.
Luther B. schrieb: >[...] > Übrigens: wir benutzten im Westen Big Endian für Zahlen, da in z.B. > "2018" mit der grössten Stelle angefangen wird. Im Arabischen tauchte > diese Zahl dagegen im Schriftbild zwar genauso auf, würde aber von > rechts nach links gelesen! Daher Arabisch=Little Endian! Onsen! Im arabischen wird zwar der Text von rechts nach links geschrieben, Zahlen aber, wie bei uns, auch wenn sie innerhalb des Textes stehen, von links nach rechts mit genau derselben Wertigkeit der Stellen. (Macht übrigens die Programmierung von Eingabefeldern für Arabisch noch ein wenig schlimmer, als es so schon ist. Btdt...) Klugscheisst Baku
Bist Du wirklich sicher, dass es sich bei Deinen Zahlen um Fließkommazahlen mit einfacher Genauigkeit gemäß IEEE 754 handelt? Normale positive Zahlen (unsigned) werden "ganz normal" durchgezählt von 0 bis (2^32)-1; vorzeichenbehaftete (signed) werden durchgezählt von -(2^31) bis (2^31)-1, d.h. im Zweierkomplement. Ein Exponent wird da überhaupt nicht benötigt. Ein Sonderfall wäre noch die Einerkomplementdarstellung, wie sie z.B. für manche Prüfsummen oder kryptografische Zwecke benötigt wird. Ist es eigentlich Zufall, dass die Werte Deiner vier Bytes aufsteigend bzw. absteigend sind? Verwechselst Du die Position des jeweiligen Bytes womöglich mit dessen Inhalt? Die Bytes dürfen natürlich niemals nach den Inhalten sortiert werden!
Andreas S. schrieb: > Bist Du wirklich sicher, dass es sich bei Deinen Zahlen um > Fließkommazahlen mit einfacher Genauigkeit gemäß IEEE 754 handelt? Wo hat das jemand behauptet?
georg schrieb: > oder anders gesagt LSB first Stop! LSB ist per definitiones Lowest significant BIT! nicht Byte. Es wird aber Byteweise abgespeichert. Dieser Teilsatz ist also falsch!
Rufus Τ. F. schrieb: > Andreas S. schrieb: >> Bist Du wirklich sicher, dass es sich bei Deinen Zahlen um >> Fließkommazahlen mit einfacher Genauigkeit gemäß IEEE 754 handelt? > > Wo hat das jemand behauptet? Maren K. schrieb: > wobei das erste bit das > Sign bit ist, dann die exponenten bits und dann kommen die Mantissen? Außerdem hat Maren in dem Bildchen die Bits mit s, e7 bis e0, m23 bis m0 bezeichnet. Das wäre typisch für IEEE 754 mit einfacher Genauigkeit.
Der Andere schrieb: > Stop! LSB ist per definitiones Lowest significant BIT! nicht Byte. > > Es wird aber Byteweise abgespeichert. Dieser Teilsatz ist also falsch! Nein, um Verwirrung zu stiften, wird die Abkürzung LSB sehr häufig auch für Least Significant BYTE verwendet. Besser wäre natürlich LSO (Least Significant Octet), also typischer ETSI-Sprech.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.