ILBC 规范

本文是 VMBC / D# 项目的系列文章，

有关 VMBC / D# ，见《我发起并创立了一个 VMBC 的子项目 D#》（以下简称《D#》） https://www.cnblogs.com/KSongKing/p/10348190.html 。

ILBC 系列文章收录在《ILBC 白皮书》 https://www.cnblogs.com/KSongKing/p/11070978.html 。

ILBC 规范：

加载程序集：

ILBC 程序集有 2 种，

1 Byte Code 程序集，扩展名为 .ilb，表示 “ILBC Byte Code” 。

2 Native Code 程序集，扩展名遵循操作系统定义的动态链接库规范，比如 Windows 上就是 .dll 文件，

Native Code 程序集就是操作系统定义的动态链接库。

假设操作系统是 Windows，程序集名字是 A，加载 A 的过程是：

在当前目录下先查找 A.ilb，若存在则 JIT 编译 A.ilb 为本地代码 A.dll，加载 A.dll，

若找不到 A.ilb，则找 A.dll，若存在则加载 A.dll 。

加载本地库 A.dll 的方式遵循操作系统定义的动态链接规范。

JIT 编译 A.ilb 为本地代码并加载的过程可以在内存中完成，不一定要生成文件 A.dll （如果技术上可以实现在内存中加载的话）。

高级语言（D#）编译的过程：

高级语言（D#）编译有 2 种方式，

1 AOT，高级语言（D#）编译器先根据高级语言（D#）源代码生成 C 语言中间代码，再由 InnerC （InnerC to Byte Code）编译为表达式树，再由 InnerC（Byte Code to Native Code）把表达式树生成为 Native Code 。 Native Code 是一个本地库，比如 .dll 。

2 JIT ，高级语言（D#）编译器先根据高级语言（D#）源代码生成 C 语言中间代码，再由 InnerC （InnerC to Byte Code）编译为表达式树，把表达式树序列化得到 Byte Code，将 Byte Code 保存为 ilb 文件即得到 Byte Code 程序集（.ilb）。

.ilb 在运行的时候由 ILBC 运行时的 InnerC (Byte Code to Native Code) 把 Byte Code 反序列化为表达式树，再把表达式树编译为 Native Code 。

把 Native Code 程序集加载到应用程序后， ILBC 运行时会调用程序集的 ILBC_Load() 函数， ILBC_Load() 会创建一个 ILBC_Assembly 结构体，并返回这个结构体的指针， ILBC_Assembly 结构体包含了程序集的元数据信息，类似 .Net / C# 中的 System.Reflection.Assembly 。

元数据就是一堆结构体（Struct），这些 Struct 及 ILBC_Load() 函数的代码是由高级语言（D#）编译器生成，代码如下：

struct ILBC_Assembly

{

ILBC_ClassLoader classLoaderList [ n ] ; // n 是程序集中 Class 的数量，由高级语言（D#）编译器在编译时指定

// classLoader 包含了加载 Class 的函数的函数指针（保存在 load 字段里）

// 每个 Class 有一个 classLoader，

// classLoaderList 是保存 classLoader 的数组，

// 在 ILBC 运行时加载 Class 时会调用 classLoader.load 保存的函数指针指向的函数，具体内容见下文

// Class 加载完成得到的 Type 对象保存在 type 字段里

}

struct ILBC_ClassLoader

{

char * className ; // Class 名字

void * load ; // 加载 Class 的函数的函数指针

ILBC_Type * type = 0 ; // 加载 Class 完成后把 Type 对象保存在这里

}

struct ILBC_Type

{

char * name ; // Class 名字

int size ; // Class 占用的空间大小（字节数）

ILBC_Field fieldList [ n ] ; // n 是 Class 中 Field 的数量，由高级语言（D#）编译器在编译时指定

int fieldCount ; // C 语言数组的长度需要自己记录

ILBC_Method methodList [ n ] ; // n 是 Class 中 Method 的数量，由高级语言（D#）编译器在编译时指定

int methodCount ; // C 语言数组的长度需要自己记录

}

struct ILBC_Field

{

char name [ n ] = "字段名" ; // n 应和字段名字符串的字节数相等， n 由高级语言（D#）编译器在编译时指定

int size; // 字段占用的字节数

int offset; // 字段相对于 ILBC_Field 结构体的首地址的偏移量

// ILBC_Type * type ;

char * type ; // type 不能声明为 ILBC_Type 或者 ILBC_Type * 类型，因为会造成 Type 和 Field 之间的循环引用，

// 所以先声明为 char * （字符串），保存 Type 的名字，通过 GetFieldType() 之类的方法来返回 Type 对象，

// Type 对象就相当于这里的 ILBC_Type 或者 ILBC_Type * 。

}

struct ILBC_Method

{

char name [ n ] = "方法名"; // n 应和方法名字符串的字节数相等， n 由高级语言（D#）编译器在编译时指定

ILBC_Argument * argList [ n ] ; // n 是方法中参数的数量，由高级语言（D#）编译器在编译时指定

Type * returnValue ; // 返回值类型

void * funcPtr ; // Method 对应的函数指针

}

struct ILBC_Argument

{

char name [ n ] = "参数名"; // n 应和参数名字符串的字节数相等， n 由高级语言（D#）编译器在编译时指定

ILBC_Type * type; // 参数类型

}

看到这里，是不是跟 C# 反射里的 AssemblyInfo， Type， FieldInfo， MethodInfo 很像？

是的， ILBC 也要支持完整的元数据架构，元数据用于动态链接和反射。

接下来是 ILBC_Load() 相关的代码：

