SBCL’nin Nintendo Switch’e port edilmesi
(reader.tymoon.eu)- Trial oyun motorunu Nintendo Switch’te çalıştırmak için Common Lisp çalışma zamanı SBCL 2 yıl boyunca port edildi; şu anda Switch üzerinde Lisp kodu derleme·çalıştırma ve paylaşımlı kütüphanelerle entegrasyon aşamasına ulaşıldı
- Switch, ARM64 Cortex-A57 4 çekirdek, 4GB RAM ortamı sunuyor; ancak kabuk, komut satırı ve derleyici yok ve çalıştırılabilir sayfa oluşturulması da engelli olduğundan, SBCL’nin tipik bootstrap yöntemiyle uyuşmuyor
- Derleme, Linux ARM64 ana makinesi ile Nintendo SDK’sının birleştirilmesiyle yapılıyor;
fasteval,immobile-code, elfination ile core kod ve veriye ayrıldıktan sonra son pakete sarılıyor - Trial REPL örneği, Switch devkit üzerinde OpenGL bağlamı, girdi işleme ve shader tahsisine kadar çalışıyor; ancak çöp toplayıcı çalıştığında çöküyor ve C callback sorunu yüzünden ses hâlâ mümkün değil
- Kalan temel işler, çok iş parçacıklı GC için safepoint kararlılığını sağlamak, C callback’leri geri getirmek, CLOS çalışma zamanı derlemesinden kaçınmak, performansı optimize etmek; ayrıca Nintendo NDA nedeniyle bazı kodlar paylaşılamıyor
Switch’te SBCL ne kadar çalışıyor?
- Trial oyun motorunu Nintendo Switch’te çalıştırmak için Charles Zhang ile birlikte son 2 yıldır SBCL portu üzerinde çalışıldı
- Temel zorluk, Trial’ın altında çalışan Common Lisp çalışma zamanını Switch platformuna uyarlamaktı
- Şu anda yapılabilenler:
- Çalışma zamanı ve derleyici port edildi; Switch üzerinde rastgele Lisp kodu doğrudan derlenip çalıştırılabiliyor
- Paylaşımlı kütüphanelerle arayüz kurulabiliyor
- Trial’ın Switch’te ihtiyaç duyduğu çeşitli işletim sistemi taşınabilirlik kütüphaneleri de port edildi
- Trial’ın REPL örneği Switch devkit üzerinde çalışıyor
- Switch’in kendisinde terminal olmadığı için, Trial OpenGL bağlamı oluşturuyor, girdiyi yönetiyor, shader tahsis ediyor ve ekranda metin gösteriyor
- Henüz takılan noktalar:
- SBCL çöp toplayıcıyı çalıştırmaya kalkınca kısa süre içinde çöküyor
- Switch’in kendine özgü kısıtları nedeniyle aşılamamış bazı noktalar var
- C callback mekanizması bozuk olduğu için ses çıkışı mümkün değil
- Performansla ilgili henüz ortaya çıkmamış başka sorunlar da olabilir
Maliyet ve sürdürülebilirlik
- Port çalışması şimdiye kadar yaklaşık 17.000 dolar tuttu ve Charles Zhang’e aylık bazda ödeme yapıldı
- Gelir, Kandria satışları ile Patreon, GitHub Sponsors, Ko-Fi desteklerinden geliyor
- İyi aylarda yaklaşık 1.200 dolar
- Kötü aylarda yaklaşık 600 dolar
- İsviçre’nin Zürih kentinde bu gelirle yaşamak zor; şu anda ebeveynlerle yaşanıyor ve kişisel harcamalar kısarak idare ediliyor
- Switch için Kandria satışlarının port maliyetini çıkarıp çıkarmayacağı şüpheli olduğundan, sınırlı kaynakların nereye harcanacağına karar vermek zorlaşıyor
- Destek gelirleri bir süre daha SBCL Switch portuna ve şu anda üzerinde çalışılan açıklanmamış oyun projesine ayrılacak
Switch ortamı ve port koşulları
- Kamuya açık olarak bilinen Switch ortamı:
- Kullanıcı kodu ARM64 Cortex-A57 çipi üzerinde çalışıyor
- 4 çekirdek ve 4GB RAM kullanılıyor
- İlk olarak Nintendo 3DS için geliştirilmiş özel bir mikrokernel işletim sistemi üzerinde çalışıyor
- SBCL’nin zaten bir ARM64 Linux portu var; dolayısıyla kod üretimi tarafı çözülmüş durumda
- Kandria 4GB RAM’e rahatça sığıyor, bu yüzden bellek kapasitesinin kendisi sorun değil
- Asıl zorluk, Switch’in özel işletim sistemiyle arayüz kurmakta yatıyor
- Genel PC işletim sistemlerinde olmayan kısıtlar var
- Bu kısıtlar Lisp gibi sistemler için özellikle sorunlu
- Switch, Trial’ın dayandığı OpenGL render’ını destekleyen tek konsol
- Xbox yalnızca DirectX destekliyor; ancak Microsoft’un geliştirdiği bir OpenGL → DirectX katmanı olduğu söylendiğinden bir ihtimal olabilir
- Playstation’ın tamamen özel bir grafik API’si olduğu söyleniyor; bu yüzden o platforma port etmek düşünülmek istenmiyor
- Geliştirme için Nintendo of Europe üzerinden erişim alındı ve yaklaşık 400 dolarlık bir devkit satın alındı
- Devkit ve SDK yalnızca Windows’ta çalışıyor; bu da sonraki derleme sürecinde ek yük getiriyor
Tipik SBCL derlemesi ve Switch ile çakıştığı noktalar
- SBCL büyük ölçüde Lisp’in kendisiyle yazılmış durumda ve küçük bir C çalışma zamanı da içeriyor
- C çalışma zamanı normal bir C derleyicisiyle derleniyor; ancak hedef işletim sistemi ortamı hakkında bilgi sahibi olması gerekiyor
- Çalışma zamanının kendisinde Lisp derleyicisi olmadığı için, SBCL’yi bootstrap etmek adına başka bir Lisp uygulaması gerekiyor; ideal olarak SBCL’nin başka bir sürümü kullanılıyor
-
PC’de 5 aşamalı derleme
build-config- Hedefe yönelik derleme yapılandırma seçeneklerini toplayıp sonraki aşamaların okuyabileceği bir biçimde çıktılıyor
make-host-1- Ana makinedeki Lisp derleyicisiyle bir çapraz derleyici oluşturuluyor
- Lisp nesnelerinin bellek yerleşimini C struct’ları olarak açıklayan header dosyaları da üretiliyor
make-target-1- Hedef C derleyicisiyle C çalışma zamanı oluşturuluyor
- C çalışma zamanı; çöp toplayıcıyı ve işletim sistemi ortamıyla yapıştırıcı kodu içeriyor
- İşletim sistemi header’larından, hedef Lisp derleyicisinin ve çalışma zamanının bilmesi gereken sabitler de üretiliyor
make-host-2make-host-1ile oluşturulan Lisp çapraz derleyicisi kullanılarak hedef Lisp sistemi, yani derleyici ve standart kütüphane derleniyor- Çalışma zamanının girebileceği bir cold core üretiliyor
make-target-2- Cold core hedef çalışma zamanına yükleniyor ve bootstrap tamamlanıyor
- Lisp sistemi belleğe yüklendikten sonra warm core olarak dump ediliyor
- Bundan sonra yeni kod yüklemek ve yeni imajlar dump etmek serbest oluyor
-
Switch’te sorun yaratan noktalar
- SBCL derlemesinde, hedef makinede Lisp kodu çalıştırmayı gerektiren aşamalar var
- Kullanıcı Lisp kodu, C gibi yalnızca basit toplu derlemeyle ele alınamıyor; çalıştığında hedef ortamda olduğunu varsayıyor
- Uygulama dağıtımı da
make-target-2benzeri şekilde, Lisp kodunun aşamalı derlenip ardından çalışma zamanıyla birlikte bir core dump edilmesine dayanıyor - SBCL çalışma zamanı açılışta core blob’unu belleğe map ediyor, kod sayfalarını çalıştırılabilir olarak işaretliyor ve özel bir giriş fonksiyonuna atlıyor
- Switch’te bu yaklaşımın tamamı sorun çıkarıyor
Switch için derleme stratejisi
- Switch bir PC ortamı değil; kabuk, komut satırı ya da derleyici araç takımı yok
- İşletim sistemi çalıştırılabilir sayfa oluşturulmasına izin vermediği için, derleme aşamaları Switch’te çalıştırılabilse bile normal Lisp aşamalı derlemesi mümkün değil
- Kodun büyük kısmı platformdan bağımsız olduğundan ARM64 için derlenebiliyor
- Yalnızca çevredeki işletim sistemi ortamına dokunan kısımların hedefinin Switch olduğu belirtilip, geri kalan uygulama Linux gibi başka bir ARM64 ortamında oluşturulabiliyor
-
Switch için derleme aşamaları
build-config- Ana sistemde çalışıyor ve Switch derlemesini ifade eden özel bir bayrak kullanıyor
fastevalcontrib etkinleştiriliyor- Switch’te çalışma zamanında derleme yapılamadığı için
fasteval, derleyici çağrısı gerektiren noktaların yerini alıyor
make-host-1- Büyük bir değişiklik yok; Switch platform hazırlığı için header’lar üretiliyor
make-target-1- Nintendo SDK’nın sağladığı C derleyicisiyle Switch için C çalışma zamanı çapraz derleniyor
- Switch OS POSIX uyumlu olmadığından, SBCL içinde özel bir çalışma zamanı hedefi oluşturulup dinamik bağlama, sayfa eşleme gibi işletim sistemi farkları stub’lanıyor ya da sarmallanıyor
- İkinci
build-config,make-host-1,make-target-1- Switch ile aynı özellik kümesine sahip genel bir ARM64 Linux sistemi oluşturuluyor
- Bazı Lisp süreçlerine, son hedefin Switch olduğunu belirten özel bir bayrak veriliyor
make-host-2,make-target-2- Biraz özel bir Linux ARM64 SBCL derlemesi elde ediliyor ve ardından kullanıcı kodu derleniyor
- Kullanıcı kodu derleme
- Linux’ta değil de Switch’te çalıştığına inandırmak için
*features*değiştiriliyor :nxekleniyor;:linux,:unix,:posixçıkarılıyor- ASDF devre dışı bırakıldıktan sonra Trial gibi programlar normal yönteme yakın şekilde derleniyor ve yeni bir core dump ediliyor
- Linux’ta değil de Switch’te çalıştığına inandırmak için
immobile-code ve elfination ile core’un paketlenmesi
- Switch’te olağan core eşleme stratejisi kullanılamadığından, Switch çalışma zamanına yeni bir core ekleme yöntemi işlemiyor
- Çözüm olarak SBCL’nin görece az bilinen
immobile-codeözelliği ve elfination kullanılıyor - Normalde SBCL, çalışma zamanında derlediği kodu bazı sayfalara yerleştiriyor ve o sayfaları çalıştırılabilir olarak işaretliyor
- Daha sonra koda ihtiyaç kalmazsa çöp toplama kapsamına girebiliyor
- Alan geri kazanılabiliyor ve kalan kod sıkıştırılabiliyor
immobile-codefarklı bir strateji izliyor- Kodu özel olarak ayrılmış kod sayfalarına koyuyor ve orada tutuyor
- Kod çöp toplanamıyor
- Bunun karşılığında geleneksel işletim sistemi yürütülebilir dosya desteğinden yararlanılabiliyor
- Yürütülebilir dosyada, işletim sisteminin kod olarak bildiği önceden işaretli bölümler bulunuyor ve program başlangıcında eşlemeyi işletim sistemi yapıyor
- Elfination aşaması, core’u normal bir yürütülebilir dosya için gereken ayrı kod ve veri bölümlerine dönüştürüyor
- Elfinator core’u analiz ediyor
- Adres alanı yerleşimi rastgeleleştirmesi için gereken konumdan bağımsız kod olacak şekilde assembly yeniden yazılıyor
- Saf kod assembly dosyası ve saf veri payload dosyası olarak ayrılıyor
- Son aşamalar:
- Elfinator ile assembly dosyası üretimi
- Son ikili dosyanın link edilmesi
- Nintendo SDK’nın authoring araçlarıyla metadata, paylaşımlı kütüphaneler, asset’ler ve uygulama ikilisinin tek bir nihai pakette birleştirilmesi
Derleme altyapısı ve paylaşılabilen kapsam
- Derleme için en azından, derlemenin büyük bölümünü yapacak bir ARM64 Linux makinesi gerekiyor
- Nintendo SDK derleyicisini ve authoring araçlarını çalıştırmak için AMD64 Windows makinesi ya da Wine kullanan AMD64 Linux makinesi gerekiyor
- Gerçek kurulum neredeyse üç makineden oluşuyor
- AMD64 “driver”
- ARM64 derleme ana makinesi
- Devkit ile iletişim kuran Windows VM
- Önbellekleme ve makineler arası senkronizasyon mantığı olan özel bir derleme sistemi yazılarak süreç otomatikleştirildi
- MSYS2/Windows ortamında da çalışması gerektiği için yol dönüşümü sorunları yaşandı
- Elfinator ve
immobile-codeARM64 üzerinde çalışır hâle getirildi; ayrıcapathname-utils,libmixed,cl-gamepadgibi yardımcı kütüphaneler de port edildi - Nintendo NDA nedeniyle birçok ayrıntı paylaşılamıyor
- Paylaşılabilen çalışmalar upstream edildi ve Lisp kütüphaneleri için özel fork tutulmuyor
- Nintendo SDK’ya doğrudan bağlanmamak için ayrı bir C kütüphanesi oluşturuldu; Lisp kütüphaneleri işletim sistemi işlevlerine bu özel arayüz üzerinden erişiyor
- Amaç, Lisp tarafını açık tutup yalnızca küçük C kütüphanesini kapalı tutmak
Mutlak işaretçiler ve yükleme sırasında yeniden konumlandırma
- Elfination baştan beri konumdan bağımsız çalışan Lisp kodu üretmek için tasarlanmış bir özellik değildi
- Lisp kodu genellikle çok sayıda mutlak işaretçi içeriyor
- SBCL derleyicisinde ve çalışma zamanında, yükleme sırasında mutlak işaretçilerin yeniden konumlandırılmasını desteklemek için çalışma yapılması gerekti
- Kod nesneleri normalde kod sabitleri içeriyor ve artık bunların mutlak işaretçi taşımaması gerekiyordu
- GC yürütme bölümünü değiştiremez
- OS yükleyicisi de mutlak işaretçileri yeniden konumlandırmak için yürütme bölümünü değiştiremez
- Çözüm yaklaşımı:
- Kod sabitleri gibi mutlak işaretçileri text alanı dışındaki okunabilir/yazılabilir bir alana taşımak
- Kod içindeki sabit başvurularını, bu okunabilir/yazılabilir alandan yüklenecek şekilde yeniden yazmak
- Yükleyici ve hareketli GC, bu alandaki işaretçileri güncelleyebilir
Çöp toplayıcı ve safepoint sorunu
- SBCL’nin standart GC’si gencgc, yani nesil tabanlı bir çöp toplayıcı
- Gencgc, nesne nesillerini ayırıyor, bunları farklı sıklıklarda tarıyor ve nesneleri başka nesil konumlarına kopyalayarak alanı sıkıştırıyor
- Bu yapı tek başına Switch’te özünde sorun değil; ancak çok iş parçacıklılık sorun yaratıyor
- Birden fazla iş parçacığı varken, bir iş parçacığı nesneye erişiyor olabilir; bu yüzden nesneler keyfi şekilde taşınamıyor
- En kolay çözüm, GC başlamadan önce tüm iş parçacıklarını durdurmak
-
Unix ve Switch farkı
- Unix sistemlerinde signal mekanizmasıyla diğer iş parçacıklarına sinyal gönderilip park olmaları sağlanabiliyor
- Switch’te signal mekanizması yok ve iş parçacıkları interrupt edilemiyor
- Bu nedenle her iş parçacığının, kendisinin park olması gerektiğini fark etmesi sağlanmalı; tipik strateji safepoint
- Safepoint, derleyicinin eklediği kodla iş parçacığının park olması gerekip gerekmediğini kontrol ettiriyor
- Bu kontrollerin bir maliyeti olduğu için olabildiğince seyrek yapılmalı
- Çok seyrek yapılırsa, tüm iş parçacıkları park olana kadar GC başlayamıyor ve diğer iş parçacıkları bekliyor
- Kontrol çok sayıda komut gerektirirse CPU cache line’larını ve boru hattı optimizasyonlarını bozabiliyor
-
Mevcut SBCL safepoint sisteminin sınırları
- SBCL’nin bugünkü safepoint sistemi Windows için yazıldı
- Windows’ta süreçler arası signal handler yok; fakat Switch’ten farklı olarak mevcut iş parçacığı için signal handling var
- Mevcut yaklaşım:
- Her iş parçacığı, safepoint’in bir kelime yazdığı bir sayfayı tutuyor
- GC başlayınca bu sayfa salt okunur yapılıyor
- Başka bir iş parçacığı safepoint’e ulaşıp sayfaya yazmaya çalıştığında segmentation fault oluşuyor ve o iş parçacığı park oluyor
- Yalnızca tek bir yazma komutu gerektiği için verimli
- Switch’te bu teknik de kullanılamıyor; bu yüzden daha karmaşık kontroller eklemek gerekiyor
- Safepoint Windows dışı platformlarda gerekmediği için başka yerlerde test edilmedi ve Switch’e özel düzeltmelerden bağımsız olarak da kararsız
- Kod tabanında bu bölümün ciddi biçimde temizlenmesi gerekebilir; ancak tamamen yeniden yazmaya gitmeden çözülmesi umuluyor
CLOS çalışma zamanı derlemesinden kaçınma
- CLOS, yöntem dağıtımı için gereken discriminating function derlemesini genellikle generic function’ın ilk çağrısına kadar erteliyor
- Çünkü CLOS çok dinamik; yöntemler neredeyse her an eklenip çıkarılabildiğinden sistemin ne zaman tamamlandığını bilmek zor
- Switch’te derleyici çağrılamadığı için bu gecikmeli derleme yaklaşımı aynen kullanılamıyor
- Mevcut strateji hızlı değerlendiriciye dayanıyor
compilefonksiyonu stub’lanıyor- Derleme yerine, kodu evaluator ile çalıştıran bir lambda üretiliyor
compile’a dayanan kullanıcı kodlarında da işe yarıyor- Gerçek derlemeye göre çalışma hızı çok daha düşük
Kalan işler ve performans riski
fastevalyaklaşımı esas olarak bir fallback- Nihai imaj dump edilmeden hemen önce mümkün olduğunca çok CLOS durumunu sabitlemenin ve olabildiğince fazla kodu önceden derlemenin yolları araştırılmak isteniyor
- Charles’ın birkaç yıl önce geri getirdiği block compilation mode da daha fazla incelenecek
- Switch’in görece zayıf işlemcisi nedeniyle ek optimizasyon gerekebilir
- Trial motoru tarafında
- Kandria kodu tarafında
- Şimdiye kadar 10 yıllık bilgisayarlar bile oyunun gereksinimlerini rahatça karşıladığı için optimizasyona görece az ihtiyaç duyulmuştu
- Yüksek öncelikli işler:
- Çöp toplayıcıyı tamamen çalışır hâle getirmek
- Şu anda açılıştan sonra Trial ana döngüsüne kadar girilebiliyor
- Çok nesilli sıkıştırmaya gelindiğinde başarısız oluyor
- C’den gelen callback’leri yeniden çalıştırmak
- SBCL kod tabanının ilgili kısmında çok sayıda elle yazılmış assembly rutini var
- Bunların
immobile-codeve elfination ile uyumlu olacak şekilde ayarlanması gerekebilir - Trial yalnızca
libmixedüzerinden ses oynatımı için callback’e ihtiyaç duyuyor
- Trial’ın selftest paketinin Switch’te tamamen geçmesi için gereken ek taşınabilirlik işlevleri üzerinde çalışmak
- Çöp toplayıcıyı tamamen çalışır hâle getirmek
NDA ile sınırlanan paylaşım kapsamı
- Port çalışmasının tamamı paylaşılmak istense de Nintendo NDA nedeniyle bu mümkün değil
- Paylaşılabilen bölümler upstream ediliyor ya da açık şekilde yayımlanıyor
- Nintendo SDK ile doğrudan bağlantılı bazı kodlar, NDA imzalamamış kişilerle paylaşılamıyor
- Nintendo Switch üzerinde Common Lisp oyunu yayımlamak isteyen biri olursa, NDA imzaladıktan sonra port çalışmasına erişim alabilir
- Patron’lara yönelik aylık güncellemelerde ilerleme daha ayrıntılı paylaşılacak
1 yorum
Hacker News yorumları
Son birkaç haftadır Common Lisp ile oyun geliştirmeyi denemek için Trial(https://github.com/Shirakumo/trial) kullandım ve çok keyif aldım
Oyunun çalışması sırasında neredeyse her şeyi değiştirebilmek gerçekten çok büyük bir avantaj; umarım bu port başarılı olur
Kod değişiklikleri arasında uygulama durumunu koruyabilmek de çok faydalı görünüyor ve Common Lisp de kabaca düşündüğümden çok daha hızlı bir dil gibi duruyor
Bana göre en büyük dezavantaj, sadece oyun geliştirmede değil genel olarak veri yapılarının kullanımı, özellikle de map'lerle çalışma biçiminin biraz hantal olması; ama bu ödün verilebilir görünüyor
Bu gerçekten harika. SBCL mükemmel bir dil gerçekleştirmesi ve Common Lisp geliştirmeyi “gerçek” bir oyun konsolunda denemek istemiştim
Shinmera'nın bu işi yapıyor olması da güzel anlamda şaşırtıcı. Onu daha önce #lispgames ve Lisp Discord'da birkaç kez görmüştüm ama bu kadar düşük seviye geliştirmeyle de ilgilendiğini bilmiyordum
SBCL'nin içine kısaca bakıp korkarak geri çekildiğim için daha da etkileyici geliyor. SBCL ile threading ve SDL2 birleşiminin şu anda Raspberry Pi'de de çalışıp çalışmadığını merak ediyorum
Ve daha önce söylendiği gibi *her :)
Böylesine ilginç ve ayrıntılı bir yazı yazdığı için yazara teşekkürler. Bu düzeyde resmî konsol portu ayrıntıları genelde ancak konsolun ömrü bittikten yıllar sonra ortaya çıkıyor gibi geliyor
Böyle derinlikli çalışmaları okuyunca, gün boyu tekrarlı yazılımlarla geçen kendi işimi düşünüp biraz kıskandığım da oluyor
Geliştirme kitlerinde genelde daha iyi hook'lar vardı ama aynı zamanda GDB merkezli akışı atlamanın da avantajları oluyordu. İki tarafı da yaşadıktan sonra, o kadar da kıskanılacak bir dünya olduğundan emin değilim
Belki de mesele, şu anda ilgime ihtiyaç duyan bir proje değil; ileride benim ilgime ihtiyaç duyacak bir projedir :D
“Her şeyi paylaşmak isterdim ama NDA yüzünden yapamıyorum” kısmını görünce, kısıtsız homebrew SDK(https://switchbrew.org/wiki/Setting_up_Development_Environment) yerine neden resmî SDK'nın kullanıldığını merak ettim
Tamamen tahmin yürütüyorum ama belki de Nintendo, üçüncü taraf SDK ile derlenen oyunların resmî olarak yayımlanmasına izin vermiyordur
Bununla ilgili olarak https://opengoal.dev var
Arka plan olarak, Naughty Dog PS2 dönemindeki Jak & Daxter serisini yaparken Lisp benzeri kendi dili GOAL'ı kullanmıştı. Yeterince hata ayıklama bilgisi bıraktıkları için tersine mühendislik mümkün oldu ve OpenGOAL projesi bunu başardı
Şimdi bu oyunlar, GOAL derleyicisinin portlandığı her platformda çalışabiliyor. Bildiğim kadarıyla şu an x86 var; Switch'e portlanırsa harika olur
Az önce Kandria satın aldım. Çok oyun oynayan biri değilim, o yüzden fazla oynayacağımı sanmıyorum ama Shinmera'nın Lisp dünyasının sınırlarını gerçekten genişlettiği açık, bu yüzden desteklemeye değer buluyorum
Onun yaptığı iş gerçekten muhteşem. Ara sıra Common Lisp kullanan biri olarak böyle işleri görmek beni çok sevindiriyor
Keşke Nintendo ya da Sony gibi şirketler bu tür çabaları doğrudan desteklese. Sonuçta bu da konsollar için oyun, yani IP üretmenin başka bir yolu; platform düzeyinde Github Accelerator benzeri bir şey başlatmalarının ne gibi bir dezavantajı olacağını göremiyorum
Nintendo'nun Switch için çıkış yapmayı teşvik edecek yeni bir teşvik yaratmasına gerek yok. Zaten 140 milyondan fazla satış ve yüksek oyun satın alma oranı şeklinde en büyük teşvik hâlihazırda mevcut
Yine de eskisi kadar çok prosedür yok. Günümüz sistemleri çoğunlukla genel amaçlı CPU ve GPU mimarilerinde birleşti; farklılıklar olsa bile bunlar çoğu zaman küçük süsler düzeyinde kalıyor
Bu yüzden güzel şeylerin tadını çıkarmak zorlaşıyor
HN'ye böyle yazılar görmek için geliyorum. Asıl yazarı ve iş arkadaşını tebrik ederim. İmkânsız olduğunu biliyorum ama Nintendo kendi sistemlerini biraz daha açık ele alsa gerçekten büyük bir nimet olurdu
Hiçbir yerde açıklanmadığı için ekleyeyim: SBCL, “Steel Bank Common Lisp” demek
“Steel Bank Common Lisp (SBCL), yüksek performanslı bir Common Lisp derleyicisidir. Hoşgörülü lisanslı bir açık kaynak/özgür yazılımdır ve ANSI Common Lisp için bir derleyici ve runtime sistemi yanında hata ayıklayıcı, istatistiksel profiler, kod kapsamı aracı ve çeşitli uzantılar içeren etkileşimli bir ortam sunar”
https://www.sbcl.org/
https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html