newbie question about dword ptr

[s***@crayne.org]

void Process(CTest* t , GETAMOUNT GetAmont)
...
...
...
30: __asm{
31: mov ecx, t ;t is the this pointer
-->004113E5 8B 4D 08 mov ecx,dword ptr [t]
32: call GetAmont
-->004113E8 FF 55 0C call dword ptr [GetAmont]
33: mov nResult, eax
-->004113EB 89 45 F8 mov dword ptr [nResult],eax
34: }
...
...

My question is: at line 31, why "mov ecx, t" was translated into "mov
ecx,dword ptr [t]"?
"t" is a pointer contains an address, while "dword ptr [t]" is a
dereference action to get the value that "t" point to?

Thanks in advance!

[s***@crayne.org]

't' is a pointer. The fact that on 32-bit systems a pointer is a
dword is not germane. The 'dword ptr' indicates that 't' is a pointer
that points to an unsigned 32-bit value. If it said 'word ptr' it
would have only accessed 16-bits at the address pointed to by 't'. Of
course the destination would have to be a 16-bit register 'ax' for it
to resolve simply. Another reason for the manifest display of 'dword
ptr' is to let you know that the assembler has made an assumption
about the size of what is pointed to. If you were attempting to move
the data to something that does not have a size associated with it,
the assembler would give a warning or error saying it couldn't
determine from either the source or destination the correct size for
the move. An 'add' comes to mind as one where this may happen because
an 'add' of an 8-bit value to a 32-bit register is legal, but if the
assembler cannot know that the source is 8-bit, then it is an error
since that instruction does not require identical sizes.

Post by s***@crayne.org
void Process(CTest* t , GETAMOUNT GetAmont)
...
...
...
30: __asm{
31: mov ecx, t ;t is the this pointer
-->004113E5 8B 4D 08 mov ecx,dword ptr [t]
32: call GetAmont
-->004113E8 FF 55 0C call dword ptr [GetAmont]
33: mov nResult, eax
-->004113EB 89 45 F8 mov dword ptr [nResult],eax
34: }
...
...
My question is: at line 31, why "mov ecx, t" was translated into "mov
ecx,dword ptr [t]"?
"t" is a pointer contains an address, while "dword ptr [t]" is a
dereference action to get the value that "t" point to?
Thanks in advance!

[cr88192]

Post by s***@crayne.org
void Process(CTest* t , GETAMOUNT GetAmont)
...
...
...
30: __asm{
31: mov ecx, t ;t is the this pointer
-->004113E5 8B 4D 08 mov ecx,dword ptr [t]
32: call GetAmont
-->004113E8 FF 55 0C call dword ptr [GetAmont]
33: mov nResult, eax
-->004113EB 89 45 F8 mov dword ptr [nResult],eax
34: }
...
...
My question is: at line 31, why "mov ecx, t" was translated into "mov
ecx,dword ptr [t]"?
"t" is a pointer contains an address, while "dword ptr [t]" is a
dereference action to get the value that "t" point to?

they are equivalent.

you can write:
mov ecx, t

because your particular assembler automatically assumes that you want the
value of t, and not a pointer to t.

now, for 'dword ptr [t]', this is the same, it also indicates to get the
value of t, and also not a pointer to it (inside the braces, t refers to a
pointer to t, and not the value of t, since x86 doesn't support indirection
of this sort...).

'dword ptr' itself is simply a way of telling the assembler that the value
is 32 bits (as opposed to, say, 16 or 64 bits). in most assemblers in most
cases, this would be inferred from the size of the register.

assemblers differ though (for example, nasm, and my assembler, would in the
former case assume you wanted a pointer to t, and so the braces are
required).


dunno if this helps any.

Post by s***@crayne.org
Thanks in advance!

.

[Dirk Wolfgang Glomp]

Post by cr88192

Post by s***@crayne.org
void Process(CTest* t , GETAMOUNT GetAmont)
30: __asm{
310: mov ecx, t ;t is the this pointer
-->004113E5 8B 4D 08 mov ecx,dword ptr [t]
32: call GetAmont
-->004113E8 FF 55 0C call dword ptr [GetAmont]
33: mov nResult, eax
-->004113EB 89 45 F8 mov dword ptr [nResult],eax
34: }
My question is: at line 31, why "mov ecx, t" was translated into "mov
ecx,dword ptr [t]"?
"t" is a pointer contains an address, while "dword ptr [t]" is a
dereference action to get the value that "t" point to?

