Bir derleyici projesinin geliştirme günlüğünü okumak… Çoğu insan için kuru, belki anlamsız bir uğraş. Ama ben bu tür şeylere bayılıyorum — commit mesajlarının, PR numaralarının, test sayılarının arkasında gerçek mühendislik kararları yatıyor çünkü,. O kararları okumak benim için neredeyse bir dedektif romanı okumak gibi hissettiriyor. Cx programlama dilinin 28 Mart 2026 tarihli geliştirme günlüğü de tam böyle bir gün: yedi commit, bir büyük branch merge, üç tip layout’unun kilitlenmesi, döngü IR’ının ilk kez üretilmesi. Tek. Bir. Günde.
Neden önemsiyorum? 2019’da kendi küçük DSL derleyicimi yazmaya kalkmıştım — hani “ne kadar zor olabilir ki” motivasyonuyla başlanan o tür projelerden. Üç hafta sonra sadece tokenizer’ı bitirmiştim. Yani “en verimli backend günü” deyince ne demek olduğunu baya iyi anlıyorum, bizzat yaşadım (en azından benim deneyimim böyle)
Submain Merge: İki Günlük Bekleme Sonunda Kapı Açıldı
PR #27. İki gündür beklenen, biraz gerginlik yaratan bir merge. Neden gerginlik? Submain dalında biriken iş yığını ciddi: çoklu dosya import pipeline’ı, Phase 8 Round 1 scalar layout, beş kritik hata düzeltmesi, ölü kod eliminasyonu, matrix runner’da çıktı doğrulaması. 6 yeni matrix testi — bunların hepsini ana dala almak, yani her şeyin birden üst üste bindiği o an, düşünsenize, bir merge conflict canavarıyla karşılaşma ihtimali her zaman var.
Ama olmamış. Temiz geçmiş.
Main branch’teki test matrix’i 78 teste ulaşmış. Tek başına bir şey ifade etmeyebilir bu sayı, ama 0.1 milestone’u için hard blocker olan şeylerin temizlendiğini düşünürsek, özellikle de çoklu dosya import meselesi, branch limbo’sunda takılı kalmış bir özelliğin sonunda ana koda girmesi — bu tip anlar projeye ciddi momentum kazandırıyor.
Bakın, Bir arkadaşım geçen yıl bir Rust projesinde benzer durumla karşılaşmıştı. Feature branch iki haftadır merge edilemiyordu, her gün main’den rebase yapıyorlardı. Sonunda “ya bugün ya hiçbir zaman” dediler ve gece 2’de merge ettiler (evet, doğru duydunuz). Sabah CI yeşildi. O rahatlamayı tahmin edebiliyorum.
Evet, doğru duydunuz.
Compound Type Layout’ları: Struct, Array, Enum
Şimdi bakın — bir derleyicinin backend’inde veri tiplerinin bellekte nasıl yerleşeceğini belirlemek gerçekten zor bir iş. Kağıt üzerinde basit görünüyor: “struct’ın alanları sırayla dizilir, padding eklenir, hizalama yapılır.” Pratikte? ABI dokümanlarıyla boğuşmak, edge case’leri düşünmek, test yazmak… İşin rengi değişiyor epey.
Struct Layout
Cx’in struct layout’u declaration-order field formatını takip ediyor (kendi tecrübem). Alanlar tanımlandıkları sırayla bellekte yer alıyor, doğal hizalama ve padding var, C tarzı basit ve öngörülebilir bir yaklaşım. src/ir/types.rs dosyasında yedi test bu layout’u doğruluyor. Az gibi gelebilir ama dur bir saniye — scalar layout dün tamamlanmış, yani temel yapı taşları sağlam, struct testleri de bunun üzerine oturuyor zaten.
İşte tam da bu noktada devreye giriyor.
Array Layout
Sabit boyutlu, bitişik (contiguous), stride tabanlı bir düzen. Offset hesabı çok temiz: elemanın stride’ı çarpı indeks. Beş yeni test bunu kanıtlıyor. Ben kendi DSL denemelerimde array layout’unu “sonra hallederiz” diye ertelemiştim — büyük hataydı. Cx ekibi bunu erkenden kilitlemiş, akıllıca.
// Basitleştirilmiş offset hesabı mantığı
fn array_offset(stride: usize, index: usize) -> usize {
stride * index
}
// Örnek: 4 byte'lık i32 elemanları olan bir array
// array_offset(4, 3) = 12 → 4. eleman 12. byte'ta başlarEnum Layout: Minimalist Tercih
İşte bu kısım ilginç. Enum layout’u 0.1 için bilinçli olarak minimal tutulmuş: sadece u8 tag temsili. Payload variant’ları yok. Discriminated union yok. Generic kaynaklı layout karmaşıklıkları yok. Hepsi post-0.1’e bırakılmış.
Açık konuşayım, bu karar beni ikiye böldü. Bir yanım “doğru karar, önce yürüyün sonra koşarsınız” diyor. Öbür yanım “ama enum’lar payload olmadan ne işe yarar ki?” diye soruyor. Neyse, milestone yönetimi açısından mantıklı bir trade-off sonuçta — her şeyi birden çözmeye çalışmak, o yolun sonu genellikle burnout.
enum Option<T> { Some(T), None } buna güzel bir örnek. Cx bunu şimdilik es geçiyor — ama 0.1 sonrasında muhtemelen en çok talep edilen özellik bu olacak.Calling Convention Kilitlendi: ABI Dokümanına 30 Satır Eklendi
Phase 8’in son büyük tasarım sorusu da cevabını bulmuş. Calling convention: tek return değeri, C ABI hizalaması. Parametre kopyalama semantiği sonraya kalmış.
Durun, bir saniye.
Hmm, bir düşüneyim… Bu ne demek pratikte? Fonksiyon çağrılarında değerlerin nasıl aktarılacağı, stack frame’in nasıl düzenleneceği, register kullanımı — bunların hepsi calling convention’a bağlı. C ABI uyumu seçmek akıllıca. FFI kapısını açık tutuyor, yani Cx kodunun ileride C kütüphaneleriyle konuşması çok daha kolay olacak.
ABI dokümanına 30 yeni satır eklenmiş. Küçük bir detay gibi görünüyor ama — inan bana, iyi dokümantasyon bir derleyici projesinin can damarı. Geçen yıl bir LLVM backend projesi inceliyordum, dokümantasyon sıfırdı, kodu anlamak için üç gün harcadım. Cx ekibinin bunu ciddiye alması güzel bir alışkanlık.
Aritmetik Tutarlılık: Wrapping vs Saturating Kaosu
Teknik ama çok önemli bir mesele bu (en azından benim deneyimim böyle). Runtime aritmetik operasyonlarında bir tutarsızlık varmış: bazı yerler saturating_add / saturating_sub kullanıyormuş, bazı yerler wrapping_add / wrapping_sub. İkisi arasındaki fark kritik:
| Yöntem | Taşma Davranışı | Örnek (u8, 255 + 1) |
|---|---|---|
| saturating_add | Maksimum değerde takılır | 255 |
| wrapping_add | Sıfıra döner (wrap around) | 0 |
Tuhaf ama, Cx ekibi tutarlılık adına her şeyi wrapping’e geçirmiş (ki bu çoğu kişinin gözünden kaçıyor). Bir de i128::MIN / -1 ve i128::MIN % -1 için özel korumalar eklenmiş — bu iki durum panic’e yol açabiliyor çünkü sonuç i128 aralığına sığmıyor, güzel ince bir nokta bu aslında. Tarayıcıda Çalışan Sıfır Kurulumlu API Yük Testi yazımızda bu konuya da değinmiştik.
Bakın, Artık tüm aritmetik i128 aralığında wrap ediyor, tip genişliği truncation’ı ise apply_numeric_cast ile assignment sırasında hallediliyor (evet, doğru duydunuz). Ama — ve bu önemli bir “ama” — dar tiplerde, mesela i8 ya da i16, ara değerler garip sonuçlar üretebilir. Yani kağıt üstünde tutarlı görünüyor, pratikte edge case’ler kalabilir hâlâ.
“Çoğu program bu yapıda sorunsuz çalışır, ama dar tip ifadeleri tuhaf ara değerler sergileyebilir.” — Cx Dev Log, 28 Mart 2026
Açık konuşayım, “Çoğu durumda çalışır” ifadeleri beni her zaman tedirgin eder açıkçası. 0.1 milestone’u için yeterli olabilir, bunu kabul ediyorum. Yapay Zekâ Kodlamada Neden Adım Adım Kazanıyor? yazısında da benzer şeyden bahsetmiştik — adım adım ilerlemek, bir anda mükemmeli hedeflemekten çok daha etkili oluyor çoğu zaman. Bu konuyla ilgili İki Site, Bir Saldırı: Chime ve Pinterest Neden Düştü? yazımıza da göz atmanızı tavsiye ederim.
Phase 10: While Döngüsü Lowering — Gerçek Mimari Sıçrama
Günün en heyecan verici kısmı bu. Backend artık döngüleri temsil edebiliyor. 189 satırlık bir ekleme src/ir/lower.rs dosyasına yapılmış, header/body/exit CFG pattern’i destekleniyor.
Neden bu kadar önemli? Döngüsüz bir dil hesap makinesi gibi — kullanışlı ama sınırlı. Döngü geldiğinde işte o zaman gerçek bir programlama dili oluyorsunuz. Koşullu dallanma ve döngü, bir dilin Turing-complete olması için en temel yapı taşları, bunlar olmadan geri kalan her şey dekorasyon. Daha fazla bilgi için Tarayıcıda Ekran Okuyucu Testi: 5 Dakikada Başla yazımıza bakabilirsiniz.
CFG pattern’i kabaca şöyle çalışıyor:
// While döngüsü CFG pattern'i (kavramsal)
//
// ┌──────────┐
// │ HEADER │ ← Koşul değerlendirilir
// └────┬─────┘
// │
// ┌────▼─────┐ false
// │ koşul? │──────────► EXIT
// └────┬─────┘
// │ true
// ┌────▼─────┐
// │ BODY │ ← Döngü gövdesi
// └────┬─────┘
// │
// └──────────► HEADER'a geri dön189 satır — fena değil bu iş için, gayet kompakt hatta. LLVM’in benzer yapıları binlerce satırla halleder, tabi orada çok daha fazla iyileştirme katmanı var. Cx’in bu aşamada sade kalması doğru tercih bence.
Ha bu arada, WebAssembly 3.0 ve.NET: 2026’da Web Uygulamalarının Yeni Ritmi yazısında da benzer CFG yapılarından bahsetmiştik. WebAssembly’nin structured control flow yaklaşımı Cx’inkinden farklı olsa da temel mantık benzer: kontrol akışını güvenli ve doğrulanabilir tutmak.
Büyük Resim: 0.1 Milestone’una Ne Kadar Kaldı?
Geri adım atıp bakınca, Cx’in tek günde neler başardığı şöyle:
- Submain → main merge tamamlandı (78 test, yeşil)
- Struct, array ve enum layout’ları kilitlendi
- Calling convention belirlendi, ABI dokümanı güncellendi
- Aritmetik operasyonlar tutarlı hale getirildi
- While döngüsü IR’ı üretilmeye başlandı
Bu, proje tarihinin “en verimli backend günü” olarak niteleniyor. Haklılar da. Scalar’dan full data type coverage’a geçiş, döngü IR’ının eklenmesi — bunlar küçük adımlar değil.
Bi saniye — Ama. Açıkça söyleyeyim — Cx hâlâ çok erken aşamada. 0.1 bile çıkmamış. Payload enum’ları yok. For döngüsü yok sanırım. Optimizasyon katmanı yok. Error recovery muhtemelen çok primitif. Bir derleyicinin “kullanılabilir” hale gelmesi için daha çok yol var önünde.
Yine de bu tür şeffaf geliştirme günlükleri bence çok değerli — hem öğrenmek isteyenler için hem de derleyici tasarımına ilgi duyanlar için. Ben her yeni log’u takip etmeyi planlıyorum şahsen.
Araya gireyim: Bir de şunu söyleyeyim: kendi projelerimde bu kadar disiplinli günlük tutmayı hiç başaramadım. En son 2024’te bir side project için “her gün commit log yazacağım” demiştim (şaşırtıcı ama gerçek). Üç gün sürdü. Cx ekibinin bu tutarlılığı takdire şayan, gerçekten.
Sıkça Sorulan Sorular
Cx programlama dili nedir ve ne amaçla geliştiriliyor?
Cx, henüz erken geliştirme aşamasında olan bir programlama dili (kendi tecrübem). Şu an 0.1 milestone’una doğru ilerliyor. Kendi derleyici backend’ini geliştiren, Rust ile yazılmış bir proje (en azından benim deneyimim böyle). Amacı hakkında detaylı bilgi için projenin GitHub sayfasını takip edebilirsiniz.
Derleyici backend’inde “layout kilitleme” ne anlama geliyor?
Bir veri tipinin bellekte tam olarak nasıl yerleşeceğinin — boyutu, hizalaması, padding’i, offset hesaplaması — kesin olarak belirlenmesi demek. Layout kilitlendiğinde artık o tip için belirsizlik kalmıyor ve üzerine güvenle kod üretimi yapılabiliyor.
Wrapping ve saturating aritmetik arasındaki fark nedir?
Wrapping aritmetikte taşma olduğunda değer sıfıra döner (255 + 1 = 0 gibi). Saturating aritmetikte ise maksimum değerde takılır (255 + 1 = 255). Cx tutarlılık için wrapping yaklaşımını tercih etmiş durumda.
CFG (Control Flow Graph) pattern’i neden döngüler için önemli?
Yani, CFG, bir programın olası çalışma yollarını temsil eden bir grafik yapısı. Döngüler, dallanmalar ve koşullu atlamalar bu grafik üzerinde modellenir. Backend’in döngüleri doğru IR’a dönüştürebilmesi için header/body/exit gibi CFG pattern’lerini tanıması gerekiyor (inanın bana)
Cx’in 0.1 sürümü ne zaman çıkacak?
Kesin bir tarih verilmiş değil. Ancak geliştirme günlüklerine bakılırsa, temel layout’lar ve kontrol akışı yapıları hızla tamamlanıyor. Enum payload’ları ve optimizasyon gibi konular post-0.1’e bırakılmış, bu da 0.1’in nispeten yakın olabileceğine işaret ediyor — ama bu konuda %100 emin değilim.
Hmm, bunu nasıl anlatsamdı…
Kaynaklar ve İleri Okuma
Araya gireyim: Cx Dev Log — 2026-03-28 (Orijinal Geliştirme Günlüğü)
Bir şey dikkatimi çekti: Rust Reference: Type Layout — Veri tipi bellekte yerleşim kuralları
LLVM Language Reference: Control Flow — Kontrol akışı IR referansı
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
