Hallo, mich plagt eine Verständnisfrage: Wenn ich auf einem Rechner mit Big Endian die Dezimalzahl 5000 als 16-bit Zahl speichere und diese dann direkt aus dem Speicher auf einen Rechner mit Little Endian überspiele, und nichts geordnet bzw. umgeschrieben wurde. Was gibt der Rechner dann mit Little Endian aus? Muss man zuallererst die Dezimalzahl 5000 als 16bit Dualzahl darstellen, oder kann man es auch als Dezimalzahl lassen?
Pat ". schrieb: > Was gibt der Rechner dann mit Little Endian aus? 34835 Pat ". schrieb: > Muss man zuallererst die Dezimalzahl 5000 als 16bit Dualzahl darstellen, Ja
Was wäre wenn man eine Zeichenkette: "MIKR" bei einem Big-Endian Format Rechner hat und diese dann ohne Umordnung in einem Little Endian Rechner ausgibt? Da würde dann: "IMRK" rauskommen oder?
Nein, Zeichenketten werden immer mit aufsteigender Adresse gespeichert. Bernd
Little Endian : M I K R -> "MIKR" Big Endian : -> "IMRK" So hätte ich mir das gedacht... Ist das nicht das gleiche Prinzip, wie bei Dezimalzahl 5000 als Dualzahl Ursprungsfrage, da gilt ja auch: 5000 = | 0001 0011 | 1000 1000 | als Big Endian. in Little Endian ausgelesen, dann: 1000 1000 0001 0011 = 34835 in dez.
Endian gilt nur und ausschließlich für einen Basistyp Char: egal, weil nur 1 Byte 16 Bit (z.b. short) Bytes vertauscht 32 Bit (z.b. long) 4 Bytes umgedreht 64 Bit (z.b. Double) ... Arrays oder Strukturen werden nicht gedreht, nur jeder Basistyp darin. Bei bitfeldern ist das analog, führt hier jetzt aber zu weit. Ein String ist ein Array von char. Darum nicht drehen. Hast Du wide Strings (z.b. utf-16) dann wird jedes Zeichen in sich gedreht.
Oke ja aber dann dürfte das mit Dezimalzahl 5000 eh passen, oder? Da haben wir ja 2 Byte: 5000 dez. = 00010011 10001000 Im Big Endian Format also : 00010011 10001000 Im Little Endian Format: 10001000 00010011 = 2^15 + 2^11 + 2^4 + 2^1 + 2^0= 34835 Hier wird ja auch nur die BYTEplatzierung vertauscht und nicht die BITplatzierung.
Nimm einfach eine CPU die zur Laufzeit die Endianess wechseln kann, z.B. aus der Renesas SH-3 Reihe.
Pat ". schrieb: > 16-bit Zahl ... > Was gibt der Rechner dann mit Little Endian aus? signed oder unsigned? -30701 bzw. 34835
Klugscheisser schrieb: > Nimm einfach eine CPU die zur Laufzeit die Endianess wechseln kann, > z.B. aus der Renesas SH-3 Reihe. Auch wieder so ein Feature aus der "Braucht kein Mensch"-Klasse. Also echt: wozu, um alles in der Welt, soll das denn gut sein?
c-hater schrieb: > wozu, um alles in der Welt, soll das denn gut sein? Also das ist ganz praktisch: wenn man versehentlich zweimal gedreht hat, kann man damit erneut drehen. Dann passt es in 50% der Fälle.
Danke für die zahlreichen Kommentare. Zum Thema signed oder unsigned, was da genau gefragt war, weiß ich jetzt nicht mehr. Aber das Prinzip ist ja das selbe bezüglich "Endianess". Zur Zeichenkettefrage wie würdet ihr das handhaben? So wie ich?(zitierter Beitrag) Mic ". schrieb: > Was wäre wenn man eine Zeichenkette: "MIKR" bei einem Big-Endian Format > Rechner hat und diese dann ohne Umordnung in einem Little Endian Rechner > ausgibt? > Da würde dann: "IMRK" rauskommen oder?
Mic ". schrieb: > Zur Zeichenkettefrage wie würdet ihr das handhaben? So wie > ich?(zitierter Beitrag) Zeichenkette bleibt wie sie ist. Dort musst du nichts umdrehen. "Test" bleibt "Test".
Rechner hört sich für mich jetzt nach PC an und wenn du da quasi einen Speicher-Dump holst und weiterverarbeiten willst, dann mußt du natürlich wissen, wie der Speicher organisiert ist. Das kriegt man dann aber mit ein paar einfachen Test-Pattern raus. Wenn du Controller meinst, dann bist du ja selbst dafür verantwortlich, wie dein Speicher organisiert ist. Bei Hochsprachen kenn ich mich nicht so aus, denke aber, dass das erst mal nicht wichtig ist, es sei denn, du willst explizit ein bestimmtes "Format" im Speicher haben. Ich kenne das aus der hardwarenahen Verarbeitung von WAV-Dateien. Dort mußt du natürlich wissen, wie deine Daten-Bytes abgelegt werden/wurden. Auf der höheren Ebene, z.B. in Python, kannst du das Format einfach vorgeben. In Assembler schaut man z.B. wie der Programmcounter im Ram abgelegt wird und es ist dann eine gute Idee, das bei eigenen Speicheroperationen genau so zu machen. Du schreibst also zuerst immer das High-Byte und dann das Low-Byte...beim Lesen machst du es umgekehrt...und hast damit keine Probleme (oder Schlimmeres). Und natürlich kann man die Vertauschung im Dezimalsystem auch machen, im Binärsysten mit Bytes ist es m.A. aber deutlich klarer. Gruß Rainer
Mic ". schrieb: > Was wäre wenn man eine Zeichenkette: "MIKR" bei einem Big-Endian Format > Rechner hat und diese dann ohne Umordnung in einem Little Endian Rechner > ausgibt? > Da würde dann: "IMRK" rauskommen oder? Ja, ich denke das past. Anordnung bei Big- Endian: 0|M I|1 2|K R|3 die Zahlen vor dem Buchstaben stehen für die Adresse. OHNE UMORDNUNG an Little Endian Rechner ausgegeben : 1|M I|0 3|K R|2 also der Reihenfolge nach 0,1,2,3 -> IMRK So finde ich auch das, dies richtig ist. Warum sollte sich dort auch nichts ändern??
Pat ". schrieb: > Anordnung bei Big- Endian: > > 0|M I|1 > 2|K R|3 > > die Zahlen vor dem Buchstaben stehen für die Adresse. Richtig. > OHNE UMORDNUNG an Little Endian Rechner ausgegeben : > 1|M I|0 > 3|K R|2 Wieso OHNE UMORDNUNG? Du hast die Bytes doch gerade umgeordnet: An Adresse 0, wo vorher ein 'M' stand, steht jetzt ein 'I', an Adresse 1 hast du das 'I' durch ein 'M' ersetzt usw. Aber genau diese Umordnung findet eben nicht statt. Sowohl bei little als auch bei big Endian werden die Elemente eines Byte-Arrays in ihrer natürlichen Reihenfolge im Speicher abgelegt:
1 | Adresse Inhalt |
2 | ─────────────── |
3 | 0 'M' |
4 | 1 'I' |
5 | 2 'K' |
6 | 3 'R' |
7 | ─────────────── |
Wäre dies nicht so, dann könnte man nicht einfach in einer Schleife mit aufsteigendem Index über die Elemente des Arrays iterieren:
1 | char s[] = "MIKR"; |
2 | for (int i=0; i<4; i++) |
3 | putchar(s[i]); |
4 | |
5 | // Ausgabe: MIKR
|
Wenn man aber eine Union aus 1 long und 4 chars macht, und diese "Zeichen" dann tatsächlich wie einen kleinen "String" behandelt und mit binären "Zeichen" aus z.B. der seriellen Schnitte füllt, dann kann es schon mal sein, dass man verdutzt aus der Wäsche guckt...
Pat ". schrieb: > So finde ich auch das, dies richtig ist. Warum sollte sich dort auch > nichts ändern?? Zu meinem Job gehört unter anderem Daten von Siemens SPS Steuerungen (big endian) mit PC aus zu lesen (little endian) um in SQL Datenbank zu schreiben. Ein bisschen Erfahrung dürfte ich dabei gesammelt haben. Aber du kannst es einfach ausprobieren und hier berichten ob das, was du für richtig hältst, auch wirklich so stimmt.
Yalu X. schrieb: > Wäre dies nicht so, dann könnte man nicht einfach in einer Schleife mit > aufsteigendem Index über die Elemente des Arrays iterieren: Man nehme einen Prozessor, der Bytes big endian adressiert, Bits aber little endian. In dem man also mit Bytebefehlen Byte-Arrays im Speicher direkt adressiern kann, 4 Mrd Bytes am Stück. Und in dem man mit Einzelbitbefehlen Bit-Arrays im Speicher direkt adressieren kann. 4 Mrd Bits am Stück. Und nun füge man in der nächsten grösseren Architekturrevision Befehle für Bitfelder hinzu. Und überlege sich, wie man diese Bitfelder adressiert, wenn sie über Bytegrenzen gehen können. Also beispielsweise ein dicht gepacktes Array aus 5 Bit breiten Feldern. Wenn man sich das aufmalt und die Operationen durchspielt, wird man feststellen, dass die little endian Bitnummerierung der ersten Architektur ein Schuss in Knie war, und man für die Bitfelder auf big endian umsteigen muss. Das Ergebnis war nun eine Architektur mit big endian Byteorder, little endian Bitorder und big endian Bitfields. In Silizium verewigte Dummheit könnte man das nennen. So geschehen bei 68000 und 68020. Vergleichweise harmlos war dagegen die PDP-11. Bei der waren die Bytes little endian, aber 32-Bit Worte hatten im Speicher das höherwertige 16-Bit Wort vorneweg. Launisch auch als middle endian bezeichnet. Netterweise machte es die (weniger bekannte) Konkurrenz von Honeywell genau umgekehrt.
:
Bearbeitet durch User
Pat ". schrieb: > Muss man zuallererst die Dezimalzahl 5000 als 16bit Dualzahl darstellen, > oder kann man es auch als Dezimalzahl lassen? Du kannst sie so lassen, weil beides das gleiche ist. Ein Assembler oder Compiler legt eine Zahl immer binär ab, weil die CPU nur binär rechnen kann. Für das Rechnen in packed BCD braucht es spezielle Bibliotheken.
Ja aber die Frage ist doch: Speicher eines Rechners mit Big Endian Format enthält Zeichenkette "MIKR". Dieser Speicherinhalt wird Byte für Byte in Datei abgespeichert, und diese Datei wird auf einem Rechner mit Little Endian Format Byte für Byte am Bildschirm ausgegeben. Was wird am Bildschirm anezeigt? Das es in der Prais nicht IMRK ausgegeben wird, ist sicherlich so aber hier bei der Frage geht es doch eher darum das man versteht das die Adressierungen bei Big Endian und Little Endian vertauscht sind, oder?
Pat ". schrieb: > Was wird am Bildschirm anezeigt? Genau das gleiche. Wenn man es byteweise anzeigt. Interessant wird es erst, wenn man es nicht byteweise darstellt, sondern beispielsweise in 16-Bit Gruppen. Wer Linux oder Windows Unix-Tools in Reichweite hat, der kann das mit od -c file (8 Bit Zeichen) od -x file (8-Bit Hex) od -tx2 file (16-Bit Hex) od -tx4 file (32-Bit Hex) mit einem File durchprobieren, das als Inhalt "ABCD" enthält. Das ist bei little endian Maschinencode ein durchaus realen Problem, wenn der nicht wie bei RISC in festen Worten codiert ist, sondern als Bytestream. Was bei der VAX dazu führte, dass deren Assembler im Listing die erzeugten Bytes von rechts nach links anordnete, damit man die darin enthaltene Konstanten noch wiederfand, ohne sich das Hirn zu verrenken.
:
Bearbeitet durch User
Pat ". schrieb: > Speicher eines Rechners mit Big Endian Format enthält Zeichenkette > "MIKR". Die Order spielt nur eine Rolle, wenn Du Zahlen 16Bittig ablegst aber 8Bittig ausliest. Bei Text ist die Order schnurz, da Lesen und Schreiben immer in der selben Breite erfolgt (ANSI bzw. Unicode).
Peter D. schrieb: > Die Order spielt nur eine Rolle, wenn Du Zahlen 16Bittig ablegst aber > 8Bittig ausliest. > Bei Text ist die Order schnurz, da Lesen und Schreiben immer in der > selben Breite erfolgt (ANSI bzw. Unicode). Das ist nicht ganz korrekt, denn es gibt Unicode-Codierungen, die mit 16bittigen Zahlen arbeiten. Dann spielt es eine Rolle. Und weil das so ist, gibt es dann auch den Unicode-BOM (byte order marker).
>direkt aus dem Speicher auf einen Rechner mit Little Endian überspiele,
Aus meiner Sicht ist das ein Fehler. Wenn Du quasi ein Protokoll für den
Datenaustausch baust, dann würde ich das explizit selbst tun. Ich finde
es falsch, einfach per memcpy irgendwelche plain Daten oder
Bausteinabbilder in den Sendepuffer einer Kommunikation zum Versenden zu
kopieren.
Ich würde das hier entweder in Strings umwandeln und als String
"Speed=5000" übertragen, oder ein binäres Protokoll selbst bauen. Dann
hast Du das selbst im Griff. Musst es aber selbst vorbereiten...
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.