我发起并创立了一个 VMBC 的子项目 D#

Posted 2021-02-07 凯特琳

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了我发起并创立了一个 VMBC 的子项目 D#相关的知识，希望对你有一定的参考价值。

大家好，

我发起并创立了一个 VMBC 的子项目 D# 。

有关 VMBC ，请参考《我发起了一个用 C 语言作为中间语言的编译器项目 VMBC》 https://www.cnblogs.com/KSongKing/p/9628981.html ，

和《漫谈编译原理》 https://www.cnblogs.com/KSongKing/p/9683831.html 。

D# ，就是一个简单版的 C# 。

下面说一下 D# 项目的大概规划：

第 1 期，实现 new 对象的机制， GC，堆。（我做）

第 2 期，实现对象的函数（方法）调用。（后人做）

第 3 期，实现元数据，简单的 IL 层基础架构。（后人做）

第 4 期，实现简单类型，如 int, long, float, double 等。（后人做）

第 5 期，实现简单的表达式和语句，如变量声明，加减乘除， if else， for 循环等。（后人做）

第 6 期，实现 D# 代码翻译为 C 语言中间代码。（后人做）

第 7 期，实现将 C 语言代码编译为本地代码。（后人做）

第 8 期，各种高级语法特性逐渐加入。（后人做）

第 9 期，各种完善发展 …… （后人做）

我们来具体看一下每一期怎么做：

第 1 期，对象的 new 机制，就是用 malloc() 在内存里申请一段内存，内存的大小（Size）是对象里所有字段的 Size 宗和，可以用 C 语言的 sizeof() 根据字段类型取得字段占用的内存长度，加起来就是对象占用的内存长度。

GC， D# 的 GC 和 C# 有一点不同， C# 的 GC 会做 2 件事：

1 回收对象占用的内存

2 整理堆里的碎片空间

D# 只有第 1 点，没有第 2 点。就是说 D# 只回收对象占用的内存，但不进行碎片整理。

C# GC 进行碎片整理需要移动对象，然后修改指向这个对象的引用，引用是一个结构体，里面包含了一个指针，指向对象的地址，对象被移动后，地址发生了改变，所以引用里的这个指针也需要修改。

其实不做碎片管理的主要原因是碎片整理的工作很复杂，我懒得写了。 ^^

碎片整理主要是解决碎片占用了地址空间和内存空间的问题，以及碎片增多时堆分配效率变低的问题。

当然还有碎片占用了操作系统虚拟内存页的问题。

首先，关于碎片占用地址空间的问题，现在是 64 位操作系统，地址空间可以达到 16 EB，不用担心地址空间用完。

内存空间的问题，现在固态硬盘已经普及，内存也越来越大，固态硬盘可以让操作系统虚拟内存很快，再加上内存也越来越大，所以也不用担心内存空间不够的问题。

碎片增多时堆分配效率变低的问题，我们打算自己实现一个堆算法，下面会介绍。

碎片占用了操作系统虚拟内存页的问题是指碎片占用了较多的页，导致操作系统虚拟内存可能频繁的载入载出页，这样效率会降低。

这个问题其实和碎片占用内存空间的问题一样，固态硬盘可以让操作系统虚拟内存很快，内存也越来越大，所以基本上也可以忽略。

另一方面， GC 整理碎片移动对象本身就是一个工作量比较大的工作，且移动对象时需要挂起所有线程。

所以，碎片整理也是有利有弊的。

D# GC 去掉了整理碎片的部分，也可以说是 “空间换时间” 的做法，

另外， D# GC 工作时不用挂起应用程序线程，可以和应用程序线程正常的并发运行。

相对于 C#，实时性也会好一些。

为什么要自己实现一个堆呢？

因为 C / C++ 的堆分配（malloc() , new）是有点 “昂贵” 的操作，

C / C++ 是 “静态语言”，没有 GC 来整理碎片，所以就需要有一个 “精巧” 的分配算法，

在申请一块内存（malloc() , new）的时候，需要寻找和申请的内存块大小（size）最接近的空闲空间，

