Div Befehl (NASM) als Ergebnis immer 0



  • Hallo zusammen,

    Ich komme bei der Division in NASM nicht weiter.
    Erstmal der kurze Code:

    ORG 100h 
    CPU 486
    [BITS 16]
    ;section .text 
    
    start: 
    
            xor ax, ax
            xor bx, bx
            xor cx, cx
            xor dx, dx
    
          	mov ax, 200d
          	mov cx, 2000d
          	mul cx
    
          	mov word [bax], ax
         	mov word [bdx], dx
    
          	call ausgabe2       
    
           	mov dx, string
    	mov ax, 0900h
    	int 21h
    
    pende:
    	mov ax, 4C00h
    	int 21h				;programm beenden
    
    ;Variablen
    bax dw 0
    bdx dw 0
    string db "          ",10,13,"$"            ;Platz für 10 Zeichen
    
    ;Funktionen
    ausgabe2:
    
    	xor bx, bx
    	xor cx, cx
    
    	mov ax, word [bax]
    	mov dx, word [bdx]
    	mov cx, 10d
    	mov bx, string
    	add bx, 09d
    .schleife:
    	div cx
    	add dl, 30h
    	mov byte [bx], dl
    	xor dx, dx
    	dec bx
    	cmp ax, 0d
    	jg .schleife 
    
    ret
    

    Hier soll lediglich 200 mit 2000 multipliziert werden, das Ergebnis in AX:DX in zwei Puffern zwischenspeichern und in der Funktion Ausgabe in einen String umwandeln und ausgeben.

    Der Wert von AX:DX ist 400.000 also "mul bx" klappt schonmal...

    Nun aber zur Division. AX hat den Wert 6784 und dx den Wert 6. Wenn ich beides getrennt prüfe zeigt er mir die richtigen Werte an... aber er dividiert mir nicht

    DX:AX / CX

    AX müsste dann 40.000 enthalten und DX 0. Er zeigt mir als String aber immer 0 an.

    (Wenn ich das gelöst bekomme, kann ich meine Grafikroutine im 640x400x8 fertigstellen)

    Was gibt es bei der 16-bit Integerdivision in NASM zu beachten?
    Falls noch jemand weiß wie ich 32-bit .exe Dateien für DOS erstellen kann währe ich auch sehr dankbar. Bin von MASM auf NASM und habe noch ein paar Probleme.

    Danke und Gruß

    Nicky



  • supernicky schrieb:

    cmp ax, 0d
    	jg .schleife
    

    JG springt, wenn ZF=0 oder SF=OF (Sign=Overflow), also ein vorzeichenbehafteter Vergleich. Richtig ist JA (springt, wenn CF=0). Besser ist JNE (springt, wenn ZF=0), die letzte Division ergibt AX=0 und DX=irgendwas.

    Was gibt es bei der 16-bit Integerdivision in NASM zu beachten?

    In puncto NASM: nichts weiter als "BITS 16". Die "CPU"-Anweisung kannst Du weglassen, das ist genau andersrum wie bei MASM: ohne "CPU" erlaubt NASM alles.

    Falls noch jemand weiß wie ich 32-bit .exe Dateien für DOS erstellen kann währe ich auch sehr dankbar. Bin von MASM auf NASM und habe noch ein paar Probleme.

    Dunkel ist der Sinn Deiner Worte. Da DOS ein 16-Bit-System ist, gibt es keine "32-bit .exe Dateien für DOS". Wenn Du 32-Bit-Register benutzen willst (mov eax,ebx), dann tu das, NASM sorgt für die richtigen Prefixe. Wenn Du eine 32-Bit-EXE für Windows herstellen willst, dann brauchst Du noch einen Linker.

    viele grüße
    ralph



  • Hallo Ralph,

    Ich meinte auch nur die Benutzung der 32-bit Register.
    Code geändert auf jne .schleife, nun zeigt er mir die 400.000 an.
    In MASM liefen alle Programme mit dieser Schleife. Aber egal 🙂

    Also lag der Fehler nur in der Schleife bei der Division. Dann mach ich mich mal an die Grafikroutine.

    Bis bald und Danke für den Hinweis

    Nicky



  • supernicky schrieb:

    Aber egal 🙂

    Das ist nicht egal. Tut mir leid, aber NASM ist ein "Schurken-Tool" - unseriös und wahrscheinlich nicht vertrauenswürdig - meine subjektive Meinung. Wenn Du unter Windows programmierst, nimm die Tools von Microsoft, MASM, Visual Studio. Unter Linux gibt es die binutils mit GNU Assembler (gas) und GNU Compiler Collection (gcc). Damit bist Du auf der sicheren Seite.



  • supernicky schrieb:

    In MASM liefen alle Programme mit dieser Schleife.

    Es ist mir nicht gelungen, MASM zu diesem Fehler zu "überreden". Würdest Du bitte die Schleife im MASM-Quellcode posten, um meine Neugier zu befriedigen? Danke.

    viele grüße
    ralph



  • aber NASM ist ein "Schurken-Tool" - unseriös und wahrscheinlich nicht vertrauenswürdig

    Wie kommst du darauf?



  • abc.w schrieb:

    supernicky schrieb:

    Aber egal 🙂

    Das ist nicht egal. Tut mir leid, aber NASM ist ein "Schurken-Tool" - unseriös und wahrscheinlich nicht vertrauenswürdig - meine subjektive Meinung. Wenn Du unter Windows programmierst, nimm die Tools von Microsoft, MASM, Visual Studio. Unter Linux gibt es die binutils mit GNU Assembler (gas) und GNU Compiler Collection (gcc). Damit bist Du auf der sicheren Seite.

    Hallo abc.w,

    ich schreibe nur .com Programme unter DOS aus reiner Neugier wie alles funktioniert.

    Gruß, Nicky



  • doppelter Beitrag


Anmelden zum Antworten