NASM: Programmfehler und Inhalt/ Adressen von Variablen
-
org 100h cpu 8086 START: mov bx, BYTE1 WDH: mov al, [bx] out 0, al inc bx jmp WDH ; Der Programmcounter des Assemblers erreicht ; hier den Wert 10Ah BYTE1 db 13 ;Adr = Inhalt = TEXT1 db 'Maschinennahes';Adr = Inhalt = db ' Programmieren' times 4 db 0 ;Adr = Inhalt = WORT1 dw 1234 ;Adr = Inhalt = DWORT1 dd 23456789 ;Adr = Inhalt =ALso ich soll folgendes Programm auf Fehler untersuchen.
Hab leider nicht soviel Ahnung von Assembler.Ist es richtig das das Programm in ner Endlossschleife läuft?
Sind die Varaiablen TEXT1 , WORT1, DWORT1 nicht überflüssig weil sie garnicht im Programm verwendet werden.
Und wie bekommt man den Inhalt und die Adr an den auskommentierten Stellen raus?
-
Dragonslayer schrieb:
[...]Hab leider nicht soviel Ahnung von Assembler.
Irgendwie beschleicht mich das Gefuehl, du sollst diese Aufgabe loesen, um das zu aendern.
Dragonslayer schrieb:
Ist es richtig das das Programm in ner Endlossschleife läuft?
Jup.
Dragonslayer schrieb:
Sind die Varaiablen TEXT1 , WORT1, DWORT1 nicht überflüssig weil sie garnicht im Programm verwendet werden.
...IMHO ist der Begriff Variable hier nicht ganz zutreffend...
Die Labels sind im Grunde vielleicht ueberfluessig und dienen hier bestenfalls der Uebersichtlichkeit. Die Speicherinhalte dahinter werden in dem Programm wahrscheinlich aber ausgelesen (wenn man davon ausgeht, dass die Labels mit DS adressiert werden koennen).Dragonslayer schrieb:
Und wie bekommt man den Inhalt und die Adr an den auskommentierten Stellen raus?
Inhalt: Augen aufmachen und lesen. Steht davor im Quellcode.
Adresse: Quellcode genau lesen, den Kommentar ueber den Labels entdecken und mal 1min scharf ueber diesen und darueber wie viel Platz die hinter den Labels abgelegten Daten verbrauchen, bzw. wie sich das auf die Adresse auswirkt, nachdenken.
-
org 100h ;starte bei adresse 256d cpu 8086 START: mov bx, BYTE1 ;Kopiere Byte in das bx register WDH: mov al, [bx] ;Schiebe den Inhalt von bx in das al register out 0, al ;Gebe al in 0 aus inc bx ; erhöhe den wert von bx um 1 jmp WDH ; Springe zu WDH ; Der Programmcounter des Assemblers erreicht ; hier den Wert 10Ah / 266d BYTE1 db 13 ;Adr =100h Inhalt = Dh TEXT1 db 'Maschinennahes';Adr =101h Inhalt = db ' Programmieren' //Adr =102h times 4 db 0 ;Adr =103h Inhalt = WORT1 dw 1234 ;Adr =107h Inhalt =4D2h DWORT1 dd 23456789 ;Adr =10Ah Inhalt =165EC15hAlso habs mir nochmal angeshen und versucht was auf die reihe zu bekommen.
Bin mir nicht sicher was
times 4 db 0 ;Adr =103h Inhalt =macht.
Sind das nicht einfach 4 Nullen die er in die nächsten 4 adressen schreibt? also:
102h 'Progammieren'
103h 0
104h 0
105h 0
106h 0
107h 1234
-
Zuerst sei mal angemerkt, dass die Adresse bei "BYTE1" ganz sicher nicht 100h ist. Schau dir das nochmal genau an.
Weiters waere das ja wirklich ein toller Kompressionsalgorithmus, der die beiden Strings 'Maschinennahes' und ' Programmieren' jeweils auf 1 Byte schrumpft. Denk darüber nochmal nach.
Mit einem hast du, wenn ich das richtig verstanden habe, allerdings recht: "times 4 db 0" erzeugt 4 0-Bytes. Entspricht uebrigens "dd 0" (ein 0-DWord).
-
Achso der startet bei 10Ah mit der label deklaation,
folglich ist BYTE1 Adr= 10Ah
TEXT1 'Maschinennahes' Adr= 10Bh
' Progammieren' Adr = 119h
times Adr = 127h
WORT1 Adr = 12Bh
DWORT1 Adr = 12Dh
-
Jo, das wuerde ich auch so sehen.
-
hm ich hätte da noch ne Frage.
Hab das Prog heute mal im 8086 gehabt.
Den Inhalt der Variablen zeigt er ja in Hex an.
Bei den BYTE VAriablen und dem Bytestring hatte ich auch die selben hexwerte als inhalt wie vermutet, nur bei den als WORT bzw DOUBLEWORT Variablen stad was völlig anderes im Speicher als das was ich angenommen hab.Meine frage also wie rechnet man WORT bzw DOUBLEWORT in hex um?
-
Duerfte man fragen, was da nun drin stand?
Meinst du also, wie sich die Hex-Ziffern beim x86 aufteilen? Die x86 benutzen die Little Endian Byte-Reihenfolge.
Dh. 165EC15h sollte als 0x15, 0xEC, 0x65, 0x01 im Speicher liegen -> niederwertigstes Byte zuerst, hoechstwertigstes zuletzt.
-
Also nach Times db 0 stand im Speicher:
d2 04 15 EC 65 01
90 90 90 90vermute mal d2 04 steht für dw 1234 und 15 EC 65 01 für dd 23456789
nur warum?edit: achso, darauf bin ich garnet gekommen mal rückwärts zu lesen
-
Hm also bleibt immer noch die Frage zu klären wo der Fehler in dem prog liegt.
Ist diese Zeile nicht fehlerhaft?
mov al, [bx]müsste es nicht heissen
mov al,[bl]weil ich mein ax = al + ah
Man schiebt immerhin den gesamten inhalt der bx , der ja doppelt so groß sein muß wie ein teilregister in das al register.
besteht da nicht die gefahr das die hälfte verloren geht.oder denke ich grade falsch und der fehler liegt woanders?
-
Dragonslayer schrieb:
Hm also bleibt immer noch die Frage zu klären wo der Fehler in dem prog liegt.
Vielleicht solltest du erstmal klaeren, was mit "der Fehler" ueberhaupt gemeint ist. Einer oder mehrere? Syntaktische (dazu muesste man wissen, mit welchem Assembler das assembliert wird) oder semantisch...?
Rein binaer betrachtet ist der Code auf jeden Fall lauffaehig.
So pauschal wuerde ich daher sagen: Der Code ist absolut fehlerfrei.Dragonslayer schrieb:
Ist diese Zeile nicht fehlerhaft?
mov al, [bx]müsste es nicht heissen
mov al,[bl]Nein. Die 1. Version stimmt schon, die 2. ist falsch. Der x86 kann generell nicht mit 8Bit Subregistern adressieren.
Dragonslayer schrieb:
weil ich mein ax = al + ah
Man schiebt immerhin den gesamten inhalt der bx , der ja doppelt so groß sein muß wie ein teilregister in das al register.
besteht da nicht die gefahr das die hälfte verloren geht.
Scheint so, als verwechselst du da registerdirekte und -indirekte Adressierung.
Was du da beschreibst waere registerdirekte Adressierung. Das wuerde so aussehen:mov al, bx ; was du beschrieben hast - ist natuerlich falschEckige Klammern deuten aber beim x86 eigentlich immer auf Speicheradressierung hin. In diesem Fall wird ein Speicheroffset ueber ein Register adressiert (bx) - dh. die Speicheradresse, die ausgelesen werden soll, steht in bx, und das Byte im Speicher, auf das bx zeigt, wird in al geladen. Das nennt man registerindirekte Adressierung.