当内存出现大量碎片，或者几乎用到 100% 内存时，分配的效率会降低，就是说分配操作可能会花费比较长的时间。

见《C++：在堆上创建对象，还是在栈上？》 https://blog.csdn.net/qq_33485434/article/details/81735148 ，

原文是这样：

“

首先，在堆上创建对象需要追踪内存的可用区域。这个算法是由操作系统提供，通常不会是常量时间的。当内存出现大量碎片，或者几乎用到 100% 内存时，这个过程会变得更久。

”

而对于 java ， C# 这样的语言来说， new 操作是常规操作，时间复杂度应该接近 O(1) 。

事实上 java , C# 的 new 操作时间复杂度可能就是 O(1)，因为有 GC 在整理碎片，所以 new 只需要从最大的空闲空间分配一块内存就可以。

所以 D# 也需要设计一种 O(1) 的堆算法。

D# 的堆算法也会沿用 “空间换时间” 的思路， new 直接从最大的空闲空间分配指定 size 的内存块，由另外一个线程定时或不定时对空闲空间排序，

比如现在在堆里有 10 个空闲空间，这个线程会对这 10 个空闲空间排序，把最大的空闲空间放在最前面，

这样 new 只要在最大的空闲空间里分配内存块就可以了。

这样 new 的时间复杂度就是 O(1) 。

这个对空闲空间排序的线程可以是 GC 线程，或者说，对空闲空间排序的工作可以放在 GC 线程里。

当然，这样对内存空间的利用率不是最高的，但上面说了，空间相对廉价，这里是 “用空间换时间” 。

这个堆算法还有一个特点就是简单，简单有什么用呢？

作为一个 IL 层，虽然 C / C++ 提供了堆算法，但是自己还是有可能自己实现一个堆，至少要有这个储备力量，

上面这个算法的好处是，因为简单，所以把研发成本降低了，包括升级维护的成本也降低了。哈哈哈。

我可不希望后来人学习 VMBC 的时候，看到一堆天书一样的代码，

我不觉得像研究九阴真经一样去研究 Linux 内核这样的事是一个好事。 ^^

接下来，我再论证一下 GC 存在的合理性，这样第 1 期的部分就结束了。

过去有观点认为， GC 影响了语言的实时性（比如 java， C#），但如果从另外一个角度来看，应用程序运行在操作系统上，也会切换回系统进程，系统进程负责进程调度虚拟内存 IO 等工作，总的来说，是对系统资源的管理。

GC 也可以看作是应用程序这个 “小系统” 里对系统资源管理的工作，所以 GC 是一个合理的并发， GC 是合理的。

第 2 期，实现对象的函数（方法）调用，这很简单，就是调用函数，给函数增加一个参数，这个参数作为第一个参数，这个参数就是 this 指针，把对象自己的地址传进去就可以了。

第 3 期，实现元数据，简单的 IL 层基础架构。简单的 IL 层基础架构主要就是元数据架构。

元数据就是一堆结构体，声明一堆静态变量来保存这些结构体就可以了。不过考虑到元数据是可以动态加载的，这样可以用 D# 自身的 new 对象机制来实现。只要声明一个静态变量作为元数据树的根就可以了。

元数据实际上也包含了第 2 期的内容，元数据会保存对象的方法（函数）的指针，这还涉及到 IL 层的动态链接，

就跟 C# 一样，比如用 D# 写了 1 个 .exe 和 1 个 .dll，用 .exe 调用 .dll ，涉及到一个 IL 层的动态链接。

C# 或者 .Net 是完全基于元数据的语言和 IL 平台， java 应该也是这样， java 刚出现时，逐类编译，也就是说，每个类编译为一个 class 文件， class 文件是最小单位的动态链接库，可以动态加载 class 文件，这个特性，在 java 刚出现的时代，是 “很突出” 的，也是区别于 C / C ++ 的 “动态特性” 。

这个特性在今天看来可能已经习以为常，不过在当时，这个特性可以用来实现 “组件化” 、“热插拔” 的开发，比如 Jsp 容器，利用动态加载 class 文件的特性，可以实现动态增加 jsp 文件，在 web 目录下新增一个 jsp 文件，一个新网页就上线了。当然也可以动态修改 jsp 文件。

