C++ で考える - Vol 1から:
2 番目のパスでは、コード ジェネレーターは解析ツリーを調べて、アセンブリ言語コードまたはツリーのノードのマシン コードを生成します。
少なくとも GCC では、アセンブリ コードを生成するオプションを指定すると、コンパイラはアセンブリ コードを含むファイルを作成することで従います。しかし、オプションを指定せずにコマンドを実行すると、内部でアセンブリ コードが生成されないのでしょうか。gcc
はいの場合、最初にアセンブリ コードを生成し、次にそれを機械語に変換する必要があるのはなぜですか?
アセンブラー段階は、次の 2 つの理由で正当化できます。
その本の第 1 版は 2000 年のものですが、c++ 自体が c に翻訳され、gnu/フリー ソフトウェアのアイデア (コンパイラのソース コードを含む) があまり知られていなかった 90 年代初頭についても語られています。
編集: GCC で使用されるいくつかの無意味な抽象マシン非依存言語の 1 つは、RTL ( Register Transfer Language )です。
それはコンパイラの実装の問題です。アセンブリ コードは、高水準言語 (コンパイルされる言語) と結果のバイナリ出力との間の中間ステップです。一般に、バイナリ コードを直接作成するよりも、最初にアセンブリに変換してからバイナリ コードに変換する方が簡単です。
Gcc は、アセンブリ コードを一時ファイルとして作成し、アセンブラを呼び出します。また、コマンド ラインで何を追加するか、何を追加しないかによって、リンカを呼び出すこともあります。これによりオブジェクトが作成され、バイナリが有効になっている場合、すべての一時ファイルがクリーンアップされます。-save-temps を使用して、実際に何が起こっているかを確認します (多数の一時ファイルがあります)。
オプションなしで gcc を実行すると、asm ファイルが完全に作成されます。
これには「必要性」はありません。単に彼らがたまたまそれを設計した方法です。複数の理由から、コンパイラーを開始する前に、アセンブラーとリンカーがすでに必要/必要になると思います（馬の前にカート、他の言語の前にプロセッサーのasm）。「UNIX の方法」は、ツールやライブラリを再発明するのではなく、上に少しだけ追加することです。そのため、asm に移動して、アセンブラーとリンカーに残りを任せることを意味します。そのように、アセンブラーのジョブの多くを再発明する必要はありません (複数のパス、ラベルの解決など)。開発者にとってはビットより ascii asm をデバッグする方が簡単です。人々は何世代にもわたるコンパイラでこの方法を行ってきました。ジャスト イン タイム コンパイラは、この習慣の主な例外です。定義上、マシン コードにアクセスできる必要があるため、実行または実行できます。