they are equivalent.
mov ecx, t
because your particular assembler automatically assumes that you want the
value of t, and not a pointer to t.
now, for 'dword ptr [t]', this is the same, it also indicates to get the
value of t, and also not a pointer to it (inside the braces, t refers to a
pointer to t, and not the value of t, since x86 doesn't support indirection
of this sort...).
'dword ptr' itself is simply a way of telling the assembler that the value
is 32 bits (as opposed to, say, 16 or 64 bits). in most assemblers in most
cases, this would be inferred from the size of the register.
assemblers differ though (for example, nasm, and my assembler, would in the
former case assume you wanted a pointer to t, and so the braces are
required).

[MASM]
t DB 0,0,0,0
nResult DB 0,0,0,0

mov cx, offset t ; get the pointer of "t"

mov dword ptr[t], 0 ; write 32-bit to "t" (need a size)
mov word ptr[t], 0 ; write 16-bit to "t" (need a size)
mov byte ptr[t], 0 ; write 8-bit to "t" (need a size)

mov cl, [t] ; get 8-Bit of "t"
mov cl, t ; get 8-Bit of "t" (i don´t use it)

mov cx, [t] ; get 16-Bit of "t"
mov cx, t ; get 16-Bit of "t" (i don´t use it)

mov ecx, [t] ; !!!results an error (i don´t know why?)
mov ecx, dword ptr[t] ; get 32-Bit of "t"

mov [nResult], al ; write al to "nResult"
mov [nResult], ax ; write ax to "nResult"
mov [nResult], eax ; !!!results an error (i don´t know why?)
mov dword ptr[nResult], eax ; write eax to "nResult"

mov di, offset t ; get the pointer of "t"
mov [di], al ; write al
mov [di], ax ; write ax
mov [di], eax ; write eax

Dirk

[cr88192]

Post by Dirk Wolfgang Glomp

Post by cr88192

Post by s***@crayne.org
void Process(CTest* t , GETAMOUNT GetAmont)
30: __asm{
310: mov ecx, t ;t is the this pointer
-->004113E5 8B 4D 08 mov ecx,dword ptr [t]
32: call GetAmont
-->004113E8 FF 55 0C call dword ptr [GetAmont]
33: mov nResult, eax
-->004113EB 89 45 F8 mov dword ptr [nResult],eax
34: }
My question is: at line 31, why "mov ecx, t" was translated into "mov
ecx,dword ptr [t]"?
"t" is a pointer contains an address, while "dword ptr [t]" is a
dereference action to get the value that "t" point to?

they are equivalent.
mov ecx, t
because your particular assembler automatically assumes that you want the
value of t, and not a pointer to t.
now, for 'dword ptr [t]', this is the same, it also indicates to get the
value of t, and also not a pointer to it (inside the braces, t refers to a
pointer to t, and not the value of t, since x86 doesn't support indirection
of this sort...).
'dword ptr' itself is simply a way of telling the assembler that the value
is 32 bits (as opposed to, say, 16 or 64 bits). in most assemblers in most
cases, this would be inferred from the size of the register.
assemblers differ though (for example, nasm, and my assembler, would in the
former case assume you wanted a pointer to t, and so the braces are
required).

[MASM]

in case you were mistaking me, I was mentioning nasm, even though the OP was
apparently using MASM, as I was giving an example.

Post by Dirk Wolfgang Glomp
t DB 0,0,0,0
nResult DB 0,0,0,0
mov cx, offset t ; get the pointer of "t"

nasm (and also my assembler):
mov cx, t

Post by Dirk Wolfgang Glomp
mov dword ptr[t], 0 ; write 32-bit to "t" (need a size)
mov word ptr[t], 0 ; write 16-bit to "t" (need a size)
mov byte ptr[t], 0 ; write 8-bit to "t" (need a size)

yes, partly showing some of the bizareness (IMO) of masm's syntax.

alternatively:
mov dword [t], 0
mov word [t], 0
mov byte [t], 0