第 4 期，实现简单类型，如 int, long, float, double 等。

C 语言里本来就有 int, long, float, double，但是在 C# 里，这些简单类型都是结构体，结构体里除了值以外，可能还有类型信息之类的。

总之会有一些封装。

D# 也一样，用结构体把 C 语言的 int, long, float, double 包装一下就可以了。

第 5 期，实现简单的表达式和语句，如变量声明，加减乘除， if else， for 循环等。

这些也不难，上面说了，值类型会包装成结构体，那么变量声明就是 C 语言里相应的结构体声明，

比如 int 对应的结构体是 IntStruct，那么， D# 里 int i; 对应的 C 语言代码就是 IntStruct i; ，

严格的讲，应该是

IntStruct i;

i.val = 0;

应该是类似上面这样的代码，因为 C 语言里 IntStruct i; 这样不会对 i 初始化， i.val 的值是随机的。

按照 C# 语法， int i; ， i 的值是默认值 0 。

也可以用 IntStruct i = IntStruct(); 通过 IntStruct 的构造函数来初始化。

我在网上查了这方面的文章，可以看看这篇《c++的struct的初始化》 https://blog.csdn.net/rush_mj/article/details/79753259 。

加减乘除， if else， for 循环基本上可以直接用 C 语言的。

第 6 期，实现 D# 代码翻译为 C 语言中间代码。

在第 6 期以前，都还没有涉及语法分析的内容，都是在设计，用 C 语言怎样来描述和实现 IL 层，具体会用 C 语言写一些 demo 代码。

第 6 期会通过语法分析把 D# 代码翻译为 C 语言中间代码。

具体的做法是，

通过语法分析，把 D# 代码转换为表达式树，表达式是对象，表达式树是一棵对象树，

转换为表达式树以后，我们就可以进行类型检查等检查，以及语法糖转换工作，

然后让表达式生成目标代码，对于一棵表达式树，就是递归生成目标代码，

一份 D# 代码文件，可以解析为一棵表达式树，这棵表达式树递归生成的目标代码就是这份 D# 代码对应的 C 语言目标代码。

关于语法分析，可以参考《SelectDataTable》 https://www.cnblogs.com/KSongKing/p/9683831.html 。

第 7 期，实现将 C 语言代码编译为本地代码。

这一期并不需要我们自己去实现一个 C 编译器，我们只要和一个现有的 C 编译器连接起来就可以了。

第 8 期，各种高级语法特性逐渐加入。

基本原理就上面那些了，按照基本原理来加入各种特性就可以。

不过别把太多 C# 的 “高级特性” 加进来，

C# 已经变得越来越复杂，正好乘此机会，复杂的不需要的特性就不用加进来了。

C# 的 “高级特性” 增加了很多复杂，也增加了很多研发成本。

刚好我们不要这些特性，我们的研发成本也降低了。

第 9 期，各种完善发展 ……

语法特性，优化， IDE，库（Lib），向各个操作系统平台移植 ……

好了，说的有点远。

优化是一个重点，比如生成的 C 语言中间代码的效率， IL 层架构对效率的影响，等等，这些是重要的评估。

就像 C / C++ 的目标是执行效率，我认为 D# 的目标也是执行效率。

D# 提供了对象和 GC，

对象提供了封装抽象的程序设计的语法支持，

GC 提供了简洁安全的内存机制，

这是 D# 为开发者提供的编写简洁安全的代码的基础，是 D# 的基本目标。

在此基础上，就是尽可能的提升执行效率。

还可以看看《漫谈 C++ 虚函数的实现原理》 https://www.cnblogs.com/KSongKing/p/9680632.html 。

上文中提到 IL 层的动态链接，这是个问题，也是个课题。

在 C# 中， IL 层的动态链接是 JIT 编译器完成的。

