タグ付けされた質問 「interpreters」

従来のインタープリター、JITコンパイラー、JITインタープリター、AOTコンパイラーの違いを理解しようとしています。 インタープリターは、何らかのコンピューター言語で命令を実行する単なるマシン（仮想または物理）です。その意味で、JVMはインタープリターであり、物理CPUはインタープリターです。 Ahead-of-Timeコンパイルとは、コードを実行（解釈）する前に特定の言語にコンパイルすることを意味します。 ただし、JITコンパイラーとJITインタープリターの正確な定義についてはわかりません。 私が読んだ定義によると、JITコンパイルとは、コードを解釈する直前にコンパイルすることです。 それで、基本的に、JITコンパイルはAOTコンパイルであり、実行（解釈）の直前に行われますか？ そして、JITインタープリターは、JITコンパイラーとインタープリターの両方を含み、解釈する直前にコードをコンパイルする（JITする）プログラムですか？ 違いを明確にしてください。

130 interpreters  jit  compilation 

これは、インタープリターおよびコンパイルされた言語について読んでいたときの不思議です。 ソースコードは実行時にインタープリターによって処理されるため、Rubyは間違いなくインタープリター言語です。 それどころか、Cはコンパイルされた言語であり、マシンに応じて最初にソースコードをコンパイルしてから実行する必要があります。これにより、実行速度が大幅に向上します。 Pythonに来ました： Pythonコード（somefile.py）をインポートすると、同じディレクトリにファイル（somefile.pyc）が作成されます。インポートはpythonシェルまたはdjangoモジュールで行われるとしましょう。インポート後、コードを少し変更し、インポートされた関数を再度実行して、まだ古いコードが実行されていることを確認します。これは、*。pycファイルはCファイルのコンパイル後に作成された実行可能ファイルに似たコンパイル済みのpythonファイルですが、*。pycファイルを直接実行することはできません。 pythonファイル（somefile.py）が直接実行された場合（./somefile.pyまたはpython somefile.py）、. pycファイルは作成されず、コードは解釈された動作を示すように実行されます。 これらは、Pythonコードが新しいプロセスにインポートされるたびにコンパイルされ、直接実行されたときに解釈されながら.pycを作成することを示唆しています。 それで、どのタイプの言語と考えるべきですか？解釈またはコンパイル？そして、その効率は、インタープリター言語およびコンパイル言語と比較してどうですか？ wikiの解釈言語ページによると、それは仮想マシンコードにコンパイルされた言語としてリストされていますが、それはどういう意味ですか？

76 programming-languages  python  compiler  efficiency  interpreters 

最初のコンパイラは1952年にグレース・ホッパーによって書かれ、Lispインタプリタは1958年にジョン・マッカーシーの学生スティーブ・ラッセルによって書かれました。コンパイラを書くことは、インタプリタよりもはるかに難しい問題のようです。もしそうなら、最初のコンパイラが最初のインタプリタの6年前に書かれたのはなぜですか？

72 history  compiler  interpreters 

企業が使用すべき推奨事項に到達するために、2つのテクノロジーを比較しています。テクノロジーBのコードがマシンコードにコンパイルされる間、テクノロジーAのコードは解釈されます。私の比較では、通訳プロセスの追加のオーバーヘッドがないため、一般にTech Bはより良いパフォーマンスを発揮すると述べています。また、プログラムはさまざまな方法で作成できるため、技術Aで作成されたプログラムは技術Bで作成されたプログラムよりも優れている可能性があると述べています。 レビューのためにこのレポートを提出したとき、レビュー担当者は、一般に解釈プロセスのオーバーヘッドがTech Bのパフォーマンスが優れていると結論付けるのに十分な大きさになる明確な理由はないと述べました。 だから私の質問は、コンパイル/解釈されたテクノロジーのパフォーマンスについて何か言うことができますか？コンパイルされたものが一般的に解釈されたものよりも速いと言える場合、どうすればレビュー担当者に私のポイントを納得させることができますか？

60 programming-languages  performance  compiler  interpreters 

