將小數字加載到64位x86寄存器中

Question

在64位x86 CPU下，我們通常將數字-1加載到寄存器中，如：

mov     rdx, -1  //  48BAFFFFFFFFFFFFFFFF

...這個操作碼需要10個字節。

另一種方式是：

xor     rdx, rdx //  4831D2        
dec     rdx      //  48FFCA  

...這個操作碼只需要6個字節。

編輯 ：

正如JensBjörnhager所說（我已經測試過） xor edx, edx操作碼應該清除整個rdx寄存器：

xor     edx, edx //  31D2        
dec     rdx      //  48FFCA 

...這個操作碼只需要5個字節。

編輯：

Alex找到另一個解決方案

mov     rdx, -1  // 48C7C2FFFFFFFF

...這個操作碼只需要7個字節。 但是如何告訴編譯器使用更短的操作碼（不使用DB）？

...

什么是更快，什么更經濟？

Answer 1

比所有提到的更短： 4883CAFF OR rdx,-1
它具有對我所知道的所有體系結構具有錯誤依賴性的令人討厭的特性，但它不應該被提及IMO。 有合理的理由使用它。 例如，如果直到很久之后才需要結果，並且它處於循環中，否則它將不適合四個16字節塊。 此外，如果速度對於特定代碼片段並不是一個大問題，那么也不要浪費寶貴的緩存空間。 它也可以用於對齊原因，但是填充到下一個更高的對齊幾乎肯定會更快。

至於告訴編譯器這個，我還沒有得到線索。

Answer 2

第一個要好得多。 第一個沒有依賴關系。 第二種具有最差的依賴性之一 - 指令在它開始之前需要緊接在它之前的指令的最終結果。 但是，如果你有一些其他指令可以在xor和dec之間滑動，那將消除依賴性，然后第二個選項可能會勝出。

第二個也對rdx的值有假依賴，而第一個沒有。 某些CPU可能足夠智能以識別此錯誤依賴性並且不會停止第一條指令，直到rdx的值已知（因為輸出為零，無論如何）。 某些x86 CPU確實具有忽略某些錯誤依賴性的邏輯。

比較代碼字節數並不是很有用。 在大多數現實條件下，代碼占用的字節數非常大。

Answer 3

還有另一種7字節的mov rdx, -1編碼mov rdx, -1 ：48C7C2FFFFFFFF。

您可以嘗試在代碼中將指令寫為mov rdx, dword -1 ，以幫助編譯器/匯編器使用這種較短的編碼。