墨篙和小奶猫

到了一定程度，为了提升对程序设计的认知深度，了解编译原理是无法回避的MidStone。编程语言种类繁乱多样，不同的专业领域都有某一具体语言的拥趸，并且彼此间往往当成梗一样的彼此取笑逗乐，如静态语言和动态语言优劣之争，Python、Perl和Ruby的脚本之王争论，Ocmal和Scheme函数式编程简洁之争……但抛去具体使用场景而谈论编程语言的优劣，无疑是浅薄且不负责任的，无益于方案设计和功能实现。因

编译原理的几个核心阶段：词法分析、语法分析和语义分析，其实编译的本质便是翻译，其各个阶段便是承担不同的翻译任务，词法分析阶段的任务是将程序输入的字符串流翻译成语言认可的字符流（剔除空格和注释等部分）；语法分析便是将程序按照语言文法的规则构建成语法树；语义分析便是在语法树构建的基础上完成语言规则的语义动作（类型检查、作用域和可视性检查、一致性检查等）。现今的程序语言绝大多数都是图灵完备的，故而语法设计

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

符号表贯穿词法分析到语义处理的全过程，是用来存放在程序中出现的符号标识符（变量、函数、过程等）的语义属性在词法分析及语法分析阶段不断积累和更新符号表中的信息，并在词法分析到代码生成甚至动态链接的各个阶段，按照各阶段的需求获取不同的属性信息进行处理。 1.符号表的作用 1. 在编译翻译各阶段不断的收集和加工符号属性； 2. 为语义分析阶段的合法性检查提供数据支持（比如变量可见性、类型匹配与否）；

1.符号表的几种组织形式 前面的文章《符号表之一：符号属性》也可以看到不同符号之间的语义属性数目和内容是存在差异的，那么如果运营符号表呢？显然有两个很明显的思路：1. 分而治之：创造多个符号表，每个符号表内的符号是属性完全相同的；（组织方法分散，虽然单个表内的运营较为简单，但是子表过多，增加了很多工作量） 图1. 分而治之：分散子表2. 集权管理：牺牲空间，添加冗余，将所有符号放在一个表内。

前面介绍了表项管理和组织，也介绍了对于一些畸形数据结构的符号表如何管理组织的方案，那么现在遇到了一种最为常见的问题：对于程序的不同层次段中，同名变量的可见性是如何通过符号表来严格约束并实现的？对于具有分程序型结构的语言程序，不同层次分程序中定义的标识符号具有不同的作用域和不同的可视性规则。通常对于具有分程序结构的语言可用两种方式组织它们的符号表：一是对每个分程序建立一个独立的分表结构的符号表；一是把

介绍了符号表的组织形式有线性组织（重插入简洁性，轻索引性能），排序组织（插入操作耗时，重索引性能），哈希表映射（以空间换取时间）。那么如下便介绍了符号表的链表实现方式和哈希表实现方式，分别对应线性组织和哈希表映射两种方式，至于排序组织方式的实现其实只需要一个动态扩展数组便可以实现，较为简单不作讨论。网上关于符号表的实现代码有很多，没有必要重复造轮子，其中个人觉得实现最好的是erhuoxifu博主的两

前面介绍完了词法分析、语法分析和语义分析，以及各阶段如何利用符号表来实现代码合理性确认以及代码地址拉链式回填等工作。编译原理出于代码编译的模块化组装考虑，一般会在语义分析的阶段生成平台无关的中间代码，经过中间代码级的代码优化，而后作为输入进入代码生成阶段，产生最终运行机器平台上的目标代码，再经过一次目标代码级别的代码优化（一般和具体机器的硬件结构高度耦合，复杂且不通用）。故而出于理解编译原理的角度考

前面提到了经过了词法分析->语法分析->语义分析->中间代码优化，最后的阶段便是在目标机器上运行的目标代码的生成了。目标代码生成阶段的任务是：将此前的中间代码转换成特定机器上的机器语言或汇编语言，这种转换程序便被称为代码生成器。1. 程序移植性和编译器模块设计的关系 之所以将编译原理分成这种多阶段多模块的组织形式，本质的考虑其实只有两个方面： 一、代码复用：尽可能在不增加程序员工作量的前提下，增