WebAssembly (Wasm) İkili Komut Mimarisi ve Doğrusal Bellek Yığın Güvenliği

Bir zamanlar, tarayıcıların en güçlü silahı olarak övündüğümüz JavaScript’in asıl kırılgan yanını anlatırken dikkatimizi çeken bir gerçek vardı. Bu dil, her şeyden önce bir yorumlayıcı (interpreter) üzerinden çalıştı: yazdığımız her satır, makinenin anlık olarak okuyup adım adım uyguladığı talimatlardı. Bu yaklaşımda gizli bir feda hep vardı — hızlı derlemek, yavaş çalışmak demekti. Bir programı derlerken, onu sonradan optimize etme lüksünden mahrum bırakmıştık. WebAssembly’in hikayesi tam da bu paradoksla başlıyor ve aslında insanlığın “hız” arayışının en zarif cümlesini yazıyor: *Neden bir şeye daha hızlı ulaşmak için onu daha yavaş derlemekten vazgeçelim?*

## JavaScript’in Performans Darboğazı

2010’ların ortasında, tarayıcılar artık sadece metin görüntüleyen kutular değil, karmaşık uygulamaların ev sahipliğini üstlenen platformlara dönüşmüştü. Ancak bu dönüşümle birlikte bir gerçekte yüzleşmek zorunda kaldık: JavaScript’in dinamik doğası, onu sonradan derlenebilir ve optimize edilebilir statik kodlardan ayırıyordu. Bir web uygulamasının ilk yükleme anında, tarayıcı o kodu sıfırdan yorumlamaya başlıyordu. Bu “soğuk başlatma” (cold start) olayı, kullanıcıların gözünün göremeyeceği milisaniyelere bile dokunabiliyordu.

Bu darboğazın kökenine inmek için bir adım geriye çekelim. Safari’nin 2008’de推出的 Nitro.js projesi aslında bu fikrin erken bir tohumuydu — JavaScript’in altındaki LLVM tabanlı makine koduna derlenmesini hayal eden bir girişimdi. Ancak bu vizyon, tam anlamıyla olgunlaşmak için yıllar aldı. WebAssembly, ilk olarak 2011’de Mozilla tarafından bir “portable compilation target” (taşınabilir derleme hedefi) olarak tasarlandı ve nihayetinde W3C çatısı altında uluslararası bir standart haline getirildi. Bu, aslında tek bir şirketin fikri değil, dünya çapında mühendislerin kolektif zekasının kristalleşmiş halidir.

## İkili Komut Formatı: Sıkıştırılmış Kodun Zarafeti

WebAssembly’in en etkileyici yönlerinden biri, metin tabanlı değil, ikili (binary) bir format kullanmasıdır. Bu seçimde derin bir mühendislik felsefesi yatıyor. İnsanlar için okunabilir `.wat` dosyaları (Text Format) aslında sadece bir eğitim aracıdır — gerçek dünyada çalışan sistem, sıkıştırılmış ikili komutları tüketir. İşte burada devreye giriyor “Compact Instruction Format” (CIF), yani Sıkıştırılmış Komut Formatı.

Bu formatın güzelliği, her bir talimatın mümkün olduğunca az bitede kodlanmasında yatar. WebAssembly’in opcode’ları (komut kodları) tek bir bitte saklanır — 0’dan 178’e kadar olan değerler, aslında tek bir ikili bayrakta temsil edilebilir. Bir talimatın tamamı genellikle 32 bittir: ilk bit opcode’ı işaret ederken, geri kalan 31 bit de operandları veya sayıları taşır. Bu yaklaşım, kaynak kodu derlerken ortaya çıkan byte kodunu, orijinal C ya da Rust programına kıyasla bile daha sıkışık hale getiriyor.

Sayıların nasıl kodlandığı ise ayrı bir sanat eseri gibidir. WebAssembly, LEB128 (Little Endian Base 128) encoding adını verdiği akıllı bir yöntem kullanır. Bu yöntem, küçük sayıları tek byte’ta, büyük sayıları ise ihtiyaç duyduğu kadar byte’ta saklayarak devasa bir tasarruf sağlar. Örneğin, sıfır değeri tek bir byte’la ifade edilirken; milyonlarca gibi büyük değerler de verimlilikten ödün vermeden kodlanabilir. Bu, gerçekten de “her bitin bir anlam taşıması gereken” bir mühendislik disiplini.

## Yığın Makinesi: Farklı Bir Düşünce Biçimi

Belki de WebAssembly’in en derin felsefi tercihi şudur: bu makine, register (kaydedici) tabanlı değil, tamamen yığın (stack) tabanlı bir mimariye sahiptir. Bu seçim, x86 veya ARM gibi geleneksel işlemcilerden kökten farklı bir düşünce biçimini temsil eder.

Bir yığın makinesinde her şey basit ama muazzamdır: bellek tek bir büyük depolama alanı olarak düşünüldüğünde, tüm hesaplamalar bu alanda üst üste binen bir yığın üzerinden yürür. Bir işlemci register tabanlıysa, her sabiti bir özel kutuda saklar; yığın makinesi ise her şeyi akışkan bir yığına bırakır ve mantık kurallarının kendisi bu düzeni yönetir. Bu yaklaşımın en büyük avantajı şudur: derleyiciler, kodu bu sade kurallara indirgemesinin son derece kolay olduğunu keşfeder. Karmaşık optimizasyonlar — değişkenleri geçici olarak silmek, kod bloklarını yeniden sıralamak gibi — register makinesinde çok zorluyken, yığın makinesinde doğal bir şekilde gerçekleşir.