mine, in some cases, will also support qword (in x86-64 mode).

Post by Dirk Wolfgang Glomp
mov cl, [t] ; get 8-Bit of "t"
mov cl, t ; get 8-Bit of "t" (i donŽt use it)
mov cx, [t] ; get 16-Bit of "t"
mov cx, t ; get 16-Bit of "t" (i donŽt use it)
mov ecx, [t] ; !!!results an error (i donŽt know why?)

maybe MASM is insane...

Post by Dirk Wolfgang Glomp
mov ecx, dword ptr[t] ; get 32-Bit of "t"
mov [nResult], al ; write al to "nResult"
mov [nResult], ax ; write ax to "nResult"
mov [nResult], eax ; !!!results an error (i donŽt know why?)
mov dword ptr[nResult], eax ; write eax to "nResult"
mov di, offset t ; get the pointer of "t"
mov [di], al ; write al
mov [di], ax ; write ax
mov [di], eax ; write eax

yes.


unrelated, and possibly arrogant (possibly also nothing new):

in my case, I wrote an assembler that uses a syntax similar to that of nasm,
but differs in a few ways, primarily that it can allow multiple opcodes per
line, ie:
mov ecx, [foo]; xor ecx, ecx; jnz bar

and, mostly uses some gas-style directives ('.text, .data, .bss, ...'). have
considered adding support for nasm-style directives as well.

note that the one clear important difference:
mine was designed to assemble for use in-place, ie, for things like JIT
compilation (unlike most others, which assemble for the sake of generating
object files...).

I am in the process of implementing a runtime C compiler which may also use
this assembler as a backend.

open issues:
how to treat assembly like a heap, ie, where it may be possible to 'free'
functions.

at present I have introduced use of begin/end pairs. in between there are
any number of "print" statements. currently I assemble these directly, but
it may well be possible to build them up in a buffer, and assemble the whole
thing when the end function is reached.

one possibility here would be doing this in 2 passes:
a dummy pass determines how much space is needed, ...;
approriate memory is allocated;
the second pass generates code into the allocated memory.

why:
it is possible that lots of functions will be assembled and used only
temporarily, so being able to free and reuse said memory makes sense (for
example, a piece of code is freed when its associated VM function gets
garbage collected).

initially, I could just pretend that it is possible to free code (using a
dummy function), and get around to actually implementing this later at some
point.

Post by Dirk Wolfgang Glomp
Dirk

.

[sun1991]

Post by cr88192

Post by s***@crayne.org
void Process(CTest* t , GETAMOUNT GetAmont)
...
...
...
30: __asm{
31: mov ecx, t ;t is the this pointer
-->004113E5 8B 4D 08 mov ecx,dword ptr [t]
32: call GetAmont
-->004113E8 FF 55 0C call dword ptr [GetAmont]
33: mov nResult, eax
-->004113EB 89 45 F8 mov dword ptr [nResult],eax
34: }
...
...
My question is: at line 31, why "mov ecx, t" was translated into "mov
ecx,dword ptr [t]"?
"t" is a pointer contains an address, while "dword ptr [t]" is a
dereference action to get the value that "t" point to?

they are equivalent.
mov ecx, t
because your particular assembler automatically assumes that you want the
value of t, and not a pointer to t.
now, for 'dword ptr [t]', this is the same, it also indicates to get the
value of t, and also not a pointer to it (inside the braces, t refers to a
pointer to t, and not the value of t, since x86 doesn't support indirection
of this sort...).
'dword ptr' itself is simply a way of telling the assembler that the value
is 32 bits (as opposed to, say, 16 or 64 bits). in most assemblers in most
cases, this would be inferred from the size of the register.
assemblers differ though (for example, nasm, and my assembler, would in the
former case assume you wanted a pointer to t, and so the braces are
required).
dunno if this helps any.

Post by s***@crayne.org
Thanks in advance!

.- Hide quoted text -
- Show quoted text -

Well, it's a bit tricky...

Sometimes when you add braces "[]", you mean to dereference it; while
other time it's simply decoration, how to tell the difference?

[cr88192]

Post by sun1991

Post by cr88192

