QBE - Derleyici Backend'i: Sürüm 1.3

 (c9x.me)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Performans optimizasyonları büyük ölçüde eklendi; QBE 1.3, standart coremark üzerinde ticari derleyici performansının %63'ünden fazlasına ulaşıyor ve Hare test paketinde qbe-1.2'ye kıyasla %33 iyileşme sağlıyor
  • QBE 1.3, 1.0'dan bu yana en büyük sürüm; yaklaşık 7 bin satır ekleme ve 1,5 bin satır silme içeriyor
  • Yeni optimizasyonlar arasında GVN/GCM, döngü optimizasyonu, if kaldırma ve CFG sadeleştirme yer alıyor, ancak yalnızca doğrulanmış bazı pass'ler korunuyor
  • Inlining, QBE'nin fonksiyon bazlı streaming derleme modeli ile uyumsuzluk yarattığı için bu optimizasyon setine dahil edilmedi
  • ee_isdigit inline edilip crcu8 daha basit, dalsız bir uygulamayla değiştirilen coremark varyantında QBE, hedeflenen gcc -O2 performansının %70'ine ulaştı
  • Yeni OCaml aracı mgen, lispy IL kalıplarını C eşleştirme koduna derleyerek mevcut elle yazılmış komut seçimi mantığını değiştirmeyi veya sadeleştirmeyi mümkün kılıyor
  • mgen, özel yorum bloklarındaki IL kalıplarını bulup hemen altına C kodu ekliyor; mevcut kullanım örneği isel.c içinde yer alıyor
  • Komut DAG eşleştirmesi, Ken Thompson'ın Plan9 C derleyicisindeki yönteme benzer bir numaralandırma yaklaşımını izliyor ve runmatch() tarafından yorumlanan basit bir bytecode matcher da üretiliyor
  • Windows ABI desteği eklendi; -t amd64_win verildiğinde Windows hedefi için derleme yapılabiliyor
  • QBE'nin ürettiği assembly hâlâ AT&T sözdizimini kullanıyor ve mingw assembler ile derleme yapılmasının uygun olduğu belirtiliyor
  • Konumdan bağımsız kod desteği geliştirildi; böylece çoğu hedefte paylaşılan nesnelerle daha sorunsuz bağlantı kurulabiliyor ve paylaşılan nesneler üretilebiliyor
  • Yeni extern dinamik sabit bayrağı (DYNCONST) sayesinde, dinamik kütüphane değişkenleri gibi global sembollere dolaylı erişim IL düzeyinde ifade edilebiliyor

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Lobste.rs görüşleri

  • Uzun süredir devam eden bir hobi projesi olarak TRIPOS/Amiga Exec tarzı küçük bir OS yapıyorum
    Bellek koruması yok, düz bir bellek haritası var ve mesajlaşma da pointer aktarma seviyesinde
    Böyle bir sistemi kendi kendine barındırır hale getirmek için PIE/PIC üretebilen küçük bir derleyici çok daha kullanışlı. Amiga tarzı kütüphanelerin doğal olarak PIC olması gerekiyor ve yürütülebilir dosyaları paylaşımlı bellek haritasında herhangi bir yere koyarken yükleme anında çok fazla yama gerektirmemesi de güzel
    GCC ve Clang bunu yapabiliyor ama fazla büyükler. Son baktığımda TCC PIC yapamıyordu, QBE’ye daha yakından bakmam gerekecek

    • Benim C derleyicim PIC üretebiliyor, ilgini çekebilir: https://codeberg.org/lsof/antcc/
      Kendi reklamım gibi duyulmasını istemem. Küçük derleyici alanını gerçekten seviyorum ve daha fazla teste de ihtiyaç var
    • Ben de düz bellek haritası, her şeyin PIE olduğu ve sistem çağrılarının fonksiyon çağrısı olduğu bir OS olan Ashet OS geliştiriyorum
      Şimdiden epey ilerledi ve birçok platformu destekliyor
      Yakında kendi kendini barındıran bir noktaya gelmesi zor görünüyor. Thumb-2 kod üretimi gerekiyor ve bunu yapmanın pratikte tek yolu doğrudan bir derleyici yazmak. Çekirdek kodu dışında kullanılabilir RAM’in yalnızca 8 MB olması gibi bir kısıt da var
      ELF dosyalarını dönüştürerek oluşturulan kendi çalıştırılabilir dosya biçimi .ashex kullanılıyor. Bu süreçte aslında tek bir mutlak atlama olan özel bir bölüm tüketiliyor ve uygulama yükleyicisi bunu gerçek sistem çağrısı adresiyle yeniden yazıyor
      Düz bellek sistemlerinin zorluğu, paylaşımlı nesneleri temiz biçimde desteklemekte yatıyor. Farklı uygulamalar arasında kod paylaşmak için tüm dinamik sembol erişimlerinin register’da tutulan değişkenler üzerinden yapılmasına yönelik derleyici desteği gerekiyor

  • Yeni extern anahtar kelimesinin gelmesine gerçekten sevindim
    Sürüm notlarında yok ama bunun thread ile de birlikte çalışması initial-exec TLS’i mümkün kılıyor. Başka bir paylaşımlı kütüphanede tanımlanan thread-local global değişkenlere erişirken buna ihtiyaç duyuluyor ve FreeBSD’nin ctype.h dosyası için gerekli
    extern, macOS veya Haiku gibi platformlarda paylaşımlı kütüphanelerdeki normal global değişkenlere, örneğin stderr’a erişmek için de gerekiyor. Artık QBE tabanlı derleyiciler çok daha fazla işletim sistemi ve kullanım senaryosunu destekleyebilir
    Roland’ın performans iyileştirmeleri için de çok minnettarım. Gerçekten harika iş çıkarmış

  • Bunu doğru okuduysam artık resmî Windows desteği mi var?
    QBE’nin tarihsel olarak ve hâlâ en büyük kısıtlarından biri bu değil miydi? Bunu görmek gerçekten güzel

  • Bu projenin hedefi Cranelift ile çakışıyor mu? QBE’yi ne zaman kullanmak gerektiğini pek kestiremiyorum

    • QBE, derleyici backend’leri dünyasının “OpenBSD”sine daha yakın. Felsefesi sadelik ve minimalizm; resmî açıklamaya göre hedefi “endüstriyel optimize edici derleyici performansının %70’ini kodun %10’u ile sunmak”
      Asıl rakipleri Cranelift ve LLVM
      Ne yazık ki geçmişte daha çok hobi dilleri veya derleyici implementasyonlarında kullanıldı. Örneğin yeni bir C benzeri dil gibi görünen myrddin artık ölmüş görünüyor, cproc ise hâlâ yaşayan bir hobi C derleyicisi implementasyonu
      Yine de Hare’in QBE’yi benimsemesinden sonra umut verici görünmeye başladı. Sorunun yanıtı burada: https://harelang.org/documentation/faq.html#why-qbe-instead-of-llvm
    • Bence hedefi yalnızca Cranelift ile değil LLVM ile de çakışıyor
      Ayrıntıları çok iyi bildiğimi söyleyemem ama karşılaştırma için bolca kaynak var. Bildiğim kadarıyla QBE, diğer ikisine göre çok daha basit bir backend olmayı hedefliyor

  • Komut seçimi matcher’ları üretmek için küçük bir DSL kullanma yaklaşımı gerçekten çok hoş