blocks|key|223568|text|它只是节省了指令和指令集的空间。您可以使用现有的(32位)指令将较小的立即值移动到64位寄存器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|223569|当MOV+EAX,+42可以重用时，它还使您不必为MOV+RAX,+42编码8字节值。|offset|length|style|CODE|223570|这种优化对于8位和16位op并不重要(因为它们较小)，而且更改规则也会破坏旧代码。|223571|entityMap^0|0|1|B|P|B|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

It simply saves space in the instructions, and the instruction set. You can move small immediate values to a 64-bit register by using existing (32-bit) instructions. 

It also saves you from having to encode 8 byte values for <code>MOV RAX, 42</code>, when <code>MOV EAX, 42</code> can be reused.

This optimization is not as important for 8 and 16 bit ops (because they are smaller), and changing the rules there would also break old code.

blocks|key|2875572|text|我不是AMD，也不是他们的代言人，但我也会以同样的方式去做。因为将上半部分置零不会创建对前一个值的依赖关系，所以CPU必须等待。如果不这样做，register+renaming机制基本上就会失败。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2875573|这样，您就可以在64位模式下使用32位值编写快速代码，而不必总是显式地破坏依赖关系。如果没有这种行为，64位模式中的每一条32位指令都必须等待之前发生的事情，即使高位部分几乎永远不会被使用。(将int设为64位会浪费缓存空间和内存带宽；x86-64+most+efficiently+supports+32+and+64-bit+operand+sizes)|style|CODE|2875574|8位和16位操作数大小的行为很奇怪。依赖的疯狂是现在避免16位指令的原因之一。x86-64继承了8086的8位和386的16位寄存器，并决定让8位和16位寄存器在64位模式下的工作方式与在32位模式下的工作方式相同。|2875575|2875576|有关实际CPU如何处理对8位和16位部分寄存器的写入(以及后续读取完整寄存器)的实际详细信息，请参阅Why+doesn't+GCC+use+partial+registers?。|2875577|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Register_renaming|1|https://stackoverflow.com/questions/38303333/the-advantages-of-using-32bit-registers-instructions-in-x86-64|2|https://stackoverflow.com/questions/41573502/why-doesnt-gcc-use-partial-registers^0|1Z|H|0|0|2P|3|3A|1O|1|0|0|0|1E|12|2|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|D|3|E|5|6|7|12|8|@$A|13|B|14|F|G]]|9|@$A|15|B|16|1|17]]|C|$]]|$1|H|3|I|5|6|7|18|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|19|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|1A|8|@]|9|@$A|1B|B|1C|1|1D]]|C|$]]|$1|M|3|-4|5|6|7|1E|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]|U|$5|P|Q|R|C|$S|V]]|W|$5|P|Q|R|C|$S|X]]]]

I'm not AMD or speaking for them, but I would have done it the same way. Because zeroing the high half doesn't create a dependency on the previous value, that the CPU would have to wait on. The <a href="https://en.wikipedia.org/wiki/Register_renaming" rel="noreferrer">register renaming</a> mechanism would essentially be defeated if it wasn't done that way.

This way you can write fast code using 32-bit values in 64-bit mode without having to explicitly break dependencies all the time. Without this behaviour, every single 32-bit instruction in 64-bit mode would have to wait on something that happened before, even though that high part would almost never be used. (Making <code>int</code> 64-bit would waste cache footprint and memory bandwidth; <a href="https://stackoverflow.com/questions/38303333/the-advantages-of-using-32bit-registers-instructions-in-x86-64">x86-64 most efficiently supports 32 and 64-bit operand sizes</a>)

The behaviour for 8 and 16-bit operand sizes is the strange one. The dependency madness is one of the reasons that 16-bit instructions are avoided now. x86-64 inherited this from 8086 for 8-bit and 386 for 16-bit, and decided to have 8 and 16-bit registers work the same way in 64-bit mode as they do in 32-bit mode.

<hr>

See also <a href="https://stackoverflow.com/questions/41573502/why-doesnt-gcc-use-partial-registers">Why doesn&#39;t GCC use partial registers?</a> for practical details of how writes to 8 and 16-bit partial registers (and subsequent reads of the full register) are handled by real CPUs.

