Cコンパイラがそれほど少ないのはなぜですか？

Cは、世界で最も広く使用されている言語の1つです。既存のコードの大部分を占め、膨大な量の新しいコードに引き続き使用されます。ユーザーに愛されており、非常に広く移植されているため、Cを実行できることはプラットフォームの非公式な定義の多くに当てはまります。

それでは、すべてのコンパイラはどこにありますか？

デスクトップには、（現実的に）GCCとClangの2つがあります。数秒間考えてみれば、おそらくインテルも存在していることを覚えているでしょう。他の人はほんの一握りで、平均的な人が名前を付けるにはあまりにもあいまいで、ほとんどの場合、最近の言語バージョン（またはよく定義された言語サブセット、単に「サブセット」）をサポートすることをほとんど気にしません。このリストのメンバーの半分は歴史的な脚注です。残りのほとんどは非常に特殊化されており、実際には完全な言語を実装していません。実際にオープンソースであると思われるものはほとんどありません。

SchemeとForth-ファンに愛されている他の小さな言語-はおそらく実際のユーザーよりも多くのコンパイラを持っています。SMLのようなものでも、Cよりも「深刻な」実装を選択できます。一方、検証を目的とする新しい（未完成の）Cコンパイラの発表では、実際にかなり否定的な応答が見られ、ベテランの実装は、 C99。

どうして？Cの実装はとても難しいですか？C ++ではありません。ユーザーは、それがどの複雑なグループに属するかについて非常に歪んだ考えを持っているだけですか（つまり、実際にはSchemeよりもC ++に近いということですか）。

今日は、あなたがする実際のCコンパイラを必要とする最適化コンパイラ、特にCは、ハードウェアに近い言語は、もはやであるため、現在のためのプロセッサは（信じられないほど複雑なアウトオブオーダー、パイプライン化、スーパースカラ、複雑でキャッシュ＆TLB、したがって、命令のスケジューリングなどが必要です）。現在のx86プロセッサは、両方が同じマシンコードを実行できる場合でも、前世紀のi386プロセッサとは異なります。Cは低レベルの言語ではない（お使いのコンピューターは高速なPDP-11ではない） David Chisnallによる論文をご覧ください。

tinyccやnwccのような素朴な非最適化Cコンパイラを使用している人はほとんどいません。最適化コンパイラが提供するコードよりも数倍遅いコードを生成するためです。

最適化コンパイラのコーディングは困難です。GCCとClangの両方が、「ソース言語に依存しない」コード表現（GCCのGimple、ClangのLLVM）を最適化していることに注意してください。優れたCコンパイラの複雑さは、解析段階ではありません！

特に、C ++コンパイラを作成することは、Cコンパイラを作成することほど難しくありません：C ++を解析して内部コード表現に変換することは複雑です（C ++仕様が複雑なため）が、よく理解されていますが、最適化の部分はさらに複雑です複雑（GCCの内部：ミドルエンド最適化、ソース言語およびターゲットプロセッサニュートラルがコンパイラの大部分を構成し、残りは複数の言語のフロントエンドと複数のプロセッサのバックエンドでバランスが取れています）。したがって、ほとんどの最適化Cコンパイラは、C ++、Fortran、Dなどの他の言語もコンパイルできます。GCCのC ++固有の部分は、コンパイラの約20％です。

また、C（またはC ++）は非常に広く使用されているため、言語のセマンティクスを十分に正確に定義していない公式の標準に正確に準拠していない場合でも、コードがコンパイル可能であると人々は期待しています（したがって、各コンパイラーは独自の解釈を持つことができます）それの）。CompCertで実証されたCコンパイラーとFrama -C静的アナライザーも調べてください。これらは、Cのより正式なセマンティクスに注意を払っています。

そして、最適化はロングテールの現象です。いくつかの簡単な最適化を実装するのは簡単ですが、コンパイラの競争力を高めることはありません！多くの異なる最適化を実装し、それらを巧みに編成および結合して、競争力のある実際のコンパイラを取得する必要があります。つまり、実際の最適化コンパイラは複雑なソフトウェアでなければなりません。ところで、GCCとClang / LLVMの両方には、いくつかの内部に特化したC / C ++コードジェネレーターがあります。そして、両方とも巨大な獣（毎年数パーセントの成長率を持つ数百万のソースコード行）であり、大規模な開発者コミュニティ（数百人、ほとんどがフルタイム、または少なくともハーフタイム）を持っています。

コンパイラの一部が並行して実行できたとしても（私の知る限り）、マルチスレッドCコンパイラはありません（プロシージャ内最適化、レジスタ割り当て、命令スケジューリングなど）。また、（特にLTOを使用した）並列ビルドでは必ずしも十分ではありません。make -j

また、Cコンパイラをゼロからコーディングするための資金を得るのは難しく、そのような努力は数年続く必要があります。最後に、ほとんどのCまたはC ++コンパイラは今日のフリーソフトウェアです（スタートアップが販売する新しいプロプライエタリコンパイラの市場はもはやありません）、または少なくとも独占的な商品（Microsoft Visual C ++など）であり、コンパイラにはフリーソフトウェアであることがほぼ必要です（多くの異なる組織からの貢献が必要だからです）。

