Seite 1 von 1

Zusammenstellung des 16-Bit-Wortes aus dem Codesegment

Verfasst: 29. Nov 2007 00:20
von tmx-master
Hi,
ich habe eine Frage zur Zusammenstellung des 16-Bit-Wortes aus dem Codesegment.
Geg.: 0x1234 (für die 4 Nibbles des Wortes) -> 0xabcd

Für BE würde ich jetzt aus Christians Erklärung ableiten:
1. Füge ab und cd zusammen: 12 und 34
2. Füge zusammen nach abcd -> 0x1234 -> Wert: 4660

Für LE würde ich jetzt aus Christians Erklärung ableiten:
1. Füge ab und cd zusammen: ba und dc (21 und 43)
2. Drehe nach dcba -> 0x4321x -> Wert: 17185

Die Frage ist ziemlich wichtig, denn wenn diese Zusammenstellung nicht korrekt ausgeführt wird, sind alle nachfolgenden Sprungsadressen falsch.
Vielleicht kann jemand recht rasch antworten. Danke.

Verfasst: 29. Nov 2007 09:47
von Sascha
Hier mal ergänzend und verbindlich:

Die Nibbles werden der Reihe nach ausgelesen. Nennen wir sie von mir aus abcd. Da fliesst natürlich ganz automatisch die Endianess mit ein, da schließlich im Codesegment alle Nibbles der Endianess folgen. Soweit klar?

Wenn Sie Big Endian haben, ist nun das erste der ausgelesenen Nibbles (hier also "a") das höchstwertige, b ist das zweit-höchstwertige, c das dritt-höchstwertige und d das niedrigstwertige.

Wenn Sie Little Endian haben, ist das erste der ausgelesenen Nibbles (hier: a) das niedrigstwertige und d das höchstwertige.

Da gibt es sonst nichts zu shiften oder zu drehen.

Verfasst: 29. Nov 2007 16:15
von MisterD123
also das vorgehen zum richtig auslesen wäre:
1) im ganzen codesegment je nach endianess immer zwei nibbles vertauschen (der "datentyp" der nibbles ist dabei irrelevant, die immediate-werte werden genauso in den nibbles verdreht als wären es vier einzelne befehle)
2) nach einem LI-nibble 1 die folgenden vier "befehle" (im nach schritt eins "richtig-genibbleten" code, _nicht_ im unverdrehten original-bytecode) je nach endianess vorwärts oder rückwärts zu einer zahl zusammenketten und auf den stack pushen.

Verfasst: 29. Nov 2007 18:17
von Bappsack
Also haltet mich jetzt net für doof aber ich Blick gar nichts mehr! Am Anfang dachte ich wir tauschen Nibbels in jedem Byte! Aber es scheint als wenn wir im Codesegment auf jeden Fall in einem 16 Bit Wort die Byte vertauschen und die Nibbels ignorieren.

Beispiel:

Bei endian_b:
x00, x38 (cs size) ---> 56 Bytes (kommt hin und ist logisch!!!!)

Bei endian_l:
x38, x00 (cs size)
Byteweises drehen: x00, x38 ----> 56 IST RICHTIG!
Nibbleweises drehen: x00, x83 -----> 131 IST FALSCH!!!

So und das is nur eins von vielen Dingen die anscheinend mehrfach interpretiert werden können und uns die Arbeit (die wohl schon so nicht gerade gering ist, an dieser Stelle sorry an die anderen Professoren deren Vorlesungen ich nicht mehr besuche weil ich am Praktikum sitze!) erschweren!

Danke für Aufmerksamkeit und Antwort
MoH

Verfasst: 29. Nov 2007 19:53
von Bappsack
Zur allgemeinen Verwirrung folgendes:

Wir haben im little Endian von vorne herein alle Nibble in den Bytes getauscht! Jetzt haben wir versucht die Datei zu lesen, doch es kam bei Zahlen nach LI nur unmögliche Zahlen herraus! Dann ist uns aufgefallen, dass beim vergleich von der BigEndian datei und LittleEndian datei folgendes nur Möglich sein kann:

Beispiel: 41 -00 - 10
Alle Nibble in den Bytes drehen -> 14 - 00 - 01
Jetzt kommt als Zahl irgendwas mit 16000 ... herraus! Ist eine nicht so tolle Zahl^^ dazu kommt, dass es in BigEndian eine 4 ist (also eine 0004). Naheliegend ist nun die Zahl wieder zu drehen, damit etwas richtiges herrauskommt!

Das Wort 40-00 gedreht ----> 0004 WOW!!! Richtig!!! xD
Bedeutet das, dass wir zuerst alle Nibble drehen und darauf alle Wörter nochmal sepperat wie oben von Sascha beschrieben?

Im Header erklärt dass übrigens auch das mit dem Byte drehen, dass ist nämlich das gleiche wie zuerst Nibble und dann Wörter drehen :D

Viel Spaß noch beim verwirrt sein ^^
grüße
MoH

