Assembly 组件8086矩阵对角数和

我想对answer属性中的所有对角线项求和，但每个当前移动到edx的项都是错误的，因为它移动的不是正确的项，我假设这是因为32位寻址。我用turbo调试器调试。任何帮助都将不胜感激

.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

---

尝试将

cx

更改为

ecx

，在第行

mov cx, n

---

不清楚为什么需要这样做。OP使用的是

循环

，它（在16位模式下）仅使用

cx

。（，x86-16代码中的默认地址大小为16位）。OP将其标记为正确，这可能表明它们正在32位模式下进行汇编并运行，而不是在大多数指令中使用带有操作数大小/地址大小前缀的16位模式？

int 21h

甚至可以在32位保护模式下工作吗？@PeterCordes（我猜，没有验证）OP在

.model

之前有

.386

，这将导致32b PM的组装变体。仍然有可能生成16b EXE，并在16b实模式下运行，因此执行的代码会弄乱原始源代码，但不知怎的，它意外地为OP工作。。。是的，应该是一团糟，因为

.code

和

.386

根据

.model

是否已经完成而运行不同。但我太懒了，不敢尝试。。。编辑：使用TASM（可能OP使用的是MASM，可能行为不同，不知道）@Ped7g:那么这不应该被标记为x86-16，因为它在32位模式下运行？OP的代码是

.386

/

.model small

，但它们不显示任何用于构建它的命令。但如果这个答案解决了问题，那就可以解释了。@PeterCordes不可能知道他实际上在执行什么，但“turbo debugger”->听起来像16b可执行文件。所以机器代码是错误的，大部分可能是

mov bx，16

，而不是

mov ebx，16

，等等，但我预计会因此发生更多的灾难。仍然不愿意亲自尝试，因为缺少有关构建/工具等的信息。。。如果OP可以有不同的设置，那么复制我自己的想法是没有意义的。@Ped7g:为32位汇编并以16位运行或以16位运行将是一个完全混乱的过程，因为这些指令中有许多都有全尺寸的立即操作数

mov r32，imm32

的长度与

mov r16，imm16

的长度不同，因此操作数大小前缀的长度在变化，如果您处于错误模式，将中断后续指令的解码。唯一可能的结论是，OP是以32位的形式组装并以32位的形式运行的，或者他们做了其他错误的事情，在计算出16/32的混淆后，决定将此答案标记为正确。您应该只

添加edx，矩阵[esi]

，而不是使用两条指令在内存中添加一个值。循环完成后，您将其加载到一个寄存器中，这是完全反向的。将值保存在寄存器中，尤其是在循环中。如果您需要将它们存储在内存中，请在循环后存储到内存中，否则根本不需要。另外，

添加esi，16

在这里是正常的。或者

添加esi，4*（m+1）

而不是硬编码行步幅。此外，您可以从

movesi、OFFSET matrix

开始，并使用指针增量。或者至少将

move-esi，0

替换为

xor-esi，esi

。