如何解决为什么x86通常不允许目标寄存器不是第一个源寄存器？
在RISC-V中，可以使用指令执行整数运算Regs[x1] <- Regs[x2]+Regs[x3]
add x1,x2,x3
在x86中，相同的操作显然需要两条指令，
mov x1,x2
add x1,x3
src1 <- src1 op src2模式对于x86中的其他基本指令来说似乎很常见，例如and，or和sub。但是，x86确实具有dest <- src1 op src2例如用于浮点add。
是两指令模式mov x1,x2； op x1,x3;通常被宏融合到单个微操作中？还是对于这些操作而言，独立的目的地如此罕见，以至于x86架构不会费心将其放在单个uop中？如果是这样，不允许独立目的地提供什么效率？
解决方法
几乎与What kind of address instruction does the x86 cpu have?相同，它解释了机器代码的原因（以及一般情况下的某些例外情况）。
如果是这样，不允许独立目的地提供什么效率？
仅代码大小。这会使其他所有情况变得更糟，这就是为什么所有现代高性能设计都提供3操作数指令的原因，以及如果他们从头开始重新构建x86-64以获得性能的话，任何人都会做什么。
x86使用紧凑的可变长度指令编码，而evolved as a 2-operand ISA out of 8-bit 8080大约是1-operand ISA，其中most opcodes implied one of the operands（通常是累加器）。
您可以说，作为CISC ISA，x86将其额外的编码空间用于存储源操作数的可能性，而不是用于单独的目标。尽管这只是一种事实，因为只有2位编码寄存器vs. [寄存器]间接vs. [reg + disp8]与[reg + disp32]。剩下的空间就不存在了，因为典型的指令只有2个字节长，操作码+ modrm。 （加上寻址模式的前缀，立即数和/或额外字节）。
有趣的是，16位的长度与ARM Thumb的长度相同，后者选择相同的选择主要是2操作数编码，因为这是使指令保持较小的方式，但有时却需要更多的指令。在原始的8086（尤其是带有半角总线的8088）上，代码提取是主要的瓶颈，而保存代码字节通常可以提高性能，而与指令数量无关。
然后将x86机器代码固定下来，而我们仍然坚持使用它。对于当今的CPU而言，这非常不便，因为32位模式下的VEX和EVEX编码比其他指令的无效编码更容易出错。这是一团糟，解码非常耗时且耗电。例如英特尔CPU有一个单独的流水线阶段，用于在将指令长度/边界馈送到解码器之前查找它们。这就是为什么现代CPU具有解码uop缓存，避免在“热”代码区域中进行重新解码的原因，以及为什么由于这些流水线较长而需要良好的分支预测的原因。
任何进行了2操作数编码以进行更大空间分配的大修都会引发一个问题，即为什么保留所有旧行李，为什么不从头开始呢？然后，为什么要完全使用x86-64，为什么不使用AArch64这样的简洁设计呢？
还要注意，ADDPD和ADDSD是2操作数SSE指令。相同指令的三操作数无损目标编码是AVX的新增功能，称为VADDPD / VADDSD。
MOV + ADD的效率
mov / add（和移位）可以通过lea完成，例如lea eax,[rdi + rsi*4]来实现return x + y*4;，从而解决了最常见指令的问题。 Using LEA on values that aren't addresses / pointers?看看x86-64优化的编译器输出。
mov reg,reg指令，但是每个ALU指令的数量明显少于1。硬件供应商还没有在解码时四处寻找融合机会。目前，他们仅将cmp / test +分支融合到单个uop中。 （或者on Intel Sandybridge-family，还有其他ALU +分支指令，例如AND + branch或DEC + branch。）What is instruction fusion in contemporary x86 processors?还涵盖了内存源CISC指令中load + ALU指令的微融合。>
MOV elimination在发布/重命名时确实使MOV + ALU对对于关键路径仍然只有1个周期的延迟。（尽管有时您可以通过使用关键路径使用原始副本，某些较短延迟或独立的dep链使用副本。但是通常这需要循环展开。）
但是，mov消除对前端吞吐量或使无序窗口保持较小状态没有帮助。对于其余的管道，MOV的成本与NOP相同。
Haswell至Skylake的前端宽度与后端中ALU执行单元的数量相同。即使使用Ice Lake和Zen（更宽的前端，仍然“仅”使用4个整数ALU执行单元），未消除的mov也很少成为瓶颈。大多数代码包括偶尔存储或非微融合的加载uop。
Intel 8086的两个操作数设计的原始动机（目的和第一个操作数必须是相同的寄存器）只是为了使指令解码器保持简单。 8086只有27,000个晶体管。英特尔没有晶体管预算来实现三个操作数指令集。
尽管经常批评x86指令集需要复杂的解码器，而这些解码器需要大量的晶体管，但只有当您尝试尽快解码现代x86指令集时，这才是正确的。正如最初的8086设计所示，从根本上来说，它不需要很多晶体管即可解码基本指令集。
设计8086时，两个操作数指令集没有什么异常之处。它的主要竞争对手68000和IBM大型机也有两个操作数指令集。这实际上是对8位微处理器设计（例如Intel 8080）的改进，后者的晶体管预算要小得多，通常会实现一个操作数指令集，而目标和第一个操作数始终是累加器。
尽管两个操作数指令集允许更紧凑的编码，但这不是目标。英特尔做出的一些设计决策简化了解码，实际上增加了代码大小。指令前缀占用了整个字节，以有效地在指令编码中添加一些位。但是，通过将它们视为在处理器中设置隐藏内部标志的单字节指令来实现它们非常容易。很少使用的一个字节的XCHG指令可能被设计为一种廉价的方式来实现NOP指令（XCHG AX，AX），尽管设计人员也有可能简单地认为它会经常用于证明一个字节编码的合理性。无论哪种方式，如果使用了其他操作码空间，那么还有许多其他更常用的操作可能会导致代码更紧凑。
如果要使用当今的晶体管预算从头开始设计指令集，则可能要设计三个操作数指令集。但是，在仍然需要晶体管数量的地方，您会看到相对较新的设计，例如仅支持两个操作数的8位AVR指令集。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。