Perché ci sono così pochi compilatori C?

C è una delle lingue più utilizzate al mondo. Rappresenta un'enorme percentuale del codice esistente e continua ad essere utilizzato per una grande quantità di nuovo codice. È amato dai suoi utenti, è così ampiamente portato che essere in grado di eseguire C è per molti la definizione informale di una piattaforma ed è elogiato dai suoi fan per essere un "piccolo" linguaggio con un set relativamente pulito di funzionalità.

Quindi dove sono tutti i compilatori?

Sul desktop, ce ne sono (realisticamente) due : GCC e Clang. Pensandoci per qualche secondo probabilmente ti ricorderai che esiste anche Intel. Ce ne sono una manciata di altri, troppo oscuri per essere nominati dalla persona media e quasi universalmente non si preoccupano di supportare una versione linguistica recente (o spesso anche un sottoinsieme di lingue ben definito, solo "un sottoinsieme"). La metà dei membri di questo elenco sono note storiche; la maggior parte degli altri è molto specializzata e non implementa ancora il linguaggio completo. Pochissimi in realtà sembrano essere open-source.

Scheme and Forth - altre piccole lingue che sono amate dai loro fan per questo - probabilmente hanno più compilatori rispetto agli utenti reali. Anche qualcosa come SML ha implementazioni più "serie" tra cui scegliere rispetto a C. Considerando che l'annuncio di un nuovo compilatore C (incompiuto) che mira alla verifica in realtà vede alcune risposte piuttosto negative, e le implementazioni veterane fanno fatica a ottenere abbastanza collaboratori da raggiungere C99.

Perché? L'implementazione di C è così difficile? Non è C ++. Gli utenti hanno semplicemente un'idea molto distorta di quale gruppo di complessità rientra (ovvero che in realtà è più vicino al C ++ rispetto allo Schema)?

Oggi, è necessario un vero compilatore C per essere un compilatore ottimizzante , in particolare perché C non è più un linguaggio vicino all'hardware, poiché i processori attuali sono incredibilmente complessi ( fuori servizio , pipeline , superscalari , con cache complesse e TLB , quindi necessita di programmazione delle istruzioni , ecc ...). I processori x86 di oggi non sono come i processori i386 del secolo precedente, anche se entrambi sono in grado di eseguire lo stesso codice macchina. Vedi che la C non è un linguaggio di basso livello (Il tuo computer non è un PDP-11 veloce) di David Chisnall.

Poche persone usano ingenui compilatori C non ottimizzanti come tinycc o nwcc , poiché producono codice che è molte volte più lento di quello che l'ottimizzazione dei compilatori può dare.

Codificare un compilatore ottimizzante è difficile. Si noti che sia GCC che Clang stanno ottimizzando alcune rappresentazioni di codice "neutre dal linguaggio di origine" (Gimple per GCC, LLVM per Clang). La complessità di un buon compilatore C non è nella fase di analisi!

In particolare, la creazione di un compilatore C ++ non è molto più difficile della creazione di un compilatore C: l'analisi del C ++ e la sua trasformazione in una rappresentazione del codice interno è complessa (perché la specifica C ++ è complessa), ma è ben compresa, ma le parti di ottimizzazione sono ancora di più complesso (all'interno di GCC: le ottimizzazioni di fascia media, neutre nella lingua di origine e nel processore di destinazione, formano la maggior parte del compilatore, con il resto bilanciato tra front-end per diverse lingue e back-end per diversi processori). Quindi la maggior parte dei compilatori C ottimizzanti sono anche in grado di compilare alcuni altri linguaggi, come C ++, Fortran, D, ... Le parti specifiche di C ++ di GCC sono circa il 20% del compilatore ...

Inoltre, C (o C ++) è così ampiamente usato che le persone si aspettano che il loro codice sia compilabile anche quando non segue esattamente gli standard ufficiali, che non definiscono abbastanza precisamente la semantica del linguaggio (quindi ogni compilatore può avere una propria interpretazione di esso). Guarda anche il compiler C comprovato CompCert e l' analizzatore statico Frama-C , che si preoccupano della semantica più formale di C.

E le ottimizzazioni sono un fenomeno long tail : implementare alcune semplici ottimizzazioni è facile, ma non renderanno competitivo un compilatore! È necessario implementare molte ottimizzazioni diverse e organizzarle e combinarle in modo intelligente per ottenere un compilatore del mondo reale competitivo. In altre parole, un compilatore per l'ottimizzazione del mondo reale deve essere un software complesso. A proposito, sia GCC che Clang / LLVM hanno diversi generatori di codice interni C / C ++ specializzati. Ed entrambi sono bestie enormi (diversi milioni di righe di codice sorgente, con un tasso di crescita di diversi percento ogni anno) con una grande comunità di sviluppatori (poche centinaia di persone, che lavorano principalmente a tempo pieno o almeno a metà tempo).

Si noti che non esiste un compilatore C multi-thread (per quanto ne so), anche se alcune parti di un compilatore potrebbero essere eseguite in parallelo (ad es. Ottimizzazione intra-procedurale, allocazione dei registri, pianificazione delle istruzioni ...). E la costruzione parallela con make -jnon è sempre abbastanza (specialmente con LTO ).