对于 D#，可以这样来动态链接，假设 A.exe 会调用 B.dll，那么在把 A 的 D# 代码编译成 C 语言目标代码的时候，会声明一个全局变量数组，这个全局变量数组作为 “动态链接接口表”，接口表会保存 A 中调用到 B 的所有构造函数和方法的地址，但是在编译的时候还不知道这些构造函数和方法的地址（在运行时才知道），所以这些地址都预留为空（0），就是说这个接口表在编译时是为运行时预留的，具体的函数地址要在运行时填入。

在运行时， JIT 编译器（内核是个 C 编译器）加载 B.dll，将 B.dll 中的 C 语言中间代码编译为本地代码，然后将编译后的各个函数的地址传给 A，填入 A 的 “动态链接接口表”，

A 中调用 B 的函数的地方在编译时会处理为到接口表中指定的位置获得实际要调用的函数地址，然后根据这个函数地址调用函数。

这有点像虚函数的调用。

接口表中为什么要保存构造函数呢？因为如果要创建 B 中定义的类的对象，就需要调用构造函数。

其实接口表除了构造函数，还要保存对象的大小（Size），创建对象的时候，先根据 Size 在堆里分配空间，再调用构造函数初始化。

B.dll JIT 编译完成时，需要把本地代码中各函数的地址传给 A，对于 C# 来说，这些是 JIT 编译器统一做的，没有 gap，

但是对于 D# 来说，如果我们不想修改 C 编译器，那么就有 gap，

这需要在 B.dll 的 C 语言中间代码里加上一个可以作为本地代码动态链接的函数（比如 win32 的动态链接库函数），通过这个函数，来把 B 的元数据传给 A，比如 JIT 编译后本地代码中各个函数的地址，

这样 A 通过调用 B 的这个函数，获取元数据，把元数据填入接口表。

上面说的 win32 动态链接库函数是通过 extern "C" 和 dllexport 关键字导出的方法，比如：

extern "C"
{
_declspec(dllexport) void foo();
}

这是导出了一个 foo() 方法。

这种方法就是纯方法，纯 C 方法，不涉及对象，更和 Com 什么的无关，干脆利落，是方法中的极品。

这种方法也再次体现了 C 语言是 “高级汇编语言” 的特点，

你可以用 C 语言做任何事。

爽，非常爽。

IL 层动态链接和本地代码库动态链接的区别是：

IL 层动态链接的 2 个 dll 是用同样的语言写的（比如 D# 的 dll 是 C 语言写的），又是同一个编译器编译成本地代码的， 2 个 dll 编译后的本地代码的寄存器和堆栈模型相同，只要知道函数地址，就可以相互调用函数。其实就跟把 A.exe 和 B.dll 里包含的 C 文件全部放在一起编译的效果是一样的。

本地代码库动态链接的话， 2 个 dll 可能是用不同的语言写的，也可能是不同的编译器编译的， 2 个 dll 的寄存器和堆栈模型可能不相同，需要按照操作系统定义的规范调用。

在上文提到的《漫谈编译原理》中，也简单的讨论了链接原理。

这个道理搞通了， D# 要搞成 JIT 也是可以的。

事实上也应该搞成 JIT，不搞成 JIT 估计没人用。

JIT 还真不是跨平台的问题，

我想起了， C++ 写了 3 行代码，就需要一个几十 MB 的 “Visual Studio 2012 for C++ Distribute Package” ，

看到这些，就知道是怎么回事了。

经过上面的讨论，一些细节就更清楚了。

D# 编译产生的 dll，实际上是个压缩文件，解压一看，里面是一些 .c 文件或者 .h 文件，相当于是一个 C 语言项目。

这样是不是很容易被反编译？

实际上不存在反编译，直接打开看就行了。 ^^

如果怕被反编译的话，可以把 C 代码里的回车换行空格去掉，这样字符都密密麻麻的排在一起，

再把变量名和函数名混淆一下。

感觉好像 javascript ……

如果跟 Chrome V8 引擎相比， VMBC / D# 确实像 javascript 。

try catch 可以自己做，也可以用 C++ 的，但我建议自己做，

因为 VMBC 是 Virtual Machine Base on C，不是 Virtual Machine Base on C++ 。

try catch 可能会用到 goto 语句。

昨天网友提起 C 语言的编译速度相对 IL 较低，因为 C 语言是文本分析， IL 是确定格式的二进制数据，