blocks|key|2875635|text|如果不将零扩展到64位，这将意味着从rax读取的指令将对其rax操作数(写入eax的指令和之前写入rax的指令)具有两个依赖项，这将导致partial+register+stall，当有3个可能的宽度时，这将开始变得棘手，因此它有助于rax和eax写入完整寄存器，这意味着64位指令集不会引入任何新的部分重命名层。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2875636|mov+rdx,+1
mov+rax,+6
imul+rax,+rdx
mov+rbx,+rax
mov+eax,+7+//retires+before+add+rax,+6
mov+rdx,+rax+//+has+to+wait+for+both+imul+rax,+rdx+and+mov+eax,+7+to+finish+before+dispatch+to+the+execution+units,+even+though+the+higher+order+bits+are+identical+anyway|code-block|syntax|javascript|2875637|非零扩展的唯一好处是确保包含rax的高位，例如，如果最初包含0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff通过保证它总是被零扩展到64位，编译器可以在mov+rdx,+rax中使用这个公理，而rax只需要等待它的单个依赖项，这意味着它可以更快地开始执行和退出，从而释放执行单元。此外，它还允许更有效的零习惯用法，如xor+eax,+eax+to+zero+rax，而不需要REX字节。|2875638|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/49867597/what-is-a-partial-flag-stall/65914478#65914478^0|I|3|T|3|12|3|1D|3|39|3|3D|3|1W|M|0|0|0|E|3|BG|C|C1|3|DQ|C|EB|3|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]]|D|@$9|17|A|18|1|19]]|E|$]]|$1|F|3|G|5|H|7|1A|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|1B|8|@$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]|$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]|$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|M|3|-4|5|6|7|1M|8|@]|D|@]|E|$]]]|N|$O|$5|P|Q|R|E|$S|T]]]]

Without zero extending to 64 bits, it would mean an instruction reading from <code>rax</code> would have 2 dependencies for its <code>rax</code> operand (the instruction that writes to <code>eax</code> and the instruction that writes to <code>rax</code> before it), this would result in a <a href="https://stackoverflow.com/questions/49867597/what-is-a-partial-flag-stall/65914478#65914478">partial register stall</a>, which starts to get tricky when there are 3 possible widths, so it helps that <code>rax</code> and <code>eax</code> write to the full register, meaning the 64-bit instruction set doesn't introduce any new layers of partial renaming.
<pre><code>mov rdx, 1
mov rax, 6
imul rax, rdx
mov rbx, rax
mov eax, 7 //retires before add rax, 6
mov rdx, rax // has to wait for both imul rax, rdx and mov eax, 7 to finish before dispatch to the execution units, even though the higher order bits are identical anyway
</code></pre>
The only benefit of not zero extending is ensuring the higher order bits of <code>rax</code> are included, for instance, if it originally contains 0xffffffffffffffff, the result would be 0xffffffff00000007, but there's very little reason for the ISA to make this guarantee at such an expense, and it's more likely that the benefit of zero extension would actually be required more, so it saves the extra line of code <code>mov rax, 0</code>. By guaranteeing it will always be zero extended to 64 bits, the compilers can work with this axiom in mind whilst in <code>mov rdx, rax</code>, <code>rax</code> only has to wait for its single dependency, meaning it can begin execution quicker and retire, freeing up execution units. Furthermore, it also allows for more efficient zero idioms like <code>xor eax, eax</code> to zero <code>rax</code> without requiring a REX byte.

blocks|key|2875698|text|从硬件的角度来看，更新半个寄存器的能力总是有些昂贵，但在最初的8088上，允许手写汇编代码将8088视为具有两个非堆栈相关的16位寄存器和八个8位寄存器、六个非堆栈相关的16位寄存器和零个8位寄存器或16位和8位寄存器的其他中间组合是有用的。这样的实用性值得付出额外的代价。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2875699|当80386添加32位寄存器时，没有提供仅访问寄存器上半部分的工具，但像ROR+ESI,16这样的指令将足够快，因此仍然可以在ESI中保存两个16位值并在它们之间切换。|offset|length|style|CODE|2875700|随着向x64体系结构的迁移，增加的寄存器集和其他体系结构增强减少了程序员将最大信息量挤入每个寄存器的需要。此外，寄存器重命名增加了执行部分寄存器更新的成本。如果代码要做类似这样的事情：|2875701|++++mov+rax,[whatever]
++++mov+[something],rax
++++mov+rax,[somethingElse]
++++mov+[yetAnother],rax|code-block|syntax|javascript|2875702|寄存器重命名和相关逻辑可以使CPU记录从[whatever]加载的值将需要写入something的事实，然后--只要最后两个地址不同--允许处理somethingElse的加载和对yetAnother的存储，而不必等待从whatever实际读取数据。然而，如果第三个指令是mov+eax,[somethingElse，并且它被指定为不影响上半部分，那么在第一个加载完成之前，第四个指令不能存储RAX，甚至允许EAX的加载也将是困难的，因为处理器必须跟踪这样的事实:虽然下半部分可用，但上半部分不可用。|2875703|entityMap^0|0|10|A|0|0|0|K|A|13|9|20|D|2I|A|32|8|3S|M|5O|3|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|X|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|Y|8|@$D|Z|E|10|F|G]|$D|11|E|12|F|G]|$D|13|E|14|F|G]|$D|15|E|16|F|G]|$D|17|E|18|F|G]|$D|19|E|1A|F|G]|$D|1B|E|1C|F|G]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|R|$]]