フリーのソフトウェアとしてCコンパイラをゼロから開発するための資金を得ることができればうれしいですが、それが今日可能であると信じるほど素朴ではありません！

Cの実装はごく少数であるという根本的な仮定に異議を唱えたいと思います。

私もCを知らず、Cを使用せず、Cコミュニティのメンバーでもありませんが、あなたが言及した少数のコンパイラよりもはるかに多くを知っています。

何よりもまず、おそらくデスクトップ上のGCCとClangの両方を完全にd小化するコンパイラがあります。MicrosoftVisualC。離れた旧従来のデスクトップユーザーから、Windowsはまだ支配的なデスクトップOS、およびWindowsデスクトップのCプログラムの大半は、おそらく、Microsoftのツールを使用してコンパイルされています。

従来、すべてのOSベンダーとすべてのチップベンダーには、独自のコンパイラがありました。Microsoftは、OSベンダーとしてMicrosoft Visual Cを持っています。IBMは、OSベンダーとチップベンダーの両方として、XLC（AIXのデフォルトシステムコンパイラであり、AIXとi / OSの両方をコンパイルするコンパイラ）を持っています。Intelには独自のコンパイラがあります。Sun / Oracleには、Sun Studioに独自のコンパイラがあります。

次に、PathScaleやThe Portland Groupなどの高性能コンパイラベンダーがあります。これらのコンパイラ（およびOpenMPライブラリ）は、数値演算に使用されます。

デジタルマーズもまだビジネスにあります。Walter Brightには、地球上で（ほとんど）自分でプロダクション品質のC ++コンパイラを作成した唯一の人物であるというユニークな区別があると思います。

最後になりましたが、組み込みマイクロコントローラー用の独自のコンパイラーがすべて揃っています。IIRCでは、コンピューティングの歴史全体でデスクトップ、モバイル、サーバー、ワークステーション、およびメインフレームのCPUが販売されているよりも、毎年多くのマイクロコントローラーが販売されています。したがって、これらは決してニッチ製品ではありません。

名誉言及はに外に出るTruffleC、Cのインタプリタ（！）JVM上で実行されている（！）を越え（任意の特定のベンチマークで最速の方）GCCとクランよりもわずか7％遅いトリュフASTインタプリタのフレームワークを使って書かれましたコンピュータ言語のベンチマークゲームであり、マイクロベンチマークの両方よりも高速です。TruffleCを使用して、Truffleチームは、JRuby + Truffleのバージョンを取得して、実際のC Ruby実装よりも速くRuby C拡張を実行することができました！

だから、これらはあなたがリストしたものに加えて6つの実装であり、Cについて何も知らなくても頭の中で名前を付けることができます。

コンパイラーはいくつ必要ですか？

異なる機能セットがある場合、移植性の問題が発生します。商品化されている場合は、「デフォルト」（GCC、Clang、またはVS）のいずれかを選択します。最後の5％のパフォーマンスに関心がある場合は、ベンチマークオフがあります。

レクリエーションや研究目的でプログラミング言語の仕事をしている場合は、より現代的な言語である可能性があります。したがって、SchemeおよびML用のおもちゃコンパイラの急増。OCamlは、玩具ではなく、アカデミック以外の用途でも牽引力を得ているようです。

これは言語によって大きく異なることに注意してください。Javaには、基本的にSun / OracleツールチェーンとGNUツールチェーンがあります。Pythonにはさまざまなコンパイラがあり、標準のインタプリタと比べてどれも本当に尊重されていません。RustとGoにはそれぞれ1つの実装があります。C＃にはMicrosoftとMonoがあります。

C / C ++は、共通の仕様の3つの主要な実装を備えているという点で、コンパイルされた言語の中でも独特です。

あまり使用されないものはすべて却下するという規則に従って、コンパイルされた他のすべての言語には0〜1があります。

そして、「コンパイル済み」を指定する必要があるのはjavascriptだけだと思います。

では、ターゲット言語は何ですか？

SMLコンパイラは多くの場合、CまたはLLVMのようなもの（または、リンク、JVMまたはJavaScriptに見られる）をターゲットとしています。

Cをコンパイルしているのは、JVMに行くからではありません。あなたはCより悪いものに行くでしょう。はるかに悪い。そして、すべてのターゲットプラットフォームで、そのマイナーな地獄を何度も複製することになります。

確かに、CはC ++ではありませんが、SchemeよりもC ++に近いと言えます。それは未定義の振る舞いの悪の独自のサブセットを持っています（組み込み型のサイズを見ています）。そして、その特徴を台無しにした場合（または「正しく」予期せずにそれを行った場合）、あなたはあなたがどれほどひどいかを教えてくれる重要なシステム上に何十年もの既存のコードを持っています。SMLコンパイラを台無しにすると、動作しなくなります-誰かが気づくかもしれません。いつか。