HEC虚拟机的一些改进建议
2008-04-08 22:46
141 查看
HEC虚拟机的一些改进建议 陈硕 2004-02-13 在《虚拟机的设计与实现——C/C++》一书中,作者Bill Blunden描述了一个简单但完整的虚拟机——HEC的设计及实现。在阅读第三章的过程中,我发现有几处值得改进的地方。不是针对HEC的总体设计和代码结构——那样牵一发而动全局,而是针对HEC虚拟机实现代码中某些细节做些改进。 1. 转换字节序 HEC的字节序(byte order)是big-endian(高位在前),而宿主平台(Win32 on Intel)是little-endian(低位在前),所以在装入.RUN文件时需要转换字节序。作者先定义了HEC虚拟机的各种类型(p.61,原书p.67): #define U1 unsigned char #define U2 unsigned short #define U4 unsigned long #define U8 unsigned __int64 然后定义了10个转换函数(p.62,原书p.68)。例如,U2 bytecodeToWord(U1 bytes[]) 的作用是将big-endian的16位无符号整数转换为本机格式: U2 bytecodeToWord(U1 bytes[]) { U2 word; U1 *buffer; buffer = (U1*)&word; buffer[0] = bytes[1]; buffer[1] = bytes[0]; return(word); } 这个函数没有考虑移植性(portability),它认定本机的字节序是little-endian。一种移植性较好的做法是: U2 bytecodeToWord(U1 bytes[]) { U2 word = (bytes[0] << 8) + bytes[1]; return word; } 这样无论主机是little-endian或者big-endian都能正确运作。在执行左移运算(<<)之前,C语言会自动把bytes[0]从unsigned char类型提升(promote)为int类型,所以不用担心数值“移掉了”。 另一种好办法是利用sockets API中的ntohs()函数: #include // or on unix-like OSes U2 bytecodeToWord(U1 bytes[]) { return ntohs(*(U2*)bytes); } 对U4 bytecodeToDWord(U1 bytes[]) 也可照此办理: U4 bytecodeToDWord(U1 bytes[]) { U4 dword = (bytes[0] << 24) + (bytes[1] << 16) + (bytes[2] << 8) + bytes[3]; return dword; } // or using ntohl() U4 bytecodeToDWord(U1 bytes[]) { return ntohl(*(U4*)bytes); } 采用同样的思路,本机数据转换为big-endian的函数可改写为(以dwordToBytecode()为例): void dwordToBytecode(U4 dword, U1 arr[]) { arr[0] = dword >> 24; arr[1] = (dword >> 16) & 0xFF; arr[2] = (dword >> 8) & 0xFF; arr[3] = dword & 0xFF; } // or using htonl() void dwordToBytecode(U4 dword, U1 arr[]) { *(U4*)arr = htonl(dword); } 在Intel处理器上,转换16位整数的字节序只需一条语句(假设数据已读取寄存器ax): xchg al, ah 改变32位整数的字节序也只需三条语句(假设数据已读取寄存器eax): xchg al, ah ror eax, 16 xchg al, ah GCC编译器在使用-O2优化开关时,就会将ntohl()函数和htonl()函数编译为上面的形式。 2. 验证字节码 在验证阶段,HEC虚拟机将检查每条指令的格式是否正确,包括操作码、寄存器号、地址值的合法性和指令的完整性,并将转换操作数的字节序。这可以视为反汇编器(disassembler)。其基本结构是 while (current_byte < stop) { U1 opcode = RAM[current_byte]; switch (opcode) { case LBI: /* LBI $r1, byte_constant BBB */ ... case ADD: /* ADD $r1, $r2, $r3 BBBB*/ ... default: /* Bad opcode */ report the error } } 其中switch-case结构的代码有近550行,列了整整12页(p.104~p.106,原书p.109~p.119)。仔细观察可以发现,其中很多代码段是重复的,很难维护。由于指令的格式很有规律,所以我们可以复用代码,简化验证过程。我的想法是,将各条指令的格式存入数组char* I_fmt[];验证字节码时,根据指令的操作码(opcode)取回格式字符串,再根据格式字符串验证指令的合法性。换句话说,这里设计了一种用于描述指令格式的小语言。基本结构为 char* I_fmt[256] = { // LBI, LWI, LDI, LQI "ORB", "ORW", "ORD", "ORQ", ... }; // in reformat() while (current_byte < stop) { U1 opcode = RAM[current_byte]; char* fmt = I_fmt[opcode]; char field; if (fmt == NULL) { // invalid opcode report the error and return } field = *fmt++; while (field != '/0') { switch (field) { case 'O': // opcode ... case 'R': // integer register ... default : FATAL_ERROR(); break; } field = *fmt++; } } 这样整个while循环只有80余行,不到原来的1/6,完整的代码可从我的个人主页下载(http://www.chenshuo.com)。这里’O’表示操作码、’R’表示整数寄存器、’F’表示浮点寄存器、’L’表示双精度浮点寄存器、’B’表示8位立即数、’W’表示16位立即数、’D’表示32位立即数、’Q’表示64位立即数、’A’表示64位地址(LAD指令)、’f’表示浮点立即数(32位)、’l’表示双精度浮点立即数(64位)、’V’表示中断向量(INT指令)等等。 3. 其他改进建议 作者声称HEC把各种整数都看作时有符号数(signed),但是他写的SLT语句确进行无符号的大小比较(p.134,原书p.137)。也就是说HEC实际上没有比较有符号整数大小的语句,它把参与大小比较的整数都看作是无符号的(意味着0<-1),这与作者的设想正好相反。因此,我建议增加一条SLTU语句,用来比较无符号整数,而原有的SLT语言则改为比较有符号数。这样就二者兼顾了。 .完.
相关文章推荐
- HEC虚拟机的一些改进建议
- HEC虚拟机的一些改进建议
- HEC虚拟机的一些改进建议
- HEC虚拟机的一些改进建议
- HEC虚拟机的一些改进建议
- HEC虚拟机的一些改进建议
- HEC虚拟机的一些改进建议
- HEC虚拟机的一些改进建议
- HEC虚拟机的一些改进建议
- HEC虚拟机的一些改进建议
- HEC虚拟机的一些改进建议
- HEC虚拟机的一些改进建议
- 改进配置管理的一些建议
- 我们在企业里要做的不是抱怨,不是提意见和建议,而是真正地对公司作一些实质性的改进
- 因为我想在博客园长呆,所以给博客园提一些改进建议
- Chromium.org team 改进vs编译速度的一些建议
- 给Android新手的一些学习建议
- 学习新手给Android新手的一些学习建议
- 关于MySQL 建表的一些建议