Re: newbie question about dword ptr
- From: "cr88192" <spamtrap@xxxxxxxxxx>
- Date: Sat, 31 Mar 2007 02:42:42 +1000
"Dirk Wolfgang Glomp" <spamtrap@xxxxxxxxxx> wrote in message
news:7kbiue.4t.ln@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
cr88192 schrieb:
<spamtrap@xxxxxxxxxx> wrote in message
news:1175161383.439872.90720@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.
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).
[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.
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
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).
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...
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.
Dirk
..
.
- References:
- newbie question about dword ptr
- From: spamtrap
- Re: newbie question about dword ptr
- From: cr88192
- Re: newbie question about dword ptr
- From: Dirk Wolfgang Glomp
- newbie question about dword ptr
- Prev by Date: Re: Cache question...?
- Next by Date: Re: newbie question about dword ptr
- Previous by thread: Re: newbie question about dword ptr
- Next by thread: Re: newbie question about dword ptr
- Index(es):
Relevant Pages
|
