手把手教你写脚本引擎（五）——简单的高级语言（3，符号表）

Vir

手把手教你写脚本引擎（五）——简单的高级语言（3，符号表）

陈梓瀚

华南理工大学软件本科05级

vczh@163.com

http://www.cppblog.com/vczh/

符号表的结构的复杂度跟语言的语义规则的复杂度有关。对于C#来说，每一个符号都附带了一大堆信息，譬如位置啦，所在的namespace啦，类型啦什么的。对于JavaScript来说，符号表几乎是不需要的，因为东西都动态了，编译时几乎不检查内容。语义分析的输出是符号表，代码生成的输入是符号表和语法树。因此语法树除了放语法相关的内容，语义相关的内容最好放到符号表里面（譬如说表达式的类型啦，语句的scope结果啦）。关于一个现实中的符号表组织可以看CMinus的语义分析结果。
  `, t% W  u- H9 W# }
5 C* @6 `/ O, j首先我们要解决类型的表达问题。一门复杂的语言的类型有很多种。这里的种类指的不是int和string的区别，而是函数类型、结构类型这种区别。每一种类型还有很多附带的属性。在语义分析的过程中，我们经常要比较两个类型是否一致。于是符号表的类型表达要设计成易于读取、修改和比较。
0 t, f$ K/ z5 I
我们通常由两种解决方法。第一种方法是用一个继承结构来表达。定义一个基类TypeBase，然后底下一堆继承。乍一看很OOP，实际不然。语义分析的时候我们对每一种特殊的类型都有一些特殊的操作，我们还是举那个判断类型是否相等的操作来说明一下。我们知道OOP里面的虚函数解决了一维的分派问题。我们拿到一个Base，对Base->Method求值，总是可以根据Base的实际类型来求值。如果我们需要对两个类型同时进行分派呢？譬如说Equal(Base1,Base2)，这种操作当且仅当Base1和Base2的实际种类相同才有比较的意义。这个时候我们改造成Base1->Equal(Base2)的话，也是免不了对Base2进行一下dynamic_cast还是什么类似的操作的。
) Q; w8 P5 ]0 j' `* k
所以我个人比较偏向于第二种做法。我们为每一个类型创建一个唯一的ID。譬如说int 是0啦，int(int,int)是1啦，int*是2什么的。比较两个类型是否相等就直接拿ID去比较，ID相等则类型相等，ID不相等则类型不相等。在实际操作上怎么做呢？我们知道语义分析的过程中会产生出一堆（理论上可以为无穷多的）新类型。每一种类型都有一些属性。譬如说基本类型是有限的，可以用enum来表达。而函数类型需要返回值和参数类型表。于是我们拿属性去要一个ID的时候，符号表首先检查这个类型是否已经存在，存在则返回对应的ID，不存在则创建一条新的记录，然后绑定一个新的ID。譬如CMinus的类型表采用如下接口分配ID：

% E1 _- S6 _4 M; E

class VL_CMinusTypeTable : public VL_Base

{
public:
% n2 z2 F6 a: S4 N% p

VInt GetPrimitiveType(VLE_CMinusPrimitiveType Type);

VInt GetPointer(VInt Type);

VInt GetArray(VInt Type , VInt Count);

VInt GetFunction(VInt ReturnType , VL_List<VInt , true>& ParameterTypes);

VInt CreateStruct();

VL_CMinusTypeSlot* GetType(VInt Type);

};

; p4 e' R8 \1 c! W! ^如果我们已知一个类型的ID，求其指针类型的ID，就调用GetPointer(TypeID)。经过这一套函数的处理，我们总是可以不用担心是否在什么地方让两个ID指向了相同的类型，或者一个类型不小心拥有了多个ID，十分好管理。

第二个问题就是要保存每一个表达式的类型和语句的Scope了。我不建议将这些信息保存在语法树里面。原因比较复杂，因为一份代码在不同的上下文中可能有不同的意思，然后我们有一天突然有需要将这些环境中的这份代码的语义分析结果保留下来的话，如果东西原本是存在语法树里面的，那就完蛋了，只能去复制语法树了。于是我建议将语法分析得不到的信息通通存进符号表。因为表达式和语句都是指针，我们只需要一些map就可以将表达式和语句的附加信息存起来了。
4 \$ r3 ~* h4 K) P& u
, d0 K6 x- C  x( T: P" m0 L9 z第三个问题是scope。一个变量或参数的作用范围是有限的，于是我们只好创建一个scope树，其中每一个节点都看得到父节点，至于能不能看到子节点我觉得是无所谓的。于是对于一个具体的scope来说，一个scope就变成了一个链表，保存了当前scope的所有符号名，然后还能知道直接或间接的父scope。下面举个直观的例子。假设我们有代码：

int A=0;
4 ]3 m- r6 I5 I) x$ D. `

int B(int C,int D)

{
  int E=0;
$ ]) t3 }# F; E& n}
7 F% i' d0 G0 y3 r$ {% l- J
" h+ ^) V1 }. E" K# I& a( r6 Z  y为了处理这份代码，我们建立了三个scope。第一个是全局scope，记录了A和B。第二个是函数scope，记录了C和D。第三个是属于语句的一个scope，记录了E。于是我们用一个链表把他们串起来：语句scope -> 函数scope -> 全局scope。

- v$ E! _: v' B! v这样做的好处是我们查找scope会变得很方便。譬如现在的上下文是语句scope，那么它理应可以看见变量、参数、全局函数和全局变量。添加一个符号也很方便，只要当前的scope没有这个名字，不管上面的scope有没有我们都可以添加，添加完就把上面的scope的同名符号给覆盖了。
. T) J6 Y# w3 {* K+ b7 g5 ]
$ X/ f: Q+ t. Y( R; ]# @- N/ |) @( s一个scope其实还可以记录其他的东西的，譬如距离最近的循环表达式啦（用来判断break是否应该存在），所属的函数啦（return后面要不要接表达式），还有其他的很多杂七杂八的东西。

第四个问题是如何创建符号表。之前的文章我们把语句和表达式都建立成了两个大型的继承结构。表达式添加一个函数叫GetType，返回一个ID。语句建立一个函数叫Validate，用来验证语句是否合法。他们的参数都是符号表和当前的scope，这样的话，表达式为了创建类型就会产生出一堆ID，语句为了让表达式可以知道每一个变量的类型就要创建scope。这么一递归下去，符号表也有了，类型也检查完了。所以上文才会说语义分析产生符号表。

符号表就介绍到这里了。一个高级语言所遇到的基本的问题其实都讲得差不多了。接下来的文章就针对具体的问题进行讲解了，譬如继承、反射、垃圾收集等等的跟具体语言相关的问题。
$ I( G( |$ y1 `) j. T

767841020

有用。。。。。。。。。。

767841020

有用。。。。。。。。。。