Neden bu kadar az C derleyicisi var?

C, dünyada en çok kullanılan dillerden biridir. Mevcut kodun büyük bir bölümünü oluşturuyor ve çok sayıda yeni kod için kullanılmaya devam ediyor. Kullanıcıları tarafından sevilir, o kadar yaygındır ki, C'yi çalıştırabilmek bir platformun gayrı resmi bir tanımıdır ve hayranları tarafından nispeten temiz özelliklere sahip "küçük" bir dil olduğu için övgüyle söz edilir.

Peki tüm derleyiciler nerede?

Masaüstünde, (gerçekçi) iki var : GCC ve Clang. Birkaç saniye düşünürseniz, muhtemelen Intel’in de var olduğunu hatırlayacaksınız. Ortalama bir insanın ismini veremeyecek kadar karanlık olan ve yeni bir dil versiyonunu (ya da çoğu zaman iyi tanımlanmış bir dil altkümesini, sadece “bir altkümeyi”) desteklemek için neredeyse hiç rahatsız edici olmayan bir avuç dolusu insan vardır. Bu listedeki üyelerin yarısı tarihsel dipnotlardır; geri kalanların çoğu çok uzmanlaşmıştır ve hala tüm dili tam anlamıyla kullanmıyorlar. Çok azı aslında açık kaynak gibi görünüyor.

Şema ve İleri - hayranları tarafından sevilen diğer küçük diller - muhtemelen gerçek kullanıcılardan daha fazla derleyiciye sahiptir. SML gibi bir şey bile , C arasında seçim yapabilecek daha "ciddi" uygulamalara sahip olsa da , doğrulamayı hedefleyen yeni (bitmemiş) bir C derleyicisinin açıklanması aslında bazı oldukça olumsuz tepkiler görmekte ve deneyimli uygulamalar bile yeteri kadar katkıda bulunanları yakalamak için çaba sarf etmektedir. C99.

Neden? C uygulaması bu kadar zor mu? C ++ değil. Kullanıcılar, hangi karmaşıklık grubuna girdikleri hakkında çok eğri bir fikre sahipler mi?

Bugün, bir olmak için gerçek bir C derleyicisi ihtiyaç optimizasyon derleyicisi , özellikle C donanıma yakın bir dil, artık çünkü akım nedeniyle işlemciler (inanılmaz derecede karmaşık dışı sipariş , ardışık , superscalar , kompleks ile önbelleklerini & TLB , bu nedenle , komut çizelgeleme , vb.) gerekir. Bugünün x86 işlemcileri, her ikisi de aynı makine kodunu çalıştırsa bile, önceki yüzyılın i386 işlemcilerine benzemiyor. C'nin düşük seviyeli bir dil olmadığını görün ( David, PC'niz hızlı bir PDP-11 değildir) .

Çok az insan tinycc veya nwcc gibi saf olmayan optimizasyonlu C derleyicileri kullanıyor , çünkü derleyicilerin optimize edebileceğinden birkaç kat daha yavaş kod üretiyorlar.

Bir optimizasyon derleyicisini kodlamak zordur. Hem GCC hem de Clang'ın bazı "kaynak dil-nötr" kod gösterimlerini optimize ettiğini unutmayın (GCC için Gimple, Clang için LLVM). İyi bir C derleyicisinin karmaşıklığı ayrıştırma aşamasında değil!

Özellikle, bir C ++ derleyicisi yapmak bir C derleyicisi yapmaktan çok daha zor değildir: C ++ 'ı ayrıştırmak ve bazı iç kod gösterimlerine dönüştürmek karmaşıktır (çünkü C ++ özelliği karmaşıktır), ancak iyi anlaşılmıştır, ancak optimizasyon parçaları daha da fazladır karmaşık (GCC içinde: orta uç optimizasyonlar, kaynak dil ve hedef işlemci nötr), derleyicinin çoğunluğunu oluşturur, geri kalan kısım birkaç dil için ön uçlar ve birkaç işlemci için arka uçlar arasında dengelenir ). Bu nedenle en iyileştirici C derleyicileri, C ++, Fortran, D, ... gibi diğer bazı dilleri de derleyebilir. GCC'nin C ++ 'a özgü bölümleri, derleyicinin yaklaşık% 20 ...

