CVM 在昨天完成了 call 指令的内容。现在，已经可以执行用 CMS 生成的关于各种函数的调用和参数的传递了（已经可以初步嵌入）。
我构想了一个 TinyChill 项目。这个项目是专门用于嵌入的。它使用 CVM 作为后端，目标是轻量化。这要求 CVM 必须达到轻量的级别。能做到跟 lua 的解释器一样好还是很难的。
现在 CVM 充满了 bug 和内存泄漏……静态寄存器的数据不自动释放没什么问题，但是动态寄存器的数据本就是要有管理的。目前都是各种 Alloc ，只申请不释放，想要直接应用还是不行的。（起码先把bug修了。）
关于内存管理，我准备祭出我当年写的 TinyGC 项目。这个 TinyGC 被人说过太中二 233。 嘛，直接用在 C++ 上还是不够好的。但是用在虚拟机上还是可以的（大概）。
TinyGC 其实是个筐，什么都可以装。我准备做成一个即插即用型的，带有各种插件的东西。统一好接口，对各种内容进行管理。什么 mark-sweep，什么 reference counting，什么 map manager，都可以放进去。同时，TinyGC 是一个协助型的。有许多子 TinyGC 系统，每个系统之间可以进行信息的交流。使用局部而不是全局管理是 TinyGC 的设计目标。
基于以上，CVM 被设计成一个可以分割成许多子系统（子环境）的系统。
CVM 的源码中不存在全局变量（除了 config.h 里的东西）。在一个引用了 CVM 的程序里，创建多个 CVM 实例也不会发生任何冲突（CPU流水线冲突啥的除外）。同时，我还要给 CVM 之间加上信息交流的通道。让多个 CVM 可以互相协作。
我的一个大构想是，许多语言的VM，什么 JVM，什么 python’s vm，都可以放在一起，进行交互。
现在的交互，主要还是编译为同一种字节码/汇编。比如 .NET 上的 IronPython ， JVM 上的 Jython。 这样的实现固然能解决问题，但是并没有保留一个完整的语言实现，相当于重写了它们的编译器。IronPython 3 迟迟没有支持完善好，我觉得还是因为工作量太大的缘故。
如果可以利用现有的语言实现，通过在它们上面开洞，从而实现多个解释器/虚拟机之间的交互，我认为是一种不错的思路。
那么怎么交互呢？
不同的实现之间，语言不通，想要交流，必须能够相互理解。而这个时候，就需要一个“中间人”。
没错，以 CMS 为核心的 CVM，就是起到了“中间人”的作用。
如果你看过 CMS 的文档就可以发现， CMS 的核心是 call 和各种 data register。 CMS 没有算术指令、系统调用指令。算术运算、系统调用等许多指令是通过 call 指令实现的。 CMS 很难在不进行扩展的情况下编译为一个实用的机器码程序。
这似乎是一个缺陷。但是，这是 CMS 有意为之的设计。 如同 lua 一样， CVM 的内核是精简的，同时可以方便地进行扩展。
这有如下几个好处：
- 容易嵌入到其他的语言实现中
- 容易实现
- 容易扩展
- 容易优化
正如前文提到的，CVM 之间能够相互理解。再加上嵌入的特性，可以通过多个 CVM 来实现不同语言实现之间的交流。不同实现只需要能够进行与 CVM 之间的交流，就能够进行相互之间的交流。——这就是 CVM 的伟大理想。