問題タブ [intermediate-language]

OpenCoverを使用してアセンブリをインストルメント化すると、SecurityTransparent属性 (および AllowPartiallyTrustedCallers のように見える) を持つアセンブリが VerificationException をスローするようです。その理由と、MVC3 のダウンロードされたコードに見られるように、条件付きコンパイルなど、これらの属性を含めずにアセンブリを再コンパイルする別の解決策があるかどうかを知りたいのですが (奇妙なことに、 codeplex のリポジトリ)。これらのアセンブリ属性がなくても、カバレッジは問題なく実行されることに注意してください。

OpenCover は、CALLI命令を使用して、計測データ (シーケンス ポイント識別子) をプロファイラーに送信します。この命令を呼び出すと、例外が発生するようです。インストルメンテーション部分は問題ないようで、JIT はインストルメント化された新しいメソッドを問題なくコンパイルします。Tiny メソッドの Fat と小さなブランチを長くする以外のすべてのインストルメンテーションを削除すると、コードは問題なく実行されるため、インストルメンテーションの行為は問題を引き起こしません。

現在、Mono.Cecil を使用して「include-in-coverage」フィルターを通過するアセンブリを調べ、インストルメンテーションをスキップしてユーザーに問題を報告してから続行していますが、できることがあるかどうか知りたいです。この問題を回避し、再コンパイルを避けるために、プロファイリング中に実行してください。

2つの質問を要約すると、「なぜそれが起こるのか?」および「再コンパイルせずに回避できますか?」

注: PartCover にもこの問題が見られるようで、別の方法を使用して訪問ポイントを記録します。

注: 私は OpenCover (オープン ソース コード カバレッジ ツール) の開発者であり、現在は PartCover のメンテナーです。

IListのインスタンスをパラメーター（または他のインターフェースですが、例として使用しましょう）として取るメソッドを作成したい場合はIList、型制約を使用してジェネリックメソッドを作成できます。例：

または、IListパラメータを直接受け取るメソッドを作成することもできます。

すべての目的と目的で、これらのメソッドはまったく同じように動作するようです。

だからここに私の質問があります-これらの2つのアプローチの違いは何ですか？2番目のアプローチの方が少し読みやすいようです。他に知っておくべき違いはありますか（生成されるILの違いなど）？前もって感謝します。

C ++コードをアセンブリコードに変換してからその逆を行う方法を知っている人はいますか？前進する方法は非常に簡単です。

出力を分析して、正しくコンパイルされているかどうかを確認したいと思います（好奇心のためですが、一部のアプリケーションが含まれている可能性があります）。ただし、アセンブリに関する私の知識は非常に限られており、出力を理解するのは困難です（これは、最適化（-O）を使用するか、デバッグ情報（-g）を使用してコンパイルする場合に特に当てはまります）。

C++コードを生成するためのC++（GCC）用のデアセンブラーはありますか？そうでない場合は、C ++コードをコンパイルしてから元に戻すことができる中間表現はありますか？

ここでC++をCに変換する方法がいくつかあるようです。GCCにはこれについて何かありますか？

質問は多くの人にとって普通のことかもしれませんが、私は他のことと同じように混乱しています。私はc＃で.netを読んでいます。私は多くの記事とmsdnを調べました。私の疑問は：

VSでC＃Windowsフォームアプリケーションコードを開発して実行すると、拡張子が「.exe」のProject \ bin \ Debug \内のファイルは中間コードですか、それともマシンコードですか。公開するとき、インストーラーを入手した瞬間、それはマシンコードですか、それとも中間コードですか？インストーラーで.netのインストールが必要な場合があるためです。

この概念を理解するのを手伝ってください。

ありがとうございました。

レクサー、構文チェッカー、およびセマンティクスを取得できたので、中間コードの生成に移りたいと思います。問題は、論理式の処理方法がわからないことです。E.true と E.false について読んだことがあります。この例はどこにでもありますが、私はそれを理解していませんでした。

たとえば、次のコードがある場合

結果はこのようなものでなければなりません

ただし、実際に if ステートメントの解析を完了するまで、ジャンプのラベルはわかりません。

そのため、クワッドを生成してからバックパッチする必要があります。この投稿の文法でどうすればできますか？

私は本当に混乱しているので、誰かがそれがどうなるか説明できますか.

次の2つのコードスニペットについてLinqpadで作成されたILを見ると、ここで何が起こるのだろうかと思います。

C＃で

結果は次のILコードになります

一方、VBでは

それは

どうやら、c＃コンパイラは、値が使用されないことを理解しているため、単に何も返しません。VB.NETでは、実際のコードが変換されます。

それはコンパイラの最適化の違いによるものですか、それとも他に何か機能しているものがありますか？

更新：これを明確にするために-私はこの1行をLinqPadに入力し、それが作成するILを確認します（最も確実にそれぞれのコンパイラーを実行することによって）。プログラムはありません。

これは、ここで提供されるソリューションの拡張です。オブジェクトを返す静的メソッドを作成しました。私の目標は、実行時に定義する型の動的メソッドを記述して、この静的メソッドが返すオブジェクトを返すことです。これまでの私のコード:

更新されたコードはメソッドを呼び出すようになりましたが、変数 returnType ではなく、動的に作成された型の型を渡しているようです。

