Algorithm 使用多寄存器处理大量数据_Algorithm_Assembly_X86_Real Mode

Algorithm 使用多寄存器处理大量数据

algorithm assembly x86

Algorithm 使用多寄存器处理大量数据,algorithm,assembly,x86,real-mode,Algorithm,Assembly,X86,Real Mode,如何使用多寄存器处理大量数据假设您需要对32位寄存器中无法容纳的大数进行一些计算，并且解决问题的唯一方法是使用寄存器，则内存解决方案不可用像乘法和偏差：我们有edx:eax 是否有方法、算法或指令将您的值直接放入reg1:reg2:reg3…regn 例如，如果内存中有dq如何一次存储在两个32位寄存器中如果可能的话对于旧的8080和Z80 CPU，直接支持多寄存器操作，尽管只有预选寄存器对，例如Z80有8位寄存器a、b、c、d、e、h，l和指令，如添加hl、de，使用16b对它们进行

如何使用多寄存器处理大量数据

假设您需要对32位寄存器中无法容纳的大数进行一些计算，并且解决问题的唯一方法是使用寄存器，则内存解决方案不可用

像乘法和偏差：

我们有

edx:eax

是否有方法、算法或指令将您的值直接放入

reg1:reg2:reg3…regn

例如，如果内存中有

dq

如何一次存储在两个32位寄存器中如果可能的话

对于旧的8080和Z80 CPU，直接支持多寄存器操作，尽管只有预选寄存器对，例如Z80有8位寄存器

a、b、c、d、e、h，l

和指令，如

添加hl、de

，使用16b对它们进行操作（但例如，与8位

add d、e

等相反，此16b

add

不更新标志，并且它们比8位变体稍慢，因此使用16位值仍有一些缺点，尽管通常16b对比仅使用8位指令编写的相同任务更有效

8080的这一特性是8086

ah:al=ax

8b寄存器的灵感（我想没有事实）形成了16b寄存器，其指令不仅使用8位寄存器，而且还使用预选对进行操作。虽然8086更像本机16b CPU，但这一特性相当复杂“支持将16b寄存器分解为8b，使8b SW的迁移更容易”，而不是“支持将两个8b寄存器配对以实现16b数学”

在此之后，80386放弃了这种做法，名为

eax

的

寄存器的32位扩展没有为上16b部分添加新别名，这使得单独访问它变得更加困难（低16b被原始

ax

别名，这对于8086/186/286的向后兼容性是必需的）

由于

eax、ebx、

上部的那些额外16b寄存器会大大增加寄存器的数量，使旧的指令编码不再可行，而且实际上，由于x86指令集的性质，基本指令的长度很难保持在2字节左右，因此额外的组合将可能会将平均值提高到3字节

现在，支持更多多寄存器组合的想法将使所需的操作码爆炸得更快更快，因此这样的ISA平均每条指令大约需要4-6字节

虽然基本上花了相当长的时间，人们才开始觉得受到16b数学的严重限制（在我看来，0到65535之间的值确实很多，当时我用Z80 CPU在ZX频谱上做一些程序），32b是真正的突破，即使是大多数现实生活中的人类数学任务，如《商店里的价格》等，也可以用32b整数轻松完成。又过了十年多，才更频繁地达到这个极限（而不仅仅是在特殊情况下），比如整部电影开始在磁盘上编码，磁盘的大小通常超过了千兆字节

因此，您所要求的通常是完全不需要的（今天的64b选项更进一步，它涵盖了疯狂的值范围），当您最终需要时，从单独的指令构建它是非常简单的…例如80386+代码添加

eax:ebx:ecx

和

esi:edi:edx

：

    ; eax:ebx:ecx += esi:edi:edx  (96b integer addition)
    add  ecx, edx
    adc  ebx, edi
    adc  eax, esi

非常简单，不足以证明上述操作码大小的爆炸性增长可以直接放入CPU。

对于旧的8080和Z80 CPU，直接支持多寄存器操作，尽管只有预选寄存器对，如Z80有8位寄存器

a、b、c、d、e、h、l

和指令like

add hl，de

使用16b对它们进行操作（但例如，与8位

add d、e