面向非专业程序员的语言,最好能在编译时检查函数签名(匹配参数名称,参数个数和其参数类型)。而C封装给lua的函数,得要传入参数、实际运行一遍,才能知道运行路径上是否有错误(对于那些运行不到的分支路径上的,函数调用错误还是无法发现)。因此,需要考虑改造lua的前端,甚至可以考虑把它从动态类型语言给改成类C的语法,而保留其VM部分。 llex.c负责词法解析的函数,400多行。lparser.c应该是负责语法和语义的,1300多行。粗看了下,代码结构还是比较清晰的。 sourceforge上的这个项目CLUE:http:///projects/cluecc/ 有点像我们想要的c解释器,c语言做前端,后端可编译成各种语言(lua, java, lisp, perl....)。clue本身带了点实验性,并不完备,最近的一次更新在2008年。 它的词法和语法用的是sparse,linux下的一个C语义分析器,实际用于检查代码包括linux下的源代码,应该来说相对比较成熟,但其支持了不少GCC的特性,可能相对比较复杂。通过调用sparse_initialize将其转换成一个symbol_list。 cluecc的源代码结构不复杂,所有关键的函数和结构都定义在global.h中。结构codegenerator来表示代码生成的后端,大部分成员变量是实现语言基本逻辑的函数指针,由各个语言后端去实现各自的codegenerator( cg_lua, cg_java, cg_javascript...)。 查看了cg_lua.c文件,基本是利用格式化打印语句转成可读的lua脚本语句,主要是花了不少代码在函数转化和循环分支语句之类的转换上面。 比较查看了不少C语言的前端解析,我们理想的目标是:a. 语法支持范围更小一点(简练表达业务逻辑即可,而不需要涉及系统方面的); b. 项目规模小,代码可读性强(因为需要理解修改); c. 有相对完备的语法错误检查和报告。 PCC用的是lex,yacc,后端也很强,各种平台。 OTCC(Obfuscated Tiny C Compiler),目前见过代码量最小的了。它本身就是为了参加一个要求能编译自身的最小编译器比赛而做的。看了下主要代码,是边parse边直接生成机器码了。这是不是我们想要的样子呢,类C语言直接生成lua的byte code. OTCC的作者另外有一个对 ISO C支持更完整的项目TCC。 google开源项目picoc,也很小,picoc的核心代码3000多行。它最初就是设计起来做为一种脚本语言,并不支持完整的ISO C标准,但基本的都有。 LCC,又一个产品级别的C语言编译器,有基于其上的lcc-win32等一整套的开发工具,包括调试。 |
|