Post by s***@crayne.org
void Process(CTest* t , GETAMOUNT GetAmont)
...
...
...
30: __asm{
31: mov ecx, t ;t is the this pointer
-->004113E5 8B 4D 08 mov ecx,dword ptr [t]
32: call GetAmont
-->004113E8 FF 55 0C call dword ptr [GetAmont]
33: mov nResult, eax
-->004113EB 89 45 F8 mov dword ptr [nResult],eax
34: }
...
...
My question is: at line 31, why "mov ecx, t" was translated into "mov
ecx,dword ptr [t]"?
"t" is a pointer contains an address, while "dword ptr [t]" is a
dereference action to get the value that "t" point to?

they are equivalent.
mov ecx, t
because your particular assembler automatically assumes that you want the
value of t, and not a pointer to t.
now, for 'dword ptr [t]', this is the same, it also indicates to get the
value of t, and also not a pointer to it (inside the braces, t refers to a
pointer to t, and not the value of t, since x86 doesn't support indirection
of this sort...).
'dword ptr' itself is simply a way of telling the assembler that the value
is 32 bits (as opposed to, say, 16 or 64 bits). in most assemblers in most
cases, this would be inferred from the size of the register.
assemblers differ though (for example, nasm, and my assembler, would in the
former case assume you wanted a pointer to t, and so the braces are
required).
dunno if this helps any.

Post by s***@crayne.org
Thanks in advance!

.- Hide quoted text -
- Show quoted text -

Well, it's a bit tricky...
Sometimes when you add braces "[]", you mean to dereference it; while
other time it's simply decoration, how to tell the difference?

because, the only time they can deference anything is when used on a
register.

example:
mov eax, [esi] ;move into eax the value at the addr given by esi

but:
mov eax, [t] ;can't deference t, as t is not a register

instead, what we deference in this case, is the pointer to t.


as a result, the only way we can do an actual deference through a variable,
is if we first load it into a register.

mov ecx, [t]
mov eax, [ecx]

note:
this assumes 32-bit mode, as in 16-bit mode, it is not possible to deference
through an arbitrary register (only certain combinations are used).

mov bx, [t]
mov ax, [bx]


maybe someone with more knowlege can answer this:
does the address-size prefix effect the coding of the mod/rm byte?...
(neither the intel nor AMD specs seem to clarify this right now, though I
think this is likely the case).


so, in any case, in 32-bit mode we can deference through an arbitrary
register (GPR):
eax, ecx, edx, ebx, esp*, ebp*, esi, edi.

in 64 bit mode, we have these GPRs:
rax, rcx, rdx, rbx, rsp*, rbp*, rsi, rdi
r8, r9, r10, r11, r12*, r13*, r14, r15

* note: these regs are special and have special encodings/behaviors (mod/rm
magic...).

note that in both 32 and 64 bit modes, one can also add another scaled reg
(1, 2, or 4 only), and an offset.

mov eax, [ecx+edx*4+5]

this is at least the general rule.


in 16-bit mode, only a few combinations are possible:
[offs/var]
[bx+si]
[bx+di]
[bp+si]
[bp+di]
[si]
[di]
[bx]

[bx+si+offs] aka [var+bx+si] or [var+bx+si+offs]
[bx+di+offs]
[bp+si+offs]
[bp+di+offs]
[si+offs]
[di+offs]
[bx+offs]


dunno if this helps explain anything.



.

[s***@crayne.org]

[..]

Post by cr88192

Post by sun1991
Well, it's a bit tricky...
Sometimes when you add braces "[]", you mean to dereference it; while
other time it's simply decoration, how to tell the difference?

because, the only time they can deference anything is when used on a
register.

I don't think so (unless I'm missing something here). Here's a
little contrived "Hello, world" program:

Microsoft (R) Macro Assembler Version 4.00

0000 CODE SEGMENT PUBLIC 'CODE'
ASSUME CS:CODE, DS:CODE

0100 org 100h ;COM file

