32ビットレジスタのx86-64命令が完全な64ビットレジスタの上位部分をゼロにするのはなぜですか？

ではインテルのマニュアルのx86-64のツアー、私が読んで

おそらく最も驚くべき事実はMOV EAX, EBX、RAXレジスタなどの上位32ビットを自動的にゼロにするなどの命令です。

同じ出典で引用されているIntelのドキュメント（手動の基本アーキテクチャで64ビットモードの3.4.1.1汎用レジスター）は、次のように述べています。

• 64ビットのオペランドは、宛先の汎用レジスターで64ビットの結果を生成します。
• 32ビットのオペランドは32ビットの結果を生成し、デスティネーションの汎用レジスターで64ビットの結果にゼロ拡張します。
• 8ビットおよび16ビットのオペランドは、8ビットまたは16ビットの結果を生成します。デスティネーション汎用レジスタの上位56ビットまたは48ビットは、それぞれ操作によって変更されません。8ビットまたは16ビット演算の結果が64ビットのアドレス計算を目的としている場合は、明示的にレジスタを完全な64ビットに符号拡張します。

x86-32およびx86-64アセンブリでは、次のような16ビット命令

mov ax, bx

eaxの上位ワードがゼロになるこの種の「奇妙な」動作を表示しないでください。

したがって、この動作が導入された理由は何ですか？一見すると論理的に見えないようです（ただし、x86-32アセンブリの癖に慣れているためかもしれません）。

私はAMDではないし、彼らの代弁者でもないが、私は同じようにそれをしただろう。上位半分をゼロにしても、以前の値に依存しないため、CPUは待機する必要があります。レジスタリネーム、それはそのように行われていなかった場合のメカニズムは基本的に敗北するだろう。

このようにして、常に明示的に依存関係を壊す必要なしに、64ビットモードで32ビット値を使用して高速コードを記述できます。この動作がなければ、64ビットモードのすべての32ビット命令は、その高い部分がほとんど使用されない場合でも、以前に発生した何かを待つ必要があります。（int64ビットを作成すると、キャッシュフットプリントとメモリ帯域幅が無駄になります。x86-64は、32ビットと64ビットのオペランドサイズを最も効率的にサポートします）

8ビットと16ビットのオペランドサイズの動作は奇妙です。依存関係の狂気は、16ビット命令が現在回避されている理由の1つです。x86-64は、これを8ビットの場合は8086、16ビットの場合は386から継承し、8ビットと16ビットのレジスタを64ビットモードでも32ビットモードと同じように機能させることにしました。

参照してくださいGCCは一部のレジスタを使用していないのはなぜ？8ビットおよび16ビットのパーシャルレジスタへの書き込み（およびその後のフルレジスタの読み取り）が実際のCPUによってどのように処理されるかについての実用的な詳細については。

命令と命令セットのスペースを節約するだけです。既存の（32ビット）命令を使用して、小さな即値を64ビットレジスタに移動できます。

またMOV RAX, 42、MOV EAX, 42再利用できる場合、の8バイト値をエンコードする必要がなくなります。

この最適化は8ビットと16ビットの演算ではそれほど重要ではなく（それらが小さいため）、そこでルールを変更すると古いコードも壊れます。

ゼロが64ビットに拡張されていない場合、それは、読み取り命令raxがそのraxオペランドに2つの依存関係（書き込むeax命令とそのrax前に書き込む命令）を持つことを意味します。これは、1）ROBが単一のオペランドに対する複数の依存関係。つまり、ROBはより多くのロジックとトランジスタを必要とし、より多くのスペースを必要とし、実行に時間がかかる可能性のある不要な2番目の依存関係の待機が遅くなります。または2）、16ビット命令で発生すると思いますが、割り当てステージはおそらく停止します（つまり、RATにax書き込み用のアクティブな割り当てがあり、eax読み取りが表示される場合、それはax書き込みが終了するます）。

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

ゼロ拡張しない唯一の利点は、の上位ビットが確実にrax含まれることです。たとえば、元々0​​xffffffffffffffffが含まれている場合、結果は0xffffffff00000007になりますが、ISAがそのような費用でこの保証を行う理由はほとんどありません。ゼロ拡張のメリットが実際に必要になる可能性が高くなるため、コードの余分な行を節約できますmov rax, 0。常に64ビットにゼロ拡張されることを保証することにより、コンパイラーは、この公理を念頭に置いて作業できます。一方、はmov rdx, rax、rax単一の依存関係を待つだけで済みます。つまり、実行をより早く開始してリタイアし、実行ユニットを解放できます。さらに、REXバイトを必要とせずxor eax, eaxにゼロ化raxするような、より効率的なゼロイディオムも使用できます。