Bu mimarinin bir de şaşırtıcı bir yan etkisi vardır: WebAssembly’in kendine özgü bir “sözdizimi” (syntax) kavrayışı oluşur. Programcılar burada klasik programlama dillerinin sözdizimini değil, yığın operasyonlarının doğal dilini öğrenirler. Her talimat aslında iki değer alır ve bir değer bırakır — bu da makinenin neredeyse matematiksel bir temizliğine işaret eder.

## LLVM Üzerinden Doğrudan Derleme

WebAssembly’in performans devriminin kalbi, derleme zincirindeki radikal bir değişiklikte gizlidir. Geleneksel yaklaşımda, C ya da C++ kodu önce makinenin native (yerel) koduna derlenirdi. Ancak WebAssembly dünyasında, bu diller doğrudan LLVM (Low-Level Virtual Machine) altyapısı üzerinden ikili kod formatına dönüştürülür. Bu, mühendislik açısından muazzam bir basitleştirme anlamına gelir.

Bir programcı artık iki ayrı derleme yolunu öğrenmek zorunda değildir. Hem native hem de WebAssembly hedefleri için tek bir LLVM backend (arka uç) kullanılır. Rust gibi modern diller, LLVM’yi doğrudan bir hedef olarak desteklerken; Go’nun WASM desteği ve C/C++’nın LLVM üzerinden geçmesi de aynı mantık üzerine kuruludur. Bu yaklaşımın en zarif yanı şudur: derleyici, WebAssembly’in yığın makinesi kurallarına çok kolay uyum sağlar çünkü optimizasyonları bu sade mimari üzerinde doğal bir şekilde uygulayabilir.

Sonuç olarak elde edilen kod, native kod kadar — hatta bazı durumlarda daha hızlı çalışabilir. Çünkü WebAssembly kodu, tarayıcının özel derleyicileri (örneğin V8’in Wasm derleyicisi) tarafından sonradan optimize edilebilir: sıklıkla kullanılan fonksiyonlar “native” makine koduna dönüştürülebilir ve böylece orijinal ikili formundan bile daha hızlı hale gelebilirler. Bu, aslında bir döngüsel iyileşme (virtuous cycle) yaratır — ne kadar çok program çalışırsa, tarayıcı o kadar iyi optimize olur.

## Doğrusal Bellek: Tek Bir Sonsuz Depolama Alanı

WebAssembly’in güvenlik felsefesini anlamak için, onun bellek modeline dikkat etmemiz gerekiyor. Bu makinede “bellek” kavramı, programcıların bildiği her şeyden farklı biçimde soyutlanmıştır. WebAssembly’de tek bir **Linear Memory** (Doğrusal Bellek) vardır ve bu bellek, aslında tek boyutlu bir **ArrayBuffer**’ın matematiksel bir modelidir.

Bu soyutlama muhteşem derecede sadeleştiricidir. Programcı artık nesnelerden, dizilerden veya karmaşık veri yapılarından bahsetmez — sadece tek bir sonsuz görünümlü byte dizisini yönetir. Her veri bu düz alanda belirli bir kaydedici (offset) adresinde yer alır ve tüm erişimler bu tek eksen üzerinde gerçekleşir. Bellek 32-bit’lik tam sayılarla hizalanmıştır (word-aligned), yani her eleman 4 byte’tan oluşur ve adresler hep 4’e bölünen değerlerle ifade edilir. Bu hizalama kuralı, hem verimliliği artırır hem de bellek erişiminin öngörülebilirliğini sağlar.

Varsayılan olarak bu bellek yaklaşık 2 gigabyte’a kadar büyütülebilir — modern sistemlerde ise 4 gigabyte’a kadar genişletilebilir. Bazı gelişmiş ortamlarda bu sınırın çok ötesine, hatta terabaytlara kadar çıkılması mümkündür. Bu büyüme özelliği, uzun süreli çalışan programların (örneğin büyük veri setleriyle uğraşan uygulamaların) ihtiyaçlarına cevap verir. Ancak burada dikkat edilmesi gereken bir gerçek vardır: WebAssembly’in bellek modeli, işletim sisteminin sanal bellek modelinden tamamen farklıdır. Burada “sanal bellek” değil, gerçekten de tek bir fiziksel görünümlü alan söz konusudur ve bu da güvenlik açısından kritik bir ayrım oluşturur.

## Tuzak (Trap): Sınır Dışına Çıkmak Bir Hata Değil, Bir Tasarım

Şimdi asıl büyüleyici kısmına gelmeliyiz: WebAssembly’de bellek sınırlarını aşmak, klasik sistemlerdeki gibi bir “hata” değil — aksine, makinenin bilinçli olarak tasarladığı bir güvenlik mekanizmasıdır. Bu meşhur olaya **trap** (tuzak) denir.

Düşünün: Programcımız, bellek dizisinin sınırlarının çok ötesinde bir adrese erişmeye çalışıyor. Klasik sistemlerde bu durum, tahmin edilemeyen şeylere yol açabilirdi — belleğin rastgele bir başka bölümüne okuma yazma yapılması, felaket düzeyinde güvenlik açıkları doğurabilirdi. Ancak Web