assumeing pos is a dword

1. mov dword ptr, eax
2. mov dword ptr, eax

in 1. the new value of Pos is eax, in 2. the new value at the mem location pointet at by edx is eax! Why if you look at the disassembly it is clear why this is, but how can i access the adrees pointed at by Pos????
Posted on 2001-08-10 16:15:56 by theNOP
> how can i access the adrees pointed at by Pos????

This moves to ecx the value pointed by
Pos and to edx the value in 4 bytes
forward:

mov eax, Pos
mov ecx,

mov edx,
Posted on 2001-08-10 16:29:21 by n u M I T_o r
If you mean that Pos holds a "pointer" to some other structure, say for example a MSG struc - then you can say:

mov esi, Pos
assume esi:ptr MSG
mov eax, .lParam

or if you want to leave out the assume dierctive

mov eax, (MSG ptr).lParam

You need the parenthesis in this case to tell masm that the .lParam binds to the expression (MSG ptr). Otherwise masm sees it as .lParam which of course makes no sense.

You can also
Posted on 2001-08-10 18:20:17 by gfalen
Another option (the one I like):
mov esi, Pos
mov eax, .MSG.lParam

The less I have to assume, the better. :) That's why I code in asm. :)
Posted on 2001-08-10 18:49:53 by bitRAKE
Cool. I was not aware of this form. Maybe that's why I regularly check this msg brd out - lol.

G. Falen
Posted on 2001-08-10 19:20:33 by gfalen
One of the reasons I like FAsm is that it has non of that ptr bs. (((:grin:)))
Posted on 2001-08-11 01:15:34 by eet_1024
This is one of the reasons why i repeat here again and again that
MASM is *not* a true Assembler.

The way it implicitely manages your symbols as hidden Equates is
driving to confusion and produces a lot of errors.

In Memory and Processor reality a symbol you use for pointing Data
is an Address Label and can not be anything else. This is true for
NASM and SpAsm which are actual Assemblers. What MASM does with this
is turning your

'Symbol'

as an Equate for, for example,

'dWord Ptr '

then, to retreive the Address, you have to use LEA (what is ridiculous).

I well know that this is complete no use to say this here, but the good
solution is to use a true Assembler.

NASM: http://nasm.2y.net/

SpAsm: http://betov.free.fr/SpAsm.html

FASM syntax is not so good at this point of vue (close to TASM Ideal
Mode one), but a bit better than the one of MASM. (Sorry i have lost
the link, but it is somewhere down here).


There are other reasons why MASM is a C-side-tool and not an Assembler:
ASSUME / STRUC / Internal Macros (PROC, at first...),...

Without these stupidities, Asm is *not* so difficult to learn, compared
to any other Language. Most of the beginners questions founded here,
come from 'out-of-Asm' MASM relative problems. Recently, for example,
a beginner said that he didn't know how to manage a Structure in MASM.
Well,... he had the answers... and no-one told him that a Structure is
nothing but a group of Data, with absolutely nothing particular to
understand... But the way MASM manages them, hidden in includes and
activate trough hidden internal Macros, makes the simplier things
unpossible to understand for a beginner and drives more experienced
programmer to wrong ways for doing things (example: Stack declared
Structures, which are longuer to write, impossible to read and slower
to run -!!!-). Have fun.


Betov.
Posted on 2001-08-11 03:10:18 by Betov
I guess the complexity of standard Intel notation depends on how much you understand about data. In standard Intel notation(MASM) you have

1. Immediate
mov eax, 1

2. Memory
mov eax,

3. Register
mov eax, ebx

With Intel notation, the square brackets mean that
it is a MEMORY operand. It can also be an index for byte count.

When standard Intel notation uses size casting, it is because MEMORY does not specify what the operand size is that is going into it.

mov , 1 ; error 1 has no data size

All 3 of the following are valid Intel notation.

mov , byte ptr 1
mov , word ptr 1
mov , dword ptr 1

Standard Intel notation only needs SIZE casting when there is no other way of specifying the size of the data.

mov eax, 1 ; valid, determined by register size
mov , 1 ; invalid, no register to determine size.

I am of the view that the alternative notations are based on the weakness of the parsing that cannot handle the more flexible and intuitive Intel notation.

Regards,

hutch@pbq.com.au
Posted on 2001-08-11 07:11:00 by hutch--
Hutch, first,

>mov , byte ptr 1
>mov , word ptr 1
>mov , dword ptr 1

... drives me in the deeper perplexity, and of course, i much prefer:

>mov Byte 1
>mov Word 1
>mov dWord 1

But, if i well understood the first question, all you say is not the
discussed problem. What i am pointing to is the fact that, for example,
after having defined a Data symbol as a Word, user is 'allowed' to
evocate it as:

>mov MyData 1 ; 1 being a Word (!!!)

Instead of the regular form:

>mov Word 1

This is completely crazy, much confusing, and source of innumerous errors,
as you surely know... There is no weakness in a Parser that prevents users
from errors and no power in the one which induces errors. You will note
that all your examples are with registers, none with Data Symbols. So, i
suspect that you well know the problem and just try to look somewhere
else ;) In a consistant Parsers, the rules for adressing with registers
and the ones for adressing with symbolic names are one and same.

I often read the beginners questions here (and usually, i do not answer
because i know that it is simple vaste of time), but what i can say is
that most of these questions *could not* be asked if they were using an
Assembler.


Additional note:

-I have never heard of any "standard Intel notation"... Just take a look
at Intel 64 Bit assembler syntax... and tell me what standard Intel is
applying there. :))

-"Standard" concept implies a definition around which everyone can agrea,
in order to make things simple, easy and rational. This is to be done.
The basics of NASM are a good start point for it.

-For the "notation depending on how much we understand about data", there
nothing particular to understand about Data in Assembly (in MASM, yes,
much, of course).



Betov.
Posted on 2001-08-11 13:11:53 by Betov
Standards are used to communicate ideas. Intel's syntax has been in use for many years and that is what makes it a standard.

mov , byte ptr 1

makes sense to me because it is the '1' which is a byte. '' isn't a byte - it's a location in memory. '1' is not a ptr, so this view falls apart, and the notation sucks.

mov byte ptr , 1 ;redundant, but most valid syntax in MASM

makes sense to me because 'eax' is a pointer, but that should be deduced from '' or ptr alone - why both! Memory pointers in registers can be anything, they are defined by what you do with them. Therefor, I think that only source should be defined when the destination is unknown (usually the source/destination is a defined data structure and no types are needed in MASM - this is a very nice feature).

mov , byte 1 ;Invalid MASM syntax

is very intuitive, but doesn't work in MASM! This idea could be extended to other types and memory references. How about some other possible syntaxes:
;Invalid MASM syntaxes
movb , 1 ;this isn't bad?
mov b$eax,1 ;SpASM syntax
mov eax[0], byte 1 ;the zero would be optimized out
mov eax.0, byte 1 ;structures could be appended as well
mov ptr eax, byte 1 ;this is almost a readable sentence!
move pointer eax byte one ;hehehe...
Posted on 2001-08-11 15:45:44 by bitRAKE