Hari ini, Anda memerlukan C compiler nyata untuk menjadi compiler mengoptimalkan , terutama karena C tidak lagi menjadi bahasa dekat dengan hardware, karena saat ini prosesor yang sangat kompleks ( out-of-order , pipelined , superscalar , dengan kompleks cache & TLB , karenanya perlu penjadwalan instruksi , dll ...). Prosesor x86 saat ini tidak seperti prosesor i386 abad sebelumnya, meskipun keduanya mampu menjalankan kode mesin yang sama. Lihat C bukan bahasa tingkat rendah (Komputer Anda bukan PDP-11 cepat) karya David Chisnall.
Hanya sedikit orang yang menggunakan kompiler C non-optimisif yang naif seperti tinycc atau nwcc , karena mereka menghasilkan kode yang beberapa kali lebih lambat daripada yang diberikan oleh kompiler optimisasi.
Pengkodean kompiler pengoptimalisasi sulit. Perhatikan bahwa baik GCC dan Dentang mengoptimalkan beberapa representasi kode "sumber bahasa-netral" (Gimple untuk GCC, LLVM untuk Dentang). Kompleksitas kompiler C yang baik tidak dalam fase parsing!
Secara khusus, membuat kompiler C ++ tidak jauh lebih sulit daripada membuat kompiler C: parsing C ++ dan mengubahnya menjadi beberapa representasi kode internal yang kompleks (karena spesifikasi C ++ kompleks), tetapi dipahami dengan baik, tetapi bagian optimasinya bahkan lebih kompleks (di dalam GCC: optimisasi ujung-tengah, bahasa sumber dan prosesor target netral, membentuk mayoritas dari kompiler, dengan sisanya diseimbangkan antara ujung depan untuk beberapa bahasa dan ujung belakang untuk beberapa prosesor). Karenanya sebagian besar kompiler C yang mengoptimalkan juga dapat mengkompilasi beberapa bahasa lain, seperti C ++, Fortran, D, ... Bagian spesifik C ++ dari GCC adalah sekitar 20% dari kompiler ...
Juga, C (atau C ++) sangat banyak digunakan sehingga orang berharap kode mereka dapat dikompilasi bahkan ketika itu tidak benar-benar mengikuti standar resmi, yang tidak mendefinisikan secara tepat semantik bahasa (sehingga setiap kompiler dapat memiliki interpretasinya sendiri. itu). Lihatlah juga ke CompCert terbukti C compiler, dan Frama-C analyzer statis, yang peduli lebih formal semantik dari C.
Dan optimisasi adalah fenomena panjang : menerapkan beberapa optimasi sederhana itu mudah, tetapi mereka tidak akan membuat kompiler kompetitif! Anda perlu menerapkan banyak optimasi berbeda, dan untuk mengatur dan menggabungkannya dengan cerdas, untuk mendapatkan kompiler dunia nyata yang kompetitif. Dengan kata lain, kompiler yang mengoptimalkan dunia nyata harus menjadi perangkat lunak yang kompleks. BTW, baik GCC dan Dentang / LLVM memiliki beberapa generator kode khusus C / C ++ internal. Dan keduanya adalah binatang buas besar (beberapa juta baris kode sumber, dengan tingkat pertumbuhan beberapa persen setiap tahun) dengan komunitas pengembang besar (beberapa ratus orang, sebagian besar bekerja penuh waktu, atau setidaknya setengah waktu).
Perhatikan bahwa tidak ada (setahu saya) compiler C multi-threaded, bahkan jika beberapa bagian dari kompiler dapat dijalankan secara paralel (misalnya optimasi intra-prosedural, alokasi register, penjadwalan instruksi ...). Dan build paralel dengan make -jtidak selalu cukup (terutama dengan KPP ).
Juga, sulit untuk mendapatkan dana pada pengkodean kompiler C dari awal, dan upaya seperti itu perlu berlangsung beberapa tahun. Akhirnya, sebagian besar kompiler C atau C ++ adalah perangkat lunak gratis saat ini (tidak ada lagi pasar untuk kompiler eksklusif yang dijual oleh startup) atau setidaknya adalah komoditas monopolistik (seperti Microsoft Visual C ++ ), dan menjadi perangkat lunak bebas hampir diperlukan untuk kompiler ( karena mereka memerlukan kontribusi dari berbagai organisasi).
Saya akan senang mendapatkan dana untuk bekerja pada kompiler C dari awal sebagai perangkat lunak bebas, tetapi saya tidak cukup naif untuk percaya bahwa itu mungkin hari ini!