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

gccコードをコンパイルしたような高度なコンパイラは、コードが記述された言語（C、C ++など）に従って機械可読ファイルにコンパイルします。実際、それらは対応する言語のライブラリと機能に従って各コードの意味を解釈します。私が間違っている場合は修正してください。 非常に基本的なコンパイラ（おそらくCで）を記述して静的ファイル（テキストファイルのHello Worldなど）をコンパイルすることにより、コンパイラをよりよく理解したいと思います。私はいくつかのチュートリアルと本を試しましたが、それらはすべて実用的なケースです。対応する言語に関連付けられた意味を持つ動的コードのコンパイルを扱います。 静的テキストを機械可読ファイルに変換する基本的なコンパイラーを作成するにはどうすればよいですか？ 次のステップは、変数をコンパイラーに導入することです。言語の一部の機能のみをコンパイルするコンパイラを作成したいと想像してください。 実用的なチュートリアルとリソースをご紹介いただければ幸いです:-)

214 c  compiler  compilation  gcc 

ケン・トンプソン・ハック（1984） Ken Thompsonは、1984年にコンパイラバイナリ（および* nixシステムのログインスクリプトのような他のコンパイル済みソフトウェア）を破壊する方法を概説しました。現代のコンパイルがこのセキュリティの欠陥に対処しているかどうか知りたいです。 簡単な説明： 2つの欠陥を含むようにコンパイラコードを書き直します。 独自のバイナリをコンパイルするとき、コンパイラはこれらの欠陥をコンパイルする必要があります 事前に選択された他のコード（ログイン関数）をコンパイルする場合、任意のバックドアをコンパイルする必要があります したがって、コンパイラは正常に動作します-ログインスクリプトなどをコンパイルするとき、セキュリティバックドアを作成でき、将来、それ自体の新しいバージョンをコンパイルするとき、以前の欠陥を保持します- そして、欠陥はコンパイラにのみ存在しますバイナリなので、検出が非常に困難です。 質問： 私はウェブ上でこれらに対する答えを見つけることができませんでした： これはジャストインタイムコンパイルとどのように関係しますか？ * nixシステムでログインを処理するプログラムのような関数は、実行時にコンパイルされますか？ これはまだ有効な脅威ですか、それとも1984年以降、これが重大な問題になるのを防ぐコンパイルのセキュリティの開発がありましたか？ これはすべての言語に影響しますか？ なぜ知りたいのですか？ 宿題をしているときにこれに出くわしましたが、面白そうに思えましたが、これが現在の問題なのか、解決された問題なのかを具体的に理解する背景がありません。 参考資料 概要 いくつかのコード

156 linux  unix  compiler  hacking 

私が読んだことから：理由は、継承があるためにどのメソッドが実際に呼び出されるかを決定するのは簡単ではないからです。 しかし、なぜJavaには少なくとも静的メソッドの末尾再帰最適化がなく、コンパイラで静的メソッドを呼び出す適切な方法を強制しないのですか？ Javaが末尾再帰をまったくサポートしないのはなぜですか？ ここに問題があるかどうかはまったくわかりません。 JörgW Mittag 1が説明したように、提案された複製について： もう1つの質問は、TCOに関する質問です。これはTREに関する質問です。TREはTCOよりもはるかに単純です。 また、別の質問では、JVMがJVMにコンパイルしたい言語実装にどのような制限を課しているのかを尋ねます。この質問は、JVMによって制限されないJavaについて質問します。 Javaを設計する同じ人々。 最後に、JVMにはメソッド内GOTOがあり、TREに必要なのはそれだけであるため、JVMにはTREに関する制限さえありません。 1作成されたポイントを呼び出すためにフォーマットが追加されました。

92 java  compiler  recursion 

プログラミング言語の文法に取り組む各方法の具体的な長所と短所は何ですか？ なぜ/いつ自分のロールをする必要がありますか？なぜ/いつ発電機を使うべきですか？

81 language-design  compiler  parsing 

