2012-03-19 12 views
16

フロントエンドとバックエンドに関するコンパイラの構造を理解しています。しかし、なぜコンパイラがフロントエンドとバックエンドに分かれているのかよく分かりません。私にはいくつかの理由を挙げることができますか?なぜなら、ほとんどの書籍/ウェブサイトはあなたのことを教えてくれるからですが、理由を教えてくれないからです!コンパイラ - フロントエンドバックエンド

ありがとうございます。

答えて

7

ソースコードをトークン化し、トークン化されたコードに基づいて実行可能コードを生成するビットであるパー​​サーであるfron-endについて言えば、移植性です。

パーサーを実行可能コード生成から分離することにより、コンパイラーをあるプロセッサー・アーキテクチャーから別のプロセッサー・アーキテクチャーに移植する方がはるかに簡単です。

48

フロントエンドは、言語そのものを処理します。スキャン、解析、解析ツリーです。バックエンドは、対象システムを扱います:オブジェクトコード形式、マシンコードそのもの... 2つのことはお互いにあまり関係がありません。移植可能なコンパイラでは、同じものを使うことが非常に望ましいです複数のバックエンドを持つフロントエンド(ターゲットごとに1つ)。

gccと同じように、フロントエンド/バックエンドのインターフェイスが言語に依存しないので、同じバックエンドでさまざまな言語のフロントエンドを使用できます。昔はこれがMxNの問題と呼ばれていました.M言語とN個のターゲットシステムがあるところでMxNコンパイラを書く必要はありません。この考え方は、M + N個のコンパイラを書くだけです。

+0

M + Nコンパイラはどうですか? ICGに変換するM個のフロントエンドとターゲットマシンコードに変換するN個のコードジェネレータがあると思います。各フロントエンドとバックエンドをコンパイラと考えていますか? – Zephyr

+0

@Zephyr、FE/BEの組み合わせがなければ、不要/扱いにくい多くの順列が必要になります。 –

+0

@ Zephyrはい、フロントエンド/バックエンドの組み合わせはコンパイラです。確かにこれは明らかですか? – EJP

4

内部擬似コードやテーブル/データ構造を使用したいからです。

a = b + c; 

あなたはそれを取って、たとえば、多くのソリューションとして

load b 
load c 
add b + c 
store a 

にそれを壊したくなりますたとえば、あなたは、コードのいくつかの行を持っている場合。内部言語は、いくつかの理由で特定のターゲットのアセンブリにまっすぐ進むよりも優れています。内部言語は、オプティマイザがあれば最適化できるもので、別のプロセッサをターゲットにしたい場合は複数のターゲットで使用するのに十分な汎用性があります。

私はそれについて十分に知っていませんが、私はあなたも共通のパーサーbison/flexを持っていると思います。何らかの中間コード/命令セットに沸かせて、それからバックエンドを書いてください。

たとえば、バックエンドに影響を与えずに、CやC++などの言語フロントエンドを使用することもできます。

また、コンパイラを論理モジュールブロックに分割すると、バックエンドとは独立してフロントエンドを開発してテストすることができます。たとえば中間言語を使ってコードを書いて、バックエンドで複数のターゲットを利用したい場合には、中間言語のエクスポートとインポートが可能です。