0100 C7 06 010F R 0111 R mov t, offset print
0106 FF 16 010F R call word ptr [t]
010A B8 4C00 mov ax, 4C00h
010D CD 21 int 21h
;-------
010F ???? t dw ?
;-------
0111 BA 0119 R print: mov dx, offset msg
0114 B4 09 mov ah, 9
0116 CD 21 int 21h
0118 C3 ret
;-------
0119 48 65 6C 6C 6F 2C 20 msg db 'Hello, world', 0Dh, 0Ah, '$'
77 6F 72 6C 64 0D 0A
24
0128 CODE ENDS
END

This appears to assemble and run OK here under DOS (albeit that
't' gets fixed-up at link time as opposed to run time).

Pete

[cr88192]

Post by s***@crayne.org
[..]

Post by cr88192

Post by sun1991
Well, it's a bit tricky...
Sometimes when you add braces "[]", you mean to dereference it; while
other time it's simply decoration, how to tell the difference?

because, the only time they can deference anything is when used on a
register.

I don't think so (unless I'm missing something here). Here's a
Microsoft (R) Macro Assembler Version 4.00
0000 CODE SEGMENT PUBLIC 'CODE'
ASSUME CS:CODE, DS:CODE
0100 org 100h ;COM file
0100 C7 06 010F R 0111 R mov t, offset print
0106 FF 16 010F R call word ptr [t]
010A B8 4C00 mov ax, 4C00h
010D CD 21 int 21h
;-------
010F ???? t dw ?
;-------
0111 BA 0119 R print: mov dx, offset msg
0114 B4 09 mov ah, 9
0116 CD 21 int 21h
0118 C3 ret
;-------
0119 48 65 6C 6C 6F 2C 20 msg db 'Hello, world', 0Dh, 0Ah, '$'
77 6F 72 6C 64 0D 0A
24
0128 CODE ENDS
END
This appears to assemble and run OK here under DOS (albeit that
't' gets fixed-up at link time as opposed to run time).

IMO, 'call' does not count as a deference.

in a kind of psuedo-asm, it would look like:
push offset ip1
mov ip, [t]
ip1:

as such, even if we can call 'through' a pointer, it is not a deference, if
only because the value stored in t is, simply, moved to ip (which is then
later accessed by the processor).


ok, but to clarify anyways, one can only deference through a register in the
general case of accessing a value stored in a memory oprand.

Post by s***@crayne.org
Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."

.

[Steve]

mov ecx, [t] ; !!!results an error (i don t know why?)

You are writing a byte value to a 32 bit register. MASM
is trying to show that.

Some lines exerpted from the listing your posted code
generated... [Some edits made to reduce size.]

Microsoft (R) Macro Assembler Version 5.00 3/30/7
Page 1-1
13 0000 66| B9 0000 R mov cx, offset t ; get the pointer of "t"
14
15 0004 C7 05 00000000 R 0000 mov dword ptr[t], 0 ; write 32-bit
to "t" (need a size)
16 0000
17 000E 66| C7 05 00000000 R mov word ptr[t], 0 ; write 16-bit
to "t" (need a size)
18 0000
19 0017 C6 05 00000000 R 00 mov byte ptr[t], 0 ; write 8-bit to
"t" (need a size)
20
21 001E 8A 0D 00000000 R mov cl, [t] ; get 8-Bit of "t"
22 0024 8A 0D 00000000 R mov cl, t ; get 8-Bit of "t"
(i don t use it)
23
24 002A 8B 0D 00000000 R mov cx, [t] ; get 16-Bit of "t"
test.ASM(22): warning A4031: Operand types must match
25 0030 8B 0D 00000000 R mov cx, t ; get 16-Bit of
"t" (i don t use it)
test.ASM(23): warning A4031: Operand types must match
26
27 0036 8B 0D 00000000 R mov ecx, [t] ; !!!results an
error (i don t know why?)
test.ASM(25): warning A4031: Operand types must match
28 003C 8B 0D 00000000 R mov ecx, dword ptr[t] ; get 32-Bit of "t"
29
30 0042 A2 00000004 R mov [nResult], al ; write al to "nResult"
31 0047 A3 00000004 R mov [nResult], ax ; write ax to "nResult"
test.ASM(29): warning A4031: Operand types must match
32 004C A3 00000004 R mov [nResult], eax ; !!!results an error
(i don t know why?)
test.ASM(30): warning A4031: Operand types must match
33 0051 A3 00000004 R mov dword ptr[nResult], eax ; write eax to "nResult"
34
35 0056 66| BF 0000 R mov di, offset t ; get the pointer of "t"
36 005A 67| 88 05 mov [di], al ; write al
37 005D 67| 66| 89 05 mov [di], ax ; write ax
38 0061 67| 89 05 mov [di], eax ; write eax