スタックオーバーフローに関するいくつかの回答を参照した後、ネイティブコンパイルされた言語の一部にガベージコレクションがあることが明らかです。しかし、これが正確にどのように機能するかは私には不明です。 ガベージコレクションがインタプリタ言語でどのように機能するかを理解しています。ガベージコレクターは、単にインタープリターと一緒に実行され、プログラムのメモリから未使用および到達不能なオブジェクトを削除します。両方が一緒に実行されています。 しかし、これはコンパイルされた言語でどのように機能しますか？私の理解では、コンパイラがソースコードをターゲットコード（特にネイティブマシンコード）にコンパイルすると、完了します。その仕事は終わりました。それでは、コンパイルされたプログラムをどのようにガベージコレクションするのでしょうか？ 「ガベージ」オブジェクトを削除するためにプログラムが実行されている間、コンパイラは何らかの方法でCPUと連携しますか？または、コンパイラは、コンパイルされたプログラムの実行可能ファイルに最小限のガベージコレクタを含めますか。 Stack Overflowに関するこの回答からの抜粋により、後者のステートメントは前者よりも妥当性があると思います： そのようなプログラミング言語の1つがEiffelです。ほとんどのEiffelコンパイラは、移植性の理由でCコードを生成します。このCコードは、標準Cコンパイラによってマシンコードを生成するために使用されます。Eiffel実装は、このコンパイルされたコードに対してGC（および場合によっては正確なGC）を提供します。VMは必要ありません。特に、VisualEiffelコンパイラーはネイティブのx86マシンコードをフルGCサポートで直接生成しました。 最後のステートメントは、プログラムの実行中にガベージコレクターとして機能するプログラムを最終的な実行可能ファイルにコンパイラが含めることを意味するようです。 ネイティブにコンパイルされ、オプションのガベージコレクタを備えたガベージコレクションに関するD言語のWebサイトのページも、ガベージコレクションを実装するために元の実行可能プログラムと一緒にバックグラウンドプログラムが実行されることを示唆しているようです。 Dは、ガベージコレクションをサポートするシステムプログラミング言語です。通常、メモリを明示的に解放する必要はありません。必要に応じて割り当てるだけで、ガベージコレクターはすべての未使用メモリを利用可能なメモリのプールに定期的に返します。 この方法は、上記の場合はされて使用され、どのように正確にそれが働くだろうか？コンパイラは、ガベージコレクションプログラムのコピーを保存し、生成する各実行可能ファイルに貼り付けますか？ または、私は私の考えに欠陥がありますか？その場合、コンパイルされた言語のガベージコレクションを実装するためにどのメソッドが使用され、どのように正確に機能しますか

79 language-agnostic  compiler  garbage-collection 

特定のオペレーティングシステム用のプログラミング言語を使用して作成されたソフトウェアがそれらでのみ動作する理由の技術的な詳細を判断しようとしています。 バイナリは特定のプロセッサに固有であり、理解しているプロセッサ固有のマシン言語と、異なるプロセッサ間で異なる命令セットがあるため、バイナリは特定のプロセッサに固有であることを理解しています。しかし、オペレーティングシステムの特異性はどこから来るのでしょうか？以前はOSが提供するAPIであると想定していましたが、次の本でこの図を見ました。 オペレーティングシステム-内部構造と設計原則7th ed-W. Stallings（Pearson、2012） ご覧のとおり、APIはオペレーティングシステムの一部として示されていません。 たとえば、次のコードを使用してCで簡単なプログラムを作成する場合： #include<stdio.h> main() { printf("Hello World"); } コンパイラはこれをコンパイルするときにOS固有のことを何ですか？

77 operating-systems  compiler 

これは、インタープリターおよびコンパイルされた言語について読んでいたときの不思議です。 ソースコードは実行時にインタープリターによって処理されるため、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 

Cは、世界で最も広く使用されている言語の1つです。既存のコードの大部分を占め、膨大な量の新しいコードに引き続き使用されます。ユーザーに愛されており、非常に広く移植されているため、Cを実行できることはプラットフォームの非公式な定義の多くに当てはまります。 それでは、すべてのコンパイラはどこにありますか？ デスクトップには、（現実的に）GCCとClangの2つがあります。数秒間考えてみれば、おそらくインテルも存在していることを覚えているでしょう。他の人はほんの一握りで、平均的な人が名前を付けるにはあまりにもあいまいで、ほとんどの場合、最近の言語バージョン（またはよく定義された言語サブセット、単に「サブセット」）をサポートすることをほとんど気にしません。このリストのメンバーの半分は歴史的な脚注です。残りのほとんどは非常に特殊化されており、実際には完全な言語を実装していません。実際にオープンソースであると思われるものはほとんどありません。 SchemeとForth-ファンに愛されている他の小さな言語-はおそらく実際のユーザーよりも多くのコンパイラを持っています。SMLのようなものでも、Cよりも「深刻な」実装を選択できます。一方、検証を目的とする新しい（未完成の）Cコンパイラの発表では、実際にかなり否定的な応答が見られ、ベテランの実装は、 C99。 どうして？Cの実装はとても難しいですか？C ++ではありません。ユーザーは、それがどの複雑なグループに属するかについて非常に歪んだ考えを持っているだけですか（つまり、実際にはSchemeよりもC ++に近いということですか）。

72 c  compiler  implementations 

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

72 history  compiler  interpreters 

コンパイラは、その正確性が与えられているかのように日常的に使用しますが、コンパイラもプログラムであり、潜在的にバグを含む可能性があります。私はいつもこの絶対的な堅牢性について疑問に思っていました。コンパイラ自体のバグに遭遇したことはありますか？コンパイラ自体に問題があることをどのように認識しましたか？ ...そして、どのようにしてコンパイラを非常に信頼できるものにしますか？

63 testing  bug  compiler  system-reliability 

