В чем смысл MethodImplOptions.InternalCall?

многие методы в BCL отмечены . Это указано что "метод реализован в самой среде выполнения общего языка".

в чем был смысл разработки фреймворка таким образом, указав явные инструкции 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);

почему ?

21
.net cil clr framework-design

3 ответов

Я думаю, что большая причина в том, что довольно сложно создать новую инструкцию IL, и это может повлиять на множество инструментов, включая внешние (ILGenerator, ilasm, ildasm, PEVerify, Reflector, PostSharp,...).

но создание нового InternalCall способ? Это почти так же просто, как написать метод на C# (я предполагаю, что я не смотрел на Ротор, чтобы проверить), и это ни на что не влияет.

и речь идет не только о его создании, я думаю, то же самое относится к обслуживанию.

8

Я думаю, что это было не слишком усложнять CLR. Когда я впервые заглянул в CIL, я не мог не заметить сходства с языком ассемблера, и более того, ограниченный набор инструкций, как будто они заставили его работать непосредственно на процессоре.

теоретически, когда CLR JIT - это пример кода для Pow вы включили в свой пост, он должен был бы выдать себе собственный код для pow обучение, так как нет родной инструкции (или это? не были в курсе новых наборов инструкций x86 с нескольких лет назад). Глядя с точки зрения производительности, но и с точки зрения реализации, гораздо проще просто вызвать mscorlib для pow код, чем просто "вставить" его в линию.

или у них могла быть таблица поиска для общих функций mscorlib, которые являются InternalCall и замените инструкцию вызовом самой функции. Но опять же, не все!--3--> так просто.

Я думаю, что это был компромисс для удобства; оба с их стороны, для ремонтопригодности CLR, более единообразного стандарта CLI и обеспечения некоторой гибкости для абонентов.

суть в том, что я не разработал CLR, и это просто с верхней части моей головы. Что-то, что я бы сделал, наверное.

3

метод является родным, по-настоящему родным, реализованным в самой среде выполнения. Не забывайте, что CLR происходит от C++ в конце концов. Это как в компиляторе. В реальном мире, сил не выполнен. Это JIT-ted, а затем выполняется, как компилятор, средой выполнения C/C++. Математика.Pow, скорее всего, [спекуляция] вызов в родную математику C/C++.метод H pow, и он определен реализацией-теперь NET и Mono реализуют CLR.

В UnityEngine.библиотеки DLL, [MethodImpl(MethodImplOptions.InternalCall)] используется на большинстве родных внешний метод. Эти методы C++, однако, используют библиотеку CLR Mono C++ напрямую, и они могут сотрудничать с C# более интимным способом, чем P/INVOKE. И путь более performant (PInvoke скрывает некоторые детали реализации и делает некоторые трудно понять)

однако, единственный способ использовать [MethodImpl(MethodImplOptions.InternalCall)] Если вы сами среда CLR-я только тестировал моно, как это, однако. Я не знаю, возможно ли даже изменить реализацию CLR Microsoft, но с Mono вы бесплатно злоупотреблять этой функцией.

кроме того, не связывайся с

2