Verfasst: 29. Nov 2007 20:33
von Alexis1987
Hy,
also zunächst mal will ich Bappsack rechtgeben.
Mir geht es genauso.
Es gibt die Angaben.
Es gibt die Beobachtung und Untersuchung der svm-Dateien im Hexeditor die den Angaben nicht wirklich entsprechen.
Und es gibt das Forum wo "verbindliche" und "klare" Aussagen gemacht werden die irgendwie nicht den Angaben und irgendwie auch nicht zu den Beobachtungen passen.

Also ich will jetzt niemandem auf die Füße treten aber ich finde wenn das Praktikum darauf hinausläuft irgendnen Hexcode zu interpretieren und zu raten was wie gemeint sein könnte, wie gedacht und wie durchgeführt dann sollte das doch auch einfach in der Aufgabenstellung stehen.
Aber bis jetzt hab ich nur rausgelesen, dass wir ne Art VM machen sollen (Oder steht das rum genipple zwischen den zeilen).

Was mich dann noch mehr verwirrt ist folgendes:
1. Wir haben ne Assembler-Quelle, nehmen wir zB endian.s
2. Haben wir die daraus erzeugte datei endian_l.svm
3. Haben wir eine Binary die es uns ermöglicht selber aus Assembler-Quellen svm-Dateien zu machen

Wenn ich jetzt 3. auf 1. anwende erhalte ich aber nicht 2.

Und NEIN ich erhalte auch nicht endian_b.svm
Und JA ich habe die Aktuelle Binary ( 29.11. 20:25 Uhr runtergeladen)

Ich hab irgendwie keine Lust mehr auf dieses Praktikum, obwohl ich die aufgabe anfangs wirklich interessant fand.

Ich hoffe es kommt bald mal jemand der mal für Klarheit sorgt und evtl auch mal schaut ob vielleicht, unter Umständen, evtl, möglicher Weise tatsächlich eine Kleinigkeit bei dem Praktikum schief gelaufen ist.

Gruß Alexis

Verfasst: 29. Nov 2007 20:59
von Sascha
Die ganze Nibble-Geschichte wird auf dem Aufgabenblatt nur im Zusammenhang mit dem Codesegment erwähnt und hat auch nur da eine Bedeutung. Klar kommt da dann Mist raus, wenn man irgendwelche Nibbles dreht.

Ansonsten fließt die Endianess nur ein, wenn man aus zwei Bytes ein Word machen möchte.

Man kann es so umsetzen wie MisterD123 skizziert hat.

Verfasst: 29. Nov 2007 21:32
von Alexis1987
Sascha hat geschrieben:Die ganze Nibble-Geschichte wird auf dem Aufgabenblatt nur im Zusammenhang mit dem Codesegment erwähnt und hat auch nur da eine Bedeutung. Klar kommt da dann Mist raus, wenn man irgendwelche Nibbles dreht..
OK, aber ich versteh immernoch nicht wieso mir die "Test-Erstell-Exe" nicht die gleiche svm-datei erstellt wie die die ich bereits vorliegen hab.

Vielleicht steh ich ja alleine da aber wenn ich die Endian-Geschichte (also im eigentlichen Sinne) richtig verstanden habe sagen die uns in welche Reihenfolge wir Daten die aus mehreren "Segmenten" (zb Byte) in unseren Speicher legen. Niederwertigstes bzw Höchstwertiges "Segment" zu erst.
Durch die Aufgabe würde ich eigentlich von einem Nipple als Segment sprechen. Sprich ich schau wie ich die nipples ablege und nicht hier achte ich auf die Bytes und hier auf die Nipples.

Ich meine bei einer Ascii-Zeichenkette sagen wir auch net "och es handelt sich ja um nen satz also sehen wir ein ganzes Wort immer als Segment."

Ich hoffe es wurde klar was ich meine.

Aber gut zu wissen wie das ganze hier aussieht.
Sascha hat geschrieben:Ansonsten fließt die Endianess nur ein, wenn man aus zwei Bytes ein Word machen möchte.
Das heißt also für das LI :
Ich betrachte 3Byte (2,5 Byte kann ich nicht einlesen).
Drehe jetzt in jedem Byte die Nipples um.
und weil ich ja ein wort als Parameter an LI übergebe drehe ich in diesem Übergabewort nochmal die Bytes um.
und dass nennt sich dann L/B-Endianess??? ...naja ok.

Ich hab einfachmal folgendes in die Test-Erstell-Binary gejagt (Little-Endian):

LI 44015
POP

erhalten hab ich folgenden Hexcode (das unterstrichene ist der Code):
53 56 4D 10 03 00 00 00 00 00 00 00 00 00 F1 BE CA

Ich drehe die Nipples um:
1F EB AC

Ich drehe nochmal die Bytes um (weil ich ja ein Wort als Parameter habe und das ja L/B-Endianess ist ;) ):
1B AF EC
=> Hoppla... hmm dann nochmal zurück.

Diesmal drehe ich aber alle Nipples eines Wortes um (Weil das jetzt ja L/B-Endianess ist ;) ):
1A BE FC
Ja jetzt stimmts.

Also ist L/B-Endianess jetzt : ich drehe erst alle Nipples eines Bytes um und wenn 2 Byte dann ein Wort machen drehe ich nochmal alle 4 Nipples des Wortes zusammen um.

