MethodImplOptions.InternalCall의 요점은 무엇입니까?

Question

BCL의 많은 메서드는 [MethodImpl(MethodImplOptions.InternalCall)] 특성으로 표시되어 있습니다. "indicates"메서드는 공용 언어 런타임 자체 내에서 구현됩니다.

런타임에서 구현해야하는 명시 적 명시된 CIL 명령어를 통해 이러한 방식으로 프레임 워크를 설계하는 요점은 무엇입니까? 궁극적으로, 속성은 런타임에 대한 계약 상 의무를 만들고 있지만 혼란스럽고 즉시 명백하지 않은 것처럼 보입니다.

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

:;

는 예를 들어, Math.Pow이 방법 (나의 점을 설명하기 위해이 만 샘플 C 번호 + IL과 IL 자체가 나쁜 경우는 내 비공식 혼합물 변명을) 기록 된 수 현재 방법 대신 :

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

왜 MethodImplOptions.InternalCall가 존재합니까?

Answer 1

저는 새로운 일리노이 명령어를 작성하는 것이 매우 어렵고 외부 명령어 (ILGenerator, ilasm, ildasm, PEVerify, Reflector, PostSharp, ...)를 비롯한 많은 도구에 영향을 미칠 수 있다고 생각합니다.

그러나 새 InternalCall 메서드를 만드는 중입니까? 이것은 C#에서 메서드를 작성하는 것만 큼 간단합니다 (로터에서 확인하지 않았다고 가정합니다). 아무 영향을 미치지 않습니다.

그리고 그것을 만드는 것이 아니라 유지 보수에도 적용됩니다.

Answer 2

CLR을 지나치게 복잡하게 만들지 않았다고 생각합니다. CIL을 처음 들여다 보았을 때 어셈블리 언어와의 유사점을 알 수 없었습니다. 그 이상의 제한된 명령어 세트는 마치 프로세서에서 직접 실행되는 것처럼 보였습니다.

이론적으로 CLR JIT에 Pow의 샘플 코드가 포함되어있는 경우 원래 지침이 없으므로 pow 명령어의 원시 코드를 자체적으로 발행해야합니다 (또는 해당되지 않았습니까? 몇 년 전부터 새로운 x86 명령어 세트에 대한 최신 정보). 성능의 관점 에서뿐만 아니라 구현의 관점에서 보더라도 코드를 pow 코드로 mscorlib에 호출하면 인라인으로 붙여 넣기하는 것보다 훨씬 쉽습니다.

또는 일반 mscorlib 함수에 대한 찾아보기 테이블이 InternalCall 일 수 있으며 함수 자체에 대한 호출로 명령을 대체 할 수있었습니다. 그러나 그때 다시, 모든 InternalCall가 그것만큼 쉽지 않다.

편의상 트레이드 오프라고 생각합니다. CLR 유지 보수성,보다 균일 한 CLI 표준 및 호출자에게 유연성을 허용하는 측면에서 모두 중요합니다.

결론은 내가 CLR을 개발하지 않았으며 이것이 내 머리 꼭대기에서 떨어져 있다는 것입니다. 내가 한 것 같아.

Answer 3

이 메서드는 원시, TRULY 네이티브이며 런타임 자체에 구현됩니다. CLR은 C++에서 비롯된 것임을 잊지 마십시오. 컴파일러와 비슷합니다. 실제로 CIL은 진정으로 실행되지 않습니다. 컴파일러처럼 C/C++ 런타임에 의해 JIT 된 다음 실행됩니다. Math.Pow는 네이티브 C/C++ math.h pow 메서드에 대한 호출 일 가능성이 가장 높으며 구현 정의입니다. 이제 NET과 Mono가 CLR을 구현합니다.

UnityEngine.dll에서 대부분의 네이티브 외부 메서드에는 [MethodImpl(MethodImplOptions.InternalCall)]이 사용됩니다. 그러나 이러한 C++ 메서드는 Mono C++ CLR 라이브러리를 직접 사용하며 P/INVOKE 자체보다 C#과 더 친밀한 방식으로 공동 작업 할 수 있습니다. 그리고 더 성능이 좋은 (PInvoke는 구현 세부 사항을 숨기고 이해하기 어렵게 만듭니다.) 그러나 CLR 런타임 자체는 을 사용하는 유일한 방법입니다. Microsoft의 CLR 구현을 변경하는 것이 가능한지 여부는 모르지만 Mono를 사용하면이 기능을 악용 할 수 있습니다.

또한 이것을 [MethodImpl(MethodImplOptions.Unmanaged)]과 함께 사용하지 마십시오. 완전히 다른 이야기입니다.

내부 호출에 대한

점점 모노가 여기에 작동하는 방법 : http://www.mono-project.com/docs/advanced/embedding/

면책 조항 : 나는 유니티 또는 모노 관련이없는거야!