假设程序集名字是 B，包含了 Person 类和 Animal 类 2 个类， Person 类有 2 个字段 name, age，有 2 个方法 Sing(0， Smile() ，

void * ILBC_ClassLoaderList_B [ 2 ] ; // 数组长度 2 表示 B 程序集包含了 2 个类

ILBC_Assembly * ILBC_Load()

{

ILBC_Assembly * assembly = ILBC_gcNew( sizeof ( ILBC_Assembly ) ) ;

assembly.classLoaderList [ 0 ].className = "Person" ;

assembly.classLoaderList [ 0 ].load = & ILBC_LoadClass_B_Person ;

assembly.classLoaderList [ 1 ].className = "Animal" ;

assembly.classLoaderList [ 1 ].load = & ILBC_LoadClass_B_Animal ;

return assembly ;

}

ILBC_Type * ILBC_LoadClass_B_Person()

{

ILBC_Type * type = ILBC_gcNew ( sizeof ( ILBC_Type ) );

// ILBC_gcNew( ) 是 ILBC 提供的一个库函数，用于在堆里申请一块空间，这里是在堆里创建一个 ILBC_Type 结构体

type.name = "Person";

type.size = 8; // Class 占用的空间大小（字节数）， name 字段是 char * 类型，假设指针是 32 位地址，占用 4 个字节， age 是 int 类型，假设是 32 位整数，占用 4 个字节，那么 Class 的占用字节数就是 4 + 4 = 8，即 size = 8; ， size 是由编译器计算决定的

type.fieldList [ 0 ].name = "name";

type.fieldList [ 0 ].size = // String 是引用类型，所以这里是引用的 Size

type.fieldList [ 0 ].type = "String"; // 假设基础库提供了 String 类型

type.fieldList [ 1 ].name = "age";

type.fieldList [ 1 ].size = 4; // 假设 int 是 32 位整数类型

type.fieldList [ 1 ].type = "Int32"; // 假设 int 是 32 位整数类型，且基础库提供的 32 位整数类型是 Int32

type.methodList [ 0 ].name = "Sing";

// 因为 Sing() 方法没有参数，所以 argList [ 0 ] 长度为 0，不用初始化

type.methodList [ 0 ].funcPtr = & ILBC_Class_B_Sing; // ILBC_Class_B_Sing 是 Sing() 方法对应的函数，由编译器生成

type.methodList [ 1 ].name = "Smile";

// 因为 Smile() 方法没有参数，所以 argList [ 0 ] 长度为 0，不用初始化

type.methodList [ 1 ].funcPtr = & ILBC_Class_B_Smile; // ILBC_Class_B_Smile 是 Smile() 方法对应的函数，由编译器生成

return type;

}

ILBC_LoadClass_B_Animal() 函数和 ILBC_LoadClass_B_Person() 函数类似。

当程序中第一次用到程序集时， ILBC 运行时（调度程序）才会加载程序集，

第一次用到程序集是指第一次用到程序集里的类，

第一次用到类是指第一次创建对象（ new 类() ）或者第一次调用静态方法（类.静态方法() ）、第一次访问静态字段（类.静态字段）这 3 种情况。

类也是在第一次用到时加载，

当然，第一次加载程序集是一定会加载一个类，但其它的类会在用到时才加载。

加载类完成时会调用类的静态构造函数。

调度程序加载完程序集后，会把程序集的 ILBC_Load() 返回的 ILBC_Assembly 结构体的指针保存到一个名字是 ILBC_AssemblyList 的链表里，

新加载的程序集的 ILBC_Assembly 结构体的指针会追加到这个链表里。

ILBC_AssemblyList 是调度程序里的一个全局变量：

ILBC_LinkedList * ILBC_AssemblyList ;

ILBC_LinkedList 是一个链表实现， ILBC_LinkedList 本身是一个结构体，定义见下文，再配合一些向链表追加元素、删除元素等函数就是一个链表实现，函数的部分略。

struct ILBC_LinkedList

{

ILBC_LinkedListNode * first ; // 链表头指针

ILBC_LinkedListNode * last ; // 链表尾指针

}

struct ILBC_LinkedListNode

{

ILBC_LinkedListNode * before ; // 上一个节点

ILBC_LinkedListNode * next ; // 下一个节点

void * element ; // 节点包含的元素，就是实际存放的数据

}

假设有 A 、B 2 个程序集， A 引用了 B，

B 中包含 Class Person， Person 有构造函数 Person() { } ，那么， A 中 new Person() 的代码会被编译成：

void * ILBC_Class_Person_Constructor = 0 ; // 这是 A 里的全局变量，表示 Person 的构造函数的函数指针， 0 表示空指针，也表示未初始化

……

// 代码中调用 Person 类构造函数的代码

// ILBC_Class_Person 是高级语言（D#）编译器生成的表示 Person 类的 Struct，包含了 Person 类的字段

if ( ! ILBC_ifClassInit_Person )

{

ILBC_Init_Linked_Class_Person() ; // 初始化 Person 类

}

// ILBC_Linked_ClassSize_Person 是一个全局变量，表示 Person 类占用的空间大小（字节数）

void * person = ILBC_gcNew( ILBC_Linked_ClassSize_Person );

// Person 类初始化后，构造函数指针 ILBC_Linked_Class_Person_Constructor 就被初始化了（填入了 Person 构造函数的地址），就可以调用了

ILBC_Linked_Class_Person_Constructor ( person ); // 调用 Person 类构造函数，把 person 结构体指针传给构造函数进行初始化

调用 Person 类的静态字段和静态方法的代码和上面类似，只需要把最后一句代码换成：

字段类型变量 = * ILBC_Linked_Class_Person_静态字段名 ; // 访问静态字段

ILBC_Linked_Class_Person_静态函数名 ( 参数列表 ) ; // 调用静态函数

ILBC_ifClassInit_Person 是一个全局变量，表示 Person 类是否已经初始化，定义如下：

char ILBC_ifClassInit_Person = 0 ;

B 程序集的 Person 类在 A 程序集里的 “初始化” 是指完成了 Person 类在 A 里的链接工作，初始化完成后， A 的代码就可以访问 Person 类了。

访问 Person 类包括创建对象（new Person() ）、调用函数、访问字段。

链接工作包括

类链接，向 A 里定义好的保存 Person 类的占用空间大小（Size (字节数)）的全局变量写入类的占用空间大小（Size (字节数)），

字段链接是向 A 里定义好的保存 Person 类的各个字段的偏移量的变量写入字段的偏移量，

函数链接是向 A 里定义好的保存 Person 类的各个方法的函数地址（函数指针）的变量写入函数地址，包括构造函数和成员函数。

ILBC_Linked_Class_Person_Constructor 是一个全局变量，表示 Person 类的构造函数的函数指针，定义如下：

void * ILBC_Linked_Class_Person_Constructor ;

ILBC_Init_Linked_Class_Person () 的代码如下：

ILBC_Init_Linked_Class_Person ()

{

lock ( ILBC_ifClassInit_Person )

{

if ( ! ILBC_ifClassInit_Person )

{

ILBC_Type * type = ILBC_Runtime_GetType( "B", "Person" ) ; // 参数 "B" 表示程序集名字， "Person" 表示类名

ILBC_Linked_ClassSize_Person = type.size ;

// ILBC_Linked_Class_Person_name 是保存 Person 类 name 字段偏移量的全局变量，由编译器生成，值需要在加载类的时候初始化，也就是下面的代码里初始化

// ILBC_Linked_ClassFieldType_Person_name 是保存 Person 类 name 字段类型（类型名字）的常量，由编译器生成，值由编译器给出，值就是 name 字段的类型的名字

ILBC_Init_Linked_Class_Field( & ILBC_Linked_Class_Person_name, ILBC_Linked_ClassFieldType_Person_name, "name", type ); // 初始化 name 字段的偏移量

ILBC_Init_Linked_Class_Field( & ILBC_Linked_Class_Person_age, ILBC_Linked_ClassFieldType_Person_age, "age", type ); // 初始化 age 字段的偏移量

// 如果有静态字段，也是同样的初始化，不过静态字段应该不是初始化偏移量，而是直接是地址，

// 静态字段的指针变量比如 “变量类型 * ILBC_Linked_Class_Person_静态字段名 ;”

ILBC_Init_Linked_Class_Person_Constructor( type ); // 初始化构造函数的函数指针

ILBC_Init_Linked_Class_Method( & ILBC_Linked_Class_Person_Sing, "Sing", type ); // 初始化 Sing() 函数的函数指针

ILBC_Init_Linked_Class_Method( & ILBC_Linked_Class_Person_Smile "Smile", type ); // 初始化 Smile() 函数的函数指针

// 如果有静态方法，也是同样的初始化，静态方法的指针变量比如 “void * ILBC_Init_Linked_Class_Person_静态方法名 ;”

ILBC_ifClassInit_Person = 1 ;

}

void ILBC_Init_Linked_Class_Field( int * fieldOffsetVar, char * fieldType, char * name， ILBC_Type * type )

{

for (int i = 0; i<type.fieldCount; i++)

{

ILBC_Field * field = & type.fieldList [ i ];

if ( field.name == name ) // 这句代码是伪码，意思是判断 2 个字符串是否相等

{

// 我们这里判断类型是否相同是不严格的，只是判断了名字

// 这里涉及到类型检查和类型安全，详细讨论见文章最后总结部分

if ( field.type ! = fieldType ) // 这句代码是伪码，意思是判断 2 个字符串是否相等

throw new Exception ( "名字为 " + name + " 的字段的类型与引用的元数据里的类型不符。" ); // 这句代码是伪码，应该是函数增加一个 errorCode 参数，通过 errorCode 参数返回异常

* fieldOffsetVar = field -> offset;

return ;

}

throw new Exception( "找不到名字是 " + name + " 的字段。" ); // 这句代码是伪码，应该是函数增加一个 errorCode 参数，通过 errorCode 参数返回异常

}

void ILBC_Init_Linked_Class_Method ( void * funcPtrVar, char * name, ILBC_Type * type )

{

for (int i = 0; i<type.methodCount; i++)

{

ILBC_Method * method = & type.methodList [ i ];

if ( method.name == name ) // 这句代码是伪码，意思是判断 2 个字符串是否相等

{

* funcPtrVar = method -> funcPtr;

return ;

}

throw new Exception( "找不到名字是 " + name + " 的方法。" ); // 这句代码也是伪码，应该是函数增加一个 errorCode 参数，通过 errorCode 参数返回异常

}

相关的全局变量 / 常量总结如下：

char ILBC_ifClassInit_Person = 0 ; // Person 类是否已初始化

int ILBC_Linked_ClassSize_Person ; // Person 类占用的空间大小（字节数），值由编译器在编译 A 项目时根据 B 的元数据给出

int ILBC_Linked_Class_Person_name ; // Person 类 name 字段的偏移量

int ILBC_Linked_Class_Person_age ; // Person 类 age 字段的偏移量

const char * ILBC_Linked_ClassFieldType_Person_name ; // Person 类 name 字段的类型（类型名字）

const char * ILBC_Linked_ClassFieldType_Person_age ; // Person 类 age 字段的类型（类型名字）

void * ILBC_Linked_Class_Person_Constructor ; // Person 类的构造函数函数指针

void * ILBC_Linked_Class_Person_Sing ; // Person 类的 Sing 方法函数指针

void * ILBC_Linked_Class_Person_Smile ; // Person 类的 Smile 方法函数指针

看到这里，大家可能会问，如果构造函数和方法有重载怎么办？

确实有这个问题，这个需要再作进一步的细化设计，现在先略过。

ILBC_Runtime_GetType() 函数的定义如下：

ILBC_Type * ILBC_Runtime_GetType( char * assemblyName, char * typeName )

{

先在 ILBC_AssemblyList 中查找名字是 assemblyName 的程序集是否已存在，

如果不存在，就先加载程序集，

加载程序集的过程上文中提过，就是先把程序集加载到应用程序，再调用程序集的 ILBC_Load() 函数，返回一个 ILBC_Assembly 结构体的指针，

调度程序把这个结构体指针保存到 ILBC_AssemblyList 这个链表里。

找到程序集后，再在 assembly.classLoaderList 里找名字是 className 的 classLoader，

找到 classLoader 以后，看 classLoader.type 字段是否是空指针（0），如果是，就说明 Class 还没有加载，

就加载 Class，加载 Class 得到的 Type 对象就存放在 classLoader.type 字段里。

加载 Class 的过程上文中讲述过，假设加载 B 程序集的 Person 对象，

就是调用 B 程序集里的 ILBC_LoadClass_B_Person() 函数，该函数加载 Person 类，并返回表示 Person 类的 Type 对象的 ILBC_Type 结构体的指针。

调用类的静态构造函数 ************* 这里加个着重号，类加载完成后调用类的静态构造函数

返回 ILBC_Type 结构体的指针。

}

访问 Person 对象的字段的代码是：

void * person ;

……

char * name = * ( person + ILBC_Linked_Class_Person_name ) ;

int age = * ( person + ILBC_Linked_Class_Person_age ) ;

调用 Person 对象的方法的代码是：

void * person ;

ILBC_Linked_Class_Person_Sing ( person ) ; // 调用 Sing() 方法， person 参数是 this 指针

ILBC_Linked_Class_Person_Smile ( person ) ; // 调用 Smile() 方法， person 参数是 this 指针

总结一下：

ILBC 的链接是类似 .Net / C# 的动态链接，

ILBC 的链接以程序集为单位，采用延迟加载（Lazy Load）的方式，只有用到程序集的时候才加载， “用到” 是指第一次用到程序集里的类（Class）。

将程序集加载到应用程序以后，对程序集里的类（Class）也采用延迟加载（Lazy Load）的方式，

第一次用到类的时候才会初始化类的链接表，链接表初始化完成后，就可以调用类了，包括创建对象，访问字段和方法。

链接表不是一个 “表”，而是一堆全局变量 / 常量，就是上文中列举出的全局变量 / 常量，这里再列举出来看看：

char ILBC_ifClassInit_Person = 0 ; // Person 类是否已初始化

int ILBC_Linked_ClassSize_Person ; // Person 类占用的空间大小（字节数），值由编译器在编译 A 项目时根据 B 的元数据给出

int ILBC_Linked_Class_Person_name ; // Person 类 name 字段的偏移量

int ILBC_Linked_Class_Person_age ; // Person 类 age 字段的偏移量

const char * ILBC_Linked_ClassFieldType_Person_name ; // Person 类 name 字段的类型（类型名字）

const char * ILBC_Linked_ClassFieldType_Person_age ; // Person 类 age 字段的类型（类型名字）

void * ILBC_Linked_Class_Person_Constructor ; // Person 类的构造函数函数指针

void * ILBC_Linked_Class_Person_Sing ; // Person 类的 Sing 方法函数指针

void * ILBC_Linked_Class_Person_Smile ; // Person 类的 Smile 方法函数指针

这些全局变量是 A 里定义的，是 A 里引用 B 的链接表。

注意， Class 的加载是在 ILBC 运行时里进行的，一个 Class 的加载对于整个应用程序只进行一次，

Class 的链接表初始化（Init）是和程序集相关的，假设有 A 、B 、C 3 个程序集引用了 D 程序集，

那么当 A 用到 D 的时候，会初始化 A 里引用 D 的链接表，

当 B 用到 D 的时候，会初始化 B 里引用 D 的链接表，

当 C 用到 D 的时候，会初始化 C 里引用 D 的链接表。

链接表是属于程序集的，假设 A 引用了 B C D，那么 A 里会有 B C D 的链接表，

也就是说上面的全局变量会在 A 里声明 3 组，分别对应 B C D 程序集。

说到这里，我们会发现，上面的全局变量的命名没有包含程序集的名字，比如 ILBC_Linked_Class_Person_name，

这个表示 Person 类的 name 字段的偏移量，

但是并没有表示出 Person 类是哪一个程序集的。

所以，应该给变量增加一个分隔符（连接符）来分隔（连接）各项信息，

我们规定， InnerC 应支持在变量名里使用 "<>" 字符串，这样可以使用 "<>" 来分隔（连接）各项信息。

注意，是 "<>" 字符串，不是 "<"，也不是 ">" ，也不是 "< …… >" ，

比如， a<>b 这个变量名是合法的， a<b 是不合法的， a>b 是不合法的， a<b>c 这个变量名也是不合法的。

ILBC_Linked_Class_Person_name 可以这样来表示：

ILBC_Linked<>B<>Person<>name ，这表示链接（引用）的 B 程序集的 Person 类的 name 字段的偏移量

"<>" 字符串在 D# 里是不能用于程序集名字空间类字段方法的名字的，所以可以在 C 中间语言里用在变量名里作为分隔符（连接符）。

ILBC 运行时调度程序应提供以下函数：

ILBC_Type * ILBC_Runtime_GetType( char * assemblyName, char * typeName )

该函数用于返回指定的程序集名的程序集中指定的类名的类的 Type 对象

ILBC_Type 是调度程序中定义的结构体，为了能让程序集访问，需要高级语言（D#）编译器引用调度程序发布的头文件（.h 文件），

这个头文件我们可以命名为 ILBC_Runtime.h ，里面会包含 ILBC_Assembly 、ILBC_ClassLoader 、ILBC_Type 、ILBC_Field 、ILBC_Method 、ILBC_Argument 等结构体定义。

void * ILBC_Runtime_heapNew ( int size )

该函数用于从堆里分配一块指定大小的内存块，参数 size 是内存块大小（字节数）。返回值是内存块指针。

ILBC 运行时自己实现了一个堆和 GC 。

当然对应的还会有一个 void ILBC_Runtime_heapFree ( void * ptr, int size ) 函数，

C 语言里的 void free(void *ptr); 是没有 size 参数的， So 。

没事，这个可以保留讨论。

ILBC 程序集应提供以下函数：

ILBC_Assembly * ILBC_Load()

该函数在 ILBC 运行时调度程序加载程序集时调用，负责程序集的初始化工作，

包括创建一个 ILBC_Assembly 结构体，并初始化 ILBC_Assembly 结构体的 classLoaderList 字段，可以参考上文代码。

ILBC 运行时调度程序接收到程序集的 ILBC_Load() 函数返回的 ILBC_Assembly 结构体指针后，会将该指针保存到 ILBC_AssemblyList 中，

ILBC_Assembly 是调度程序里的一个全局变量，是一个链表。

说到链表，调度程序里保存 Assembly 的列表 ILBC_AssemblyList 是链表，

Assembly 里保存 Type 的列表 classLoaderList 是数组，

Type 里保存 Field 、Method 的列表 fieldList, methodList 也是数组，

而上文中根据名字查找 Field 、Method 的算法是遍历数组，查找 Assembly 、Type 的部分虽然没有直接用代码写出来，但应该是遍历链表 / 数组。

从性能优化的角度来看，根据名字查找成员（Assembly, Type, Field, Method 等）应该优化为查找 Hash 表，

这个优化关系到加载程序集和类的效率，也是反射的效率。

动态链接程序集，加载程序集和类，就是一个反射的过程。

相传 .Net 2.0 对反射性能进行了优化，使得反射性能得到了明显的提升，大概也是加入了 Hash 表吧！哈哈哈。

而 .Net 对反射进行了优化，理论上本身就是提升了动态链接程序集、加载程序集和类的效率，也就是提升了 .Net 运行应用程序的效率。

在 .Net / C# 里， Hash 表可以使用 Dictionary，但在 IL 里，估计得自己写一个。

不过这也是一件好玩的事情，

我接下来会写一篇文章《自己写一个 Hash 表》。

《自己写一个 Hash 表》这篇文章已经写好了，见 https://www.cnblogs.com/KSongKing/p/10425152.html 。

调度程序的 ILBC_Runtime_GetType() 、 ILBC_Runtime_heapNew() 、 ILBC_Runtime_heapFree() 和程序集的 ILBC_Link() 这 4 个函数是操作系统动态链接库规范定义的动态链接库导出函数。

这么考虑主要是之前并未打算自己实现一个 C 编译器，

但现在既然我们要自己实现一个 C 编译器（InnerC），那么这些就不成问题了，

这 4 个函数可以用我们自己定义的规则来访问。

比如，我们可以定义在调度程序的开头的一段字节来保存 ILBC_Runtime_GetType() 、 ILBC_Runtime_heapNew() 、 ILBC_Runtime_heapFree() 这 3 个函数的地址，在程序集的开头的一段字节来保存 ILBC_Link() 函数的地址。

这样，调度程序和程序集之间就可以通过函数指针来调用接口函数，速度很快。

但如果要这样的话，调度程序和程序集应该是同构的，同构是指同一种语言、同一个编译器编译产生的本地代码。

所以，调度程序也应该是用 InnerC 编写和编译生成的。

这么一来， InnerC 的地位就很重要了。 ^^

InnerC 是 ILBC 的基础。

不过这样一来， InnerC 可能也需要支持结构体，不然不好写。呵呵。

这样的话， ILBC 本地代码程序集就不需要是操作系统定义的动态链接库，而是按照 ILBC 规范编译成的本地代码，我们可以把这种按照 ILBC 规范编译成的本地代码程序集的扩展名命名为 “.iln”，表示 “ILBC Native Code” 。

关于泛型，突然想到，泛型纯粹是编译期检查，除此以外什么都不用做，顶多为每个泛型类型生成一个具体类型，通过具体类型可以获取泛型参数类型就可以了。

但泛型确实能提高性能，因为泛型不需要运行期类型转换（Cast），

运行期类型转换就是一堆 if else ，

我们可以看看编译后生成的代码，

源代码：

B b = new B();

A a = (A) b ;

编译后的代码：

B b = new B();

A a;

Type aType = typeof(A) ;

Type bType = typeof(B);

if ( aType == bType )

a.ptr = b.ptr ; // 这句是伪码，表示 b 引用的指针值赋给 a 引用

else if ( aType 是 bType 的父类)

a.ptr = b.ptr ;

else if ( 其它转型规则 )

a.ptr = b.ptr ; // 或者其它转型方式，比如拆箱装箱

else

throw new CastException( "无法将 " + bType + " 的对象转换为 " + aType + " 。" ) ;

而泛型是这样：

List<string> strList = new List<string>();

strList [ 0 ] = "aa" ;

string s = strList [ 0 ];

编译后的代码：

List<string> strList = new List<string>();

strList [ 0 ] = "aa" ;

string s;

s.ptr = strList [ 0 ].ptr; // 指针直接赋值

因为编译期已经做过类型检查，所以引用的指针直接赋值，所以泛型没有性能损耗。

当然， JIT 编译器需要为泛型类型生成具体类型，使得泛型类型可以按照 CLR 的规则 “是一个正常的类型”，通过具体类型可以获取泛型参数类型。

泛型类型？具体类型？泛型参数类型？

有点绕。

假设有 class A<T> ，

那么， A<T> 叫泛型类型，

A<string> 叫具体类型，

T ，叫泛型参数类型，比如 A<string> 的泛型参数类型是 string 。

对于 ILBC，具体类型可以在 C 中间代码里生成。

再来看看基础类型，

基础类型包括值类型、数组、String，

ILBC 会内置实现基础类型，

值类型包括 int, long, float, double, char 等，这些类型在 C 语言里都有对应的类型，但是为了实现 “一切皆对象”，即所有类型，包括值类型和引用类型都从 object 继承这个架构，还需要对 C 语言里的 int, long, float, double, char 等做一个包装，用一个结构体（Struct）来把 int, long, float, double, char 等包起来。

包起来以后，为了提高执行效率，编译器还需要对代码进行一些优化，对于栈里分配的 int, long, float, double, char 等的加减乘除等运算就直接用 C 语言的 int, long, float, double, char 等的加减乘除等运算，即不用结构体包起来，而是直接编译为 C 语言里的 int, long, float, double, char 等。

而对于

void Foo( object o )

{

Type t = o.GetType() ;

}

这样的代码，因为参数 o 可能是任意类型，所以传给参数 o 的 int 类型就应该是包装过的 int，也就是一个结构体，比如：

struct Int32

{

int val ; // 值

string typeName ; // 类型名字，或者广义的来说，这个字段表示类型信息

}

Object 的 GetType() 方法通过这个字段返回 Type 对象。

而对于 typeof(int) 则可以在编译器编译为 Hard Code 返回 Int32 的 Type 对象。

又比如对于 Convert.ChangeType( object o, Type t ) 方法，

假设参数 o 要传一个 int 类型的话，也需要传包装过的 int 类型，也就是上文定义的 struct Int32 。

所以， InnerC 的 InnerC to Byte Code 模块，除了语法分析器，又增加了一个模块，优化器。

So ……

语法分析器产生表达式对象树后，把表达式树传给优化器，优化器可以阅读表达式树，发现可以优化的地方可以修改表达式树，

修改后的表达式树就是优化后的表达式树，再传给 Byte Code to Native Code，编译为本地代码。

可以把优化后的表达式树再逆向为 C 代码，这样就可以看到优化后的 C 中间代码。

InnerC 的 InnerC to Byte Code 可以提供逆向的功能。

再来看结构体（Struct），

D# / ILBC 不打算提供结构体，因为结构体没什么用。 ^^

提供结构体会让 ILBC 的设计变得复杂，增加了研发成本。

当然结构体使用栈空间，减少了堆管理和 GC 的工作，但是从线程的角度来看，栈比较大的话线程切换的性能消耗可能也比较大。看你怎么看了 ~ 。

出于动态链接的要求， .Net / C# 的结构体应该不是在编译期静态分配内存空间的，而是在运行期分配空间，因为结构体保存在栈里，所以是动态分配栈空间。

所以， .Net / C# 里创建结构体也是用 new 关键字。

D# / ILBC 的 DateTime 类型是一个引用类型（Class），是一个可以用 D# 写的普通的引用类型（Class）。

.Net / C# 的 DateTime 是值类型，我估计 .Net / C# 现在想把 DateTime 改成 Class，但是改不过来了。哈哈哈哈。

如上文所述， D# / ILBC 提供的基础类型是基础类型值类型、数组、String，值类型包括 int, long, float, double, char 等，

基础类型由 D# / ILBC 内置实现。

其它类型由 D# 编写，包括 DateTime 及基础库里的各种类型。

说到基础库，就会想到和本地代码的交互性，就是访问本地代码，

在 .Net / C# 里，托管代码和本地代码之间的交互使用 P / Invoke ，

对于 D# / ILBC，会提供这样一些接口：

1 指针

2 申请一段非托管内存，非托管内存不会由 GC 回收，需要手动回收

3 回收一段非托管内存

有了这 3 个接口，基本上就够了，可以访问非托管代码了。

非托管内存和托管内存同属一个堆，只是 GC 不会回收非托管内存。

再来看类型检查和类型安全，

上文中初始化链接表的字段偏移量时会对字段类型进行检查， A 程序集在运行期链接的 B 程序集的 Person 类的字段类型应该和 A 程序集在编译期引用的 B 程序集的 Person 类的类型一致，否则认为类型不匹配，不允许链接，也就是不允许使用现在的 Person 类。

为什么要进行类型检查？

如果类型不匹配，会发生访问了不该访问的内存的错误，这种错误难以排查，产生的结果是意想不到的，

这也是 java， .Net 这类虚拟机（运行时）出现要解决的问题吧！

java, .Net 这类虚拟机（运行时）通过运行期类型检查来实现类型安全，避免类型错误导致访问了错误的内存。

.Net / C# 对类型的检查是严格准确的，所有类型最终会归结到基础类型（值类型数组 String），

而基础类型都是 .Net 内置类型，是强名称的，可以严格的检查，

推而广之， .Net 基础库都是强名称的，可以准确的检查类型，

对于开发人员自己编写的类，也可以根据字段逐一校验，实际加载的程序集的类的字段应包含大于等于编译时引用的程序集的类的字段，字段名字和类型必须匹配，比如编译时引用的 Person 类的 name 字段是 String 类，那么运行期加载的 B 的 Person 类也应该要有 name 字段，且类型应该是 String，否则认为类型不匹配。

我们上文对字段类型的检查是不严格的，只是检查类型的名字。

应该注意的是，强名称类型检查不代表内存安全，强名称只是验证程序集（类）的身份，但是类如果本身存在 Bug，也会发生访问了自身对象以外的内存的问题。

但是，由于数组作为基础类型提供，数组中会判断 “索引是否超出数组界限”，所以，开发者写的代码一般应该不会发生访问内存越界（访问了自身对象以外的内存）的问题。

当然这仅限于托管代码，对于非托管代码，因为指针的存在，所以有可能发生访问内存越界的问题。

.Net / C# 解决这个问题的做法是，把指针用 IntPtr 类型封装起来，不允许修改，只是作为一个常量数值传递。

另一方面，如果 Class Size（类占用的空间大小(Size)）、字段偏移量、方法的函数地址这 3 项元数据都是动态链接的话，

类型检查其实也没什么好查的。 ^^

因为这 3 项元数据都是来源于同一个类，是自洽的，如果发生了访问内存越界的问题，是类自身代码的逻辑问题。

强名称检查是验证程序集（类）的身份。

为什么要动态链接 Class Size（类占用的空间大小(Size)）、字段偏移量？

这是为了兼容性，比如， B 程序集的 Person 类现在有 name, age 2 个字段，后来又加了一个 favour 字段，这样就改变了 Class Size，

name, age 的偏移量也可能会发生改变，

但是应该让原来引用了 B 程序集的应用程序能继续正常使用 Person 类，

所以需要动态链接 Class Size 和字段偏移量。

考虑到软件被攻击和破解的风险，可以考虑加入像 .Net / C# 一样的强名称程序集的功能。

不过如果是 AOT 编译的话，即使没有强名称，要破解也没有那么容易，因为 AOT 编译生成的是本地代码。 ^^

我们上面说程序集和类型的名字，比如调用 ILBC_Runtime_GetType( "B", "Person" ) 函数返回 Person 的 ILBC_Type 结构体指针，

"B" 是程序集名字， "Person" 是类名，

这段代码是举例，我们给程序集名字和类型的名字下一个定义：

程序集名字是程序集文件的文件名（不包含扩展名），

类型的全名（Full Name）是 “名字空间.类名”，这个和 C# 一样。

假设名字空间是 “B”，则 Person 类的全名是 “B.Person”，

上文调用 ILBC_Runtime_GetType( "B", "Person" ) 函数的类名应该是类的全名 “B.Person” 。

如果 D# / ILBC 支持强名称程序集，则对于强名称程序集， Full Name 中还会包含强名称版本信息，可以认为和 .Net / C# 一样。

我们再详细说明一下高级语言（D#）编译的过程，

高级语言（D#）编译会生成 2 个文件，

1 元数据文件，

2 程序集文件

上文中没有交代元数据文件，

元数据文件保存了程序集的元数据信息，包括类，类的字段（字段名、字段类型），方法（方法签名），

高级语言（D#）编译器可以根据元数据知道程序集有哪些成员（类，类的字段，类的方法），

这样可以用于开发时的智能提示，以及编译时的类型检查。

最重要的是高级语言（D#）编译器需要根据元数据生成程序集中加载 Class 的代码，

加载 Class 的代码就是上文中的 ILBC_Type * ILBC_LoadClass_B_Person() 函数，

这个函数就是 “Class Loader”，是保存在 ILBC_Assembly 结构体的 classLoaderList 字段中，

classLoaderList 是一个数组，元素是 ILBC_ClassLoader 结构体， ILBC_ClassLoader 结构体的 load 字段就是保存 “Class Loader” 函数的函数指针的字段。

程序集文件可能是 Byte Code 程序集，也可能是本地代码程序集，

如果是 JIT 编译方式，就是 Byte Code 程序集，

如果是 AOT 编译方式，就是本地代码程序集，

高级语言（D#）编译器编译时只需要元数据文件，不需要程序集文件，

应用程序运行的时候只需要程序集文件，不需要元数据文件。

元数据文件就像是 C 语言的头文件。

所以， ILBC 涉及的文件会有这么几种：

1 元数据文件

2 C 中间代码文件，这个不是必需的，但是作为调试研究学习，可以生成出来。

3 Byte Code 程序集文件，

4 本地代码程序集文件，

我们可以对这 4 种文件命名扩展名：

1 元数据文件，扩展名 “.ild”，表示 “ILBC Meta Data”，

2 C 中间代码文件，扩展名 “.ilc”，表示 “ILBC C Code”，

3 Byte Code 程序集文件，扩展名 “.ilb”，表示 “ILBC Byte Code”，

4 本地代码程序集文件，扩展名 “.iln”，表示 “ILBC Native Code”，

好的， ILBC 规范暂时就写这么多，

接下来的计划是堆、 GC 、 InnerC 语法分析器。

有网友提出不需要沿袭传统的面向对象方式，而是可以用和 Rust 相似的方式，

我下面写一段代码把这种方式描述一下：

class C1

{

int f1;

string f2;

}

void M1( C1 this )

{

……

}

void M2( C1 this)

{

……

}

这就是 C1 类的定义，方法定义在外面，类似 C# 的扩展方法，

这相当于传统的面向对象里 C1 类有 2 个方法（M1(), M2()），

我们在定义一个 C2 类，让 C2 “继承” C1 类：

class C2 : C1

{

}

再把 M1() 的定义改一下：

void M1( C2 C1 this )

{

……

}

this 参数的类型加入了 C2，由 C2 C1 共同作为 this 参数的类型，

这样 C2 就继承了 C1 的 M1() 方法，，，注意只继承了 M1() 方法，没有继承 M2() 方法。

C2 可以添加自己的字段，也可以多继承，当然如果 “父类” 之间有重名的字段，就不能同时继承有重名字段的父类。

C2 也可以添加自己的方法，事实上这也不能说是自己的方法，这个方法不仅仅能在 “父子” 类之间共享，

也能在 “毫无关系” 的类之间共享，只要方法内对 this 引用的字段在类里存在就行。

这种做法确实挺呵呵的，但也很爽。

这种做法我称之为 “静态绑定”，因为和 Javascript 的 “动态绑定” 相似，只不过这是在编译期进行的，所以叫 “静态绑定” 。

同时，从编译期 “静态” 的角度，又和泛型很像。

网友说这种做法 “只需要结构体和扩展方法就行，不需要类。” ，

确实，就是这样，只要有结构体和扩展方法就可以。

说的直一点，只要有结构体和函数就可以。

我要呵呵了，这算是面向过程 -> 面向对象 -> 面向过程么？

经过后来的讨论和思考， D# 还是不打算这样做， D# 的目标是实现一个经典的简洁的面向对象语言。

D# 会支持简洁的面向对象和函数式。

简洁的面向对象包括单继承、接口、抽象类 / 抽象方法 / 虚方法，

函数式是闭包。

不过，关于上述的 “静态绑定” 的做法，倒是讨论清楚了， “绑定” 有 3 种：

1 静态绑定，在编译期为每个绑定生成一份方法（函数）代码，每一份函数代码逻辑相同，区别是访问对象字段的偏移量。

2 静态绑定，方法（函数）只有一份，但在编译期为每个绑定生成一段绑定代码，绑定代码的逻辑是把对象字段的偏移量转换为函数里对应的偏移量。

3 动态绑定，在运行期为绑定生成绑定代码。

关于堆和 GC，我的想法是这样：

GC 根据 2 张表来回收对象（内存），

1 引用表

2 对象表

这 2 张表实际上是链表，

每次 new 对象的时候，会把对象添加到对象表里，

每次给引用赋值的时候，会把引用添加到引用表里，

每次引用超出作用域，或者引用被赋值为 null 时，会将引用从引用表里删除，当然这段代码是编译器生成的。

这样， GC 回收对象（内存）的时候，就先扫描引用表，对引用表里的引用指向的对象，在对象表里做一个标记，表示这个对象还在使用，

扫描完引用表后，扫描对象表，如果对象未被标记还在使用，就表示已经没有引用在指向对象，可以回收对象。

而要在每次给引用赋值的时候把引用添加到引用表，需要 lock 引用表，把对象添加到对象表也需要 lock 对象表。

lock 会带来性能损耗，通过测试可以看到， C# 中 lock 的时间花费大约是 new 的 3 倍（new 应该要查找和修改堆表，所以应该也有 lock），

执行次数比较小时，小于 3，比如 10 万次，

执行次数比较大时，大于 3，比如 1 亿次，

所以，看起来， C# 的 new 的 lock 的效率比 lock 关键字的 lock 的效率高，

或者说，如果我们用上述的架构，给引用赋值时把引用添加到引用表，使用 lock 关键字来实现 lock，

这样对性能的影响很大，只要想想给引用赋值的性能花费比 new 还大就知道了，

从测试结果上来看， new 的执行应该是指令级的，大概在 5 个指令以内就可以完成，

对于 .Net / C# 这样有 GC 的语言，应该只需要从剩余空间中分配内存块就可以，不需要像 C / C++ 那样用树操作查找最接近要分配的内存块大小的空闲空间，

再加上 lock 的时间，全部加起来大概在 5 个指令以内，

lock 大概占 2 个指令，开始 lock 占 1 个指令，结束 lock 占 1 个指令，

当然这些是估算。

所以可以看出来， .Net / C# 的 new 操作对堆表的 lock 是指令级的，不是调用操作系统的 lock 原语，

这样的目的是让 new 的操作很快，接近 O(1)，

对于 ILBC 而言，如果采用给引用赋值时修改引用表， new 对象时修改对象表，

那么，修改引用表和对象表的操作也应该接近 O(1)，就是像 .Net / C# 的 new 一样，这样才有足够的效率。

这就是说，修改引用表和对象表的 lock 也要像 .Net / C# 的 new 对堆表的 lock 一样，是指令级的。

这就需要我们自己来实现一个 lock，而不是使用操作系统的 lock 原语。

怎么来实现自己的一个 lock ？

根据网上查阅的结果，光从软件层面是不行的，光从 C 语言层面也不行，需要硬件的支持和汇编编程。

可以参考《聊聊C++中的原子操作》 https://baijiahao.baidu.com/s?id=1609585581486387645&wfr=spider&for=pc ，

《java并发中的原子变量和原子操作以及CAS介绍》 https://blog.csdn.net/wxw520zdh/article/details/53731146 ，

文中提到 “CAS …… 虽然看似复杂，但却是 Java 5 并发机制优于原有锁机制的根本。” ，

而 CAS 是通过 CPU 提供的 CMPXCHG 指令支持，可以参考《cpu cmpxchg 指令理解 (CAS)》 https://blog.csdn.net/xiuye2015/article/details/53406432 ，

所以我们可以用 CMPXCHG 指令来实现 lock ，原理是这样：

在内存里用一个字来存储 lock 标志（flag），如果是 64 位处理器，则字长是 64，即 8 个字节（Byte），

简化起见，我们就不考虑 32 位处理器了，只考虑 64 位处理器。

当要 lock 时，用 CMPXCHG 指令比较 flag 是否等于 0，如果相等则将当前线程 ID 复制到 flag，这表示当前线程获得了锁，接着执行锁里要执行的操作就行。

如果不等于 0，则 CMPXCHG 指令会把当前 flag 的值复制到指定的寄存器里，检查寄存器里的 flag 值是否是当前线程 ID，如果是，表示在当前线程的锁范围内，接着执行锁里要执行的操作就行。

如果 flag 值不等于当前线程 ID，表示当前锁由别的线程占有，则当前线程挂起，挂起前会把指令计数器再次指向上述检查锁的指令，下次恢复运行时，会重新执行上述检查锁的操作。

我们可以用多个字来表示多个 lock，比如用一个字表示引用表 lock，一个字表示对象表 lock，一个字表示堆表 lock，等等。

当然，为了提高效率，对象表 lock 和堆表 lock 大概可以合为一个 lock，因为修改对象表和堆表都发生在 new 操作的时候，可以把 new 操作作为一个原子操作，只用一个 lock，这样， new 操作包含的 2 个步骤修改对象表和修改堆表都在一个 lock 里进行。

这种做法相比操作系统的 lock 原语，可能更简单，但是功能也相对局限，比如不能支持嵌套 lock，以及必须预先为每一种 lock 分配一个字，而操作系统 lock 是可以动态 lock 的，比如 C# 中只要调用 Monitor.Enter() 方法就可以开始 lock，通常我们是用 lock 关键字，这在编译期被编译器处理为 Monitor.Enter() 和 Monitor.Exit() 方法对，但是如果在运行期调用 Monitor.Enter() 方法，也是可以开始 lock 的。

操作系统的 lock 可能是利用了虚拟内存，或者说存储管理部件，只需要在存储管理的锁表里设置要锁定的地址，存储管理部件会判断是否允许访问该地址。

设置锁表的原理是，在锁表里设置当前线程 ID 和要锁定的地址，如果相同的线程 ID + 锁定地址已经存在，则设置失败，设置失败则线程挂起，等下次恢复运行时再接着设置。

设置成功则表示当前线程获得对指定地址的锁，存储管理部件将只允许当前线程访问指定地址，不允许其它线程访问指定地址。

事实上，我们用 CMPXCHG 指令的做法也可以实现和操作系统类似的效果，包括动态的锁定任意的对象（不需要预先分配字），也支持嵌套 lock，

这需要在 object 类（所有引用类型的基类）里加入一个 lock 字段，当我们 lock 某个对象时，会先看 lock 字段是否等于 0，如果等于 0，则写入当前线程号，这样就获得了对该对象的锁，如果不等于 0，则比较是否等于当前线程 ID，如果等于，表示对象被当前对象锁定，于是接着执行锁定里的操作，如果不等，表示对象被其它线程锁定，则当前线程挂起，等下次恢复运行时，重复上述过程。

这个过程和上面叙述的利用 CMPXCHG 指令实现锁的过程是一样的，但不用预先分配字，用 object 的 lock 字段作为这个 “字” 就可以。

判断 object 的 lock 字段是否等于 0，若等于则写入当前线程号，返回 true，否则 lock 字段不变，返回 false，这个操作是 “原子操作”，这个原子操作就是 CMPXCHG 指令实现的。

但用我们的做法有一个条件，就是需要在所有（可能并发）访问对象的地方都加上 lock，

而操作系统的锁则不必需，操作系统由于是利用虚拟内存（存储管理部件）实现的，所以在代码的 a 处加了 lock， b 处不加 lock，但 a 处锁定对象，则 b 处将不能访问。

虽然如此，我们在使用操作系统 lock 的时候，通常也会在 a 处和 b 处都加上 lock，这是为了设计意图的需要，我们需要 a 和 b 严格的同步（互斥）通信，就需要给 a 处和 b 处都加上 lock 。

我把我们的做法称为 “IL Lock” ，用关键字 illock 表示，

把操作系统的 lock 称为 “System Lock”，用关键字 syslock 表示，

在 D# 中，使用 IL Lock 可以这样写：

illock ( obj )

{

……

}

使用 System Lock 可以这样写：

syslock ( obj )

{

……

}

理论上，我们可以提倡使用 IL Lock，这样可以获得比 System Lock 更高的性能。 ^^

好的，堆和 GC 的部分基本理清了，接下来会开始 InnerC 语法分析器。

到目前为止， InnerC 在 ILBC 的地位变得重要， InnerC 会是 ILBC 的内核模块。

InnerC 支持基础类型（int, long, float, double, char）， if else, for, while，函数，指针，数组，结构体，

InnerC 不保证支持 Ansi C 的全部标准，

InnerC 还会有一些新的特性：

1 对 void * 类型的函数指针不检查函数签名，可以调用任意的参数列表和返回任意的返回值，当然调用了不匹配的参数列表就会发生错误，可能导致程序崩溃，这个特性是用在 C 中间代码里，不建议开发人员使用。

对于声明了函数签名的函数指针，仍然会检查调用的参数列表及返回值是否符合函数签名（指针类型），开发人员应使用这种方式，保证安全性。

2 为了便于实现一些动态特性和对本地代码访问的灵活性， InnerC 支持用函数指针调用动态的参数列表，参数列表是一个数组，类似 .Net / C# 的反射，把参数放在数组里传给 MethodInfo.Invoke( object[] args ) 方法。

初步构想可以增加一个 invoke 关键字，可以用于函数指针的函数调用，比如：

void * funcPtr ;

void * args ;

……

( * funcPtr ) ( invoke args ) ; // 调用 funcPtr 指向的函数，参数列表是 args

3 新增 casif 关键字以支持 casif 语句。

casif 语句类似 if 语句，但判断条件是通过 CMPXCHG 指令实现的 CAS 原子操作， CAS 全称 “Compare and Swap” 。

casif 语句格式如下：

casif ( 参数1, 参数2, 参数3 )

{

语句块 1

}

else

{

语句块 2

}

参数1 是一个变量或者常量，参数2 是一个指针，参数3 是一个变量或者常量，

当参数1 和参数2 指向的值相等时，把参数3 的值复制到参数2 指向的存储单元，并认为判断条件成立，执行语句块 1 。

否则认为判断条件不成立，执行语句块 2 。

其实上面说的用 CMPXCHG 指令实现 IL Lock 的做法还有一点问题，其实不需要向对象的 lock 字段写入当前线程 ID，只要写入 1 就可以， 1 表示对象被锁定， 0 表示对象未被锁定。

这样逻辑就更简化了。

对引用表对象表堆表的 lock 都会统一使用 IL Lock 。

暂时先写到这里， ILBC 目前计划发展 2 门高级语言， D# 和 c3 ， c3 由一位网友提出，参考《c3 语言草案》 https://note.youdao.com/ynoteshare1/index.html?id=bec52576b45ec0d918a95f75db0ea68e&type=note#/ 。

内容有点多，所以后面的内容放到了《ILBC 规范 2》 https://www.cnblogs.com/KSongKing/p/10440001.html 。

posted on 2019-02-07 14:58 凯特琳阅读(951) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

凯特琳

ILBC 规范

导航

公告