语义分析之二：地址回填问题的”拉链“式解决方案

前一篇文章介绍了语义分析过程涉及到中间代码生成过程，整个生成思路都是静态的，但是如果遇到较为复杂的逻辑问题，比如控制流出口地址填写问题、外部变量引用的地址填写回填，这便涉及到边编译边回填逻辑地址的问题。遇到这种动态控制流逻辑问题，语义分析阶段采用了一种巧妙的”拉链“式回填方案，时空效率都不错的解决方案。

说着很玄乎，其实”拉链“式解决方案是链表思想的灵活使用，这一思路可以说蛮有灵性的，所以特地写了这篇文章，用来为日后可能的需求提供思路。说了这么多，下面便引入控制流逻辑地址回填问题。

//假设要翻译 if a<b or c<d and e>f ...这段程序

//理想的情况是翻译成下面这样
（1）　if a＜b goto E．true //E.true代表该if...else...逻辑的正向逻辑段入口地址，但是翻译当前bool表达式显然是暂且还不能确定E.true的
（2）　goto （3）
（3）　if c＜d　goto （5）
（4）　goto E．false       //E.false代表if...else...的反向逻辑段入口地址
（5）　is e＞f goto E．true
（6）　goto E．false //到bool表达式翻译完成时，才能确定原来逻辑块的正向段入口地址是7
（7） ...

可以看到上面的出现E.true和E.false的地方是需要回填的逻辑地址，这里比较常见的思路可能是额外为每个逻辑地址保存一个数组用来记录需要的所有地址，比如定义一个E.true-speicific-array并将(1）（2）填入该数组中。这种做法显然是很笨的，有没有比较好的方法？这便是”拉链“式解决方案，借鉴自链表的思想，为所有需要回填E.true的指令行首尾串在一起。如下所示

 （10）　…　goto　E．true
   　　  …
 （20）　…　goto　E．true
　　     …
 （30）　…　goto　E．true

//首尾相连，采用倒序的方式串在一起，这样不借助额外的数据结构便实现了定位的目的，并且动态增长也是很简单的

　　（10）　…　goto　（0）
　　       …
　　（20）　…　goto　（10）
　　       …
　　（30）　…　goto　（20）

不过既然说到了这里，那么通过”拉链“策略便可以自然地引出符号表的概念。对于上面逻辑地址的回填其实还可以让编译程序通过临时变量来保存并回填，那么如果对于goto语句这种段跳转的逻辑，显然便是需要更严格的数据结构来进行相应的数据加工了。

现在如果存在一个语句goto procedure_P;代表跳转到procedure_P段，那么如何翻译该程序段。显然编译程序在没有扫描到段P时，只能翻译成（jump, -, -, P)，然后等待段P确定后再回填，但回填后难道就把这个段P的入口地址信息给丢弃吗？那如果之后又遇到了goto procedure_P;又该怎么办呢？所以显然需要保存这个段P的入口地址信息，这个用来保存标识符（变量、函数、过程段等）相关属性的表格便是符号表。

拉链式回填方案和符号表的配合使用