As part of a larger program, I've tried to have some quick visual debugging output.
An array of dd (that each hold a byte sized value) get reduced to an ascii db and copied to a zero terminated string.
Unfortunately it seems to come out as 4 bytes, though with forced code comes out as expected.
PABCD@@@B@@@C@@@D PABCD as expected (forced)
P@@@A@@@B@@@C@@@D P@@@A as it actually is
steps dd 0
but dd 16, 1, 2, 3, 4,
5, 6, 7, 8,
9,10,11,12,
13,14,15,16,
0, 0
szWorks db "The algorithm works.",0,0,0,0
szWhat db " ",0,0,0,0
fill1 db 64 (32)
fill2 db 0,0,0,0
.code
mov edx, but[ 0]
add edx, 64
mov szWhat[0], dl
mov eax, 1
.if eax == 0 ;forced code
mov edx, 65
mov szWhat[ 1], dl
mov edx, 66
mov szWhat[ 2], dl
mov edx, 67
mov szWhat[ 3], dl
mov edx, 68
mov szWhat[ 4], dl
.elseif eax == 1 ;intended code
mov edx, but[ 1]
add edx, 64
mov szWhat[ 1], dl
mov edx, but[ 2]
add edx, 64
mov szWhat[ 2], dl
mov edx, but[ 3]
add edx, 64
mov szWhat[ 3], dl
mov edx, but[ 4]
add edx, 64
mov szWhat[ 4], dl
.endif
[attachment deleted by admin]
Yes !
Thanks Eóin
That was it, it was driving me nuts.
Compiler languages with their automatic array element size adjustments clouded my thinking.
Kept thinking it is a dword array so it takes a dword chunck at a time and indexes by dwords
but my reasoning was flawed, thinking the index is incremented in dwords
when it is really incremented in bytes.
so it should be
mov edx, but[ 1*4] letting the assembler calculate the offset into the array
add edx, 64
mov szWhat[ 1], dl
mov edx, but[ 2*8]
or
mov edx, but[ 4] or precalculating it manually
add edx, 64
mov szWhat[ 1], dl
mov edx, but[ 8]