ASM Community

The first case is correct because you are loading a value from memory using "pTable" as the memory reference (pointer), and using that value as a memory reference itself.

The second example will not work because you are using "pTable" as the memory reference, which is why you are overriding it.

Here is an example in NASM syntax (which I find more uniform and clear in this case)...

;LOCAL pTable
pTable DD 0

;First Case
mov ebx, DWORD ;***** This illustrates the difference *****
mov DWORD, eax

;Second Case
mov DWORD, eax

If you notice in the above code, the first instruction of the first case uses the same principles as the first instruction of the second case, that being "pTable" as a memory reference.

This is something that MASM "hides" for you by keeping track of variable references and accessing them in a C-like manner (directly addressing the value of a variable, not the pointer/address of it). Thus, "mov ebx, pTable" is the equivalent of "mov ebx, dword ptr ". I think the main reason being, is that MASM was further designed in mind to be used as an intermediate stage for compilers... this is where referencing values of variables instead of their pointer/address becomes easier.

For example, it is much easier to write "invoke MyFunction, pTable" instead of "invoke MyFunction, dword ptr "... imagine having to do that for every variable value you wish to reference. For most people who are debugging/reading their ASM equivalent code, it would get annoying to read the same thing over and over ("dword ptr " ad-infitium).

In the end, MASM is a pretty good assembler... as long as you are aware of its idiosyncrasies.

     All my code has the following header statements

Q        EQU     QWORD PTR
D        EQU     DWORD PTR
W        EQU     WORD PTR
B        EQU     BYTE PTR

     So I code like this:

  PUSH W
  MOV AL,B
  ...ETC

Ratch

On the x86, register values (your first post) and immediate values (your 2nd post) that get moved into memory require an effective memory address. That memory address will always be direct, not a pointer to a pointer. So no, you are suck with the first method.

If you find yourself reloading a register with a memory value (like the "pTable" stored pointer) one too many times, you have to re-think and re-design the way you are programming. This is usually were functions/subroutines come in to play.

As for Ratch/JimmyClif's examples, it just reinforces why I will never program in MASM/POASM unless forced to. Using one abstraction to mask another was never my style. Basically, **** or get off the pot... but as I said... that is just my style ;)

You cannot use "one" instruction unless you create a macro (a fake instruction) that will generate two real instructions. The CPU itself does not support indirect addressing via memory for data.

No problem. Just keep in mind that high-level languages usually keep track of variable lifetime for you, which is calculated in to the optimizations. In Assembly Language, you have to exercise complete control. How/when you access a variable (or any data in memory/registers) is static, meaning that once you put that instrunction there... it stays there. You are the optimizer now ;)

It takes a bit to get used to, but eventually you will feel "naked" when programming in HLLs :P

you got fooled by stupid HLLish MASMy syntax, where "mov a, eax" is same as "mov ,eax". IMHO too many things are uncertain and context dependant in MASM, no general rules.

I meant like one of those dreams where you are in the middle of a crowd and they are staring at you because you are naked. You have know idea what to do... you just know you are not in control at the moment :P



That is why most of us do it. Just don't get "too" caught-up in optmizations. Usually there are better algorthims that you can implement if you find yourself in the middle of an optimization nightmare. Design your program from the Top-Down (HLL type logic), and build it from the Bottom-Up (ASM programming) :)