おそらくばかげた質問ですが、MSILにはスタック上のデータを操作するための一般的なForthのような機能がありますか？（たとえば、DUP、SWAPなど）

私は、いくつかの「問題のある」プロパティを持つ関数型言語を実行するために、中間言語と仮想マシンに取り組んでいます。

• レキシカル名前空間 (クロージャ)
• 動的に増加するコール スタック
• 遅い整数型 (bignums)

中間言語はスタック ベースで、現在の名前空間の単純なハッシュ テーブルを使用します。どのように見えるかを理解するために、McCarthy91関数を次に示します。

「大きなループ」は簡単です。

• 命令をフェッチする
• 命令ポインタ（またはプログラムカウンタ）をインクリメントします
• 命令を評価する

に加えてsto、rcl関数呼び出しには 3 つの命令があります。

• call名前空間をコピー (ディープ コピー) し、命令ポインタをコール スタックにプッシュします。
• call-fastは同じですが、浅いコピーのみを作成します
• tail基本的には「goto」です

実装は実に簡単です。より良いアイデアを提供するために、「大きなループ」の途中からのランダムなスニペットを次に示します (更新、以下を参照)。

問題は次のとおりです。McCarthy91 を -10000 の値で 16 回呼び出すと、ほとんど違いはありませんが、3 秒かかります (ディープコピーを最適化した後、1 秒近く追加されます)。

私の質問は、この種の言語の解釈を最適化するための一般的な手法は何ですか? ぶら下がっている果物はありますか？

リストにスライス (引数、さまざまなスタック、名前空間のマップのスライスなど) を使用したので、この種のことをあらゆる場所で行いますcall_stack[:len(call_stack) - 1]。今のところ、どのコードがこのプログラムを遅くしているのか、まったくわかりません。私は主に一般的な最適化戦略を探していますが、ヒントをいただければ幸いです。

余談:

呼び出し規則を回避することで、実行時間をかなり短縮できます。命令はスタックのlist <n>n 個の引数をフェッチし、それらのリストをスタックにプッシュし、args命令はそのリストからポップして、各項目をスタックにプッシュします。これは、第一に、関数が正しい数の引数で呼び出されていることを確認し、第二に、可変引数リスト (つまり ) で関数を呼び出せるようにするため(defun f x:xs)です。それを削除し、sto* <x>を置き換える命令を追加するとsto <x>; rcl <x>、2 秒に短縮できます。まだ華麗ではありません、とにかくこれlist/argsビジネスを持たなければなりません. :)

もう1つ（これは私が知っている長い質問です、申し訳ありません）：

pprof を使用してプログラムをプロファイリングしても、ほとんどわかりませんでした (明らかでない場合に備えて、私は Go を初めて使用します) :-)。これらは、pprof によって報告された上位 3 項目です。

これまでに行った変更は次のとおりです。

• ハッシュテーブルを削除しました。代わりに、配列へのポインターだけを渡すようになり、必要な場合にのみローカル スコープを効率的にコピーします。
• 命令名を整数のオペコードに置き換えました。以前は、文字列の比較にかなりの時間を費やしていました。
• 命令はなくなりましたcall-fast(他の変更の後、スピードアップはもはや測定できませんでした)
• 「int」、「float」、および「str」命令を使用する代わりに、1 つだけ使用evalし、コンパイル時に定数を評価します (つまり、バイトコードのコンパイル)。次にeval、それらへの参照をプッシュします。
• のセマンティクスを変更した後.if、これらの疑似関数を取り除くことができました。と同様の暗黙の gotos とブロック セマンティクスを使用して、今.ifでは 、.elseandです。(いくつかのサンプルコード).endif.sub

レクサー、パーサー、およびバイトコード コンパイラを実装した後、速度は少し低下しましたが、それほどではありませんでした。MC(-10000) を 16 回計算すると、1.2 秒で 420 万のバイトコード命令が評価されます。生成されるコードのサンプルを次に示します(このから)。

全体はgithubにあります

GHCの設計は、「スパインレス、タグレスGマシン」の略であるSTGと呼ばれるものに基づいています。

現在、G-machineは、怠惰の実装方法を定義する「グラフ還元マシン」の略です。評価されていないサンクは式ツリーとして保存され、プログラムを実行するには、これらを通常の形式に縮小する必要があります。（ツリーは非巡回グラフですが、Haskellの広範な再帰は、Haskell式が一般的なグラフを形成することを意味します。したがって、ツリー削減ではなくグラフ削減になります。）

あまり明確ではないのは、「スパインレス」と「タグレス」という用語です。

1. 「スパインレス」とは、関数適用に関数アプリケーションノードの「スパイン」がないことを指していると思います。代わりに、呼び出された関数に名前を付け、そのすべての引数を指すオブジェクトがあります。あれは正しいですか？

2. 「タグレス」とは、コンストラクターノードがコンストラクターIDで「タグ付け」されていないことを指し、代わりに大文字小文字の表現はジャンプ命令を使用して解決されると思いました。しかし、今はそれが正しいかどうかわかりません。代わりに、ノードが評価状態でタグ付けされていないという事実を参照しているようです。誰かがこれらの解釈のどれが正しいか（もしあれば）を明確にすることができますか？