Windows on Arm, Tek Uygulamada Hem Yerli Hem Emüle Edilen x64 Kodu Çalıştırabiliyor: Apple Mac’lerde Asla İzin Vermedi.

Apple, Apple Silicon’e geçiş yaptığında uygulamalar ya Arm için yerel olarak derlenip çalıştırılabiliyor ya da Rosetta aracılığıyla x86_64 uygulaması olarak derlenip çalıştırılabiliyordu. Ancak bu kesin bir seçimdi; birini ya da diğerini seçiyorsunuz, ikisini birden yapamıyorsunuz. Windows on Arm da x64 uygulamaları emüle etmek için benzer bir şey yapıyor, ancak Microsoft bir adım daha ileri gitti: tek bir Windows süreci, yerel Arm kodunu emüle edilen x64 kodunun yanında çalıştırabiliyor. Bunun nedeni Arm64EC.

Arm64EC, Microsoft tarafından 2021’de Windows 11 on Arm ile birlikte duyurulan bir uygulama ikili arayüzü (ABI)’dür. Arm64EC, Arm üzerinde Office ile eski x64 eklentilerini çalıştırmak gibi işleri mümkün kılıyor ve Windows, bir x64 uygulaması kendisine çağrı yaptığında kendi yerel olarak çalışan kısmının miktarını değiştirebiliyor. Test ettiğim HP OmniBook Ultra 16’da, Nvidia’nın RTX Spark sürücü paketi kullanıcı modu bileşenlerinin çoğunu iki kez paketliyor: biri sıradan Arm64 olarak, diğeri ise Arm64EC olarak.

Ancak bunun biraz bir bedeli var. Arm64EC kodu daha az CPU kaydedicisi kullanırken dolaylı çağrılar ayrıca Arm ya da x64 kodunu çağırıp çağırmadıklarını belirlemek için ekstra bir kontrolden geçmek zorunda. Üstelik bu, Arm tarafından tanımlanmış bir standart değil; Microsoft’a özgü bir tasarım, ancak Wine da bunun için destek uyguladı.

Arm64EC, x64’ün kurallarını izleyen Arm kodudur

EC, Emulation Compatible (Emülasyon Uyumlu) anlamına gelir

Bir ABI, derlenen kod için kurallar kümesini tanımlar ve böylece ayrı ayrı inşa edilmiş parçalar birlikte çalışabilir. Kaydedicilerin bir fonksiyonun argümanlarını hangi şekilde taşıdığı, yapıların bellekte nasıl dizildiği, dönüş değerinin nereye gittiği gibi şeyler olabilir. x64 Windows’un bir kurallar kümesi, normal Arm64 Windows’un ise başka bir kurallar kümesi vardır; bu yüzden bir Arm64 programı x64 DLL yükleyemez. Arm64EC ise üçüncü bir kurallar kümesi tanıtır; talimatları CPU üzerinde yerel olarak çalışan gerçek Arm64 talimatlarıdır, ancak veri yapıları ve yığın dizilimi gibi konularda x64 uyumlu yazılım örf ve adetlerini izler. Arm64’ün çağrı örf ve adetlerinin çoğunu yine korur.

Bunun pratikte anlamı şudur: Arm64EC olarak derlenen kod, mevcut mimari kontrollerinde kendisini x64 olarak tanıtar. Bir uygulamayı Arm64EC için derlediğinizde, derleyici x64 derlemelerinin kullandığı _M_AMD64 makrosunu tanımlar ve x64 için derlenip derlenmediğini soran herhangi bir uygulamaya bunun öyle olduğu söylenir. Veri yapıları da x64’ün yerleşim kurallarını izler ve derlenen Arm64EC çalıştırılabilir dosyaları başlıklarında x64 makine türü içerir. Sistem bunu bilir; Görev Yöneticisi bu uygulamaları “ARM64 (x64 uyumlu)” olarak gösterir. Ancak bu yalnızca x64 için geçerlidir; 32 bitlik x86 uygulamaları hâlâ eski WOW64 öykilleme katmanını kullanır.

Ancak bunun için başlıca neden eklenti desteğidir. Microsoft, Arm64EC’i tanıtmadan önce bir uygulamayı Arm’a taşımak Microsoft’un sözleriyle “ya hep ya hiç” durumuydu. Kendi sürecinize kontrolünüz olmayan üçüncü taraf DLL’lerini yükleyen bir uygulamanız varsa—örneğin bir Office ekleentiisi ya da bir DAW için ses eklentisi—orijinal geliştiricinin de kendi kodunu taşımasını beklemeniz gerekirdi. Arm64EC bunu çok kolaylaştırır, çünkü kendi kodunuzu yerel Arm olarak yeniden derleyebilir ve aynı süreçte x64 eklentilerini Prism öykilleme altında yükleyebilirsiniz.