我之前也想过这个问题，我还想过像 .Net Gac 一样搞一个本地代码程序集缓存，这样，运行一个 D# 程序时，可以先用 Hash 检查一下 C 中间代码程序集文件是否和之前的一样，如果一样就直接运行缓存里的本地代码程序集就可以。

由这个问题，又想到了， D# 应该支持静态编译（AOT），这也是 C 语言的优势。

D# 应该支持 JIT 和 AOT， JIT 和 AOT 可以混合使用。

比如，一个 D# 的程序，里面一些模块是 AOT 编译好的，一些模块是 JIT 在运行时编译的。

为此，我们提出一个 ILBC 的概念， ILBC 是 Intermediate Language Base on C 的意思。

ILBC 不是一个语言，而是一个规范。

ILBC 是指导 C 语言如何构建 IL 层的规范，以及支持这个规范的一组库（Lib）。

ILBC 规范草案大概是这样：

ILBC 程序集可以提供 2 个 C 函数接口，

1 ILBC_Main()，这是程序集的入口点，和 C# 里的 Main() 是一样的，

2 ILBC_Link() ，这就是上面讨论的 IL 层的动态链接的接口，这个函数返回程序集的元数据，其它 ILBC 程序集获得元数据后，可以根据元数据调用这个程序集里的类和方法。元数据里的内容主要是类的大小（Size）、构造函数地址、成员函数地址。

哎？不过说到这里，如果要访问另外一个程序集里的类的公有字段怎么办？嘿嘿嘿，

比如 A.dll 要访问 B.dll 里的 Person 类的 name 字段，这需要在把 A 项目的 D# 代码编译成 A.dll 时从 B.dll 的元数据里知道 name 字段在 Person 类里的偏移量，这样就可以把这个偏移量编译到 A.dll 里， A.dll 里访问 Person 类 name 字段的代码会被处理成 *( person + name 的偏移量 ) ， person 是 Person 对象的指针。

这是在把 D# 代码编译成 A.dll 的时候根据 B.dll 里的元数据来做的工作，这不是动态链接，那算不算 “静态链接” ？因为字段的访问的处理比较简单， “链接” 包含的工作可能更复杂一些，当然，你要把字段的处理叫做链接也可以，怎么叫都可以。

那函数调用能不能也这样处理？

访问字段的时候，是对象指针 + 字段偏移量，

函数则是编译器编译为本地代码，函数的本地代码的入口地址是编译器决定的，需要编译器把 C 中间代码编译为本地代码后才知道，所以函数需要动态链接。

从上面的讨论我们也看到， ILBC 程序集会有一个 .dat 文件（数据文件），用来存放可以静态知道的元数据，比如类字段方法，类的大小（Size），字段的偏移量（Offset）。元数据的作用是类型检查和根据偏移量生成访问字段的 C 中间代码。

元数据里的类的大小（Size）和字段偏移量是 D# 编译器计算出来的，这需要 D# 编译器知道各种基础类型（int, long, float, double, char 等）在 C 语言里的占用空间大小（Size），这是 D# 编译器的参数，需要根据操作系统平台和 C 编译器来设定。

类（Class）在 ILBC 里是用 C 语言的结构体（Struct）来表示，结构体由基础类型和结构体组成，所以只要知道了基础类型的 Size，就可以计算出结构体的 Size，当然也就知道了类的 Size 和字段偏移量。

但有一个问题是， D# 编译器对字段的处理顺序和 C 编译器是否一样？如果不一样，那 D# 把 name 字段放在 age 之前， C 编译器把 age 字段放在 name 字段之前，那计算出来的字段偏移量就不一样了，就错误了。这就呵呵了。

不过 C 编译器好像是按照源代码里写的字段顺序来编译的，这个可以查证确认一下。

比如，有一个结构体 Person ，

struct Person

{

char[8] name;

int age;

}

那么，编译后的结果应该是 Person 的 Size 是 12 个 byte，前 8 个 byte 用来存储 char[8] name; ，后 4 个字节用来存储 int age; ，（假设 int 是 32 位整数）。