HTH

Steve N.

[cr88192]

Post by Steve

mov ecx, [t] ; !!!results an error (i don t know why?)

You are writing a byte value to a 32 bit register. MASM
is trying to show that.

only because masm wants to try to fantasize that variables in assembler
actually have types...


<snip>

IMO, masm is insane...


then again, I once used masm, but later on switched to nasm and haven't
touched the beast since...


people can disagree with me here if they want.

Post by Steve
HTH
Steve N.

.

[Gil Hamilton]

Post by s***@crayne.org
void Process(CTest* t , GETAMOUNT GetAmont)
31: mov ecx, t ;t is the this pointer
-->004113E5 8B 4D 08 mov ecx,dword ptr [t]
My question is: at line 31, why "mov ecx, t" was translated into "mov
ecx,dword ptr [t]"?
"t" is a pointer contains an address, while "dword ptr [t]" is a
dereference action to get the value that "t" point to?

I see a lot of other responses already but I suspect they may have missed
the source of your confusion.

In C you have defined 't' as a pointer value. In assembly language, 't' is
interpreted as a reference to the memory address containing the pointer
value. In this particular case, because 't' is an argument to the
function, it (the actual pointer value named 't') exists on the stack.
According to the "standard" C/C++ function prologue, as first argument this
puts it just beyond the saved frame pointer and the return address. Its
address would be the value of the EBP register + 8 (the size of 2 32-bit
stack values).

So the assembler interprets "mov ecx, t" to mean "move the memory
associated with the label t into ecx". "[t]" (with brackets) simply
emphasizes that the source is "the memory at t" (the 'dword ptr' part is
also redundant in this particular bit of code and just emphasizes that the
size being moved is 32 bits). Sure enough, if you disassemble the
generated code [8B 4D 08], you see that it's translated as "mov ecx, dword
ptr [ebp+8]".

In other words, "dword ptr [t]" is not (in C terms) "dereferencing the
pointer t"; it is simply loading the value of the pointer t into the
register ECX (which is where the 'this' pointer is expected to reside on
entry to a non-static C++ method).

GH

[sun1991]

Post by Gil Hamilton

Post by s***@crayne.org
void Process(CTest* t , GETAMOUNT GetAmont)
31: mov ecx, t ;t is the this pointer
-->004113E5 8B 4D 08 mov ecx,dword ptr [t]
My question is: at line 31, why "mov ecx, t" was translated into "mov
ecx,dword ptr [t]"?
"t" is a pointer contains an address, while "dword ptr [t]" is a
dereference action to get the value that "t" point to?

I see a lot of other responses already but I suspect they may have missed
the source of your confusion.
In C you have defined 't' as a pointer value. In assembly language, 't' is
interpreted as a reference to the memory address containing the pointer
value. In this particular case, because 't' is an argument to the
function, it (the actual pointer value named 't') exists on the stack.
According to the "standard" C/C++ function prologue, as first argument this
puts it just beyond the saved frame pointer and the return address. Its
address would be the value of the EBP register + 8 (the size of 2 32-bit
stack values).
So the assembler interprets "mov ecx, t" to mean "move the memory
associated with the label t into ecx". "[t]" (with brackets) simply
emphasizes that the source is "the memory at t" (the 'dword ptr' part is
also redundant in this particular bit of code and just emphasizes that the
size being moved is 32 bits). Sure enough, if you disassemble the
generated code [8B 4D 08], you see that it's translated as "mov ecx, dword
ptr [ebp+8]".
In other words, "dword ptr [t]" is not (in C terms) "dereferencing the
pointer t"; it is simply loading the value of the pointer t into the
register ECX (which is where the 'this' pointer is expected to reside on
entry to a non-static C++ method).
GH

Yes, you are right. I kind of see ASM like C, thus create some
misunderstanding. ASM has its own rules to folllow. Thanks, GH. :)