Microsoft 64 bitlik Office’ini Arm için böyle inşa etti ve “mevcut x64 eklentilerinin sorunsuz çalışacağını” belirtti. Şirket, Arm üzerinde bir x64 uygulaması tarafından yüklenen işletim sistemi kodunun çoğunun Arm64EC olarak derlendiğini, bunun da öykillenmiş uygulamanın çağrdığı Windows kodunun büyük kısmının yerel olarak çalıştığı anlamına geldiğini söylüyor. Bu kavramın kökleri, benzer şekilde Arm64 kodunu x86 uyumluluğuyla birleştiren ve Build 2017’de ilk kez gösterilen Microsoft’un eski Derlenmiş Hibrit PE (CHPE) kavramına dayanıyor.

Arm64EC, x64 ile uyumlu kalmak için bazı kaydedicilerden vazgeçiyor

Uyumlu değiller ve bunları kaydedecek yer yok

Arm64, 31 genel amaçlı kaydediciye ve 32 vektör kaydediciye sahipken, x64 16 genel amaçlı kaydediciye ve AVX-512 kullanılmadığında 16 vektör kaydediciye sahiptir. Bu, özellikle Windows için bir sorundur, çünkü işletim sistemi bir işlemin CPU durumunu CONTEXT adlı bir yapı kullanarak temsil eder; bu yapı özel durum işleme, hata ayıklayıcılar ve GetThreadContext gibi API’lerin dayandığı bir yapıdır. Windows x86_64 varsayımları üzerine inşa edildiği için x64 kodu, bu yapının x64 düzenine sahip olmasını bekler.

Arm64EC, x64 yapısını koruyarak bu sorunu aşar ve böylece kullanılan Arm kaydedicilerin tümü x64 CONTEXT yapısına sığar. X0, RCX’e eşlenir; X1, RDX’e; yığın göstergesi RSP’ye; program sayacı RIP’e ve benzeri. Eşlemelerin bazıları biraz tuhaftır, çünkü Arm’ın birkaç kaydedicisi (X6, X7, X9 ile X12 arasında, X15 ve bağlantı kaydedicisi) x87 kayan nokta kaydedicilerinin slotlarına yerleştirilir.

Sığmayan her şey tamamen kullanımdan kaldırılır; buna X13, X14, X23, X24 veya X28 dahildir ve V16 ile V31 arasındaki vektör kaydedicilere erişilemez. Uzun süreli Microsoft mühendisi Raymond Chen, değerlerinin “bağlam anahtarı veya eşzamanlı özel durumlar boyunca korunmadığını” açıkladı. (Kaydedecek bir yerleri yok!)” Microsoft, eşlemeyi, normal Arm64 çağrı sözleşmelerinin kullandığı tüm kaydedicilerin hâlâ kullanılabilir kalacağı şekilde seçti; böylece Arm64EC işlevleri birbirini, tıpkı native Arm64 kodunda yaptıkları gibi çağırabilir.

Bazı istisnalar vardır; bunlar arasında printf gibi değişken sayıda argüman alan işlevler yer alır. Bunlar, yalnızca ilk dört argüman pozisyonunun kaydedicilere uygun olduğu, x64 benzeri argüman iletimi kurallarını kullanır. Bu kısıtlama, derleyicinin değerleri tutması için daha az kaydedici anlamına gelir ve bu da aşırı yüklenme (overhead) yol açabilir.

Thunks ve çağrı denetleyicileri, iki taraf arasındaki her atlamayı yönetir

Bir katman, çevirmen gibi davranmak zorundadır

Her iki sistemin de eşleşen veri düzenlerine sahip olduğu durumlarda bile Arm64 ile x64, bir fonksiyonun argümanlarının nereye yerleştirileceği konusunda hemfikaz değildir. Microsoft’un kendi örneği, bir int, bir double, başka bir int ve başka bir double alan bir fonksiyondur. Arm64’te bunlar sırasıyla X0, D0, X1 ve D1’e giderken, x64’te RCX, XMM1, R8 ve XMM3’e gider. Her argümanın türüne ve konumuna bağlı olarak dönüşümü sağlayan küçük bir yapıştırıcı kod parçasına “thunk” denir.