如果是这样，那就没问题了。 D# 编译器和 C 编译器都按照源代码里书写的顺序来编译字段。

C# 好像也沿袭了这样的做法，在反射里用 type.GetFields() 方法返回 Field List， Field 的顺序好像就是跟源代码里书写的顺序一样的。

而且在 C# 和非托管代码的交互中（P / Invoke）， C# 里定义一个字段名字段顺序和 C 里的 Struct 一样的 Struct，好像也直接可以传给 C 函数用，比如有一个 C 函数的参数是 struct Person，在 C# 里定义一个和 C 里的 Person 一样的 Struct 可以直接传过去用。

我们来看一下方法的动态链接的具体过程：

假设 A 项目里会调用到 B.dll 的 Person 类的方法， Person 类有 Sing() 和 Smile() 2 个方法， D# 代码是这样：

public class Person

{

public Sing()

{

// do something

}

public Smile()

{

// do something

}

那么 A 项目里调用这 2 个方法的 C 中间代码是：

Person * person ; // Person 对象指针

……

ilbc_B_MethodList [ 0 ] ( person ); // 调用 Sing() 方法

ilbc_B_MethodList [ 1 ] ( person ); // 调用 Smile() 方法

大家注意，这里有一个 ilbc_B_MethodList ，这是 A 项目的 D# 代码编译生成的 C 中间代码里的一个全局变量：

uint ilbc_B_MethodList ;

是一个 uint 变量。

uint 变量可以保存指针， ilbc_B_MethodList 实际上是一个指针，表示一个数组的首地址。

这个数组就是 B.dll 的函数表。函数表用来保存 B.dll 里所有类的所有方法的地址（函数指针）， D# 编译器在编译 B 项目的时候会给每个类的每个方法编一个序号。

编号规则还是跟编译器对源代码的语法分析过程有关，基本上可能还是跟书写顺序有关，不过不管这个编号规则如何，这都没有关系。

总之 D# 编译器会给所有方法都编一个号（Seq No），每个方法的编号是多少，这些信息会记录在 B.dll 的元数据里（metadata.dat），

D# 编译器在编译 A 项目时，会根据 A 引用的 B.dll 里的元数据知道 B.dll 里的方法的序号，

这样， D# 编译器就可以把调用 Sing() 方法的代码处理成上述的代码：

ilbc_B_MethodList [ 0 ] (); // 调用 Sing() 方法

注意， ilbc_B_MethodList [ 0 ] 里的 “0” 就是 Sing() 方法的序号，通过这个序号作为 ilbc_B_MethodList 数组的下标（index），可以取得 Sing() 方法的函数地址（函数指针），然后就可以调用 Sing() 方法了。

上文说了， ilbc_B_MethodList 表示 B.dll 的函数表的首地址，

那么， B.dll 的函数表从哪里来？

函数表是在加载 B.dll 时生成的。

运行时会把 B.dll 编译为本地代码并加载到内存，然后调用上文定义的 ILBC_Link() 函数，

ILBC_Link() 函数会生成函数表，并返回函数表的首地址。

ILBC_Link() 函数的代码是这样的：

uint ilbc_MethodList [ 2 ] ; // 这是一个全局变量

uint ILBC_Link()

{

ilbc_MethodList [ 0 ] = & ilbc_Method_Person_Sing ;

ilbc_MethodList [ 1 ] = & ilbc_Method_Person_Smile ;

return ilbc_MethodList ;

}

void ilbc_Method_Person_Sing ( thisPtr )

{

// do something

}

void ilbc_Method_Person_Smile ( thisPtr )

{

// do something

}

uint ilbc_MethodList [ 2 ] ; 就是 B.dll 的函数表，这是一个全局变量。

里面的数组长度 “2” 表示 B.dll 里有 2 个方法，现在 B.dll 里只有 1 个类 Person， Person 类有 2 个方法，所以整个 B.dll 只有 2 个方法。

如果 B.dll 有多个类，每个类有若干个方法，那 D# 编译器会先对类排序，再对类里的方法排序，总之会给每个方法一个序号。

uint ILBC_Link() 函数的逻辑就是根据方法的序号把方法的函数地址填入 ilbc_MethodList 数组对应的位置，

再返回 ilbc_MethodList 数组的首地址。

也就是先生成函数表，再返回函数表首地址。

上文说了，运行时加载 B.dll 的过程是，先把 B.dll 编译成本地代码，加载到内存，再调用 ILBC_Link() 函数，这样 B 的本地代码函数表就生成了。

然后运行时会把 ILBC_Link() 函数返回的函数表首地址赋值给 A 的 ilbc_B_MethodList ，这样 A 就可以调用 B 的方法了。

因为函数是动态链接的，函数表里函数的顺序是由 D# 编译器决定的，所以和 C 编译器无关，不需要像字段那样考虑 C 编译器对函数的处理顺序。

以上就是 ILBC 的草案。还会陆续补充。

IL 层动态链接是 ILBC 的一个基础架构。

ILBC 的一大特点是同时支持 AOT 和 JIT ， AOT 和 JIT 可以混合使用，也可以纯 AOT，或者纯 JIT 。

我查了一下， “最小的 C 语言编译器”，查到一个 Tiny C，可以看下这篇文章《TCC（Tiny C Compiler）介绍》 http://www.cnblogs.com/xumaojun/p/8544083.html ，

还查到一篇文章《让你用C语言实现简单的编译器，新手也能写》 https://blog.csdn.net/qq_42167135/article/details/80246557 ，

他们还有个群，我打算去加一加。

还查到一篇文章《手把手教你做一个 C 语言编译器:设计》 https://www.jianshu.com/p/99d597debbc2 ，

看了一下他们的文章，主要是我对汇编和操作系统环境不熟，不然我也可以写一个小巧的 C 语言编译器。

ILBC 会自带运行时，如果是纯 AOT，那么运行时里不用带 C 语言编译器，这样运行时就可以小一些。

如果运行时不包含庞大的类库，又不包含 C 语言编译器，那么运行时会很小。

我建议 ILBC 不要用在操作系统上安装运行时的方式，而是每个应用程序随身携带运行时，

ILBC 采用简单的、即插即用的方式，引用到的 ILBC 程序集放在同一个目录下就可以找到。

程序集不需要安装，也不需要注册。

D# 可以编写操作系统内核层以上的各种应用，

其实除了进程调度虚拟内存文件系统外，其它的内核模块可以用 D# 编写，比如 Socket 。

这有 2 个原因：

1 GC 需要运行在一个独立的线程里， GC 负责内存回收和空闲空间排序。所以 D# 需要有一个线程的架构。

2 D# 的堆算法是不严格的、松散的，需要运行在虚拟内存广大的地址空间和存储空间下，不适合用于物理内存。

所以， D# 的适用场景是在进程调度虚拟内存文件系统的基础上。

为什么和文件系统有关系？

因为虚拟内存会用到文件系统，所以 ~ 。

D# / ILBC 的目标是跨平台跨设备。

后面会把进一步的设计放在系列文章里，文章列表如下：

《我发起并创立了一个 C 语言编译器开源项目 InnerC》 https://www.cnblogs.com/KSongKing/p/10352273.html

《ILBC 运行时（ILBC Runtime）架构》 https://www.cnblogs.com/KSongKing/p/10352402.html

《ILBC 规范》 https://www.cnblogs.com/KSongKing/p/10354824.html

《堆和 GC》写作中。

《InnerC 语法分析器》写作中。

以上是关于我发起并创立了一个 VMBC 的子项目 D#的主要内容，如果未能解决你的问题，请参考以下文章

ILBC 运行时（ILBC Runtime）架构

我发起并创立了一个 Javascript 前端库开源项目 jWebForm

用 EPWA 写一个漫画阅读器 ComicReader

我发起了一个分布式爬虫调度的开源项目 DSpiders

我发起了一个操作系统 GUI 和 Tcp / IP 包的开源项目 DeviceOS

vue创立项目脚手架并且与git仓库关联起来

我发起并创立了一个 VMBC 的 子项目 D#

我发起并创立了一个 VMBC 的子项目 D#