a MOV command syntax question
MEHMET KILICKAYA
memory location ( in win32 assembly ) ?
Please don't use in the syntax any variable name except registers.
Thanks in advance
Alvise Valsecchi
Variables do not exist in asm, only memory locations addressed by a label for
the content to be accessed.
When you write
.data
foo DD ?
foo represents the address of the doubleword relative to the data segment (in
win32 the address is nothing but the offset).
Normal moves are like this:
mov foo,eax
that means that the doubleword in eax is copied at the address foo . If you do
not want to use the symbol "foo" (that you called a "variable name") you should
know the offset, that is the same. Should the offset of foo be 500 bytes from
the beginning of the the data segment the above code should look like this:
mov ebx,500
mov [ebx],eax
But actually foo IS EQUAL TO 500 because it is the address of the doubleword.
In some code around the web I found this code:
mov [foo],eax
but those programmers should know that square brackets are superfluous, because
mov foo,eax
not only is equivalent, but it is also the correct form. On the other hand any
register enclosed in square brackets is different from the same register
without brackets. These two statements
mov ebx,eax
mov [ebx],eax
are different by far.
But the message you posted I think is related to another kind of addressing. I
suppose that you want to address memory locations without a label that
represent their address. To do this you need at least the address of the first
memory location, all subsequent addresses can be obtained incrementing the
starting address, like this:
.data
xyz dw 1000 dup(?) ;my vector made of 1000 words (the address of the first
word is xyz)
.code
mov ecx,1000
mov esi,offset xyz
loop_label:
mov ax,[esi] ; ---> Please don't use in the syntax any variable name except
registers !!!
inc esi
inc esi
loop loop_label
In this case all words from the second on are addressed only using registers.
Good luck. Alvise.
Alvise Valsecchi
In my previous posting this line
> mov ax,[esi] ; ---> Please don't use in the syntax any variable name except
should be replaced by this
mov [esi],esi ; ---> Please don't use in the syntax any variable name except
A.V.
Julian St.
>Please can anybody show me the syntax of MOV command that puts a value in a
>memory location ( in win32 assembly ) ?
mov [aDWordVar],eax
mov [aWordVar],eax
mov [aByteVar],al
mov [aDWordVar],2145324
mov [aWordVar],21345
mov [aByteVar],234
Gruss
JMMR
Meine Homepage:
http://surf.to/JMMR/
(Zum Antworten via Mail .nospam in der eMail Adresse entfernen.)
Randolf (Randy) Richardson
> In some code around the web I found this code:
>
> mov [foo],eax
>
> but those programmers should know that square brackets are superfluous, because
>
> mov foo,eax
>
> not only is equivalent, but it is also the correct form. On the other hand any
> register enclosed in square brackets is different from the same register
> without brackets. These two statements
In IDEAL mode, using square brackets is a requirement.
Eric Benton
is the same as "mov foo, eax".
I have always disagreed with this syntax,
to me it should have been implemented as so:
mov [foo],eax // mov eax to the address pointed to by foo
// if
foo dd 12345678h
// then its mov contents of eax to address 12345678h
mov foo, eax // update the pointer foo with the contents of eax
// if foo resides at ds:1234h then mov the contents of
// eax to ds:1234h
But thats just how i would have done it.
Eric
> In some code around the web I found this code:
>
> mov [foo],eax
>
> but those programmers should know that square brackets are superfluous,
because
>
> mov foo,eax
>
> not only is equivalent, but it is also the correct form. On the other hand
any
> register enclosed in square brackets is different from the same register
> without brackets. These two statements
>
Julian St.
<erbe...@EarthLink.Net> schreibt:
>mov [foo],eax // mov eax to the address pointed to by foo
> // if
>foo dd 12345678h
> // then its mov contents of eax to address 12345678h
>
>mov foo, eax // update the pointer foo with the contents of eax
> // if foo resides at ds:1234h then mov the contents of
> // eax to ds:1234h
foo is just a offset with which one can find the variable one requested. foo IS
NOT the variable, it's a symbol. Just look at the NASM syntax.
Randolf (Randy) Richardson
> is the same as "mov foo, eax".
> I have always disagreed with this syntax,
> to me it should have been implemented as so:
>
> // if
> foo dd 12345678h
> // then its mov contents of eax to address 12345678h
Contents of "foo" are filled with value in EAX register.
To me this method makes sense because it's consistent with the way
local and parameter variables from the stack are also accessed.
> mov foo, eax // update the pointer foo with the contents of eax
> // if foo resides at ds:1234h then mov the contents of
> // eax to ds:1234h
The address of data can't be changed in this way, but you can get the
address of foo into the EAX register as follows:
Mov EAX, offset foo
Alvise Valsecchi
> In IDEAL mode, using square brackets is a requirement.
Sorry, I did not know. Anycase this is the occasion for me to have a look at IDEAL
mode syntax. I am new to TASM. For more than 10 years I have been using MASM to write
DOS programs. To be more precise I bought IBM Macro Assembler /2 in 1987... Now I am
developing win32asm programs since I discovered the great Iczelion's tutorials. So I
also bought TASM to try the assembler from Bordand.
A.V.
Alvise Valsecchi
upon the issue of memory addressing.
In theory there is direct addressing, indirect addressing, indirect-indirect
addressing and so forth (not all memory addressing methods are implemented by
different versions of assemblers).
In practice MASM and TASM-no-ideal-mode support only direct addressing, and
TASM-ideal-mode supports indirect addressing too.
In the first case MOV FOO,EAX and MOV [FOO],EAX are equivalent, and the former
syntax is better.
In TASM ideal mode the above MOVs would be completely different, each having its
own effect. MOV FOO,EAX is an example of direct addressing, and MOV [FOO],EAX is
an example of indirect addressing. This latter means that the content of eax is
stored into the memory location which address is the content of the memory
location which address is FOO (sorry for the play on words).
I would appreciate comments. Bye from Alvise.
Randolf (Randy) Richardson
Other differences with IDEAL mode include defining procedures first
with the "Proc" keyword instead of the function name, which just seems
more logical to me from a source code processing standpoint. For
example:
MASM mode: FunctionName Proc Near
IDEAL mode: Proc FunctionName Near
I also read somewhere years ago that this results in faster
compilation, which was probably more of an issue in the days of the XT.
All my assembler software development is done exclusively in IDEAL mode
these days. For a MASM developer, however, TASM is great because it can
emulate the quirks (see the documentation for the "QUIRKS" directive)
which Microsoft is so infamous for. >8-)
There are other differences too, but the documentation is probably the
best bet.
Rohland Atchison
Alvise Valsecchi wrote:
>
> Reading the replies from Randolph Richardson and Eric Benton made me think again
> upon the issue of memory addressing.
>
> In theory there is direct addressing, indirect addressing, indirect-indirect
> addressing and so forth (not all memory addressing methods are implemented by
> different versions of assemblers).
In practice, TASM supports the Intel 386 architecture. Therefore
it supports direct, indirect indexed (or based), and based and indexed
with displacement. The level of indirection only goes to one level for
this processor and assembler. Multiple level or cascaded indirect
addressing is not available for this combination.
>
> In practice MASM and TASM-no-ideal-mode support only direct addressing, and
> TASM-ideal-mode supports indirect addressing too.
What?? I think you are a little confused about what is indirect
addressing. See the example code below.
>
> In the first case MOV FOO,EAX and MOV [FOO],EAX are equivalent, and the former
> syntax is better.
Defend your above assertion! Why is the first syntax better?
>
> In TASM ideal mode the above MOVs would be completely different, each having its
> own effect.
If the MOVs are different, then why do they generate the same code
as shown below?
MOV FOO,EAX is an example of direct addressing, and MOV [FOO],EAX is
> an example of indirect addressing.
Wrong! The brackets around [Foo] are needed to quiet the warnings
given in the IDEAL mode. The brackets are an unambiguous indication that
Foo is a memory contents address and not a possible EQU for another
register. The addressing is direct. The code generated for these two
instructions is the same as shown below.
This latter means that the content of eax is
> stored into the memory location which address is the content of the memory
> location which address is FOO (sorry for the play on words).
Do you believe the above statement now?
>
> I would appreciate comments. Bye from Alvise.
OK, look at the code below.
1 VERSION T410
2 IDEAL ; Notice the mode we are in.
3 P586N
4 0000 MODEL SMALL
5 0000 UDATASEG
6 Org $+6
7 0006 ???? Foo DW ?
8 0008 CODESEG
9 Org $+7
10 0007 Tag:
11 0007 A3 0006r Mov Foo,AX ; typical squawk from IDEAL
mode when a memory contents reference in not bracketed
*Warning* C:\TASM\TRY\INDIRECT.ASM(11) Pointer expression needs
brackets
12 000A A3 0006r Mov [Foo],AX ; The contents of AX is
copied into the contents of location FOO. Direct addressing.
13 000D C7 06 0006r 0003 Mov [Foo],3 ; The constant 3 is
written into the contents of location FOO. Direct addressing
14 0013 C7 06 0006r 0003 Mov [Foo],Offset 3 ; Same as above
15 0019 B8 0004 Mov AX,4 ; The constant 4 is written into
AX
16 001C B8 0004 Mov AX,Offset 4 ; Same as above
17 001F A1 0006r Mov AX,Foo ; Another squawk from IDEAL
mode for not putting brackets on a memory contents reference.
*Warning* C:\TASM\TRY\INDIRECT.ASM(17) Pointer expression needs brackets
18 0022 B8 0006r Mov AX,Offset Foo ; The address (not the
contents) of FOO is loaded into AX
19 0025 A1 0006r Mov AX,[Word Foo] ; This time the contents
of address FOO are copied into AX. It is a direct addressing operation.
20 0028 89 1C Mov [Word SI],BX ; The contents of BX are
copied into the contents of the address contained in SI. This time it
is an INDIRECT addressing operation. Notice that the IDEAL mode
requires the WORD directive to document that register SI specifies a
word address.
21 002A 8B 41 03 Mov AX,[BX+DI+3] ; The contents of the
address made up of the sum of the base register BX plus the index
register DI and the offset 3 are copied into AX. This is an indirect
addressing operation.
22 002D 66| 67| 8B 44 B3 03 Mov EAX,[EBX+ESI*4+3] ; The
contents of the address made up of the sum of the base register EBX plus
index register ESI shifted left by 4 plus the offset 3. Another fancy
indirect addressing operation.
23 0033 EB D2 Jmp Tag ; a direct jump to the address Tag
24 0035 FF 27 Jmp [Word BX] ; An indirect jump to the
address contained in register BX
25 ;
26 MASM ; Notice what mode we are in now.
27 0037 A3 0006r Mov Foo,AX ; No squawks here,
MASM mode does not rigidly enforce good syntax.
28 003A A3 0006r Mov [Foo],AX ; Just about
anything goes in this mode.
29 003D C7 06 0006r 0003 Mov [Foo],3
30 0043 C7 06 0006r 0003 Mov [Foo],Offset 3
31 0049 B8 0004 Mov AX,4
32 004C B8 0004 Mov AX,Offset 4 ;
33 004F A1 0006r Mov AX,Foo ;
34 0052 B8 0006r Mov AX,Offset Foo ;
35 0055 A1 0006r Mov AX,[Foo] ;
36 0058 89 1C Mov [SI],BX ; indirect addressing
37 005A 8B 41 03 Mov AX,[BX+DI+3]
38 005D 66| 67| 8B 44 B3 03 Mov EAX,[EBX+ESI*4+3]
39 0063 EB A2 Jmp Tag
40 0065 FF 27 Jmp [BX]
41 END
Observe that just because brackets appear in an instruction, it
does not necessarily mean that indirect addressing is involved. Further
observe that the Intel processor is incapable of indirectly referencing
to/from a memory location alone. At least one register is needed to be
part of an indirect reference. Other processors like the Motorola 68000
series have more indirect addressing options. Somebody correct me if I
am wrong.
Does that clear up some things? Regards, Macroman.
Alvise Valsecchi
Richardson ("In IDEAL mode, using square brackets is a requirement."), and worse did my unknowledge of ideal
mode. The quoted assertion made me think that TASM ideal mode supports indirect addressing. In any case
thanks from your answer.
> In practice, TASM supports the Intel 386 architecture. Therefore
> it supports direct, indirect indexed (or based), and based and indexed
> with displacement. The level of indirection only goes to one level for
> this processor and assembler. Multiple level or cascaded indirect
> addressing is not available for this combination.
I understand this.
> > In practice MASM and TASM-no-ideal-mode support only direct addressing, and
> > TASM-ideal-mode supports indirect addressing too.
>
> What?? I think you are a little confused about what is indirect
> addressing. See the example code below.
Indirect addressing is "referring to a memory location which address is the content of another memory
location". I am not confused about indirect addressing, just thought that ideal mode supported it. That was
not impossible: remember that assemblers we use are actually "macroassemblers", that perform some code
expansions when required.
> > In the first case MOV FOO,EAX and MOV [FOO],EAX are equivalent, and the former
> > syntax is better.
>
> Defend your above assertion! Why is the first syntax better?
Because the first syntax not only is rid from unuseful characters (the square brackets), but would not use
characters (the square brackets) that are designed for another purpose.
> > In TASM ideal mode the above MOVs would be completely different, each having its
> > own effect.
>
> If the MOVs are different, then why do they generate the same code
> as shown below?
Well, my misunderstand of Ideal mode made me think wrong, now I see there is no difference. But this
enforces my convincement that syntax without square brackets is better.
> MOV FOO,EAX is an example of direct addressing, and MOV [FOO],EAX is
> > an example of indirect addressing.
>
> Wrong! The brackets around [Foo] are needed to quiet the warnings
> given in the IDEAL mode. The brackets are an unambiguous indication that
> Foo is a memory contents address and not a possible EQU for another
> register. The addressing is direct. The code generated for these two
> instructions is the same as shown below.
This is the the fundamental assertion. Perfectly correct. Once again I excuse myself for my unknowledge of
Ideal mode, and for misunderstand Randolf Richardson's assertion. I promise I will never talk about Ideal
mode without reading Borland's documentation first. But this enforces, once again, my convincement that
syntax without square brackets is better.
> This latter means that the content of eax is
> > stored into the memory location which address is the content of the memory
> > location which address is FOO (sorry for the play on words).
>
> Do you believe the above statement now?
OK, now I understand. This is why I asked for comments.
> OK, look at the code below.
... code ...
> Observe that just because brackets appear in an instruction, it
> does not necessarily mean that indirect addressing is involved.
That is why I think square brackets should not be used in these occasions.
> Further
> observe that the Intel processor is incapable of indirectly referencing
> to/from a memory location alone. At least one register is needed to be
> part of an indirect reference.
> Other processors like the Motorola 68000
> series have more indirect addressing options. Somebody correct me if I
> am wrong.
You are true.
I try to summarize:
- MASM and TASM support what 386 architecture offers: direct addressing, indexed addressing and indexed with
displacement addressing
- TASM requires square brackets to quiet warnings from the compiler and to distinguish from possible EQUs
Additions and corrections are wellcome. Bye from Alvise.
P.S.: I wrote mountains of code without knowing about Ideal mode. I will read about it. But at present it
does not seem to me that it is better than MASM syntax.
Randolf (Randy) Richardson
> > What?? I think you are a little confused about what is indirect
> > addressing. See the example code below.
>
> another memory location." I am not confused about indirect addressing, just thought that
> ideal mode supported it. That was not impossible: remember that assemblers we use are
That has always been my understanding of this too. =)
The indirect addressing, or "indexed addressing" as the reference books
I have call it, is definitely supported. In the case of reading
information from a structure, we can do the following:
Mov EBX, offset FooStructure ; Offset to structure
Mov EAX, [EBX] ; Get 32-bit pointer to string
Mov ECX, [EBX+4] ; Get 32-bit length of string
I believe the use of square brackets in addressing data labels makes
sense since it can also be seen as a form of indexed addressing, at
least from the compiler's point of view:
Mov EAX, [Foo] ; Label "Foo" is a pointer to data
> > > In the first case MOV FOO,EAX and MOV [FOO],EAX are equivalent, and the former
> > > syntax is better.
> >
> > Defend your above assertion! Why is the first syntax better?
>
> Because the first syntax not only is rid from unuseful characters (the square brackets), but
> would not use characters (the square brackets) that are designed for another purpose.
Is "Mov EBX, EAX" the same as "Mov [EBX], EAX?" Definitely not. And
since static data labels such as "Foo" really can't be changed (because
they translate to fixed addresses in the resulting executable binary
file), the use of "Mov Foo, EAX" is simply not allowed.
When it comes to reading source code, the square brackets are extremely
useful because they make the source code much easier to read (our brains
already work hard enough, after all we are assembler programmers!).
[Snip]
> > MOV FOO,EAX is an example of direct addressing, and MOV [FOO],EAX is
> > > an example of indirect addressing.
> >
> > Wrong! The brackets around [Foo] are needed to quiet the warnings
> > given in the IDEAL mode. The brackets are an unambiguous indication that
> > Foo is a memory contents address and not a possible EQU for another
> > register. The addressing is direct. The code generated for these two
> > instructions is the same as shown below.
>
> This is the the fundamental assertion. Perfectly correct. Once again I excuse myself for my
> unknowledge of Ideal mode, and for misunderstand Randolf Richardson's assertion. I promise
> I will never talk about Ideal mode without reading Borland's documentation first. But this
> enforces, once again, my convincement that syntax without square brackets is better.
Please don't make such promises. When I referred to the manual
originally, I was suggesting that this be a good place to start learning
about IDEAL mode. By all means, please DO ask about IDEAL mode on these
forums because the fact that one person is trying to understand it
better could very well be an indication that there are many others who
don't post their questions even though they have similar quests -- I
believe this benefits everyone.
[Snip]
> I try to summarize:
>
> - MASM and TASM support what 386 architecture offers: direct addressing, indexed addressing
> and indexed with displacement addressing
Yes.
> - TASM requires square brackets to quiet warnings from the compiler and to distinguish from
> possible EQUs
For the purpose of eliminating ambiguity. When I was learning
assembler I found MASM mode frustrating sometimes because of the
inconsistency between the way data labels and registers are handled in
this regard, and IDEAL mode made my life much simpler.
> Additions and corrections are wellcome. Bye from Alvise.
>
> P.S.: I wrote mountains of code without knowing about Ideal mode. I will read about it. But
> at present it does not seem to me that it is better than MASM syntax.
The really great thing about TASM is that you don't have to rewrite ALL
your code to accomodate IDEAL vs. MASM mode. With TASM you can switch
between IDEAL and MASM mode as many times as you like. I did this when
converting my source code, as I had time, until I was able to completely
get rid of all the MASM directives.
The following directives are available:
IDEAL ; Switch to Ideal mode
MASM ; Switch to MASM mode
MASM51 ; Switch to MASM 5.1 mode
QUIRKS ; Allow full MASM compatibility
I hope this helps. Good luck!
Alvise Valsecchi
> > Indirect addressing is "referring to a memory location which address is the content of
> > another memory location."
> That has always been my understanding of this too. =)
This is a good definition, to which we both agree.
> The indirect addressing, or "indexed addressing" as the reference books
> I have call it, is definitely supported.
"Indexed addressing" means addressing through an "index register". In 8088 & 8086 index registers
are SI and DI (Source Index and Destination Index). BX is a CPU register, but can be used as an
index register. In 80386 index register are ESI and EDI (Extended SI and Extended DI). Extended
CPU registers (EAX, EBX, ECX, EDX) can be used as index registers. When using these registers: SI,
DI, BX, ESI, EDI, EAX, EBX, ECX, EDX to address memory locations you must use square brackets.
So "indexed addressing" is not exactly "indirect addressing" because the former involves index
registers, and the latter memory locations, see the above definition. The only CPU I can remember
of that supports true indirect addressing (and indirect-indirect addressing too) is the CPU of my
very old HP85. It has instructions that support 2 levels of indirections using memory locations.
Incredible. I studied that CPU in 1981. Its design was excellent: it had a CPU registers bank made
of 64 8-bit registers, that can be grouped in 16, 32, and 64 bit registers. Math operations
supported 64 bit operations !!! In BCD too !!! (HP is always HP).
According to your reference books I would say that indexed addressing is definitely supported.
> In the case of reading information from a structure, we can do the following:
>
> Mov EBX, offset FooStructure ; Offset to structure
> Mov EAX, [EBX] ; Get 32-bit pointer to string
> Mov ECX, [EBX+4] ; Get 32-bit length of string
Correct. The second and the third moves are respectively examples of indexed addressing and
indexed addressing with a displacement.
> I believe the use of square brackets in addressing data labels makes sense since it can
> also be seen as a form of indexed addressing, at least from the compiler's point of view:
>
> Mov EAX, [Foo] ; Label "Foo" is a pointer to data
Labels are pseudoinstructions that tell the assembler to substitute themselves with the respective
addresses. Foo is only the address of a memory location (a "pointer" in C and C++). Mov EAX, Foo
should mean that the address is loaded into EAX, not the content of the location at that address.
But actually Mov EAX, Foo means that the content of the location at address Foo is loaded into
EAX. I admit that MASM syntax is inconsistent.
> Is "Mov EBX, EAX" the same as "Mov [EBX], EAX" ? Definitely not.
I never made this example. In my example I was using FOO, not any CPU register.
> And since static data labels such as "Foo" really can't be changed (because
> they translate to fixed addresses in the resulting executable binary
> file), the use of "Mov Foo, EAX" is simply not allowed.
MASM allows this for the sake of simplicity (I think).
> By all means, please DO ask about IDEAL mode on these
> forums because the fact that one person is trying to understand it
> better could very well be an indication that there are many others who
> don't post their questions even though they have similar quests -- I
> believe this benefits everyone.
True.
> For the purpose of eliminating ambiguity. When I was learning
> assembler I found MASM mode frustrating sometimes because of the
> inconsistency between the way data labels and registers are handled in
> this regard, and IDEAL mode made my life much simpler.
I can still read my old MASM code w/o ambiguities. I will read about IDEAL mode, and maybe will
post some messages in the future.
Bye from Alvise.
Randolf (Randy) Richardson
> > The indirect addressing, or "indexed addressing" as the reference books
> > I have call it, is definitely supported.
>
> "Indexed addressing" means addressing through an "index register". In 8088 & 8086 index
> registers are SI and DI (Source Index and Destination Index). BX is a CPU register, but can
> be used as an index register. In 80386 index register are ESI and EDI (Extended SI and
> Extended DI). Extended CPU registers (EAX, EBX, ECX, EDX) can be used as index registers.
> When using these registers: SI, DI, BX, ESI, EDI, EAX, EBX, ECX, EDX to address memory
> locations you must use square brackets. So "indexed addressing" is not exactly "indirect
> addressing" because the former involves index registers, and the latter memory locations,
> see the above definition. The only CPU I can remember of that supports true indirect
> addressing (and indirect-indirect addressing too) is the CPU of my very old HP85. It has
> instructions that support 2 levels of indirections using memory locations. Incredible. I
> studied that CPU in 1981. Its design was excellent: it had a CPU registers bank made of 64
> 8-bit registers, that can be grouped in 16, 32, and 64 bit registers. Math operations
> supported 64 bit operations !!! In BCD too !!! (HP is always HP). According to your
> reference books I would say that indexed addressing is definitely supported.
Thanks for the great explanation! Sometimes I wished Intel CPUs had
more registers, and the way your HP85 lets you use them is very nice
indeed!
> > In the case of reading information from a structure, we can do the following:
> >
> > Mov EBX, offset FooStructure ; Offset to structure
> > Mov EAX, [EBX] ; Get 32-bit pointer to string
> > Mov ECX, [EBX+4] ; Get 32-bit length of string
>
> Correct. The second and the third moves are respectively examples of indexed addressing and
> indexed addressing with a displacement.
This is not indirect addressing then? By the way, I'm self-taught in
assembler programming, so the terminology is sometimes foggy for me. If
you don't mind, could you show an example of indirect addressing? I'm
very interested because it's likely a new technique for me.
> > I believe the use of square brackets in addressing data labels makes sense since
> > it can also be seen as a form of indexed addressing, at least from the compiler's point
> > of view:
> >
> > Mov EAX, [Foo] ; Label "Foo" is a pointer to data
>
> Labels are pseudoinstructions that tell the assembler to substitute themselves with the
> respective addresses. Foo is only the address of a memory location (a "pointer" in C and
> C++). Mov EAX, Foo should mean that the address is loaded into EAX, not the content of the
> location at that address. But actually Mov EAX, Foo means that the content of the location
> at address Foo is loaded into EAX. I admit that MASM syntax is inconsistent.
To get the memory address into EAX, we would do the following in IDEAL
mode:
Mov EAX, offset Foo ; Get memory address of "Foo"
> > Is "Mov EBX, EAX" the same as "Mov [EBX], EAX" ? Definitely not.
>
> I never made this example. In my example I was using FOO, not any CPU register.
I'm aware of that. In this case I was drawing a parallel to make my
point. When I'm reading my source code, I know very clearly what the
following mean:
Mov EAX, [EBX] ; Get contents of address in EBX
Mov EAX, [Foo] ; Get contents of address "Foo"
Mov EAX, offset Foo ; Get address of "Foo"
With respect to the above, the following is ambiguous to me after
reading source code for hours on end, thus the 'square brackets' vs.
'"offset" keyword' mean there's one less thing for me to think about:
Mov EAX, Foo ; Is this address, or contents?
> > And since static data labels such as "Foo" really can't be changed (because
> > they translate to fixed addresses in the resulting executable binary
> > file), the use of "Mov Foo, EAX" is simply not allowed.
>
> MASM allows this for the sake of simplicity (I think).
The equivilant in IDEAL mode is:
Mov [Foo], EAX ; Save contents of EAX in "Foo"
[Snip]
> > For the purpose of eliminating ambiguity. When I was learning
> > assembler I found MASM mode frustrating sometimes because of the
> > inconsistency between the way data labels and registers are handled in
> > this regard, and IDEAL mode made my life much simpler.
>
> I can still read my old MASM code w/o ambiguities. I will read about IDEAL mode, and maybe
> will post some messages in the future.
That's because you've taken the time to understand the way the MASM
compiler interprets source code. For myself, I found that the way IDEAL
mode is interpreted is more consistent all around and therefor easier to
read -- but that's just my personal preference.
I'm glad you're going to read about it, and hope that you'll find it
useful! =)
> Bye from Alvise.