Wastrel, zamanında geliştirilmiş bir WebAssembly derleyicisi olarak son birkaç ayda kaydettiği ilerlemelerle dikkat çekiyor. Şubat ayı başında, Wastrel’in çöp toplama (garbage collection) kullanan programları çalıştırabildiğini göstermiştim, ancak test ettiğim iki yapay program sadece mikrobenchmark’lar olarak sınırlıydı ve gerçek bir araç zincirinin çıktısını yansıtmıyordu.
Hoot Derleyici ile Çalışmalar
Bu döngüde, Hoot’un Scheme’den Wasm’a derleyici çıktısını derlemeye çalıştım. Burada ilginç zorluklarla karşılaştım!
Hoot derleyicisini yazarken, tarayıcı hedefi olarak tasarlanmıştı; tarayıcıda zaten mevcut olan BigInt uygulaması sayesinde, Hoot tarafından üretilen Wasm dosyaları, dış referanslar (externref) aracılığıyla ana bilgisayarın büyük sayılarını kullanıyor. Wastrel içinde, büyük sayı işlemlerini gerçekleştirmek için gerekli olan içe aktarmaları uyguladım; toplama, çarpma gibi işlemleri mini-gmp kullanarak gerçekleştirdim. Eğer büyük sayılar önemli hale gelirse, tam GMP’yi bağlama seçeneğim olacak.
Büyük sayılar, Wastrel’de Wasm modülünün bir parçası olarak tanımlanmayan ilk yönetilen veri türüydü. Bu nedenle, bu “ana bilgisayar” veri türlerine tür kodları tahsis etmek için bir olanak eklemek zorunda kaldım. Zamanla daha fazla tür eklenecek: zayıf haritalar, ephemeronlar vb.
İstisna Yönetiminde Güncellemeler
Hoot, önceden standartlaştırma aşamasında kalmış bir istisna yönetim biçimi kullanıyordu ve geçen Temmuz’da standartlaştırılan daha yeni bir versiyona güncelleme yapma fırsatını buldum. Wastrel’de bu güncellemeleri uygulamak daha kolay oldu.
Chris Fallin’in WasmTime’da karşılaştığı bazı problemler, Wastrel durumunda geçerli olmadı: örneklerin kümesi derleme zamanında bilindiği için, istisna etiketleri için statik tür kodları tahsis edebiliyoruz. Ayrıca, geriye doğru işlem yapmam gerekmiyordu; sadece setjmp ve longjmp kullanmam yeterliydi.
Hataların Belirlenmesi
Yazdığım bu paragrafa, sadece setjmp kullanımının neden yeterli olduğunu kısaca açıklamak amacıyla eklenmişti. Wastrel, geçici verileri yeniden kullanmadığı için, “volatile problemi” konusunda endişelenmem gerektiğini düşünmüyordum. Ancak, local.set ile ilgili olarak, yerel nesnelerin (otomatik saklama süresine sahip nesneler) değiştirilmesi bu kuralı ihlal edebilir. Blog yazımı yazarken, her fonksiyonu analiz ederek try_table içinde değiştirilen yerel nesneleri belirledim. Bu süreçte birçok hata ile karşılaştım.
Performans İyileştirmeleri
Wastrel, başlangıçta iç içe geçmiş C kodları üretiyordu, bu da dosya boyutunu artırıyordu. Bunun yerine, birçok C dosyası üretecek şekilde yeniden yapılandırdım. Modüldeki tüm fonksiyonların bir DAG ormanı oluşturmasına ve ormanın alt ağaçlarını tüketerek “yeterli” kodu bölmek üzere ilerlemesine izin verdim. Bu değişiklik, derlemelerin çok daha hızlı gerçekleşmesini sağladı.
Gelecek Planları
Wastrel, C koduna dönüş sürecinde hala geliştirilmesi gereken birçok yön var. Hoot’un işlevselliğini artırmak ve daha fazla özellik eklemek için çalışmalarım devam ediyor. Gelecek hedeflerim arasında, Wastrel’in hata ayıklama işlevselliğini geliştirmek ve daha fazla standart ile uyum sağlamak var.
Sonuç olarak, Wastrel’in gelişimi, zorluklarla dolu ancak aynı zamanda öğretici bir süreç oldu. WebAssembly ekosistemindeki yenilikleri takip ederek, gelecekte daha fazla özellik ve işlevsellik sunmayı umut ediyorum. Bu yolculuk, hem Wastrel hem de Hoot için yeni ufuklar açacak.
Read more → wingolog.org