コンパイラーとインタープリターのトピックを集中的に研究しています。基本的な理解が正しいかどうかを確認したいので、次のことを想定しましょう。 「Foobish」という言語があり、そのキーワードは <OUTPUT> 'TEXT', <Number_of_Repeats>; したがって、コンソールに10回印刷する場合は、次のように記述します。 OUTPUT 'Hello World', 10; こんにちはWorld.foobish-file。 次に、選択した言語（この場合はC＃）でインタープリターを作成します。 using System; namespace FoobishInterpreter { internal class Program { private static void Main(string[] args) { analyseAndTokenize(Hello World.foobish-file)//Pseudocode int repeats = Token[1]; string outputString = Token[0]; for (var i = 0; i < repeats; i++) { Console.WriteLine(outputString); } } …

42 compiler  interpreters 

私は、特にlispで書かれたLispインタープリターを研究することを志望するプログラマーに求める新しいプログラマーのための多くのCSカリキュラムと学習提案を見てきました。これらのサイトはすべて、「その知的な啓示」、「すべての真面目なプログラマーが持つべき啓発体験」、「ハードウェアとソフトウェアの関係を示す」、その他の曖昧な声明、特にこの記事からこの評判の高いハウツー。 私の質問の一般的な感情は、Lispが上記の目標をどのように達成し、なぜLispを達成するのかということです。他の言語はなぜですか？ Schemeでスキームインタプリタの記述を終えたばかりなので（SICP http://mitpress.mit.edu/sicp/から取得）、現在スキームでPythonインタプリタを記述しており、この伝説的なエピファニーを得るのに苦労しているため、これを求めています。それは前者から具体的に来ることになっています。プログラムの仕組みを理解するために、スキームインタープリターで活用できる2つの言語間の特定の技術的な詳細を探しています。 すなわち： 解釈する言語で書かれた通訳者の研究が強調されているのはなぜですか？元の言語と構築された言語をまっすぐに保つのは単に素晴らしい精神的な運動ですか、それともその性質でしか解決できない特定の問題がありますか？元の言語？ Lispインタプリタは、将来のソフトウェア設計のために優れたアーキテクチャの概念をどのように実証しますか？ この演習をC ++やJavaなどの別の言語で行った場合、何が恋しいですか？ 何が最も使用され、この運動からテイクアウトや「精神的なツールが」？** ** このエクササイズから、他のどのツールよりも頭の中で解析ツールを設計するスキルが得られていることに気付いたので、答えを選択しました。スキームに適した異なる解析方法を見つけたいと思います。 Pythonインタープリターよりもインタープリター。

30 self-improvement  language-design  lisp  language-features  interpreters 

ここでは、インタプリタ言語とコンパイル言語の実装について多くの質問があります。区別が実際に意味をなすかどうか疑問に思っています。（実際には、質問は通常言語に関するものですが、それらの言語の最も一般的な実装について本当に考えています）。 現在、厳密に解釈される実装はほとんどありません。つまり、コードを一度に1行ずつ解析して実行する人はほとんどいません。さらに、マシンコードにコンパイルする実装も一般的ではなくなりました。ますます、コンパイラはある種の仮想マシンをターゲットにしています。 実際、ほとんどの実装は同じ基本戦略に集中しています。コンパイラーは、JITを介してネイティブコードに解釈またはコンパイルされるバイトコードを生成します。コンパイルと解釈の伝統的なアイデアのミックスです。 したがって、私は尋ねます：最近、解釈された実装とコンパイルされた実装の間に便利な区別はありますか？

29 programming-languages  compiler  interpreters 

コンパイラの作業が本質的にソースコードをマシンレベルのコードに変換することである場合、コンパイラに不具合、つまり障害のある「翻訳」が存在する可能性があります 通訳についても同じことが言えます。必要なコンテンツを出力できない場合がありますか？ コンパイラ/インタープリターのバグを聞いたことはありませんが、存在しますか？

28 compiler  bug  interpreters 

私はPythonをよく知りません。動的言語（Python、Lua、Scheme、Perl、Rubyなど）の正確な機能が実装を強制的に遅らせていることを、より正確に理解しようとしています。 その一例として、Lua 5.3 メタテーブル機構は直感的にLuaを非常に遅くしますが、実際にはLuaは非常に高速（およびPythonよりも高速）であると噂されています。 また、私は現在のプロセッサ上のため、メモリがはるかに遅い生の計算よりであることを直感（おそらく間違ったものを）持っているラà、動的な型チェック（（キャッシュミスでメモリアクセスが算術演算の何百ものと同じ時間が必要）if (value->type != INTEGER_TAG) return;でCの用語）は非常に高速に実行できます。 もちろん、プログラム全体の分析（スターリンスキームの実装のように）は、翻訳者が高速で実行されるため、動的言語の実装を行うことができますが、最初はプログラムアナライザー全体を設計する時間がないふりをしましょう。 （私はMELTモニターで動的言語を設計するようなもので、その一部はCに翻訳されます）

26 python  performance  compiler  dynamic-typing  interpreters 

私が理解しているように、コンパイルされた言語とpythonの速度の違いの原因は、最初のコードがネイティブマシンのコードまですべてコンパイルされるのに対し、pythonはPVMによって解釈されるpythonバイトコードにコンパイルされることです。この方法でPythonコードを複数のオペレーティングシステムで使用できることがわかります（少なくともほとんどの場合）が、理解できない、なぜ従来のコンパイラと同じ方法でコンパイルするPython用の追加の（オプションの）コンパイラがないのかわかりません。これはプログラマーに選択を任せることになり、それは彼らにとってより重要です。ネイティブマシンでのマルチプラットフォームの実行可能性またはパフォーマンス。一般に; コンパイルされたものと解釈されたものの両方として振る舞うことができる言語がないのはなぜですか？

25 python  compiler  interpreters 

私はコンパイルと解釈を理解しようと、段階的に全体像を把握しようとしています。だから、この記事を読んでいる間に質問に思いついた。http://www.cs.man.ac.uk/~pjj/farrell/comp3.htmlこの記事 それは言います： コンパイラの次の段階は、パーサーと呼ばれます。コンパイラのこの部分は、言語の文法を理解しています。構文エラーを特定し、エラーのないプログラムを別の言語で解釈または書き出すことができる内部データ構造に変換する責任があります。 しかし、トークナイザーが構文エラーのある特定のストリームを適切にトークン化する方法を理解できませんでした。 そこにとどまるか、パーサーに間違った情報を提供する必要があります。トークン化は一種の翻訳者でもないのですか？ したがって、トークン化中にコードの字句破損行をどのように単に克服するか。 トークナイザーの見出しの上のリンク内にトークンの例があります。 私が理解しているように、トークンの形式は次のように思えます。コードに何か問題があると、トークンも破損します。 私の誤解を明確にしていただけますか？

23 compiler  parsing  interpreters 

ウィキペディアによると、コンパイラを記述するという文脈での「ブートストラップ」という用語はこれを意味します。 コンピューターサイエンスでは、ブートストラップは、コンパイルするソースプログラミング言語でコンパイラー（またはアセンブラー）を記述するプロセスです。この手法を適用すると、セルフホスティングコンパイラが実現します。 そして、それがどのように機能するかを理解できます。しかし、話は通訳者にとっては少し違うようです。もちろん、セルフホスティングのインタープリターを作成することもできます。それは私が求めていることではありません。私が実際に求めていることである：それは、元の、最初のインタプリタの自己ホスト型インタプリタから独立させることが可能です。私の言いたいことを説明するために、この例を考えてみましょう。 最初のインタープリターバージョンを言語Xで記述し、インタープリターはYと呼ばれる作成中の新しい言語用です。最初に言語Xのコンパイラを使用して実行可能ファイルを作成します。これで、言語Xで作成されたインタープリターを使用して、新しい言語Yで作成されたファイルを解釈できます。 私が理解している限りでは、言語Xで作成したインタープリターを「ブートストラップ」できるようにするには、言語Yでインタープリターを書き換える必要があります。ただし、ここで問題があります。言語Yでインタープリター全体を書き換えたとしても、言語Xで作成した元のインタープリターが必要になります。インタープリターを言語Yで実行するには、ソースファイルを解釈する必要があります。しかし、ソースファイルを正確に解釈するにはどうすればよいでしょうか？もちろん、何もありえないので、最初のインタープリターを使用する必要があります。 言語Yで作成する新しいインタープリターの数に関係なく、Xで記述された最初のインタープリターを使用して後続のインタープリターを常に解釈する必要があります。これは単に通訳者の性質のために問題のようです。 ただし、逆に、通訳に関するこのウィキペディアの記事では、実際に自己ホスト型通訳について説明しています。関連する小さな抜粋を次に示します。 自己通訳とは、自身を解釈できるプログラミング言語で書かれたプログラミング言語インタープリターです。例は、BASICで書かれたBASICインタプリタです。セルフインタープリターは、セルフホスティングコンパイラに関連しています。 解釈対象の言語用のコンパイラーが存在しない場合、セルフインタープリターを作成するには、ホスト言語（別のプログラミング言語またはアセンブラー）で言語を実装する必要があります。このような最初のインタープリターを持つことにより、システムはブートストラップされ、言語自体でインタープリターの新しいバージョンを開発できます しかし、これがどのように行われるかは、まだはっきりしていません。何であれ、ホスト言語で書かれたインタープリターの最初のバージョンを常に使用せざるを得ないようです。 さて、上記の記事は、ウィキペディアがセルフホスティングインタプリタと思われるいくつかの例を提供している別の記事にリンクしています。しかし、よく調べてみると、これらのセルフホスティングインタープリターの多くの主な「解釈」部分（特にPyPyやRubiniusなどのより一般的なもの）は、実際にはC ++やCなどの他の言語で書かれているようです。 それで、私が上で説明したことは可能ですか？自己ホスト型インタープリターは元のホストから独立できますか？もしそうなら、これはどのように正確に行われますか？

21 language-agnostic  compiler  interpreters 

私は通訳者/コンパイラを研究してきましたが、その後、JITコンパイル、特にGoogle ChromeのV8 Javascript Engineに出会いました。 私の質問は- どのように標準の解釈よりも速くできますか？ そもそもJITコンパイルが使用されなかったのはなぜですか？ 私の現在の理解 すべてのJavascriptプログラムはソースコードとして開始され、実行方法に関係なく、最終的にはマシンコードに変換されます。 JIT-CompilationとInterpretationは 両方ともこのパスに従う必要があります。どのようにJIT-Compilationを高速化することができますか（また、AOT-Compilationとは異なり、JITは時間制約があるため）。 JIT-Compilationは、ウィキペディアのJIT-Compilation Articleに基づいた比較的古いイノベーションのようです。 「最初に公開されたJITコンパイラは、一般的に1960年に McCarthyによってLISPで動作するとされています。」 「Smalltalkの（C。1983）たとえば、マシンコードへの変換は、オンデマンドで行われた。JITコンパイルの新たな側面を開拓し、その結果は後で使用するためにキャッシュされた。メモリが不足になった場合、システムはこのコードと再生成の一部を削除しますそれが再び必要になったとき。」 では、なぜJavascript が最初から解釈されたのですか？ 私は非常に混乱しており、これについて多くの研究を行ってきましたが、満足のいく答えは見つかりませんでした。 とても明確で簡潔な回答をいただければ幸いです。また、通訳者、JITコンパイラなどについての追加説明が必要な場合は、それも歓迎します。

19 javascript  compiler  interpreters  jit 

私は現在、以下に基づいて式エバリュエーター（式のような単一行式）を実装しています。 入力された式は、リテラルブール、整数、小数、文字列、関数、識別子（変数）を分離するためにトークン化されます シャンティングヤードアルゴリズムを実装し（可変数の引数を持つ関数を処理するように少し変更）、括弧を取り除き、適切な優先順位で演算子を後置された順序で並べます 私のシャンティングヤードは、トークンの（シミュレートされた）キューを単に生成します（配列によって、Powerbuilder Classic言語はオブジェクトを定義できますが、ネイティブストレージとしてのみ動的配列を持ちます-真のリストではなく、ディクショナリーではありません）。シンプルなスタックマシン 私の評価者はうまく働いていますが、私はまだ足りないので、if()どうすればいいのか迷っています。 私のシャンティングヤードのポストフィックスおよびスタックベースの評価if()で、trueとfalseの部分を持つ別の関数として追加すると、1つif(true, msgbox("ok"), msgbox("not ok"))で両方のメッセージが表示され、1つだけ表示したいとします。これは、関数を評価する必要がある場合、その引数はすべて評価済みでスタックに配置されているためです。 if()怠惰な方法で実装する方法を教えてもらえますか？ 私はこれらを一種のマクロとして処理することについて考えましたが、初期の段階ではまだ条件の評価ができていません。おそらく、キューとは別の種類の構造を使用して、条件とtrue / false式を別々に保持する必要があるのでしょうか？現時点では、式は評価前に解析されますが、将来の評価のために中間表現を一種のプリコンパイルされた式として保存することも計画しています。 編集：問題について少し後で、私は自分の式のツリー表現（線形トークンストリームの代わりにAST）を構築でき、そこから自分のの別のブランチを簡単に無視できると思いif()ます。

10 language-design  compiler  interpreters 

Javaは、その驚くべき移植性でしばしば賞賛されています。これは、JVMが原因だと思います。私の質問は、Cがコンパイル/解釈/ JITされるのを阻止するものです。もしそうなら、Cは1度だけ記述して、あなたが持っているどのデバイスでも動作させることができます。しかし、これはCプログラムを処理するための一般的なメカニズムではありません。 もちろん、このようにCを処理することの欠点は何ですか？もちろん移植性以外に、このようにJavaを処理してマシンコードにコンパイルしないことの利点は何ですか？

9 java  c  compiler  jvm  interpreters