From a hardware perspective, the ability to update half a register has always been somewhat expensive, but on the original 8088, it was useful to allow hand-written assembly code to treat the 8088 as having either two non-stack-related 16-bit registers and eight 8-bit registers, six non-stack-related 16-bit registers and zero 8-bit registers, or other intermediate combinations of 16-bit and 8-bit registers. Such usefulness was worth the extra cost.
When the 80386 added 32-bit registers, no facilities were provided to access just the top half of a register, but an instruction like <code>ROR ESI,16</code> would be fast enough that there could still be value in being able to hold two 16-bit values in ESI and switch between them.
With the migration to x64 architecture, the increased register set and other architectural enhancements reduced the need for programmers to squeeze the maximum amount of information into each register. Further, register renaming increased the cost of doing partial register updates. If code were to do something like:
<pre><code> mov rax,[whatever]
 mov [something],rax
 mov rax,[somethingElse]
 mov [yetAnother],rax
</code></pre>
register renaming and related logic would make it possible to have the CPU record the fact that the value loaded from <code>[whatever]</code> will need to be written to <code>something</code>, and then--so long as the last two addresses are different--allow the load of <code>somethingElse</code> and store to <code>yetAnother</code> to be processed without having to wait for the data to actually be read from <code>whatever</code>. If the third instruction were <code>mov eax,[somethingElse</code>, however, and it were specified as leaving the upper bits unaffaected, the fourth instruction couldn't store RAX until the first load was completed, and even allowing even the load of <code>EAX</code> to occur would be difficult, since the processor would have to keep track of the fact that while the lower half was available, the upper half wasn't.

In the <a href="http://x86asm.net/articles/x86-64-tour-of-intel-manuals/" rel="noreferrer">x86-64 Tour of Intel Manuals</a>, I read

<blockquote>
 Perhaps the most surprising fact is that an instruction such as <code>MOV EAX, EBX</code> automatically zeroes upper 32 bits of <code>RAX</code> register.
</blockquote>

The Intel documentation (3.4.1.1 General-Purpose Registers in 64-Bit Mode in manual Basic Architecture) quoted at the same source tells us:

<blockquote>
 <ul>
 <li>64-bit operands generate a 64-bit result in the destination general-purpose register.</li>
 <li>32-bit operands generate a 32-bit result, zero-extended to a 64-bit result in the destination general-purpose register.</li>
 <li>8-bit and 16-bit operands generate an 8-bit or 16-bit result. The upper 56 bits or 48 bits (respectively) of the destination general-purpose register are not be modified by the operation. If the result of an 8-bit or 16-bit operation is intended for 64-bit address calculation, explicitly sign-extend the register to the full 64-bits.</li>
 </ul>
</blockquote>

In x86-32 and x86-64 assembly, 16 bit instructions such as

<pre><code>mov ax, bx
</code></pre>

don't show this kind of "strange" behaviour that the upper word of eax is zeroed.

Thus: what is the reason why this behaviour was introduced? At a first glance it seems illogical (but the reason might be that I am used to the quirks of x86-32 assembly).

Why do x86-64 instructions on 32-bit registers zero the upper part of the full 64-bit register?

在中，我读到也许最令人惊讶的事实是，诸如MOV EAX, EBX这样的指令会自动将RAX寄存器的高32位清零。在同一来源引用的英特尔文档(手册基本体系结构中64位模式下的3.4.1.1通用寄存器)告诉我们：在目标通用register.32-bit操作数中，64位操作数生成64位结果，在目标通用register.8-bi...

问为什么32位寄存器上的x86-64指令将整个64位寄存器的高位部分置零？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么32位寄存器上的x86-64指令将整个64位寄存器的高位部分置零？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么32位寄存器上的x86-64指令将整个64位寄存器的高位部分置零？
EN