Inoltre, è difficile ottenere finanziamenti per la codifica di un compilatore C da zero, e tale sforzo deve durare diversi anni. Infine, oggi la maggior parte dei compilatori C o C ++ sono software gratuiti (non esiste più un mercato per i nuovi compilatori proprietari venduti dalle startup) o almeno sono prodotti monopolistici (come Microsoft Visual C ++ ), ed è quasi necessario essere un software gratuito per i compilatori ( perché hanno bisogno di contributi da molte organizzazioni diverse).

Sarei felice di ottenere finanziamenti per lavorare da zero su un compilatore C come software libero, ma non sono abbastanza ingenuo da credere che sia possibile oggi!

Vorrei contestare la vostra ipotesi di base che ci sono solo un numero limitato di implementazioni in C.

Non conosco nemmeno C, non uso C, non sono un membro della comunità C, eppure conosco molto di più dei pochi compilatori che hai citato.

Innanzitutto, c'è il compilatore che probabilmente ridimensiona completamente sia GCC che Clang sul desktop: Microsoft Visual C. Nonostante gli ostacoli che OSX e Linux hanno fatto sul desktop, e la condivisione di mercato che iOS e Android hanno "rubato" lontano dagli ex utenti desktop tradizionali, Windows è ancora il sistema operativo desktop dominante e la maggior parte dei programmi desktop C di Windows è probabilmente compilata utilizzando strumenti Microsoft.

Tradizionalmente, ogni fornitore di sistemi operativi e ogni fornitore di chip aveva i propri compilatori. Microsoft, come fornitore del sistema operativo, dispone di Microsoft Visual C. IBM, sia come fornitore del sistema operativo sia come fornitore di chip, ha XLC (che è il compilatore di sistema predefinito per AIX e il compilatore con cui vengono compilati sia AIX che i / OS) . Intel ha il proprio compilatore. Sun / Oracle hanno il proprio compilatore in Sun Studio.

Quindi, ci sono i fornitori di compilatori ad alte prestazioni come PathScale e The Portland Group, i cui compilatori (e librerie OpenMP) vengono utilizzati per lo scricchiolio dei numeri.

Anche Digital Mars è ancora in attività. Credo che Walter Bright abbia l'eccezionale distinzione di essere l'unica persona al mondo che è riuscita a creare da solo un compilatore C ++ di qualità di produzione.

Ultimo ma non meno importante, abbiamo tutti i compilatori proprietari per microcontrollori incorporati. IIRC, ogni anno vengono venduti più microcontrollori rispetto a CPU desktop, mobili, server, workstation e mainframe vendute nell'intera storia dell'informatica combinata. Quindi, questi sono sicuramente non prodotti di nicchia.

Una menzione d'onore va a TruffleC , un interprete C (!) In esecuzione su JVM (!) Scritto usando il framework di interpreti Truffle AST che è solo il 7% più lento di GCC e Clang (qualunque sia il più veloce su qualsiasi dato benchmark) in tutto il Computer Language Benchmark Game, e più veloce di entrambi sui microbenchmark. Utilizzando TruffleC, il team Truffle è stato in grado di ottenere la propria versione di JRuby + Truffle per eseguire le estensioni di Ruby C più velocemente dell'attuale implementazione di C Ruby!

Quindi, queste sono 6 implementazioni in aggiunta a quelle che hai elencato che posso nominare in cima alla mia testa, senza nemmeno sapere nulla di C.

Di quanti compilatori hai bisogno?

Se hanno diversi set di funzionalità, si crea un problema di portabilità. Se sono mercificati, scegli "default" (GCC, Clang o VS). Se ti interessa l'ultima performance del 5%, hai un benchmark-off.

Se stai facendo un lavoro di linguaggio di programmazione per scopi ricreativi o per scopi di ricerca, è probabile che sia in un linguaggio più moderno. Da qui la proliferazione di compilatori di giocattoli per Scheme e ML. Sebbene OCaml stia ottenendo una certa trazione per usi non accademici non giocattolo.

Nota che questo varia molto in base alla lingua. Java ha essenzialmente la toolchain Sun / Oracle e quella GNU. Python ha vari compilatori nessuno dei quali è veramente rispettato rispetto all'interprete standard. Rust e Go hanno esattamente un'implementazione ciascuno. C # ha Microsoft e Mono.

C / C ++ è unico tra i linguaggi compilati in quanto ha 3 importanti implementazioni di una specifica comune.

Seguendo la regola di respingere tutto ciò che non è molto usato, ogni altra lingua compilata ha 0 a 1.

E penso che JavaScript sia l'unico motivo per cui devi specificare "compilato".

Qual è la tua lingua di destinazione?

I compilatori SML hanno spesso come target C o qualcosa di simile a LLVM (o come si vede nel tuo link, JVM o JavaScript).

Se stai compilando C, non è perché stai andando alla JVM. Stai andando a qualcosa di peggio di C. Molto peggio. E poi puoi duplicare quel piccolo inferno un sacco di volte per tutte le tue piattaforme target.

E certo, C non è C ++, ma direi che è più vicino a C ++ che a Scheme. Ha un suo sottoinsieme di malvagità comportamentale indefinita (sto osservando le dimensioni dei tipi incorporati). E se rovini quelle minuzie (o lo fai "correttamente" ma inaspettatamente) allora hai decenni di codice esistente su sistemi vitali che ti diranno quanto sei terribile. Se rovini un compilatore SML, semplicemente non funzionerà e qualcuno potrebbe accorgersene. Un giorno.