DWORD PTR



  • Hallo!

    Was bedeutet dieses "PTR" im Disassembly? Dass es für Pointer steht, kann ich mir schon denken, aber was tut es?

    mov    DWORD PTR [ebp-0x8],0xcc
    

    Vom Assembler programmieren kenne ich nur folgendes:

    mov    DWORD [ebp-0x8],0xcc
    

    Ich muss beim Dereferenzieren einer Adresse natürlich angeben, ob ich sie als BYTE, WORD oder DWORD ansprechen möchte. Aber dieses "PTR" hab ich dazu noch nie verwendet gehabt.


  • Mod

    Das ist nur eine syntaktische Variante.



  • danke für AW!



  • DAS PTR wird nur bei MASM verwendet.

    Die Angabe ob BYTE, WORD, oder DWORD wird nur bei Operanden mit Imediate Werte benötigt, weil andernfall ein Register mit bekannter Grösse verwendet wird.

    Aussnahme: bei "MASM" mit 32bit-Register als Operand wo trotzdem eine "DWORD PTR"-Angabe gemacht werden muss. Bei 16 Bit und 8 Bit Registern aber nicht.
    Beispiel
    mov DOWRD PTR[edi],eax
    mov [edi],ax
    mov [edi],al
    Mit imediate Wert:
    mov BYTE PTR[edi],0FFh
    mov WORD PTR[edi],0FFFFh
    mov DWORD PTR[edi],0FFFFFFFFh

    Anders bei "NASM":
    mov [edi],eax
    mov [edi],ax
    mov [edi],al
    Mit imediate Wert:
    mov BYTE[edi],0FFh
    mov WORD[edi],0FFFFh
    mov DWORD[edi],0FFFFFFFFh

    Dirk



  • ah das wirds gewesen sein. ich hab bis jetzt immer in NASM programmiert, während ich beim Disassembler einfach das Intel Format eingestellt habe und dachte dass ist genau das gleiche wie NASM, aber offensichtlich gibts da dann doch feine Unterschiede.



  • freecrac schrieb:

    Aussnahme: bei "MASM" mit 32bit-Register als Operand wo trotzdem eine "DWORD PTR"-Angabe gemacht werden muss.[...]
    Beispiel
    mov DOWRD PTR[edi],eax

    Das stimmt so nicht.
    Der Type muss nur angeben werden, wenn dieser sich nicht aus den Operanden oder dem Befehle erschließen lässt. Daher wird auch MOV [EDI],EAX akzeptiert.



  • foo_bär schrieb:

    freecrac schrieb:

    Aussnahme: bei "MASM" mit 32bit-Register als Operand wo trotzdem eine "DWORD PTR"-Angabe gemacht werden muss.[...]
    Beispiel
    mov DOWRD PTR[edi],eax

    Das stimmt so nicht.
    Der Type muss nur angeben werden, wenn dieser sich nicht aus den Operanden oder dem Befehle erschließen lässt. Daher wird auch MOV [EDI],EAX akzeptiert.

    Aha,gut zu wissen, aber seit welcher MASM-Version ist das schon so?

    Weil MASM 5.00(vom 6. Aug 1987) mit einem "MOV [EDI],EAX" noch nicht klar kommt und dann mit einem schweren Fehler abbricht.
    Aber mit "MOV DWORD PTR[EDI],EAX" geht es dann prima.

    Dirk



  • fdsfsdfsfs schrieb:

    ah das wirds gewesen sein. ich hab bis jetzt immer in NASM programmiert, während ich beim Disassembler einfach das Intel Format eingestellt habe und dachte dass ist genau das gleiche wie NASM, aber offensichtlich gibts da dann doch feine Unterschiede.

    Es gibt noch einen weiteren bedeutender Unterschied:

    FOO db 0,0,0,0,0,0,0
    
    ; NASM: 
            mov si, FOO        ; holt Offset-Adresse von FOO
    
    ;-------------------------------------------------------
    
    ; MASM:
            mov si, offset FOO ; holt Offset-Adresse von FOO
            mov si, [FOO]      ; holt den Inhalt von FOO
    
            mov si, FOO        ; holt ebenfalls den Inhalt von FOO
    

    Den letzten Befehl sollte man so besser nicht ohne eckige Klammern verwenden wegen der Verwechslungsgefahr menschlicher Leser, wird aber als ein Befehl mit eckigen Klammern von MASM interpretiert.

    Dirk



  • freecrac schrieb:

    Aha,gut zu wissen, aber seit welcher MASM-Version ist das schon so?
    Weil MASM 5.00(vom 6. Aug 1987) mit einem "MOV [EDI],EAX" noch nicht klar kommt und dann mit einem schweren Fehler abbricht

    Bemerkenswert das jemand noch ein solches Fossil verwendet 🕶
    MASM 6.1x sollte es heutzutage mindestens sein, empfehlen würde ich aber 8+ oder jWasm.

    BTW: vielleicht mal eine Blick in MASM 6.11 Programmer's guid werfen - es hat sich doch eignes von Version 5.x nach 6.0/6.1 getan.



  • foo_bär schrieb:

    freecrac schrieb:

    Aha,gut zu wissen, aber seit welcher MASM-Version ist das schon so?
    Weil MASM 5.00(vom 6. Aug 1987) mit einem "MOV [EDI],EAX" noch nicht klar kommt und dann mit einem schweren Fehler abbricht

    Bemerkenswert das jemand noch ein solches Fossil verwendet 🕶

    Für 16 Bit DOS-Anendungen, die ihrerseits selber in den PM schalten wollen und wo man kein 32Bit-PM zum Assemblieren verwendet werden kann braucht man mit MASM 5 nicht pausenlos neubooten, um die Anwendung zu testen.

    MASM 6.1x sollte es heutzutage mindestens sein, empfehlen würde ich aber 8+ oder jWasm.

    Ja MASM 6.1x ist schon interessant, weil z.B. MMX-Befehle kennt MASM 5 noch gar nicht und dann muss man diese mit MASM 5 von Hand coden, was relativ aufwendig ist. Nur zum Testen eigener Anwendungen die selber in den PM schalten wollen muss man halt immer wieder neu booten, was man mit MASM 5 nicht braucht, weil MASM 5 auch im 16 bit RM arbeiten kann, aber MASM 6.x kann das nicht mehr.
    Aus diesem Grund verwende ich gelegentlich auch immer noch MASM 5.

    Aber wirklich empfehlen kann ich MASM 5 auch nicht. So hat mir MASM 5 auch schon Befehle erzeugt, die im Listing gar nicht enthalten waren und womit das Programm abstürzte. Die Suche im Listing nach dem Fehler war erfolglos. Aber wer rechnet denn gleich damit das MASM 5 fehlerhaft arbeitet. Erst als ich die *.exe untersucht habe, bemerkte ich das MASM 5 dort andere Befehle eingetragen hat, die gar nicht im Listing enthalten waren. Wirklich reproduzieren konnte ich diesen Fehler aber leider nicht. Nachdem ich im Listing an der fehlerhaften Stelle einige Befehle umgestellt habe, verwand der Fehler und tauchte nicht wieder auf und die Anwendung arbeitete fortan fehlerfrei. Das war schon sonderbar.

    BTW: vielleicht mal eine Blick in MASM 6.11 Programmer's guid werfen - es hat sich doch eignes von Version 5.x nach 6.0/6.1 getan.

    Oh ja, dieses Werk kenne ich wirklich noch gar nicht und werde es mir gleich näher anschauen. Vielen Dank für deine Aufmerksamkeit und Hinweise.

    Dirk


Log in to reply