significado - que es el clr de.net framework
¿Cuál es el punto de MethodImplOptions.InternalCall? (3)
Creo que fue para no complicar en exceso el CLR. La primera vez que miré a CIL no pude evitar notar las similitudes con un lenguaje ensamblador, y más que eso, el conjunto de instrucciones limitadas, casi como si lo hubieran hecho para ejecutarse directamente en un procesador.
En teoría, cuando el CLR JIT sea el código de muestra para Pow que incluyó en su publicación, tendría que emitirse el código nativo para la instrucción pow , ya que no hay instrucción nativa (o ¿no? No ha estado actualizado con nuevos conjuntos de instrucciones x86 desde hace unos años). Mirando desde el punto de vista del rendimiento pero también desde el punto de vista de la implementación, es mucho más fácil llamar a mscorlib para el código de poder, que simplemente "pegarlo" en línea.
O bien, podrían haber tenido una tabla de búsqueda para las funciones comunes de mscorlib que son llamadas InternalCall y sustituir la instrucción con una llamada a la función en sí. Pero, de nuevo, no todas las InternalCall son tan fáciles como eso.
Creo que fue una compensación por conveniencia; tanto por su parte, para el mantenimiento de CLR, un estándar de CLI más uniforme y para permitir cierta flexibilidad a las personas que llaman.
La conclusión es que no he desarrollado el CLR y esto es sólo un poco de mi cabeza. Algo que hubiera hecho, supongo.
Muchos métodos en el BCL están marcados con el [MethodImpl(MethodImplOptions.InternalCall)] . Esto indicates que el "método se implementa dentro del propio tiempo de ejecución del lenguaje común".
¿Cuál fue el punto de diseñar el marco de esta manera después de haber especificado instrucciones CIL explícitas que el tiempo de ejecución se vería obligado a implementar? En última instancia, el atributo está creando obligaciones contractuales para el tiempo de ejecución, pero de una manera que me parece confusa y no es evidente de inmediato.
Por ejemplo, Math.Pow podría haberse escrito de esta manera (disculpe mi mezcla informal de C # + IL y la propia IL si es mala; esto es solo una muestra para explicar mi punto):
public static double Pow(double x, double y)
{
ldarg.0
ldarg.1
pow // Dedicated CIL instruction
ret
}
En lugar de la forma actual:
[MethodImpl(MethodImplOptions.InternalCall)]
public static double Pow(double x, double y);
¿Por qué existe MethodImplOptions.InternalCall ?
Creo que una razón importante es que es bastante difícil crear una nueva instrucción IL y podría afectar a muchas herramientas, incluidas las externas ( ILGenerator , ilasm, ildasm, PEVerify, Reflector, PostSharp, ...).
¿Pero creando un nuevo método InternalCall ? Eso es casi tan simple como escribir el método en C # (supongo que no miré a Rotor para verificar) y no afecta nada.
Y no se trata solo de crearlo, creo que lo mismo se aplica al mantenimiento.
El método es nativo, REALMENTE nativo, implementado en el propio Runtime. No se olvide, que CLR viene de C ++ después de todo. Es como en el compilador. En el mundo real, CIL no se ejecuta realmente. Es ejecutado por JIT y luego ejecutado, como un compilador, por un tiempo de ejecución C / C ++. Math.Pow es probablemente [una especulación] una llamada al método C / C ++ math.h pow nativo, y está definido por la implementación: ahora NET y Mono implementan el CLR.
En UnityEngine.dll, [MethodImpl(MethodImplOptions.InternalCall)] se usa en la mayoría de los métodos externos nativos. Sin embargo, estos métodos de C ++ usan la biblioteca Mono C ++ CLR directamente y pueden cooperar con C # de una manera más íntima que P / INVOKE. Y mucho más eficaz (PInvoke oculta algunos detalles de implementación y hace que algunos sean difíciles de entender)
Sin embargo, la única forma de usar [MethodImpl(MethodImplOptions.InternalCall)] es si usted es el mismo tiempo de ejecución de CLR. Sin embargo, solo probé Mono de esta manera. No sé si es posible incluso alterar la implementación de CLR de Microsoft, pero con Mono usted es libre de abusar de esta característica.
Además, no ensucie esto con [MethodImpl(MethodImplOptions.Unmanaged)] - es una historia completamente diferente.
Más información sobre las llamadas internas y cómo funciona Mono, aquí: http://www.mono-project.com/docs/advanced/embedding/
Descargo de responsabilidad: ¡NO estoy relacionado con Unity o Mono!