Ayrıca, C (veya C ++) o kadar yaygın bir şekilde kullanılır ki, insanlar, kendi dillerinin anlamlarını tam olarak yeterince tanımlamamış olan resmi standartlara tam olarak uymasalar bile, kodlarının uyuşmasını beklerler (böylece her derleyicinin kendi yorumu olabilir. onun). Ayrıca CompCert'in kanıtlanmış C derleyicisine ve C'nin daha resmi anlamsallığına önem veren Frama-C statik analizörüne bakın .

Ve optimizasyonlar uzun kuyruklu bir fenomendir: birkaç basit optimizasyon uygulamak kolaydır, ancak bir derleyiciyi rekabetçi hale getirmezler! Çok farklı optimizasyonlar uygulamanız ve rekabetçi bir gerçek dünya derleyicisini elde etmek için bunları akıllıca organize etmeniz ve birleştirmeniz gerekir. Başka bir deyişle, gerçek dünyayı optimize eden bir derleyici, karmaşık bir yazılım parçası olmalıdır. BTW, hem GCC hem de Clang / LLVM, birkaç dahili uzman C / C ++ kod üretecine sahiptir. Ve her ikisi de büyük bir geliştirici topluluğuna (çoğunlukla tam zamanlı veya en az yarı zamanlı çalışan birkaç yüz kişi), büyük canavarlardır (her yıl yüzde birkaç büyüme oranına sahip birkaç milyon kaynak kod satırı).

Orada olduğuna dikkat edin hiçbir bile, çok kanallı C derleyicisi (benim en iyi bildiğim için) bazı (..., talimat zamanlama tahsisi kayıt, örneğin içi prosedürel optimizasyonu) bir derleyici parçaları paralel olarak çalıştırılabilir. Ve paralel inşa etmek make -jher zaman yeterli değildir (özellikle LTO ile ).

Ayrıca, bir C derleyicisini sıfırdan kodlamak için fon almak zordur ve bu tür bir çabanın birkaç yıl sürmesi gerekir. Son olarak, çoğu C veya C ++ derleyicisi bugün ücretsiz bir yazılımdır (yeni başlayanlar tarafından satılan yeni özel derleyiciler için artık bir pazar yoktur) veya en azından tekelci ürünler ( Microsoft Visual C ++ gibi) vardır ve en az bir zamanlar derleyiciler için ücretsiz bir yazılım olması gerekir ( çünkü birçok farklı kuruluşun katkılarına ihtiyaç duyuyorlar).

C derleyicisinde çalışmak için ücretsiz yazılım olarak sıfırdan bir finansman sağlamaktan memnuniyet duyarım, ancak bugün mümkün olduğuna inanacak kadar saf değilim!

Sadece az sayıda C uygulamasının olduğu varsayımına itiraz etmek isterim.

C'yi tanımıyorum bile, C'yi kullanmıyorum, C topluluğunun bir üyesi değilim ve henüz bahsettiğim birkaç derleyiciden bile daha fazlasını biliyorum.

Birincisi ve en önemlisi, masaüstünde hem GCC hem de Clang'ı tamamen cüceleyen bir derleyici var: Microsoft Visual C Hem OSX hem de Linux'un masaüstünde yaptıkları yollara rağmen, iOS ve Android'in "çalındığı" pazar payına rağmen uzaklıkta eski geleneksel masaüstü kullanıcılarından Windows hala baskın masaüstü işletim sistemi ve Windows masaüstü C programlarının çoğunluğu muhtemelen Microsoft araçlarını kullanarak derlenmektedir.

