19

私は自分のおもちゃのプログラミング言語に取り組んでいます。今のところ、私は AST からソース言語を解釈しています。バイトコードにコンパイルしてからそれを解釈すると、どのような利点が得られるのか疑問に思っています。

今のところ、次の3つのことを念頭に置いています。

  • 特に配列が O(1) ランダム アクセス (つまり、10 個の命令を上下にジャンプ) をサポートしている場合、構文ツリーを何百回もトラバースすると、配列内の命令を実行するよりも遅くなる可能性があります。
  • 型付けされた実行環境では、AST が型付けされているため、ランタイム コストが発生します。また、AST を常にトラバースしているためです (つまり、10 種類のノードがあり、現在実行している型を確認する必要があります)。型のないバイトコードにコンパイルすると、型のチェックとコンパイルの後、型のない値とコードになるため、これを改善するのに役立つかもしれません。
  • バイトコードにコンパイルすると、移植性が向上する場合があります。

私のポイントは正しいですか？バイトコードへのコンパイルの背後にある他の動機は何ですか?

4

2 に答える 2

11

主な理由は速度です。AST の解釈は実際には遅すぎます。

バイトコードを使用するもう 1 つの理由は、簡単にシリアル化 (ディスクに格納) できるため、配布できるからです。これが Java の機能です。

于 2012-07-11T13:22:15.203 に答える
9

バイトコード (またはスレッド化されたコードなどの他の「解釈しやすい」形式) を生成するポイントは、基本的にパフォーマンスです。

AST インタプリタが次に何をすべきかを決定するには、ツリーをトラバースし、ノードを検査し、ノードのタイプを決定し、オペランドのタイプをチェックし、正当性を検証し、AST 指定演算子のどの特殊なケースが適用されるかを決定する必要があります ( 「+」と表示されますが、16 ビットの加算または文字列の連結を意味しますか?)、最終的に何らかのアクションを実行する前に。

最終的なアクションを実行し、ある種の簡単に解釈できる構造を生成すると、「実行」時に、インタープリターはそのすべてのチェック/特別なケースの決定なしで、単にアクションの実行に集中できます。

もう 1 つの最近の言い訳は、多数のよく知られた仮想マシン (JVM、MSIL、Parrot など) のいずれかのバイト コードを生成する場合、インタープリターをコーディングする必要さえないということです。JVM と MSIL については、それらに関連付けられた JIT コンパイラの利点も得られます。また、言語を慎重に設計することで、Java と C# の真の魅力である巨大なライブラリとの互換性も得られます。

于 2012-07-15T22:40:47.760 に答える