作為在運行時生成 x86-64 機器代碼的專案的一部分，我經常需要將一個位從一個暫存器復制到另一個位位置的另一個暫存器。
我想出了這段代碼（將源暫存器的第 23 位復制到目標的第 3 位的示例）：
bt eax, 23 ; test bit 23 of eax (source)
setc ebx ; copy result to ebx (ebx is guaranteed to be zero before)
shl ebx, 3 ; shift up to become our target bit 3
and ecx, 0xFFFFFFF7 ; remove bit 3 from ecx (target)
or ecx, ebx ; set new bit value
鑒于我需要 5 條指令來將一個暫存器的一位復制到另一個暫存器的另一位，我想在 x86 上是否有使用較少指令的東西？
我已經閱讀了一些關于 BMI 指令的內容，但不幸的是它們不提供使用立即數的位提取。
uj5u.com熱心網友回復：
選擇：
rcr ecx,3 1
bt eax,23
rcl ecx,3 1
uj5u.com熱心網友回復：
指令數量不是一個好的性能指標。 以位元組為單位的代碼大小（x86 機器指令是可變長度），或現有主流 CPU 如何執行它們：前端微指令的數量（解碼后）和/或延遲/吞吐量是相關的優化目標，重要的取決于關于這么小的東西的周圍代碼。（在預測現代超標量處理器上的操作延遲時需要考慮哪些因素以及如何手動計算它們？）
rcr/rcl不幸的是非常慢，尤其是 count != 1。
四個單 uop 指令要快得多，包括一個BMI2rorx，用于將要插入的位復制并旋轉到 tmp 暫存器中的正確位置，然后and將其隔離。或正常班次/如果您不需要保留輸入。這比我想通過 CF 反彈它的任何方法都更有效。
這比xor-zero/ bt/ setc/更有效shl。它還避免了部分注冊錯誤依賴或停滯：setc ebx不存在，僅setc bl（或setc bh）。這也意味著，如果您可以銷毀輸入暫存器而不是使用臨時暫存器，那么您就不需要像setc bl/這樣低效的東西movzx ebx, bl，這會將零擴展置于延遲的關鍵路徑上，并擊敗 mov 消除。
我暫時切換到 EDX，因為它在正常的呼叫約定中被呼叫破壞了。
; input in EAX, output in ECX
; no pre-conditions necessary
; unlike the original which doesn't count the cost of zeroing EDX
rorx edx, eax, 23-3 ; shift bit 23 to bit 3. Use SHR if you don't need the EAX value later
and edx, 1<<3 ; and isolate
and ecx, 0xFFFFFFF7 ; clear it in the destination
or ecx, edx ; and merge
; total size: 14 bytes of machine code for imm8 masks, 20 for imm32 masks
; 4 uops.
如果您愿意，or可以改為add或lea，因為我們知道沒有重疊的 1 位。 lea如果您希望將結果保存在不同的暫存器中，則可用作復制和合并。但是，如果您愿意，您只需or進入臨時 reg 而不是 ECX，并且您可以選擇任何您想要的臨時 reg，包括 EAX（在這種情況下您可以優化rorx到shr.） add如果您想要分支，這將很有用來自它的標志，因為它可以與jccSandybridge 家族 的某些形式進行宏融合。xor也可以，但沒有優勢，而且對于人類讀者來說不是慣用的。
這些都是 Intel 和 AMD 上的單 uop 指令，并且您的目標位位置足夠低，以至于兩個 AND 掩碼都可以放入符號擴展 imm8 中，因此 AND 指令每個為 3 個位元組。（而不是 6 個and r/m32, imm32）。 rorx不過是 6 個位元組，帶有 VEX 前綴和 imm8。總大小為 14 位元組，如果目標位在低 7 之外，則為 20 位元組。（如果使用像and dl, 0x80/ ... /這樣的位元組運算元大小，則為低 8 or cl, dl，這會導致 P6 系列出現部分暫存器問題，但很好別處。）
（問題中使用的指令也是單uop，包括bt。在AMD CPUbts等上是2 uop，但bt只有1。）
With a higher destination bit-number, you could save size using btr ecx, 30 (4 bytes, still 1 uop on Intel) instead of and ecx, ~(1<<30) (6 bytes, or 5 bytes into EAX). But that costs an extra uop on AMD.
Of course if you care about code-size, you'd mov edx, eax / ror edx, 23-3 (5 bytes total) instead of using rorx (6 bytes). So that's a total of 17 bytes with a high destination bitpos. Or 15 if we can destroy EAX.
If the bit positions were runtime-variables, this would be less efficient, needing a variable count shift. (And some subtraction or something to generate shift counts.) A different strategy might be better there.
Another way to exchange bits between registers is with masked XORs, but that's not more efficient here where we don't want to swap, just go one way. And we can use the inverted mask as an immediate. (Or if in a register, with BMI1 andn.)
- Merge bit sequences a and b according to a mask
- How to use bitwise operations to assign specific bits of a byte according to two other bytes? (bit blend according to a mask)
- Swapping bits at a given point between two bytes
The main problem is that x86 lacks a bitfield insert. Extract with shift/and is easy enough, although that's still 2 instructions unless you have AMD TBM for the immediate form of bextr, using the XOP encoding. (Bulldozer-family only.) Or use pext if you already have a constant in a register. It would be neat if there was an inverse of bt that deposited CF at the specified position, but there unfortunately isn't.
If there was a bitfield insert instruction, either from CF or from the low bit of another register, you wouldn't need to mask.
Avoiding a temp reg without rcr/rcl - only slightly slower, still 4 uops
@rcgldr shows an interesting trick using rcr/rcl which is good for code size, but unfortunately slow on modern CPUs where rcl and rcr r32, imm are many uops, e.g. 7 uops on Zen3 with 3c throughput, and 8 uops on Sandybridge-family (including Alder Lake) with 6c throughput. (https://uops.info/ / https://agner.org/optimize/)
That's 10 bytes of machine code and doesn't need a temp register. We can duplicate the functionality with only 12 bytes of machine code, but still only 4 single-uop instructions, assuming a modern-enough x86. The above version will be faster on Intel Haswell and earlier.
This has a longer critical-path latency from ECX->result (3 cycles), but same for EAX->result (3 cycles), assuming single-uop adc and rotates. Also more of the uops compete for the shift units, so can't run on as wide a choice of back-end ports. Whether this matters depends on the surrounding code.
It's the same code size even when the destination bit-position is > 8, and for 64-bit mode avoids needing any 8-byte masks.
If you don't have a spare register you can clobber (including the input), this is very likely worth it. Or just for code-size, if this isn't a really hot part of your code.
;; 12 bytes total. More latency through ECX, and some uops have fewer ports to choose from
ror ecx, 3 1 ; 1 uop on Intel HSW and later, and AMD
; the bit to be replaced is now at the top of ECX, and in CF
bt eax, 23 ; 1 uop
adc ecx, ecx ; 1 uop on Broadwell and later, and AMD.
; Shift in the new bit, shifting out the old bit (into CF in case you care)
rol ecx, 3 ; 1 uop on HSW and later, and AMD
; restore ECX's bits to the right positions, overwriting CF
The initial rotate-right can be rcr or ror; we don't care whether the bit we want to replace is shifted into the top bit temporarily, or only into CF. ror is much faster.
We basically emulate rcl ecx, 3 1 with rcl ecx, 1 and then rol ecx, 3. It differs in FLAGS output I think, but matches in ECX result and how it reads from FLAGS.
And then replace rcl r32, 1 with the equivalent but faster adc same,same; they differ only in the FLAGS output. adc doesn't have any weird partial-flags writing (leaving most of SPAZO unaffected) that makes rotates more expensive on Intel. adc was 2 uops on Intel before Broadwell, but has been 1 uop on AMD for a long time.
This goes through FLAGS using bt so it can easily support a runtime-variable source bit position. For a variable destination bit-position, you'd have to calculate shift counts, and ror reg, cl is slower (3 uops on Intel). Unfortunately there's no variable-count rorx, only shlx / shrx.
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/437325.html