prob with this small piece of code

[Rainstorm]

ji,..

Code Select Expand

  .data
blockk db 4 dup (?)

    .code

start:
  mov blockk, 6
  mov ecx, 4
  mov esi, offset blockk    ; get the base address

    @@:

    mov edx, [esi+ecx]
  print ustr$(edx),13,10
  sub ecx, 1
  jnc @B

  inkey
  exit
end start

[MichaelW]

The problem is that the StdOut function called by the print macro, like all of the MASM32 functions, and all of the Windows API functions, does not preserve ECX (or EAX or EDX). Also [ESI+4] is actually one byte past the end of your data.

[Rainstorm]

I am not getting the windows error msg now,.. after modifying the code & its
assembling proper (was assembling proper before too)
however it isn't showing all the values
jussst one line appears..in the dos window

[Edit] :i had pusshed & popped wrongly after modifying that am getting 4 values in the dos
window & it seems to work proper.

here's the modified code..

Code Select Expand

   .data

blockk db 4 dup (?)


    .code

start:
  mov blockk, 6
  mov ecx, 3
  mov esi, offset blockk    ; get the base address

    @@:

    mov edx, [esi+ecx]

push edx
push ecx

  print ustr$(edx),13,10

[color=Red]pop ecx
pop edx[/color]

  sub ecx, 1
  jnc @B

  inkey
  exit

end start

thankyou.

[MichaelW]

Your pushes and pops are out of order. The stack works as Last-In-First-Out, so the pops need to be reversed. Also, for this code there is no need to preserve EDX because you are reloading it at the top of the loop.

[Rainstorm]

ya, i just realised that & Edited my earlier post saying that (about the push & pops)

here's the output i get

Code Select Expand


0
3145720
855630016
6


i presume the 6 that i moved goes into the 1st byte of the array
don't quite understand the other 3 values though

ty

Rainstorm

[MichaelW]

You did not initialize the data when you defined it, so initially all the bytes contain whatever garbage value happens to be stored there. But there is another error that I failed to see. Because the destination register is 32 bits MASM is assuming that you want to move DWORD values into EDX, and is encoding the instruction accordingly. To load byte values, which is how the data is defined, the instruction should be:

Code Select Expand


movzx edx, BYTE PTR[esi+ecx]


[Rainstorm]

thanks  MichaelW.

Because the destination register is 32 bits MASM is assuming that you want to move DWORD values into EDX, and is encoding the instruction accordingly.

was that,....because it works properly no.

-

[MichaelW]

No, it does not work properly. Because you are accessing 4 bytes of data as DWORDs, when ECX = 3 you are actually accessing 3 bytes past the end of the data. When ECX = 0, EDX gets the value 6 only if the second, third, and fourth bytes are set to zero. In the following, the bytes are reversed between memory and register because that is how the processor stores DWORDs (and WORDs).

blockk 6???XXX

ECX = 0, EDX = ???6
ECX = 1, EDX = X???
ECX = 2, EDX = XX??
ECX = 3, EDX = XXX?

[Rainstorm]

michael sry made a typo in my last post  : )
thought it worked proper..
(using  -  movzx edx, BYTE PTR[esi+ecx])

rainstorm wrote..

was that,....because it works properly no.

no = now*
meant,  now..

this is the out put i get..

Code Select Expand

0
0
0
6

thnks for the explanation.
just trying to understand all that you said in the last post.
will post again..

-

[Rainstorm]

hi,..just want to confirm that am understanding you properly about the dwords.

quote..

No, it does not work properly. Because you are accessing 4 bytes of data as DWORDs, when ECX = 3 you are actually accessing 3 bytes past the end of the data. When ECX = 0, EDX gets the value 6 only if the second, third, and fourth bytes are set to zero.

movzx edx, BYTE PTR[esi+ecx]

could you confirm this for me..
Do you mean that,.. because the destination edx is 32bit that it automatically accesses 4 bytes
from the given address onwards in the source operand ?

Also, if  i did,  movzx edx, BYTE PTR blockk[ecx] that would just access a byte right ? & not aa Dword - since the induvidual elements are always bytes.

As for the bytes getting inverted while put in memory, that thing always confuses me in the code,
as sometimes when taken out of the memory in code it gets inverted agaain & so turns out
right in the end - if there's something that's done to usually handle that..could you mention it.

------------------------------------------
i tried this too
in the old code (with,   movzx edx, BYTE PTR[esi+ecx])
I intialised the other bytes in the data decleration..

blockk db 4 dup (4)

& still got a proper out put

4     (ecx = 3)
4     (ecx = 2)
4      (ecx = 1)
6      (ecx = 0)

Many thanks.

Rainstorm

[MichaelW]

For this form:

mov edx, [esi+ecx]

Each move is moving a dword into edx.

For this form:

movzx edx, BYTE PTR[esi+ecx]

Each move is moving a byte into dl and zero extending it to fill the full 32-bit register.

I was assuming that you were still using the first form.

The reverse storage in memory matters for values that were stored in memory as one size, and are being accessed as a different size. For example, if you stored the byte sequence 12h, 34h, 56h, 78h in memory and accessed it as a dword, you would get 78563412h.