What's the point of MethodImplOptions.InternalCall?

Question

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

Answer 1

I think it was to not over-complicate the CLR. When I first looked into CIL I couldn't help notice the similarities with an assembly language, and more than that, the limited instructions set, almost as if they had made it to run directly on a processor.

In theory, when the CLR JIT's that sample code for Pow you included in your post, it would have to issue itself the native code for the pow instruction, since there's no native instruction (or is it? haven't been up to date with new x86 instruction sets since a few years back). Looking from the performance point of view but also from the implementation point of view, it is much easier to just call into mscorlib for the pow code, than just "paste" it inline.

Or, they could have had a lookup table for common mscorlib functions that are InternalCall and substitute the instruction with a call to the function itself. But then again, not all InternalCall are as easy as that.

I think it was a trade-off for convenience; both on their side, for CLR maintainability, a more uniform CLI standard and to allow some flexibility to callers.

Bottom-line is that I haven't developed the CLR and this is just off the top of my head. Something I would've done, I guess.