Geleneksel olarak, her işletim sistemi satıcısı ve her bir yonga satıcısının kendi derleyicileri vardı. Bir işletim sistemi satıcısı olarak Microsoft, bir işletim sistemi satıcısı ve bir yonga satıcısı olarak Microsoft Visual C'ye sahiptir. IBM, XLC'ye sahiptir (AIX için varsayılan sistem derleyicisi ve hem AIX hem de i / OS'nin derlendiği derleyici) . Intel kendi derleyicisine sahip. Sun / Oracle, Sun Studio'da kendi derleyicisine sahiptir.

Daha sonra, derleyicileri (ve OpenMP kütüphaneleri) numaralandırma için kullanılan PathScale ve The Portland Group gibi yüksek performanslı derleyici satıcıları vardır.

Digital Mars da hala iş başında. Walter Bright'ın (çoğunlukla) üretim kalitesinde bir C ++ derleyicisi oluşturmayı başaran tek kişi olma özelliğine sahip olduğuna inanıyorum.

Son fakat en az değil gömülü mikrodenetleyiciler için tüm özel derleyiciler var. IIRC, her yıl satılan masaüstü, mobil, sunucu, iş istasyonu ve anabilgisayar işlemcilerinden daha fazla mikrodenetleyici var. Yani, bunlar kesinlikle niş ürünler değil .

Onursal bir açıklama, Truva AST'ye gider, JVM'de (!) Çalışan Truffle AST tercüman çerçevesi kullanılarak yazılan JVM (!) Üzerinde çalışan bir C tercümanı (!); Bilgisayar Dilleri Benchmark Oyunu ve mikrobenchmarklarda her ikisinden de daha hızlı. TruffleC kullanarak, Truffle ekibi, Ruby C eklentilerini asıl C Ruby uygulamasından daha hızlı yürütmek için JRuby + Truffle sürümlerini alabildi!

Yani bunlar, C hakkında hiçbir şey bilmeden, kafamın üst kısmından adlandırabileceğim, listelediklerinize ek olarak 6 uygulama.

Kaç tane derleyiciye ihtiyacınız var?

Farklı özellik kümeleri varsa, taşınabilirlik sorunu yaratırsınız. Eğer metalaştırılmışlarsa "varsayılan" ı (GCC, Clang veya VS) seçin. Son% 5 performansa önem veriyorsanız bir kıyaslama yaptınız.

Programlama dili yapıyorsanız eğlence amaçlı veya araştırma amaçlı çalışırsanız, daha modern bir dilde olabilir. Bu nedenle Scheme ve ML için oyuncak derleyicilerin çoğalması. Her ne kadar OCaml oyuncak olmayan akademik olmayan kullanımlar için biraz çekişiyor gibi görünmektedir.

Bunun dile göre çok değiştiğine dikkat edin. Java aslında Sun / Oracle araç zincirine ve GNU'ya sahiptir. Python'un standart yorumlayıcıya kıyasla hiçbirine gerçekten saygı duyulmayan çeşitli derleyicileri vardır. Rust ve Go'nun her biri tam olarak bir uygulamaya sahiptir. C #, Microsoft ve Mono'ya sahiptir.

C / C ++, ortak bir belirtimin 3 ana uygulamasına sahip olması nedeniyle derlenmiş diller arasında benzersizdir.

Çok fazla kullanılmayan herhangi bir şeyi reddetme kuralına göre, derlenmiş her dilin 0'dan 1'e olması gerekir.

Bence javascript 'derlenmiş' olarak belirtmeniz gereken tek neden.

Peki hedef diliniz nedir?

SML derleyicileri genellikle C veya LLVM gibi bir şeyi hedeflemektedir (veya bağlantınızda, JVM veya JavaScript’te görüldüğü gibi).

C'yi derliyorsanız, JVM'ye gideceğiniz için değil. C'den daha kötü bir şeye gideceksin . Ve sonra bu küçük cehennemi, tüm hedef platformlarınız için bir kaç kez çoğaltırsınız.

Ve elbette, C C ++ değil, ama C ++ 'a Scheme'den daha yakın olduğunu söyleyebilirim. Kendi tanımsız davranış kötülük alt kümesi var (Size yerleşik türlerin boyutuna bakıyorum). Ve eğer o minutiyi mahvedersen (ya da "doğru" ama beklenmedik şekilde yaparsan), o zaman onlar için ne kadar korkunç olduğunu söyleyen hayati sistemler üzerinde onlarca yıl var olan kodun vardır. Bir SML derleyici kadar vida varsa, sadece işe yaramaz - ve birisi olabilir dikkat edin. Bir gün.