Mon Aug 1 16:31:15 2005 章亦春 vs. 代晓珂
 
  希望你能参与到 Salent 的项目的开发中来。我们已经完成了 RAM 和 ALU 的编写与自动化测试工作，支持 x86 通用指令集和 x87 FPU 指令集的译码器也已完成过半。  	  我希望你能协助万珣新进行 MMU 的开发，或者协助张星进行 指令执行单元 （IEU）的开发。  	  MMU是什么？  	  MMU 是 Memory Management Unit 的首字母缩写，目前的主要功能是将“字”切片为“字节”。  	  毕竟我们的 RAM 是按“字”来存取的，而处理器却时常按照“字节”来读写。MMU 的作用就是协调这种差异。  	  它在处理器和 RAM 之间扮演着“中间人”的角色。  	  由于我们使用 Verilog HDL 而不是 VHDL 来描述硬件设计，因此你可能需要首先学习一下 Verilog HDL 语言。  	  机器内部的工作没有想象中的那么复杂。
推荐一本教材…… 	英文版的 《计算机组成》，张星那儿已经借了一本，我这儿也有一本。就是上学期我一直捧在手上看的。 	从 Perl Template Toolkit 的文档，到 Intel 的软件开发人员参考手册……
从《计算机组成》到 NASM 在线文档…… 	我的体验表明，硬件设计与测试工作确实非常有趣，相信你会乐此不疲的。 	我们在 Salent 项目中使用了 C/C++、MASM 汇编、Tcl 仿真脚本、Perl 语言、Perl 模板表示语言……甚至是自己设计的“微型语言”…… 	你将看到我们在这儿融合了大量极为精彩的软件和硬件技术。 	我有计划再在 Salent 项目中引入 Java，C#，JavaScript,Visual Basi，甚至于 Haskell 和 Perl6 这些语言。 	如此之多的语言和文化在 Salent 项目中交汇成一股伟大的洪流，势不可当！ 	我希望你把工作的重点放到以 Verilog HDL 语言为基础的硬件设计工作上，我刚才讲到的大多数的语言主要是为测试服务的。 	我们还剩下四个硬件模块尚未完成：
IEU （指令执行单元）
IDU （指令译码器）
MMU （存储管理单元）
TopLevel （顶层模块） 	可是，为什么不顺便学习一下我们酷酷的基于 ModelSim 的测试台的构建技术呢？ 	这可是真正意义上的自动化测试：
随机产生合法的输入信号，然后自动检查仿真器的输出…… 	祥子为 RAM 准备的“应用测试台”不仅找出了 RAM 设计中的不少微妙的问题，还捕捉到了 ModelSim 仿真器中的一个 bug 呢！ 	我在生成 idu 的状态机 AST 的过程中也捕获到了 Intel 技术文档中的不少 typo ！ 	原先 Intel 的员工也不过如此哦…… 	但我们的文档完全可以避免，知道为什么么？ 	文档，我们的 idu 实现，以及我们的 idu 测试台都是根据一棵 AST 由程序自动生成的呀！ 	而这棵 AST （Abstract Semantic Tree）又是从 Intel 的文档自动转换过来的。 	因此 Intel 文档中的所有 typo 都会反映到我们的 idu 实现和 idu 测试台的代码中，并最终被测试台捕捉到。 	神奇的技术，不是么？ 	AST 的中文翻译可以作“抽象语义树”。你可以简单地把它想象成内存中的一棵“多叉树”，或者“树林”什么的。 	就是那种东西。 	只有 Perl hackers 才能精确理解的东西…… 	Salent 中应用的大多是我们刚刚学习的最新技术。 	因此你可以借此得到快速地提升，呵呵。 	不少技术和设计模式是我们的首创。 

Fri Sep 2 16:46:50 2005 章亦春 vs. 万珣新

  MMU 你还得多费一些心思呀。  	  我希望你用高级语言对 Verilog 版本的 MMU 进行改写，以便于对硬件设计进行应力测试。  	  你得考虑从软件的角度进行 MMU 改写。  	  同时尽量保证二者接口上的兼容性。  	  我希望能将你 C++/Perl 版本的 MMU 作为我的 x86 虚拟机的一部分。  	  因此你的软件版本的 MMU 应考虑到其实际需要实现的功能。  	  硬件设计的直接翻版对我的 SVM 虚拟机而言是没有意义的。  	  你准备使用什么语言？  	  C/C++？Perl？  	  那好吧，你用 C++ 进行编写。  	  唔，我并没说最好用 Perl。事实上我们也需要 C 与 Perl 两个版本的实现。  	  请使用与 C 兼容的 C++ 语言。  	  不使用标准库。  	  一定要使用的话，你必须提供自己的标准库实现。  	  我希望最终实现 SVM 的自举(bootstrap)。  	  或者说是你的 MMU 的自举。  	  iostream 不能使用。  	  它至多用于你的 C++ MMU 的调试目的。  	  面向对象机制不能使用
重载机制不能使用
缺省参数不能使用
常量定义不能使用
C++ 标准库不能使用
C++ 模板不能用 	我希望你写出严格的 C 代码。 	C++ MMU 的接口应该和你的 Verilog MMU 的接口非常相近。 	我想你的 C MMU 的接口应该类似下面这个样子： 	int mmu_access(int rw, Byte* byte, int addr); 	mfc,strb 信号以及与 RAM 的接口信号在 SVM 的上下文中没有太大的意义。 	我希望你能把 Verilog MMU 的 mar 信号更名为更有意义的 addr 	SVM 代表 Salent Virtual Machine 	正如著名的 JVM 代表 Java Virtual Machine 那样。 	SVM 的“自举”就是在 SVM 上能够跑 SVM 自身。 	所以 SVM 最终必须用 SVM 支持的 x86 指令进行编写。 	这也就是为什么我不允许你使用那样依赖于外部操作系统和 VC 编译器的 C/C++ 标准库。 	你的 C 版本的 MMU 将为 VC 编译器编译为 MASM 汇编代码，然后再由我们自己的汇编器 SASM 汇编为我们的 SVM 支持的 x86 机器指令。 	从而最终完成“自举”过程。 	SVM 所需的 idu/ieu/ram/alu 等部件的“自举”过程与 mmu 类似。 	SVM 是一个宏伟而有趣的工程！ 	呵呵，能够在自己运行自己的虚拟机！ 	或者自己运行运行自己的自己的虚拟机！ 	SVM runs at SVM that also runs at another SVM. 	金字塔想建多高就建多高！ 	就像一个人自己把自己给举起来了！ 	……是为“自举”，呵呵。 	It's my lastest crazy idea! 	C MMU 既可用于自动化测试 Verilog MMU，又可成为我的 SVM 的一部分，何乐而不为呢？ 	咱们的汇编语言老师会大吃一惊的。 	完成 SVM 的自举过程之后，我们就应该开始考虑为 Salent 机器开发自己的 OS 了，不是么？ 	正好可以和当前学习的众多课程结合到一起耶。 	但我也想让你体会到“可行”这个词。 	还有“易行”！