そのため、特定のプロセッサでCを使用したソフトウェア設計に取り組んでいます。ツールキットには、CおよびC ++をコンパイルする機能が含まれています。私がやっていることに関しては、この環境で利用可能な動的メモリ割り当てはなく、プログラムは全体的にかなり単純です。言うまでもなく、このデバイスにはプロセッサー能力やリソースがほとんどありません。C ++を使用する必要はまったくありません。 そうは言っても、関数のオーバーロードを行う場所はいくつかあります（C ++の機能）。いくつかの異なるタイプのデータを送信する必要がありますが、printf何らかの%s（またはなんらかの）引数でスタイルの書式設定を使用する気はありません。私はC ++コンパイラにアクセスできない人を何人か見ましたprintfが、私の場合はC ++サポートが利用可能です。 これで、なぜ関数をオーバーロードする必要があるのか​​という疑問を最初から得ることができると確信しています。だから私は今すぐそれに答えようとします。シリアルポートからさまざまな種類のデータを送信する必要があるため、次のデータ型を送信するオーバーロードがいくつかあります。 unsigned char* const char* unsigned char const char 私は、これらすべてを処理する1つのメソッドを持たないことを好みます。私はちょうどそれがシリアルポートを送信する関数を呼び出すときに、私は多くの資源を持っていないので、私はかろうじて行うにはしたくない何でもいいけど、私の送信を。 他の人が私のプログラムを見て、「なぜCPPファイルを使用しているのですか？」だから、それが私の唯一の理由です。それは悪い習慣ですか？ 更新 私は尋ねられたいくつかの質問に対処したいと思います： あなたのジレンマに対する客観的な答えは以下に依存します： C ++を使用する場合、実行可能ファイルのサイズが大幅に増加するかどうか。 現在、実行可能ファイルのサイズは、プログラムメモリの4.0％（5248バイトのうち）とデータメモリの8.3％（342バイトのうち）を消費しています。つまり、C ++用にコンパイルしています... Cコンパイラを使用していないため、Cでどのように見えるかわかりません。私はこのプログラムがこれ以上成長しないことを知っているので、リソースがどれだけ限られているかについては、私はそこで大丈夫だと言います... C ++を使用している場合、パフォーマンスに顕著な悪影響があるかどうか。 ある場合、私は何にも気づいていません...しかし、それでも私は完全に理解していないので、私はこの質問をしている理由かもしれません。 Cコンパイラーのみが使用可能な別のプラットフォームでコードを再利用できるかどうか。 私はこれに対する答えが間違いなくノーであることを知っています。別のプロセッサへの移行を実際に検討していますが、より強力なARMベースのプロセッサのみです（事実、C ++コンパイラツールチェーンを持っていることは事実です）。

60 c++  c  compiler  functions  method-overloading 

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

60 programming-languages  performance  compiler  interpreters 

私たちは日々の生活の非常に重要なタスクを含め、コンピューティングにますます頼るようになっているので、私はそれらの重要なコンポーネントがどのようにテストされるのかと思っていました。 より技術的には、コンパイラとアセンブラはどのようにテストされますか？（これは停止の問題に関連すると思います!!）

57 programming-practices  compiler  theory 

数年前、IntelがVisual Studio互換コンパイラを販売していることを発見したとき、私は驚きました。私は特にC / C ++および素晴らしい診断ツールでそれを試しました。しかし、コードは、違いに気付くほど計算集約的ではありませんでした。唯一の印象は、Intelがまさに今私のためにそれを行ったのか、すごい、ナノ秒の解像度を備えた驚くべきツール、信じられないほどでした。しかし、トライアルは終了し、チームは真剣に購入を検討しませんでした。 あなたの経験から、ライセンス費用が問題にならない場合、どのベンダーが勝者ですか？ 神聖な戦争を引き起こすのは、広範で曖昧な質問や態度ではありません。この種の質問は、非常に目に見える2つのツールに関するものです。ツールに謎や驚きがあるときは誰も好きではありません。そして最高と最高の間の選択は常に痛みです。また、草は常に環境に優しい議論であることも理解しています。すべての「what ifs」ストーリーを聞きたいです。 Intelが今月のチップステッピング用にローカルに最適化し、すべてのハードウェアターゲットがMicrosoftのコンパイルと同じように実際に動作するとは限らない場合はどうなりますか？AMDハードウェアがターゲットであり、すべてが理由なくスローダウンする場合はどうなりますか？または、一方で、Intelのハードウェアに気付かないほど多くの機会があり、Microsoftコンパイラライターが採用するには遅すぎて、コンパイラに実装できない場合はどうでしょうか。両方が正確に同じ場合、実際には単一のコードベースが2つの異なるボックスにラップされ、サードパーティショップによって両方のベンダーにライセンスされている場合はどうでしょうか。 等々。しかし、誰かがいくつかの答えを知っています。

56 compiler 

文脈自由文法（CFG）が何であるかを説明しようとする資料の量を考えると、そのような文法が「コンテキスト-自由"。そして、私の考えでは、誰もそうすることに成功していません。 私の質問は、なぜ文脈自由文法が文脈自由と呼ばれるのですか？「コンテキスト」とは何ですか？コンテキストは、現在分析されている構造を取り巻く他の言語構造である可能性があるという直感がありましたが、そうではないようです。誰でも正確な説明を提供できますか？

55 programming-languages  compiler  grammar