原始IL指令集是基于栈的指令集，优点是指令个数少、优雅、紧凑，非常适合表示虚拟机逻辑，但并不适合被解释器高效解释运行。因此我们需要将它转换为自定义的另一种能够高效 解释执行的指令集，然后再在我们的解释器中运行。
IL指令集的缺陷
- IL是基于栈的指令，运行时维护执行栈是个无谓的开销
- IL有大量单指令多功能的指令，如add指令可以用于计算int、long、float、double类型的和，导致运行时需要根据上文判断到底该执行哪种计算。不仅增加了运行时判定的开销，还增加了运行时维护执行栈数据类型的开销
- IL指令包含一些需要运行时resolve的数据，如newobj指令第一个参数是method token。token resolve是一个开销很大的操作，每次执行都进行resolve会极大拖慢执行性能
- IL是基于栈的指令，压栈退栈相关指令数较多。像a=b+c这样的指令需要4条指令完成，而如果采用基于寄存器的指令，完全可以一条指令完成。
- IL不适合做其他优化操作，如我们的InitOnce JIT技术。
- 其他
hybridclr令集设计目标
hybridclr指令集设计目标就是解决原始IL的缺陷，以及做一些更高级的优化，目前主要包含以下功能
- 指令中包含要操作的目标地址，不再需要维护栈
- 对于单指令多功能指针需要为每种操作数据类型维护一个对应指令，免去运行时维护类型及判定类型的开销。如如add指令，要特例化为add_int、add_long之类的指令
- 对于涉及到token解析的指令，尽量转换指令时直接固定，省去计算或者查询的开销。如 newobj中 method token字段，直接转变成 MethodInfo* 元数据
- 对于一些常见操作如 a = b + c，需要
ldloc b , ldloc c, add, stloc a这4条指令，我们希望提供专用指令折叠它 - 需要能与一些常见的优化技术配合，如函数inline、InitOnce动态jit技术
- 需要考虑到跨平台问题，如在armv7这种要求内存对齐的硬件上，也能高效执行
hybridclr使用经典的寄存器指令集配合一些其他运行时设施实现以上目标。
运行环境
无论指令的内容如何，指令的执行结果必须产生副作用（哪怕是nop这种什么也不干的指令，也导致当前指令寄存器ip发生变化），而这些副作用，必然作用于运行环境（甚至有可能作用于指令本身，如InitOnce技术）。正因为指令执行离不开具体的执行环境，指令设计必然跟hybridclr解释器及il2cpp运行时的运行环境紧密相关。
hybridclr函数帧栈
大多数基础指令都是操作 函数参数、局部变量、执行栈顶的数据，在hybridclr中使用数据栈来存放这些数据，并以逻辑地址（类型uint16_t）来标识要操作的数据的位置。逻辑地址是局部的，每个函数的执行栈帧的逻辑地址从0开始，最大2^16-1。
逻辑地址的布局如下
函数帧根据其嵌套顺序，在数据栈上的位置从低位向高位扩展，如下图
数据栈每个slot都为一个size=8的StackObject类型对象，每个变量可能占1个或多个slot。例如int类型变量只占一个slot，但Vector3类型变量占2个slot。
localVarBase 指针为函数帧栈的基准位置。
union StackObject
{
void* ptr; // can't adjust position. will raise native_invoke init args bugs.
bool b;
int8_t i8;
uint8_t u8;
int16_t i16;
uint16_t u16;
int32_t i32;
uint32_t u32;
int64_t i64;
uint64_t u64;
float f4;
double f8;
Il2CppObject* obj;
Il2CppString* str;
Il2CppObject** ptrObj;
};
StackObject* localVarBase;
运行时相关
除了只操作函数帧栈及当前函数状态的指令外，剩下的指令都要依赖于il2cpp运行时及hybridclr解释器执行环境MachineState提供的api才能完成功能。更细化地说，又分为几类
- metadata数据相关。如typeof指令，依赖于运行时将token转换为Il2Class*运行时metadata
- 对象相关。如 ldsfld指令 类型静态成员访问
- gc相关。如newobj指令依赖于gc相关机制分配对象内存
- 多线程相关。如ThreadStatic类型的类静态成员变量
- 其他一些特殊机制。如localloc指令依赖于 hybridclr的MachineState提供api来分配内存
指令结构
hybridclr指令结构如下
其中指令的前2字节是opcode，剩下的指令数据我们称之为指令param。param分为几种类型：
- 数据逻辑地址。
- 普通字面常量。比如
a = b + 5，其中常量5必然要体现到指令之中 - resolve后的数据。如
ldtoken，为了优化性能不想每次执行时计算token，那就必然要把运行时resolve好的token对应的元数据包含到指令中 - resolve后的数据的指针。一些指令中包含不定长度的数据，如switch语句可能包含n个case项目的跳转地址。为了让指令本身大小固定，我们将这些不定长的数据存到InterpMethodInfo的resolvedDatas中，用一个uint32_t的索引指向它的位置。
- 其他一些辅助数据
- 为了保证param内存对齐访问而插入的padding参数
跨平台兼容性
指令直接相关的跨平台兼容性问题主要是内存对齐问题。目前arm64 CPU支持非对齐的内存访问，但armv7仍然要求内存对齐，否则一旦发生非对齐访问，要么就运行效率大幅下降，要么直接导致崩溃。 尽管可以针对64位和32位设计两套完全不同的指令，但出于方便维护考虑，hybridclr还是统一使用了一套指令集。
hybridclr指令的一些设计约束：
- 每条指令的前2字节必须为opcode
- 满足内存对齐。指令param的size可能是1、2、4、8。为了满足内存对齐的要求，我们在param之间插入一些uint8_t类型的无用padding数据。
padding优化
为了最大程度减少浪费的padding数据空间，我们将所有param排序，从小到大排列，同时插入padding以满足内存对齐。经过不太复杂的推理，我们可以知道，每条指令最多浪费7字节的padding空间。
指令实现
由于IL指令众多，我们无法一一介绍所有指令对应的hybridclr指令集设计，我们分为几大类详细介绍。
空指令
如nop、pop指令，直接在transform阶段就被消除，完全不产生对应的hybridclr指令。
简单数据复制指令
典型有
- 操作函数参数的指令。如 ldarg、starg、ldarga
- 操作函数局部变量的指令。如 ldloc、stloc、ldloca
- 隐含操作eval stack栈顶数据的指令。如add、dup
对于操作函数帧栈的指令，一般要做以下几类处理
- 为源数据和目标数据添加对应的逻辑地址字段
- 对于源数据或者目标数据有多个变种的指令，统一为带逻辑地址字段的指令。如ldarg.0 - ldarg.3、ldarg、ldarg.s 都统一为一条指令。
以典型的ldarg指令为例。如果被操作函数参数的类型为int时，对应的hybridclr指令为
struct IRCommon
{
uint16_t opcode;
}
struct IRLdlocVarVar : IRCommon
{
uint16_t dst;
uint16_t src;
uint8_t __pad6;
uint8_t __pad7;
};
// 对应解释执行代码
case HiOpcodeEnum::LdlocVarVar:
{
uint16_t __dst = *(uint16_t*)(ip + 2);
uint16_t __src = *(uint16_t*)(ip + 4);
(*(uint64_t*)(localVarBase + __dst)) = (*(uint64_t*)(localVarBase + __src));
ip += 8;
continue;
}
- dst 指向当前执行栈顶的逻辑地址
- src ldarg中要加载的变量的逻辑地址
- __pad6 为了内存对齐而插入的
- __pad7 同上
需要expand目标数据的指令
根据CLI规范，像byte、sbyte、short、ushort这种size小于4的primitive类型，以及underlying type为这些primitive类型的枚举，它们被加载到evaluate stack时，需要符号扩展为int32_t类型数据。我们不想执行ldarg指令时作运行时判断，因为这样会降低性能。因此为这些size小于4的操作，单独设计了对应的指令。
以byte类型为例，对应的hybridclr指令为
struct IRLdlocExpandVarVar_u1 : IRCommon
{
uint16_t dst;
uint16_t src;
uint8_t __pad6;
uint8_t __pad7;
};
// 对应解释执行代码
case HiOpcodeEnum::LdlocExpandVarVar_u1:
{
uint16_t __dst = *(uint16_t*)(ip + 2);
uint16_t __src = *(uint16_t*)(ip + 4);
(*(int32_t*)(localVarBase + __dst)) = (*(uint8_t*)(localVarBase + __src));
ip += 8;
continue;
}
静态特例化的指令
有一类指令的实际执行方式跟它的参数类型有关，如add。当操作的数是int、long、float、double时，执行对应类型的数据相加操作。但实际上由于IL程序的静态性，每条指令操作的数据类型肯定是固定的，并不需要运行时维护数据类型，并且根据数据类型决定执行什么操作。我们使用一种叫静态特例化的技术，为这种指令设计了多条hybridclr指令，在transform时，根据具体的操作数据类型，生成相应的指令。
以add 对两个int32_t类型数据相加为例
struct IRBinOpVarVarVar_Add_i4 : IRCommon
{
uint16_t ret;
uint16_t op1;
uint16_t op2;
};
// 对应解释执行代码
case HiOpcodeEnum::BinOpVarVarVar_Add_i4:
{
uint16_t __ret = *(uint16_t*)(ip + 2);
uint16_t __op1 = *(uint16_t*)(ip + 4);
uint16_t __op2 = *(uint16_t*)(ip + 6);
(*(int32_t*)(localVarBase + __ret)) = (*(int32_t*)(localVarBase + __op1)) + (*(int32_t*)(localVarBase + __op2));
ip += 8;
continue;
}
直接包含常量的指令
有一些指令包含普通字面常量，如ldc指令。相应的寄存器指令只是简单地添加了相应大小的字段。
以ldc int32_t类型数据为例
struct IRLdcVarConst_4 : IRCommon
{
uint16_t dst;
uint32_t src;
};
// 对应解释执行代码
case HiOpcodeEnum::LdcVarConst_4:
{
uint16_t __dst = *(uint16_t*)(ip + 2);
uint32_t __src = *(uint32_t*)(ip + 4);
(*(int32_t*)(localVarBase + __dst)) = __src;
ip += 8;
continue;
}
隐含常量的指令
有一些指令隐含了所操作的常量，如 ldnull、ldc.i4.0 - ldc.i4.8 等等。对于这类指令，如果有对应的直接包含常量的指令的实现，则简单转换为 上一节中介绍的 直接包含常量的指令。后续可能会进一步优化。
以ldnull为例
struct IRLdnullVar : IRCommon
{
uint16_t dst;
uint8_t __pad4;
uint8_t __pad5;
uint8_t __pad6;
uint8_t __pad7;
};
// 对应解释执行代码
case HiOpcodeEnum::LdnullVar:
{
uint16_t __dst = *(uint16_t*)(ip + 2);
(*(void**)(localVarBase + __dst)) = nullptr;
ip += 8;
continue;
}
指令共享
为了减少指令数量，操作相同size常量的ldc指令会被合并为同一个。如ldloc.r4 指令就被合并到ldloc.i4指令的实现。
包含resolved后数据的指令
有一些指令包含metadata token，如sizeof、ldstr、newobj。为了避免巨大的运行时resolve开销，hybridclr在transform这些指令时就已经将包含token数据resolve为对应的runtime metadata。
更细致一些，又分为两类。
直接包含resolved后数据的指令
以sizeof为例，原始指令token为类型信息，transform时，直接计算了对应ValueType的size，甚至都不需要专门为sizeof设计对应的指令，直接使用现成的LdcVarConst_4指令。
case OpcodeValue::SIZEOF:
{
uint32_t token = (uint32_t)GetI4LittleEndian(ip + 2);
Il2CppClass* objKlass = image->GetClassFromToken(token, klassContainer, methodContainer, genericContext);
IL2CPP_ASSERT(objKlass);
int32_t typeSize = GetTypeValueSize(objKlass);
CI_ldc4(typeSize, EvalStackReduceDataType::I4);
ip += 6;
continue;
}
间接包含resolved后数据的指令
像ldstr、newobj这些指令包含的token经过resolve后，变成对应runtime metadata的指针，考虑到指针在不同平台大小不一，因此不直接将这个指针放到指令中，而是换成一个uint32_t类型的指向InterpMethodInfo::resolvedData字段的index param。执行过程中需要一次向resolvedData的查询操作，时间复杂度为O(1)。
以newobj指令为例
struct IRLdstrVar : IRCommon
{
uint16_t dst;
uint32_t str;
};
// 对应解释执行代码
case HiOpcodeEnum::LdstrVar:
{
uint16_t __dst = *(uint16_t*)(ip + 2);
uint32_t __str = *(uint32_t*)(ip + 4);
(*(Il2CppString**)(localVarBase + __dst)) = ((Il2CppString*)imi->resolveDatas[__str]);
ip += 8;
continue;
}
分支跳转指令
原始IL字节码使用了相对offset的跳转目标，并且几乎为每条跳转相关指令都设计了near和far offset 两条指令，hybridclr为了简单起见，直接使用4字节的绝对跳转地址。
以br无条件跳转指令为例
struct IRBranchUncondition_4 : IRCommon
{
uint8_t __pad2;
uint8_t __pad3;
int32_t offset;
};
// 对应解释执行代码
case HiOpcodeEnum::BranchUncondition_4:
{
int32_t __offset = *(int32_t*)(ip + 4);
ip = ipBase + __offset;
continue;
}
offset为转换后的指令地址的绝对偏移。
对象成员访问指令
由于字段在对象中的偏移已经完全确定，transform时计算出字段在对象中的偏移，保存为指令的offset param, 执行时根据对象大小，使用this指针和偏移，直接访问字段数据。
以ldfld 读取int类型字段为例
struct IRLdfldVarVar_i4 : IRCommon
{
uint16_t dst;
uint16_t obj;
uint16_t offset;
};
// 对应解释执行代码
case HiOpcodeEnum::LdfldVarVar_i4:
{
uint16_t __dst = *(uint16_t*)(ip + 2);
uint16_t __obj = *(uint16_t*)(ip + 4);
uint16_t __offset = *(uint16_t*)(ip + 6);
CHECK_NOT_NULL_THROW((*(Il2CppObject**)(localVarBase + __obj)));
(*(int32_t*)(localVarBase + __dst)) = *(int32_t*)((uint8_t*)(*(Il2CppObject**)(localVarBase + __obj)) + __offset);
ip += 8;
continue;
}
ThreadStatic 成员访问指令
在初始化Il2CppClass时，如果它包含ThreadStatic属性标记的静态成员变量，则为它分配一个可以放下这个类型所有ThreadStatic变量的ThreadLocalStorage的连续空间。 借助于il2cpp运行时对ThreadStatic的支持，相关指令实现相当简单直接。
以ldsfld指令为例
struct IRLdthreadlocalVarVar_i4 : IRCommon
{
uint16_t dst;
int32_t offset;
int32_t klass;
};
// 对应解释执行代码
case HiOpcodeEnum::LdthreadlocalVarVar_i4:
{
uint16_t __dst = *(uint16_t*)(ip + 2);
uint32_t __klass = *(uint32_t*)(ip + 8);
int32_t __offset = *(int32_t*)(ip + 4);
Il2CppClass* _klass = (Il2CppClass*)imi->resolveDatas[__class];
Interpreter::RuntimeClassCCtorInit(_klass);
(*(int32_t*)(localVarBase + __dst)) = *(int32_t*)((byte*)il2cpp::vm::Thread::GetThreadStaticData(_klass->thread_static_fields_offset) + __offset);
ip += 16;
continue;
}
数组访问相关指令
比较常规直接，不过有个特殊点：根据规范index变量可以是i4或者native int类型。由于数组访问是非常频繁的操作，我们不想插入运行时数据类型类型及转换，因为我们根据index变量的size为每条数组相关指令设计了2条hybridclr指令。
以ldelem.i4 指令的index是i4类型的情形为例
struct IRGetArrayElementVarVar_i4_4 : IRCommon
{
uint16_t dst;
uint16_t arr;
uint16_t index;
};
// 对应解释执行代码
case HiOpcodeEnum::GetArrayElementVarVar_i4_4:
{
uint16_t __dst = *(uint16_t*)(ip + 2);
uint16_t __arr = *(uint16_t*)(ip + 4);
uint16_t __index = *(uint16_t*)(ip + 6);
Il2CppArray* arr = (*(Il2CppArray**)(localVarBase + __arr));
CHECK_NOT_NULL_AND_ARRAY_BOUNDARY(arr, (*(int32_t*)(localVarBase + __index)));
(*(int32_t*)(localVarBase + __dst)) = il2cpp_array_get(arr, int32_t, (*(int32_t*)(localVarBase + __index)));
ip += 8;
continue;
}
函数调用指令
目前调用AOT函数和调用Interpreter函数使用不同的指令，因为Interpreter函数可以直接复用已经压到栈顶的数据，可以完全优化掉 Manged2Native -> Native2Managed 这个过程，提升性能。
调用解释器函数时可以复用当前 InterpreterModule::Execute函数帧，也节省了函数调用开销，同时也避免了解释器嵌套调用过深导致native栈overflow的问题。
对于带返回值的函数，由于多了一个返回值地址参数ret，与返回void的函数分别设计了不同指令。
如果调用的是AOT函数，由于每条函数的参数不定，我们将参数信息记录到resolvedDatas，然后argIdxs中保存这个间接索引。另外还需要通过桥接函数完成解释器函数参数到native abi函数参数的转换，为了避免运行时查找的开销，也提前计算了这个桥接函数，记录到resolvedDatas中，然后在managed2NativeMethod中保存了这个间接索引。
以call指令为例，为它设计了5条指令
- IRCallNative_void
- IRCallNative_ret
- IRCallNative_ret_expand
- IRCallInterp_void
- IRCallInterp_ret
以IRCallNative_ret的实现为例，介绍调用AOT函数的指令：
struct IRCallNative_ret : IRCommon
{
uint16_t ret;
uint32_t managed2NativeMethod;
uint32_t methodInfo;
uint32_t argIdxs;
};
// 对应解释执行代码
case HiOpcodeEnum::CallNative_ret:
{
uint32_t __managed2NativeMethod = *(uint32_t*)(ip + 4);
uint32_t __methodInfo = *(uint32_t*)(ip + 8);
uint32_t __argIdxs = *(uint32_t*)(ip + 12);
uint16_t __ret = *(uint16_t*)(ip + 2);
void* _ret = (void*)(localVarBase + __ret);
((Managed2NativeCallMethod)imi->resolveDatas[__managed2NativeMethod])(((MethodInfo*)imi->resolveDatas[__methodInfo]), ((uint16_t*)&imi->resolveDatas[__argIdxs]), localVarBase, _ret);
ip += 16;
continue;
}
如果调用Interpreter函数，由于函数参数已经按顺序压到栈上，只需要一个argBase参数指定arg0逻辑地址即可，不需要借助resolvedDatas，也不需要managed2NativeMethod桥接函数指针。 这也是解释器函数不受桥接函数影响的原因。
以IRCallInterp_ret为例，介绍调用Interpreter函数的指令：
struct IRCallInterp_ret : IRCommon
{
uint16_t argBase;
uint16_t ret;
uint8_t __pad6;
uint8_t __pad7;
uint32_t methodInfo;
};
// 对应解释执行代码
case HiOpcodeEnum::CallInterp_ret:
{
MethodInfo* __methodInfo = *(MethodInfo**)(ip + 8);
uint16_t __argBase = *(uint16_t*)(ip + 2);
uint16_t __ret = *(uint16_t*)(ip + 4);
CALL_INTERP_RET((ip + 16), __methodInfo, (StackObject*)(void*)(localVarBase + __argBase), (void*)(localVarBase + __ret));
continue;
}
异常机制相关指令
异常机制相关指令本身不复杂，但异常处理机制非常复杂。
异常这种特殊的流程控制指令，跟分支跳转指令相似，原始指令里包含了相对offset，为了简单起见，指令转换时我们改成int32_t类型的绝对offset。
以leave指令为例
struct IRLeaveEx : IRCommon
{
uint8_t __pad2;
uint8_t __pad3;
int32_t offset;
};
// 对应解释执行代码
case HiOpcodeEnum::LeaveEx:
{
int32_t __offset = *(int32_t*)(ip + 4);
LEAVE_EX(__offset);
continue;
}
一些额外的instinct 指令
对于一些特别常见的函数，为了优化性能，hybridclr直接内置了相应的指令，例如 new Vector{2,3,4}，如可空变量相关操作。这些instinct指令的执行性能基本与AOT持平。
以 new Vector3() 为例
struct IRNewVector3_3 : IRCommon
{
uint16_t obj;
uint16_t x;
uint16_t y;
uint16_t z;
uint8_t __pad10;
uint8_t __pad11;
uint8_t __pad12;
uint8_t __pad13;
uint8_t __pad14;
uint8_t __pad15;
};
// 对应解释执行代码
case HiOpcodeEnum::NewVector3_3:
{
uint16_t __obj = *(uint16_t*)(ip + 2);
uint16_t __x = *(uint16_t*)(ip + 4);
uint16_t __y = *(uint16_t*)(ip + 6);
uint16_t __z = *(uint16_t*)(ip + 8);
*(HtVector3f*)(*(void**)(localVarBase + __obj)) = {(*(float*)(localVarBase + __x)), (*(float*)(localVarBase + __y)), (*(float*)(localVarBase + __z))};
ip += 16;
continue;
}
InitOnce 指令
有一些指令（如ldsfld）第一次执行的时候需要进行初始化操作，但后续再次执行时，不需要再执行初始化操作。但即使这样，免不了一个检查是否已经初始化的操作，我们希望完全优化掉这个检查行为。InitOnce动态JIT技术用于解决这个问题。
InitOnce是hybridclr的专利技术，暂未在代码中实现，这儿不详细介绍。
其他技术相关指令
限于篇幅，对于这些指令，会在单独的文章中介绍
总结
至此我们完成hybridclr指令集实现相关介绍。