Welcome to ShenZhenJia Knowledge Sharing Community for programmer and developer-Open, Learning and Share
menu search
person
Welcome To Ask or Share your Answers For Others

Categories

Many methods in the BCL are marked with the [MethodImpl(MethodImplOptions.InternalCall)] attribute. This indicates that the "method is implemented within the common language runtime itself".

What was the point of designing the framework in this way over having specified explicit CIL instructions that the runtime would be forced to implement? Ultimately, the attribute is creating contractual obligations for the runtime, but in a way that appears to me to be confusing and not immediately obvious.

For example, Math.Pow could have been written this way (excuse my informal mixture of C# + IL and the IL itself if it is bad; this is only a sample to explain my point):

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

instead of the current way:

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

Why does MethodImplOptions.InternalCall exist?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
thumb_up_alt 0 like thumb_down_alt 0 dislike
543 views
Welcome To Ask or Share your Answers For Others

1 Answer

I think a big reason is that it's quite hard to create a new IL instruction and it could affect a lot of tools, including external ones (ILGenerator, ilasm, ildasm, PEVerify, Reflector, PostSharp, …).

But creating a new InternalCall method? That's almost as simple as writing the method in C# (I assume, I didn't look at Rotor to verify) and it doesn't affect anything.

And it's not just about creating it, I think the same applies to maintenance.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
thumb_up_alt 0 like thumb_down_alt 0 dislike
Welcome to ShenZhenJia Knowledge Sharing Community for programmer and developer-Open, Learning and Share
...