1

I want to sum all diagonal items in answer property, but each current moving item to edx is wrong as it moves not the right one, I assume it's because of 32 bit addressing. I debugged with turbo debugger. Any help will be appreciated. 

.386
.model small
.stack 16h
.data
matrix dd 1, 2, 3
       dd 4, 5, 6
       dd 7, 8, 9
n equ 3
m equ 3 

answer dd 0

.code 
start: 
mov ax, @data
mov ds, ax 

mov cx, n
mov ebx, 16
mov esi, 0 
zrtik: 
mov edx, matrix [esi]
add answer, edx
add esi, ebx
loop zrtik

mov edx, answer 


mov ah, 4ch
int 21h
end start
Vahe Karamyan
  • 33
  • 1
  • 10
  • You should just `add edx, matrix[esi]` instead of using 2 instructions to add to a value in memory. After the loop you're loading it into a register, which is totally backwards. Keep values in registers especially inside loops. If you need them in memory, store to memory after the loop, otherwise not at all. Also, `add esi, 16` would be the normal thing here. Or `add esi, 4 * (m+1)` instead of hard-coding the row-stride. Also, you could start with `mov esi, OFFSET matrix` and use a pointer increment. Or at least replace `mov esi,0` with `xor esi,esi`. – Peter Cordes Apr 06 '18 at 04:35

1 Answers1

1

Try to change cx into ecx, in line

mov cx, n
Sep Roland
  • 33,889
  • 7
  • 43
  • 76
Spike Bughdaryan
  • 160
  • 1
  • 9
  • It's not clear *why* this would be needed. The OP is using `loop`, which (in 16-bit mode) only uses `cx`. ([`loop` uses the address-size to choose between cx / ecx / rcx](https://stackoverflow.com/questions/46881279/how-exactly-does-the-x86-loop-instruction-work/), and the default address-size in x86-16 code is 16 bits). The OP marked this correct, which maybe indicates that they're assembling for and running in 32-bit mode, rather than 16-bit mode with operand-size / address-size prefixes for most of the instructions? Does `int 21h` even work in 32-bit protected mode? – Peter Cordes Apr 06 '18 at 04:28
  • @PeterCordes (I guess, didn't verify) OP has `.386` ahead of `.model`, which will cause 32b PM variant of assembling. It's still possible that 16b EXE is produced, and run in 16b real mode, and the executed code is thus messed up original source, but it somehow works for OP by accident? ... Yeah, should be messed up, because the `.code` and `.386` operate differently based on `.model` been already done or not. But too lazy to try myself. ... EDIT: with TASM (maybe OP is using MASM and that maybe behaves differently, no idea) – Ped7g Apr 06 '18 at 07:04
  • @Ped7g: Then this shouldn't be tagged x86-16, because it's running in 32-bit mode? The OP's code is `.386` / `.model small`, but they don't show any commands for building it. But if this answer fixed it, then that would explain it. – Peter Cordes Apr 06 '18 at 15:23
  • 1
    @PeterCordes it's impossible to tell what he is actually executing, but "turbo debugger" -> sounds like 16b executable. So the machine code is wrong, most of that is probable `mov bx,16` instead of `mov ebx,16`, etc, but I would expect lot more havoc to happen due to that. Still not willing to try myself, because missing info in question about build/tools/etc... no point to replicate my own idea, if the OP can have different setup. – Ped7g Apr 06 '18 at 15:35
  • 1
    @Ped7g: Assembling for 32-bit and running as 16 or vice versa would be a total mess, because many of these instructions have full-size immediate operands. `mov r32, imm32` is a different length from `mov r16, imm16`, so the operand-size prefix is length-changing and will break decoding of later instructions if you're in the wrong mode. Only possible conclusion is that the OP is assembling as 32-bit and running as 32-bit, or else they were doing something else wrong and just decided to mark this answer correct after figuring out a 16 / 32 mixup. – Peter Cordes Apr 06 '18 at 15:44