Bir giriş thunk’u, Arm64EC’ye çağrı yapan x64 kodunu ele alır ve argümanları x64’ün düzeninden Arm’ın düzenine yeniden yerleştirir. Arm64EC kodu x64 olabilecek bir şeye çağrı yaptığında aynı işlemi tersine yapan bir çıkış thunk’u da vardır. Sorun, derleyicinin kendisinin genellikle hangi mimariye çağrı yaptığını bilememesidir; bir fonksiyon işaretçisi yerel Arm koduna ya da yalnızca çalışma zamanında belli olabilecek emüle edilmiş x64 koduna işaret edebilir. Microsoft bu sorunu, Arm64EC’deki dolaylı çağrıların Windows tarafından sağlanan bir “çağrı denetleyicisi” üzerinden geçmesiyle çözmüştür. Hedef Arm64EC ise çağrı yerel olarak sürer; x64 ise denetleyici onu çıkış thunk’u üzerinden emülatöre yönlendirir.

Bunun çalışması için Arm64EC ikilik dosyalarının, kod sayfalarının hangi kısımlarının Arm64EC hangi kısımlarının ise x64 talimatları içerdiğini belirten yerleşik bir tablosu bulunur. Arm64EC’deki fonksiyonlar ayrıca ilk talimatlarının hemen önüne, giriş thunk’larına göre bağıl ofseti saklamak için dört bayt ayırır; böylece emülatör x64 kodunun bir Arm64EC fonksiyonuna çağrı yaptığında doğru thunk’u bulmak için o ofseti kullanır. Son olarak, bir JIT derleyicisi tarafından çalışma zamanında üretilen kod varsayılan olarak x64 olarak kabul edilir, bu nedenle .NET, Java ve diğer değiştirilmemiş x64 çalışma zamanları çalışmaya devam eder.

İlk birkaç talimatını ezberleterek sistem işlevlerine bağlanan Windows uygulamaları, x64 talimatlarını bulmayı bekler. Varsayılan olarak Arm64EC DLL’leri, her dışa aktarılan işlev için Microsoft’un “ileriye yönlendirme dizisi” dediği küçük bir x64 kabuğu sağlar. Bu, yürütme işlemini gerçek Arm64EC koduna yönlendirir ve hiçbir şey tarafından değiştirilmediğinde Windows kabuğu tamamen atlar. Bir şey değiştirmişse, öykünücü bağı korumak için değiştirilmiş sürümü çalıştırır.

İşte Arm64EC ile ilişkili aşırı yüklemenin nedeni de budur; her dolaylı Arm64EC çağrısı, iki taraf da yerel olsa bile bir deneme gerektirir ve x64 koduna geçen çağrılar bir thunk ve öykünücüye geçiş gerektirir. Ancak Arm64EC işlevleri arasındaki doğrudan çağrılar yalnızca normal Arm çağrılarıdır.

Arm64X, Microsoft’un burada sunduğu çözümün başka bir parçasıdır; hem normal Arm64 kodunu hem de Arm64EC kodunu tek bir dosyaya paketleyebilen bir dosya biçimidir. Microsoft’un benzetmesi, eski kırmızı-mavi 3B görüntülerle karşılaştırılır: “x64 bir uygulama DLL’i x64 DLLmiş gibi görürken, Arm64 bir uygulama aynı DLL’i Arm64 DLLmiş gibi görür.” Arm64X, Windows tarafından hem x64 hem de Arm64 uygulamalarının System32’den ihtiyaç duyduğu sistem DLL’leri tarafından kullanılır; bu da şirketin 32-bit x86 uygulamaları için kullanılan SysWOW64 klasörü yerine tek bir x64 sistem dosyası klasörü kullanmasına olanak tanır. Ayrıca hem normal Arm64 hem de Arm64EC süreçlerinin DLL’lerini doğrudan birbirinin yükleyememesi nedeniyle, her ikisini de desteklemesi gereken geliştiriciler için de faydalıdır.

macOS, Intel ve Arm kodunun bir süreçte paylaşılmmasına izin vermez

Birlikte çalışabilirler, ancak aynı yerde değil

Apple’ın Rosetta ve Apple çipleri yaklaşımı tamamen farklıdır; şirketin resmi belgelerinde “Sistem, arm64 kodu ile x86_64 kodunu aynı süreçte karıştırmanızı engeller. Rosetta çevirisi, sürecin dinamik olarak yüklediği tüm kod modüllerini içeren bir süreci kapsar.” Yerel bir Arm uygulaması, aynı sürece yalnızca Intel’e özgü bir eklenti yüklemeye çalışırsa, sistem bunun yerine bir hata verir.

