32-bit yazmaçlar üzerindeki x86-64 talimatları, tam 64-bit yazmaçların üst kısmını neden sıfırlıyor?

In Intel Kılavuzları X86-64 Tour , okuduğum

Belki de en şaşırtıcı gerçek, gibi bir komutun MOV EAX, EBXotomatik olarak üst 32 bitlik RAXyazmacı sıfırlamasıdır .

Aynı kaynakta alıntılanan Intel belgeleri (3.4.1.1 Kılavuz Temel Mimaride 64-Bit Modunda Genel Amaçlı Kayıtlar) bize şunları söyler:

• 64 bitlik işlenenler, hedef genel amaçlı kayıtta 64 bitlik bir sonuç oluşturur.
• 32 bitlik işlenenler, hedef genel amaçlı kayıtta 64 bitlik bir sonuca sıfır genişletilmiş 32 bitlik bir sonuç üretir.
• 8 bit ve 16 bit işlenenler, 8 bitlik veya 16 bitlik bir sonuç oluşturur. Hedef genel amaçlı yazmacın üst 56 biti veya 48 biti (sırasıyla) işlem tarafından değiştirilmez. 8 bitlik veya 16 bitlik bir işlemin sonucu 64 bit adres hesaplaması için tasarlandıysa, kaydı açıkça işaretleyerek tam 64 bit'e genişletin.

X86-32 ve x86-64 derlemesinde, aşağıdaki gibi 16 bit talimatlar

mov ax, bx

eax'ın üst kelimesinin sıfırlandığı bu tür "garip" davranışı göstermeyin.

Öyleyse: bu davranışın ortaya çıkmasının nedeni nedir? İlk bakışta mantıksız görünüyor (ancak nedeni x86-32 montajının tuhaflıklarına alışmış olmam olabilir).

AMD değilim ya da onlar adına konuşmuyorum, ama aynı şekilde yapardım. Çünkü yüksek yarının sıfırlanması, CPU'nun beklemesi gereken önceki değere bağımlılık yaratmaz. Kayıt yeniden adlandırma bu şekilde yapılmadığı takdirde mekanizma esas mağlup olacaktır.

Bu şekilde, her zaman açıkça bağımlılıkları kırmak zorunda kalmadan, 64 bit modunda 32 bit değerleri kullanarak hızlı kod yazabilirsiniz. Bu davranış olmasaydı, 64-bit kipteki her bir 32-bit komut, daha önce olmuş bir şeyi beklemek zorunda kalacaktı, ancak bu yüksek kısım neredeyse hiç kullanılmayacaktı. ( int64 bit yapmak, önbellek ayak izini ve bellek bant genişliğini boşa harcar ; x86-64, 32 ve 64 bit işlenen boyutlarını en verimli şekilde destekler )

8 ve 16 bitlik işlenen boyutları için davranış gariptir. Bağımlılık çılgınlığı, şu anda 16 bit talimatlardan kaçınılmasının nedenlerinden biridir. x86-64, bunu 8 bit için 8086'dan ve 16 bit için 386'dan devraldı ve 8 ve 16 bitlik kayıtların 32 bit modunda olduğu gibi 64 bit modunda da çalışmasına karar verdi.

Ayrıca bkz. GCC neden kısmi kayıtları kullanmıyor? 8 ve 16 bitlik kısmi yazmaçlara yazma işlemlerinin (ve tam yazmacın sonraki okumalarının) gerçek CPU'lar tarafından nasıl işlendiğine dair pratik ayrıntılar için.

Sadece talimatlarda ve talimat setinde yer tasarrufu sağlar. Mevcut (32 bit) talimatları kullanarak küçük anlık değerleri 64 bitlik bir kayda taşıyabilirsiniz.

Ayrıca, sizi MOV RAX, 42ne zaman MOV EAX, 42yeniden kullanılabileceği için 8 bayt değerini kodlamak zorunda kalmaktan kurtarır .

Bu optimizasyon 8 ve 16 bit operasyonlar için o kadar önemli değildir (çünkü daha küçüktürler) ve oradaki kuralları değiştirmek eski kodu da bozacaktır.

Sıfır 64 bite genişletmeden, bu, bir komut okumasının işlenen raxiçin 2 bağımlılığa sahip olacağı anlamına gelir rax(ona yazan eaxkomut ve ondan raxönce yazan komut ), bu şu anlama gelir: 1) ROB için girişler olmalıdır. tek bir işlenen için birden fazla bağımlılık, bu da ROB'nin daha fazla mantık ve transistör gerektireceği ve daha fazla yer kaplayacağı anlamına gelir ve yürütme, yürütülmesi uzun sürebilecek gereksiz bir ikinci bağımlılık için beklemenin daha yavaş olacağı anlamına gelir; veya alternatif olarak 2), tahmin ettiğim gibi 16 bitlik komutlarla olur, tahsis aşaması muhtemelen durur (yani, eğer RAT bir axyazma için aktif bir tahsise sahipse ve bir eaxokuma görünürse, axyazma emekli olana kadar durur).

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

Sıfır genişletmenin tek yararı, daha yüksek sıralı bitlerin raxdahil edilmesini sağlamaktır, örneğin, orijinal olarak 0xffffffffffffff içeriyorsa, sonuç 0xffffffff00000007 olacaktır, ancak ISA'nın bu garantiyi böyle bir masrafla vermesi için çok az neden vardır ve Sıfır uzantının faydasının aslında daha fazla gerekli olması daha olasıdır, bu nedenle fazladan kod satırından tasarruf sağlar mov rax, 0. Her zaman sıfırın 64 bite genişletileceğini garanti ederek, derleyiciler bu aksiyomu akılda tutarak çalışabilirler mov rdx, rax, raxyalnızca tek bağımlılığını beklemek zorundadır, yani yürütmeye daha hızlı başlayıp emekli olabilir ve yürütme birimlerini serbest bırakır. Ayrıca, bir REX baytı gerektirmeden xor eax, eaxsıfır gibi daha verimli sıfır deyimlere izin verir rax.