Ich weiß ja net... Hauptsache es klappt jetzt (wie auch immer)

Gruß Alexis

Verfasst: 29. Nov 2007 21:52
von Sascha
Okay, dann versuche ich mal, es an dem Beispiel zu erklären, in der Hoffnung die allgemeine Verwirrung zu entwirren und dem ganzen Rumgedrehe Einhalt zu bieten:

Wir haben F1 BE CA (Anmerkung: Das ist Big Endian geschrieben, weil wir das so gewohnt sind - aus Rechnersicht gibt es kein "Links" oder "Rechts" in den Zahlen.)

Die Datei ist Little Endian, also ist jeweils das niederwertige Nibble das, welches zuerst kommt. Also ausgeschrieben:

1. Nibble: 1
2. Nibble: F
3. Nibble: E
4. Nibble: B
5. Nibble: A
6. Nibble: C

Soweit klar?

Man sieht auch direkt, dass der erste Befehl ein LI (0x1) ist, gefolgt von 4 Nibbles, die das Argument darstellen und dann dem nächsten Befehl POP (0xC). Nach dem LI kommen also F, E, B, A in der Reihenfolge. Käme danach noch ein Opcode, wäre das an Stelle 7, weil POP keine Argumente hat. (Nur LI hat Argumente.)

Bis hierhin irgendwas unklar?

Die Frage ist nun, wie aus den vier Nibbles das Word entsteht. Da wir Little Endian haben, ist das erste Nibble, also das F dasjenige mit der niedrigsten Wertigkeit und das A ist das mit der höchsten Wertigkeit. In der gewohnten Big Endian-Schreibweise ist das also insgesamt 0xABEF, was 44015_{10} entspricht.

Inwiefern entspricht das jetzt nicht den Angaben, und inwiefern entspricht das nicht demjenigen, was ich weiter oben geschrieben habe?

Verfasst: 29. Nov 2007 21:54
von Bappsack
Also erstmal danke Alexis, dachte schon ich wäre alleine auf dieser Welt :D

Also wenn das mit dem drehen nur auf das Codesegment angewendet wird *überleg* Wieso wird dann auch (und zwar im Hex eindeutig erkennbar) auch im Header gedreht?

Und weiter bleibt immer noch ungeklärt wieso ich im Codesegment erstmal alle nibbles drehen muss und darauf nochmal jedes Wort (Bei LIs kommt das vor). Wenn ich das nicht mache, dann kommt nur nonsense raus!

Die Zeit schreitet fort und die Entdeckung neuer Probleme auch,
wünsche noch allen eine gute Nacht ;)
grüße
MoH

Verfasst: 29. Nov 2007 22:00
von Bappsack
Sorry, hatte noch geschrieben als du auch geschrieben hast Sascha.
Aber leider stimmt das nicht ganz so in der Umsetztung:

Wir haben nämlich folgendes Problem: (bei deinem Beispiel)

1. Nibble: 1
2. Nibble: F
3. Nibble: E
4. Nibble: B
5. Nibble: A
6. Nibble: C

Ließt sich die Zahl so leider nicht richtig, um eine Zahl die verwendbar ist herrauszubekommen muss man die Zahl nach dem LI so lesen:
A B E F ... ansonsten haben wir Zahlen, die teilweise als Sprungziele weit außerhalb von der Datei liegen und so 100% stimmen!

grüße
MoH

Verfasst: 29. Nov 2007 22:53
von Tim86
Da wir das Problem auch haben, eine kurze Nachfrage:

Sehe ich das richtig, dass der Endian nur dann eine Rolle spielt, wenn ich aus mehreren kleinen Einheiten (Bytes, Nibbles) größere Einheiten bilde (Wörter, Bytes)?

Verfasst: 30. Nov 2007 14:21
von Sascha
Bappsack hat geschrieben:Ließt sich die Zahl so leider nicht richtig
Was heißt "sie liest sich nicht richtig"? An dem Beispiel: Bei Big Endian, steht das höherwertige am Anfang, bei Little Endian das niederwertige.

Ich zitiere mich selbst aus obigem Posting:
Sascha hat geschrieben:Die Datei ist Little Endian, also ist jeweils das niederwertige Nibble das, welches zuerst kommt.
Das heisst, dass das "F" das niederwertigste ist. An dem "Schaubild" muss man also "nach oben" lesen => 0xABEF


Zu der anderen Frage:
Tim86 hat geschrieben:Sehe ich das richtig, dass der Endian nur dann eine Rolle spielt, wenn ich aus mehreren kleinen Einheiten (Bytes, Nibbles) größere Einheiten bilde (Wörter, Bytes)?
Richtig, die Endianess bestimmt allgemein, wie man aus kleineren Einheiten größere zusammensetzt.

Bezogen auf das Praktikum bestimmt sie, wie man aus Bytes oder Nibbles ein Wort zusammenbaut. (Letzters braucht man NUR beim Argument von LI.) Ausserdem bestimmt sie, wie man ein Byte im Codesegment in zwei Nibbles zerlegt.