Estou trabalhando em uma ILGenerator
extensão para ajudar a emitir fragmentos de IL usando Expression
. Tudo estava bem, até eu trabalhar na parte de conversão de números inteiros. Há algo realmente contra-intuitivo para mim, como:
- Use
conv.i8
para converterInt32
paraUInt64
- Use
conv.u8
para converterUInt32
paraInt64
Eles são todos porque a pilha de avaliação não controla a assinatura inteira. Entendo perfeitamente o motivo, é um pouco complicado de lidar.
Agora, quero apoiar a conversão envolvida IntPtr
. Tem que ser mais complicado, já que seu comprimento é variável. Decidi ver como o compilador C # o implementa.
Agora concentre-se no particular IntPtr
da Int64
conversão. Aparentemente, o comportamento desejado deve ser: ausência de operação em sistemas de 64 bits ou extensão de sinal em sistemas de 32 bits.
Como no C # o native int
é envolvido pela IntPtr
estrutura, tenho que examinar o corpo do seu Int64 op_Explicit(IntPtr)
método. O seguinte é desmontado pelo dnSpy do .NET core 3.1.1:
.method public hidebysig specialname static
int64 op_Explicit (
native int 'value'
) cil managed
{
.custom instance void System.Runtime.CompilerServices.IntrinsicAttribute::.ctor() = (
01 00 00 00
)
.custom instance void System.Runtime.Versioning.NonVersionableAttribute::.ctor() = (
01 00 00 00
)
.maxstack 8
IL_0000: ldarga.s 'value'
IL_0002: ldfld void* System.IntPtr::_value
IL_0007: conv.u8
IL_0008: ret
}
É estranho que conv.u8
apareça aqui! Ele executará uma extensão de zero em sistemas de 32 bits. Confirmei que com o seguinte código:
delegate long ConvPtrToInt64(void* ptr);
var f = ILAsm<ConvPtrToInt64>(
Ldarg, 0,
Conv_U8,
Ret
);
Console.WriteLine(f((void*)(-1))); // print 4294967295 on x86
No entanto, ao examinar as instruções x86 do seguinte método C #:
static long Convert(IntPtr intp) => (long)intp;
;from SharpLab
C.Convert(IntPtr)
L0000: mov eax, ecx
L0002: cdq
L0003: ret
Acontece que o que realmente acontece é uma extensão de sinal!
Notei que Int64 op_Explicit(IntPtr)
tem um Intrinsic
atributo. É o caso de o corpo do método ser completamente ignorado pelo JIT de tempo de execução e substituído por alguma implementação interna?
Pergunta FINAL: Preciso me referir aos métodos de conversão IntPtr
para implementar minhas conversões?
Apêndice Minha ILAsm
implementação:
static T ILAsm<T>(params object[] insts) where T : Delegate =>
ILAsm<T>(Array.Empty<(Type, string)>(), insts);
static T ILAsm<T>((Type type, string name)[] locals, params object[] insts) where T : Delegate
{
var delegateType = typeof(T);
var mi = delegateType.GetMethod("Invoke");
Type[] paramTypes = mi.GetParameters().Select(p => p.ParameterType).ToArray();
Type returnType = mi.ReturnType;
var dm = new DynamicMethod("", returnType, paramTypes);
var ilg = dm.GetILGenerator();
var localDict = locals.Select(tup => (name: tup.name, local: ilg.DeclareLocal(tup.type)))
.ToDictionary(tup => tup.name, tup => tup.local);
var labelDict = new Dictionary<string, Label>();
Label GetLabel(string name)
{
if (!labelDict.TryGetValue(name, out var label))
{
label = ilg.DefineLabel();
labelDict.Add(name, label);
}
return label;
}
for (int i = 0; i < insts.Length; ++i)
{
if (insts[i] is OpCode op)
{
if (op.OperandType == InlineNone)
{
ilg.Emit(op);
continue;
}
var operand = insts[++i];
if (op.OperandType == InlineBrTarget || op.OperandType == ShortInlineBrTarget)
ilg.Emit(op, GetLabel((string)operand));
else if (operand is string && (op.OperandType == InlineVar || op.OperandType == ShortInlineVar))
ilg.Emit(op, localDict[(string)operand]);
else
ilg.Emit(op, (dynamic)operand);
}
else if (insts[i] is string labelName)
ilg.MarkLabel(GetLabel(labelName));
else
throw new ArgumentException();
}
return (T)dm.CreateDelegate(delegateType);
}
Int64 op_Explicit(IntPtr)
do modo x64. Como isso é alcançado? Investiguei o caminho do arquivo do qual o System.Private.CoreLib
assembly é carregado (por Assembly.Location
), mas eles são os mesmos entre x86 e x64.