Windows64 neden x86-64'teki diğer tüm işletim sistemlerinden farklı bir çağrı kuralı kullanıyor?

AMD, x86-64'te kullanılacak arama kuralını açıklayan bir ABI belirtimine sahiptir. Kendi x86-64 çağrı kuralına sahip Windows dışında tüm işletim sistemleri bunu takip eder. Neden?

Bu farklılığın teknik, tarihsel veya politik nedenlerini bilen var mı yoksa bu tamamen bir NIHs sendromu meselesi mi?

Farklı işletim sistemlerinin daha yüksek seviyeli şeyler için farklı ihtiyaçları olabileceğini anlıyorum, ancak bu, örneğin Windows'ta yazmaç parametresinin rcx - rdx - r8 - r9 - rest on stackdiğer herkes kullanırken neden olduğunu açıklamıyor rdi - rsi - rdx - rcx - r8 - r9 - rest on stack.

Not: Bu arama kurallarının genel olarak nasıl farklılaştığının farkındayım ve gerekirse ayrıntıları nerede bulacağımı biliyorum. Bilmek istediğim şey neden .

Düzenleme: Nasıl yapılacağını öğrenmek için, örneğin wikipedia girişine ve oradaki bağlantılara bakın.

X64'te dört bağımsız değişken kaydı seçme - UN * X / Win64 için ortak