Bu, Intel ve Arm kodunun Mac’te birlikte çalışamayacağı anlamına gelmiyor; yalnızca tek bir süreç içinde paylaşılamazlar. Apple’ın kendi önerisi, eklentilerin ayrı süreçlerde çalıştırılması ve XPC üzerinden iletişim kurabilmesidir. Bu da arm64 eklentileri için bir hizmet, x86_64 olanlar için başka bir hizmet anlamına gelir ve Audio Units buna en bilinen örneklerden biridir. macOS, Intel’e özel AU eklentilerini ana programın dışında çalıştıran yerleşik bir AUHostingCompatibilityService sunar; Ableton gibi programlar da Intel tabanlı eklentileri desteklemek için bunu kullanır. Intel’e özel VST2 ve VST3 eklentileri yine bu şekilde çalışmaz ve Ableton’un tek çözümü tüm DAW’ı Rosetta üzerinden çalıştırmaktır.

Apple, Intel kodunu sonsuza kadar saklamak istemedi; bunu açıkça, C++ ABI’sini Apple silikon için “iOS cihazların ABI’siyle eşleşecek şekilde, ancak Intel tabanlı Mac bilgisayarların ABI’siyle eşleşmeyecek” biçimde belirlediğinde ortaya koydu. Rosetta’nın da bir raf ömrü var; yalnızca “macOS 27’ye kadar” genel amaçlı bir araç olarak varlığını sürdürecek. Microsoft’un Windows’ta x64 öykürtmesi için buna eşdeğer bir şeyi yoktur ve Arm64EC, eski x64 kodunun çalışmaya devam edeceği varsayılan bir platformun ürünüdür.

Arm64EC bir Microsoft tasarımıdır, ancak bunu kullanan yalnızca Microsoft yoktur

Wine da bunu uyguladı

Arm64EC, resmi olarak standartlaştırılmış bir ABI değildir; Microsoft, Windows’taki normal Arm64 ABI’sinin “genellikle ARM’ın standart AArch64 EABI’sini izlediğini” belirtir. ARM’ın kendi AArch64 için ABI özellikleri de Arm64EC’den söz etmez. Bu, Microsoft’un x64 öykürtme sisteminin etrafında inşa edilmiş, Microsoft’un belgelediği (ARM’ın değil) Windows’a özgü bir tasarım.

Arm64EC, başkaları için de oldukça büyük bir emek gerektiriyor. 2024 yılında llvm-mingw araç zincirinin bakımcısı Martin Storsjö, GCC posta listesinde “ARM64EC tamamen farklı bir şey; neredeyse her tek tek düzeyde tamamen ayrı bir ABI” demişti. GCC o dönemde yalnızca normal Windows on Arm için destek alıyordu ve bugün bile Arm64EC’nin GCC’de desteklenmediği görülüyor. LLVM bunu 18.1 sürümünden beri destekliyor ve Rust, bunu Tier 2 hedefi olarak sunuyor; ancak Rust’ın Arm64EC hedefi için listelenen bakımcı bir Microsoft geliştiricisi.

Wine, az sayıdaki bağımsız uygulamadan birine sahip ve destek 2025’in Ocak ayında Wine 10.0 ile geldi. Yayının öne çıkan başlıca noktalarından biriydi ve aynı yayın, yalnızca uygulamanın x86-64 kodunun emülasyon gerektirdiği şekilde “ARM64EC desteğinden yararlanarak tüm Wine kodunu yerel olarak çalıştıran” bir x86-64 emülasyon arayüzü de ekledi. Wine’ın kendi x86-64 emülatorü yok, ancak Arm Linux için bir x86 emülatorü olan FEX, Arm64EC olarak derlendiğinde bu arayüzü uyguluyor. Arm uygulamaları, tek bir uyarıyla Windows’ta kullanılan aynı tekniklerle Linux’ta çalıştırılabilir: Wine 10.0, “Windows ABI’nin belirttiği şey bu olduğu için” 4K bellek sayfa boyutu gerektiriyor.

Sonuç olarak Apple, tüm macOS ekosistemine sahip olması sayesinde önemli ölçüde daha basit bir yaklaşıma sahip. Windows, onlarca yıllık uyumluluk varsayımıyla inşa edilmiş durumda ve Arm64EC, o eski yazılımın hâlâ çalışması gerektiğinde elde ettiğiniz şey. Mükemmel olmayabilir, ancak Microsoft’un Arm’a yaklaşımı, birkaç yıl öncesine göre çok daha ileri.