コード生成-Cは良いコンパイラバックエンドでしょうか？
this および this のスタックオーバーフローの質問では、コンパイラバックエンドとしてのCは悪い考えであると回答が述べています。
しかし、なぜ？
Cには、大幅に最適化できるコンパイラが多数あります。すべてのプラットフォームには、それをサポートするコンパイラがあり、存在するすべてのアーキテクチャにコンパイルできます。さらに、Nimや [〜＃〜] v [〜＃〜] などの言語は、Cコードの生成をサポートしています。
だから、なぜCが悪い考えなのか、私にはまったくわかりません。私の見解では、それはかなり良い選択のようです。
「良い」と「悪い」バックエンドを定義する
どのような基準に従って、それが良いソリューションか悪いソリューションかを評価しますか？知らないうちに、私たちは客観的な助言よりも主観的な信念を持っています。
- あなたの議論により、Cコンパイラは、移植可能な作業ソリューションを非常に高速に開発するための魅力的な代替手段になります。例：Bjarne StroustrupはC++を発明し、 Cフロントエンド で始まりました。これは約10年間、優れたソリューションであることが証明されました。
- Cを経由するとプロセスが遅くなります。大きなコードを入力として受け取り、さらに大きなコードを出力として書き、Cコンパイラにこの大きなソースを再度処理させるなどです。C++の例を続けるには、超高速を発見したら Zortech C++ コンパイラー、遅いCFrontはすぐにもうあまり良くないように見えました。
- 最後に、言語の近接性にも依存します。一部の構成要素はCでは簡単に表現できず、多くのボイラープレートコードが必要です。これは自然言語の翻訳に似ています。日本語からドイツ語に直接翻訳する場合、日本語から英語に翻訳したり、英語からドイツ語に翻訳したりするよりも正確な結果が得られます。
つまり、普遍的な善悪はありません。
- レポートジェネレータまたは数学シミュレーションエンジンを作成する必要があるだけの場合、中間Cの欠点は利点と比較して無視できます。
- しかし、より真剣な言語設計を行っている場合は、より堅牢なソリューションを採用することをお勧めします。幸いにも、アセンブラー生成を手動で作成する必要はありません。Javaのバイトコード、Pythonのバイトコード、 [〜＃〜] cil [〜＃〜] と他の利用可能な仮想マシンの間で、最適な方法を選択できます実績のある高性能コンパイラーとJITコンパイラーを再利用します。
すべてのプラットフォームには、それをサポートするコンパイラがあり、存在するすべてのアーキテクチャにコンパイルできます。
しかし、それらすべてが同じように動作するわけではありません。コンパイラー作成者として、私のintsが実際に4バイトであるかどうかを判断するために、configureスクリプトに依存する（または作成する）必要はありません。私は、いくつかの未定義の動作のCコンパイラーの実装に依存していたため、いくつかの難解なプラットフォームで奇妙なバグを追いかけたくありません。そして、私は本当にGod-knows-whatによって最適化されたいくつかのCコードのダンプを検査したくありません。
LLVMやその他の一般的なバックエンドターゲットは、コードを書くときに操作するのが少し難しいですが、コードが記述された後はveryそれらがどのように動作するかについて明確であり、（一般的に）コンパイラの開発者が作成することのできる破局の種類をデバッグするための専用ツールがあります。
Cがコンパイラにとって適切なバックエンドではない理由は簡単です。
すべての翻訳は不完全です。
したがって、ソース言語をターゲット言語に完全にマッピングできず、したがってCに非常に類似している場合を除き、翻訳はすべてではないにせよ、偽の制約を追加したり、複雑にしたり、間違ったりします。
コンパイラライターのターゲット言語は、通常、ソース言語のかなりクリーンで効率的なマッピングを可能にするように設計されています。
Cには独自のセマンティクスがあり、それを直接書き込むために作成されたものであり、それ以外の目的のために作成されたわけではありません。