Hi,

What's the difference between:

mov ,1

and:

mov eax,pResult
mov ,1


I think there should be none, but It actually performs different.
pResult it the pointer to a variable that will contain the result of the operations performed by a Proc. So, when I end the proc, I want to store at the "Result code"but only the second way works. With the first one, I always get a 0.

Thanks a lot, Kefren
Posted on 2001-10-30 04:51:40 by kefren
Hi kefren

x86 does not support the adressing mode using memory as a pointer. So mov ,1 simplu put 1 into pResult.
mov ,1 is equal to mov pResult,1

KetilO
Posted on 2001-10-30 05:06:45 by KetilO
So, this is wrong too:

add eax,DWORD PTR

since pdw is a memory variable.
I should replace it with:

mov edx,pdw
add eax,DWORD PTR

Isn't it?

Kefren
:stupid:
Posted on 2001-10-30 05:10:42 by kefren
Heh, this is what you get from masm's somewhat ambiguous syntax.
Long live nasm for requiring around memory access :).
Posted on 2001-10-30 05:21:47 by f0dder
kefren,

The use of square brackets in any Intel compliant assembler means a memory operand. Where some have problems is that MASM allows you to name stack local variables and use the name in the place of what the assembler resolves the name to which is something like .

Some people make the mistake in Intel compliant assemblers of using square brackets as decorations or additional notation but it is ignored by the assembler and it makes the use of square brackets ambiguous.

LOCAL variable:DWORD ; stack variable
eax register

mov eax, variable
is the same as (mov eax, )

mov eax,
is copying the memory operand at the address in EAX back into the register EAX.

If you stick to the standard notation, you will avoid the ambiguity and other people will be able to read your code more clearly.

Regards,

hutch@pbq.com.au
Posted on 2001-10-30 06:13:09 by hutch--
I appreciate the MASM syntax of not being forced to use brackets for variable access. May be its a bit more confusing newbies, but it should be no problem at all for "experienced" coders.

japheth
Posted on 2001-10-30 07:06:01 by japheth
I prefer it anyway. It allows me to quickly identify memory access
as I scroll down a large source file, in an 8-hour coding session.
And it's required when using registers to dereference memory anyway,
so...

Oh yes, and what's the deal with masm not allowing immediate
addresses like "mov [0DEADBEEFh], eax" ? Bleh!
Posted on 2001-10-30 07:10:56 by f0dder
Thanks a lot for the explanations.

Now, I will abuse your willing to share knowledge, ang go on bothering you.

So, suppose I am making a function in a library. The function "receives" one parameter, that is supposed to be a pointer to the "result" of the function.

MyProc PROC pResult:DWORD

pResult is in the stack, right?


When I finally want to put the result in its memory location, if I followed you, I MUST do the following:

1)
mov eax,pResult
mov ,myvalue

that is equal to:

2)
mov eax,
mov ,myvalue

where offset is a number that I am too ignoranto to define, but the assembler is clever enough to define.

Now, Hutch, are you suggesting to me that I should learn what "offset" should be in this case and use notation 2)?

Second question:
Suppose another prog part, where MyVariable is a global variable. Does this become correct or not?

.data
MyVariable dd 123

.data?

pMyVariable dd ?

.code


mov eax,OFFSET MyVariable
mov pMyVariable,eax
;If I'm right, pMyVariable now is a pointer to MyVariable.

mov ecx,
;What did I move to ecx? is it like mov ecx,MyVariable or not?



Thanks a lot again and again.

'Bye, Kefren
Posted on 2001-10-30 07:23:31 by kefren
memory access to absolut addresses should alway be possible with "mov ds:[0DEADBEEFh], eax", I suppose.
Posted on 2001-10-30 07:28:06 by japheth
thanks japheth. The error you get when not using a segment
override is a bit baffling, though...


test.asm(18) : error A2001: immediate operand not allowed


a "need segment override" would have been more appropriate imo.
And it's a bit superfluous anyway, since data access is normally
done through DS. But oh well.


kefren, let the assembler do the offset calculations for you. Otherwise
you might as well go back to debug.exe. Yes, your code stores a
pointer (offset :)) in the pMyVariable. And "mov pMyVariable,eax"
and "mov , eax" would produce the exact same result.
Which is why you should get used to always using , it's
more intuitive and helps avoiding stupid mistakes. Basta. :).
Posted on 2001-10-30 07:54:56 by f0dder
f0dder,

code as much brackets as you want :rolleyes: .
Posted on 2001-10-30 09:12:47 by japheth
Japheth, I will. And I will continue shaking my head at you non-bracket
heretics in amusement :grin:
Posted on 2001-10-30 09:18:38 by f0dder
mov eax,OFFSET MyVariable
mov pMyVariable,eax
;If I'm right, pMyVariable now is a pointer to MyVariable.

You'r right

mov ecx,
;What did I move to ecx? is it like mov ecx,MyVariable or not?

=mov ecx, pMyVariable ; square brackets are useless
=mov ecx, offset MyVariable

mov ecx, pMyVariable
mov ecx,
;is same as
mov ecx, MyVariable
Posted on 2001-10-30 17:29:31 by Aaro
Ok, thanks all!

Now things are slowly gettin clearer!

'Bye, Kefren
Posted on 2001-10-31 02:44:18 by kefren
Kefren,

========================
2)
mov eax,
mov ,myvalue

where offset is a number that I am too ignorant to define, but the assembler is clever enough to define.

Now, Hutch, are you suggesting to me that I should learn what "offset" should be in this case and use notation 2)?
========================

You are barking up the wrong tree here, what I was trying to show you is how the stack works. When you pass parameters on the stack, they are positive addresses in EBP, they start at .

When you create a LOCAL variable, they are negative values written below the top of the stack and this is why I used the notation .

What the assembler does in fact is calculate all of the offsets for local values and feed them into the places where you use named local variables.

When you have code like,

LOCAL var:DWORD
LOCAL array[128]:DWORD
LOCAL buffer[260]:BYTE

you don't really want to calculate all of these offsets manually. The assembler does this for you.

Stack memory is writable so YES you can modify LOCAL values AND parameters without any problems.

It is common to pass a count in a parameter and decrement it down to zero in the procedure so writing to stack values, either LOCAL or parameters is normal.

Regards,

hutch@movsd.com
Posted on 2001-10-31 04:43:15 by hutch--
....mmm, things are getting darker again.:confused:

I think I need a full immersion on Aoa for a little while, than I'll be back with other questions on the stack.

I thank you a lot, Hutch. I understand it must be very annoying to explain such basic things to a hard-head like me.

See you later, Kefren
Posted on 2001-10-31 07:00:17 by kefren
OK, here I am.:alright:

One thing I did not know was hte stack manipulation that is (automatically) made when entering a Proc.
So, the Base Pointer is updated so that it actually contains the old Stack pointer. And the esp? Is it updated so that the LOCAL variables are actually contained into the stack?

If I understood it all, if in a called proc I pop something, I pop a local variable, and not the parameters passed. The paramteres are actually "outside" the current stack. When I exit a proc, ebp is restored so that things get right again.

Whee, not so easy.

'Bye, Kefren
Posted on 2001-10-31 07:37:23 by kefren
Hi kefren,
I just wanted to say thank you for raising such an interesting question. I was searching the board for an answer to my question and I got the EXACT answer right here! ^_^
Posted on 2003-02-19 19:32:06 by bgong68