35

BCL の多くのメソッドは、 [MethodImpl(MethodImplOptions.InternalCall)]属性でマークされています。これは、「メソッドが共通言語ランタイム自体に実装されている」ことを示します。

ランタイムが強制的に実装する明示的な CIL 命令を指定するよりも、このようにフレームワークを設計するポイントは何でしたか? 最終的に、属性はランタイムの契約上の義務を作成しますが、私には混乱を招き、すぐには明らかではないように見えます。

たとえば、次のMath.Powように記述することもできます (C# + IL と IL 自体の非公式な混合が悪い場合は申し訳ありません。これは私の要点を説明するためのサンプルにすぎません)。

public static double Pow(double x, double y)
{
    ldarg.0
    ldarg.1
    pow // Dedicated CIL instruction
    ret
}

現在の方法の代わりに：

[MethodImpl(MethodImplOptions.InternalCall)]
public static double Pow(double x, double y);

なぜMethodImplOptions.InternalCall存在するのですか？

4

4 に答える 4

9

ILGenerator大きな理由は、新しいIL命令を作成するのが非常に難しく、外部ツール（ 、ilasm、ildasm、PEVerify、Reflector、PostSharpなど）を含む多くのツールに影響を与える可能性があることだと思います。

しかし、新しいInternalCallメソッドを作成しますか？これは、C＃でメソッドを作成するのとほぼ同じくらい簡単で（私はRotorを調べて検証しなかったと思います）、何にも影響しません。

作成するだけでなく、メンテナンスにも同じことが言えると思います。

于 2012-06-22T18:02:14.120 に答える
4

CLRを過度に複雑にしないためだったと思います。CIL を最初に調べたとき、アセンブリ言語との類似点に気付きました。それ以上に、まるでプロセッサ上で直接実行するように作成したかのように、命令セットが限定されていました。

理論的には、CLR JIT のサンプル コードがPow投稿に含まれている場合、powネイティブ命令がないため (または新しい x86 では最新になっていないため)、命令のネイティブ コードを発行する必要があります。数年前からの命令セット)。パフォーマンスの観点からだけでなく、実装の観点からも、powコードをインラインで「貼り付ける」よりも、mscorlib を呼び出してコードを呼び出す方がはるかに簡単です。

または、一般的な mscorlib 関数のルックアップ テーブルを用意してInternalCall、命令を関数自体の呼び出しに置き換えることもできます。しかし、繰り返しになりますが、すべてInternalCallがそれほど簡単なわけではありません。

利便性とのトレードオフだったと思います。CLRの保守性、より統一されたCLI標準、および呼び出し元にある程度の柔軟性を与えるために、両方の側で。

要するに、私は CLR を開発していないということです。私がしただろう何か、私は推測します。

于 2012-06-22T17:34:43.837 に答える