X86 hakkında akılda tutulması gereken şeylerden biri, "kayıt numarası" kodlamasının yazmaç adının açık olmamasıdır; talimat kodlaması açısından ( MOD R / M baytı, bkz. http://www.c-jump.com/CIS77/CPU/x86/X77_0060_mod_reg_r_m_byte.htm ), kayıt numaraları 0 ... 7 - bu sırayla - ?AX, ?CX, ?DX, ?BX, ?SP, ?BP, ?SI, ?DI.

Dolayısıyla, dönüş değeri için A / C / D'yi (regs 0..2) ve ilk iki argümanı ("klasik" 32 bitlik kuraldır) seçmek __fastcallmantıklı bir seçimdir. 64bit'e gitme söz konusu olduğunda, "daha yüksek" kayıtlar sipariş edilir ve hem Microsoft hem de UN * X / Linux ilk olanlar için R8/ R9olarak gitti .

Bunu göz önüne aldığımızda tutulması, Microsoft'un seçimi RAX(dönüş değeri) ve RCX, RDX, R8, R9(arg [0..3]) seçerseniz anlaşılabilir bir seçim vardır dört argümanlar için kayıtlar.

AMD64 UN * X ABI'nin neden daha RDXönce seçtiğini bilmiyorum RCX.

X64'te altı bağımsız değişken kaydı seçme - UN * X'e özgü

RISC mimarilerinde UN * X, geleneksel olarak kayıtlarda geçen argümanları - özellikle ilk altı argüman için (en azından PPC, SPARC, MIPS'de böyledir) yapmıştır. AMD64 (UN * X) ABI tasarımcılarının bu mimaride de altı kayıt kullanmayı seçmelerinin ana nedenlerinden biri bu olabilir.

Yani isterseniz altı bağımsız değişkenleri geçmesine kayıtları ve seçim için mantıklı RCX, RDX, R8ve R9dördü için iki başka hangi almalı?

"Daha yüksek" regler, onları seçmek için ek bir talimat ön ek baytı gerektirir ve bu nedenle daha büyük bir komut boyutu ayak izine sahiptir, bu nedenle seçenekleriniz varsa bunlardan herhangi birini seçmek istemezsiniz. Klasik kayıtlardan, örtük anlamı nedeniyle RBPve RSPbunlar mevcut değildir ve RBXgeleneksel olarak, AMD64 ABI tasarımcılarının gereksiz yere uyumsuz olmak istemediği UN * X (global ofset tablosu) üzerinde özel bir kullanımı vardır.
Ergo, tek seçenek vardı RSI/ RDI.

Öyleyse , argüman yazmaçlarını RSI/ RDIolarak almanız gerekiyorsa, bunlar hangi argümanlar olmalıdır?

Bunları yapmak arg[0]ve arg[1]bazı avantajları vardır. CHao'nun yorumuna bakın.
?SIve ?DIdize talimatı kaynağı / hedef işlenenleridir ve cHao'nun da bahsettiği gibi, argüman kayıtları olarak kullanımları, AMD64 UN * X arama kurallarıyla mümkün olan en basit strcpy()işlevin yalnızca iki CPU talimatından oluştuğu anlamına gelir, repz movsb; retçünkü kaynak / hedef adresler arayan tarafından doğru kayıtlara yerleştirilmiştir. Özellikle düşük seviyeli ve derleyici tarafından üretilen "yapıştırıcı" kodunda (örneğin, bazı C ++ yığın ayırıcılarının yapım sırasında sıfır dolduran nesneleri veya çekirdeğin sıfır dolduran yığın sayfalarını düşünün.sbrk()veya yazma üzerine kopyalama sayfa hataları) muazzam miktarda blok kopyalama / doldurma, bu nedenle bu tür kaynak / hedef adres bağımsız değişkenlerini "doğru" kayıtlar.

Yani bir bakıma, BM * X ve Win64 BM * X "prepends" iki ek argümanlar, kasten seçilmiş içinde sadece farklıdır RSI/ RDIkayıtları, dört bağımsız değişken doğal seçim RCX, RDX, R8ve R9.

Onun ötesinde ...

UN * X ve Windows x64 ABI'leri arasında, argümanların belirli kayıtlara eşlenmesinden daha fazla fark vardır. Win64'e genel bakış için, kontrol edin:

http://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx

Win64 ve AMD64 UN * X, yığın alanının kullanım şekli açısından da çarpıcı biçimde farklılık gösterir; Win64 üzerinde, örneğin, arayan gerekir hatta args 0 ... 3 kayıtlarında geçirilen rağmen fonksiyon argümanlar için stackspace tahsis. Öte yandan, UN * X'te, bir yaprak işlevinin (yani, diğer işlevleri çağırmayan), 128 Bayttan fazlasına ihtiyaç duymuyorsa yığın alanı ayırması bile gerekmez (evet, sahipsiniz ve kullanabilirsiniz belirli miktarda yığın ayırmadan ... pekala, çekirdek kodu değilseniz, şık hataların kaynağı). Tüm bunlar belirli optimizasyon seçimleridir, bunların çoğu için mantık, orijinal posterin wikipedia referansının işaret ettiği tam ABI referanslarında açıklanmıştır.

IDK, Windows'un yaptıklarını neden yaptı? Bir tahmin için bu cevabın sonuna bakın. SysV çağrı sözleşmesinin nasıl kararlaştırıldığını merak ediyordum, bu yüzden posta listesi arşivine girdim ve bazı düzgün şeyler buldum.

AMD mimarları üzerinde aktif olduğu için AMD64 e-posta listesindeki bu eski başlıklardan bazılarını okumak ilginç. Örneğin, kayıt adlarının seçilmesi zor kısımlardan biriydi: AMD , orijinal 8 yazmacı r0-r7'yi yeniden adlandırmayı veya yeni yazmaçları şöyle çağırmayıUAX düşündü .

Ayrıca, çekirdek geliştiricilerinden gelen geri bildirimler, orijinal tasarımı syscallve swapgskullanılamaz hale getiren şeyleri belirledi . AMD , herhangi bir gerçek yonga yayınlamadan önce bunu çözmek için talimatı bu şekilde güncelledi . 2000 yılının sonlarında Intel'in muhtemelen AMD64'ü benimsemeyeceği varsayımı da ilginçtir.

SysV (Linux) çağrı kuralı ve kaç kaydın arayanın korunmasına karşı kaç kaydın aranarak kurtarılacağına dair karar, ilk olarak Kasım 2000'de Jan Hubicka (bir gcc geliştiricisi) tarafından yapıldı. O SPEC2000 derlenmiş ve kod boyutu ve komutların sayısına baktım. Bu tartışma dizisi, bu GY sorusuyla ilgili cevaplar ve yorumlarla aynı fikirlerin bazıları etrafında dönüyor. 2. bir iş parçacığında, mevcut diziyi en uygun ve umarız son olarak önerdi ve bazı alternatiflerden daha küçük kodlar üretti .

"Genel" terimini, kullanılıyorsa itilmesi / çıkarılması gereken çağrı korumalı kayıtları kastetmek için kullanıyor.

Seçimi rdi, rsi, rdxilk üç bağımsız değişken tarafından motive edilmiş olarak:

• memsetbağımsız değişkenlerinde C dizesi işlevini çağıran işlevlerde küçük kod boyutu tasarrufu (gcc, bir rep dizesi işlemini satır içine alır?)
• rbxREX önekleri (rbx ve rbp) olmadan erişilebilen iki çağrı korumalı reg'e sahip olmak bir kazançtır çünkü çağrı korumalıdır. Muhtemelen, herhangi bir talimat tarafından dolaylı olarak kullanılmayan diğer tek kural olduğu için seçilmiştir. (rep string, shift count ve mul / div çıktıları / girdileri diğer her şeye dokunur).
• Özel amaçlı yazmaçların hiçbiri çağrı korumalı değildir (önceki noktaya bakın), bu nedenle rep dizesi komutlarını veya değişken sayı kaydırmasını kullanmak isteyen bir işlev, işlev argümanlarını başka bir yere taşımak zorunda kalabilir, ancak / arayanın değerini geri yükleyin.

• EAX gibi özel amaçlar için yaygın olarak kullanılan kayıt olduğundan, dizinin başlarında RCX'ten kaçınmaya çalışıyoruz, bu nedenle dizide eksik olması aynı amaca sahiptir. Ayrıca, sistem çağrıları için kullanılamaz ve mümkün olduğunca işlev çağrı sırasına uyacak şekilde sistem çağrı dizisi yapmak istiyoruz.

  (arka plan: syscall/ sysretkaçınılmaz imha rcx(ile rip) ve r11(ile RFLAGSçekirdek başlangıçta ne olduğunu göremiyorum bu yüzden,) rcxne zaman syscallran.)

Çekirdek sistem çağrısı ABI, ABI işlev çağrısı ile eşleşecek şekilde seçilmiştir, r10bunun yerine rcxbir libc sarmalayıcı mmap(2)can just mov %rcx, %r10/ mov $0x9, %eax/ gibi çalışır syscall.

İ386 Linux tarafından kullanılan SysV çağrı kuralı, Window 32bit __vectorcall ile karşılaştırıldığında berbattır. Yığın üzerindeki her şeyi edx:eaxaktarır ve küçük yapılar için değil, yalnızca int64 için döner . Uyumluluğunu sürdürmek için çok az çaba harcanması şaşırtıcı değil. Bunu yapmamak için bir neden olmadığında rbx, orijinal 8'de (REX önekine ihtiyaç duymayan) bir başkasına sahip olmanın iyi olduğuna karar verdikleri için çağrıyı korumalı tutmak gibi şeyler yaptılar.

ABI'yı optimum hale getirmek, uzun vadede diğer tüm düşüncelerden çok daha önemlidir. Bence oldukça iyi bir iş çıkardılar. Farklı kayıtlardaki farklı alanlar yerine kayıtlara paketlenmiş yapıları döndürmek konusunda tam olarak emin değilim. Sanırım tarlalarda gerçekten işlem yapmadan onları değerine göre geçiren kod bu şekilde kazanır, ancak fazladan paket açma işi aptalca görünüyor. Daha fazla tamsayı dönüş rdx:raxyazmacıları olabilirdi, bu yüzden 4 üyeli bir yapıyı döndürmek onları rdi, rsi, rdx, rax veya başka bir şekilde döndürebilirdi.

SSE2 tamsayılar üzerinde çalışabildiğinden, tamsayıları vektör reglerinde geçirmeyi düşündüler. Neyse ki bunu yapmadılar. Tam sayılar, işaretçi ofsetleri olarak çok sık kullanılır ve belleği yığınlamak için bir gidiş dönüş oldukça ucuzdur . Ayrıca SSE2 komutları, tamsayı komutlarından daha fazla kod baytı alır.

Windows ABI tasarımcılarının, asm'yi birinden diğerine aktarması gereken veya #ifdefbazı ASM'lerde birkaç s kullanabilen kişilerin yararına 32 ve 64 bit arasındaki farkları en aza indirmeyi hedeflediklerinden şüpheleniyorum, böylece aynı kaynak daha kolay bir şekilde oluşturulabilir. bir işlevin 32 veya 64 bit sürümü.

Araç zincirindeki değişiklikleri en aza indirmek pek olası görünmüyor. Bir x86-64 derleyicisinin, yazmacının ne için kullanıldığını ve çağırma kuralının ne olduğunu gösteren ayrı bir tabloya ihtiyacı vardır. 32 bit ile küçük bir örtüşmeye sahip olmanın, araç zinciri kod boyutu / karmaşıklığında önemli tasarruflar sağlama olasılığı düşüktür.

Microsoft'un başlangıçta "AMD64'ün ilk çabalarına resmi olarak bağlı olmadığını" ( Matthew Kerner ve Neil Padgett'in "A History of Modern 64-bit Computing" kitabından), çünkü Intel ile IA64 mimarisi üzerinde güçlü ortaklar olduğunu unutmayın. Bence bu, GCC mühendisleri ile hem Unix hem de Windows üzerinde kullanmak üzere bir ABI üzerinde çalışmaya açık olsalar bile, bunu yapmayacakları anlamına geliyordu, çünkü olmadıklarında AMD64 çabasını halka açık bir şekilde desteklemek anlamına geliyordu '' Henüz resmi olarak yapılmadı (ve muhtemelen Intel'i alt üst ederdi).

Bunun da ötesinde, o günlerde Microsoft'un açık kaynak projelerle dost olma yönünde kesinlikle hiçbir eğilimi yoktu. Kesinlikle Linux veya GCC değil.

Öyleyse neden bir ABI üzerinde işbirliği yapsınlar? ABI'lerin farklı olduğunu tahmin ediyorum çünkü aşağı yukarı aynı anda ve tek başına tasarlandılar.

"A History of Modern 64-bit Computing" den bir başka alıntı:

Microsoft işbirliğine paralel olarak AMD, çipe hazırlanmak için açık kaynak topluluğunu da meşgul etti. AMD, alet zinciri çalışması için hem Code Sorcery hem de SuSE ile sözleşme yaptı (Red Hat, Intel tarafından IA64 araç zinciri bağlantı noktasında zaten çalışıyordu). Russell, SuSE'nin C ve FORTRAN derleyicileri ürettiğini ve Code Sorcery'nin bir Pascal derleyicisi ürettiğini açıkladı. Weber, şirketin bir Linux bağlantı noktası hazırlamak için Linux topluluğuyla da meşgul olduğunu açıkladı. Bu çaba çok önemliydi: Microsoft için AMD64 Windows çabasına yatırım yapmaya devam etmesi için bir teşvik görevi gördü ve aynı zamanda o sırada önemli bir işletim sistemi haline gelen Linux'un yongalar piyasaya sürüldüğünde kullanılabilir olmasını sağladı.

Weber, Linux çalışmasının AMD64'ün başarısı için kesinlikle çok önemli olduğunu söyleyecek kadar ileri gitti, çünkü AMD'nin gerekirse başka şirketlerin yardımı olmadan uçtan uca bir sistem üretmesini sağladı. Bu olasılık, AMD'nin diğer ortaklar geri çekilse bile en kötü durumda hayatta kalma stratejisine sahip olmasını sağladı ve bu da diğer ortakları geride bırakılma korkusuyla meşgul etti.

Bu, AMD'nin bile MS ve Unix arasındaki işbirliğinin zorunlu olarak en önemli şey olduğunu düşünmediğini, ancak Unix / Linux desteğine sahip olmanın çok önemli olduğunu gösteriyor. Belki bir veya iki tarafı uzlaşmaya veya işbirliği yapmaya ikna etmeye çalışmak, ikisini de rahatsız etme çabasına veya riskine (?) Değmez miydi? Belki de AMD, ortak bir ABI önermenin bile, çip hazır olduğunda yazılım desteğinin hazır olması gibi daha önemli bir hedefi geciktirebileceğini veya rayından çıkarabileceğini düşündü.

Benim açımdan spekülasyon, ancak ABI'lerin farklı olmasının ana nedeni, MS ve Unix / Linux taraflarının birlikte çalışmamasının politik nedeniydi ve AMD bunu bir sorun olarak görmedi.

Win32'nin ESI ve EDI için kendi kullanımları vardır ve bunların değiştirilmemesini (veya en azından API çağrılmadan önce geri yüklenmelerini) gerektirir. 64 bit kodun RSI ve RDI ile aynı şeyi yaptığını hayal ediyorum, bu da neden işlev argümanlarını iletmek için kullanılmadıklarını açıklıyor.

Yine de RCX ve RDX'in neden değiştirildiğini size söyleyemem.