第 13 章　编程语言与编译

13.1语言的层次：从机器到人

编程语言不是只有一种，而是一个从底层到高层的谱系，越往上越贴近人、越远离硬件：

层次谱系的经济学：为什么四层语言并存

既然高级语言开发效率高，为什么不把汇编和 C 淘汰掉？因为每一层都有不可替代的场合，这背后是一笔「翻译税」的账。你写一行高级语句，确实省了心，但翻译成机器码后往往膨胀成多条指令——翻译器替你做的事（分配寄存器、安排内存、选择指令）一件都不会消失，只是从「你亲手做」变成了「编译器替你做」。于是：写系统底层、驱动、启动代码时，抽象层薄一点反而意味着控制多一点、意外少一点，C 和汇编仍是主力；写应用、脚本、数据分析时，人的时间比机器的时间贵，抽象层厚一点让开发快一点，高级语言稳赢。层次谱系不是「进化淘汰赛」，而是分工生态：越靠近硬件的层管「精确与高效」，越靠近人的层管「表达与速度」。

层次还决定了一个关键性质：可移植性住哪一层。机器码是与具体指令集绑死的（第 11 章：换一套 ISA 就不认），汇编几乎同样绑死，而高级语言源代码是跨平台的——同一份源码，在 x86 机器上用 x86 编译器翻一次，在 ARM 机器上用 ARM 编译器再翻一次，就能各自运行。所以「跨平台」的准确含义是源代码层可移植、机器码层不可移植；Java 宣传的「一次编译、到处运行」走的是第三条路——先编译成不绑定任何 CPU 的「字节码」，再由各平台的虚拟机执行，把「翻最后一公里」的活儿留给了运行环境。

最后把「翻译发生在什么时候」这个伏笔埋下：有的语言把翻译全放在运行之前（编译型），有的放在运行之中（解释型），有的两头都占（先编译成中间码、运行时再解释）——这条时间轴正是 13.5、13.6 两节的主线，也是「编译 vs 解释」之争的全部内容。

工程视角：安全关键软件（航电、汽电）在语言层次的选择上普遍保守：偏好编译型语言 + 强静态检查（编译期能抓住的错误绝不留到运行期），并刻意限制动态特性（运行期改变程序行为的特性）——因为认证的审查对象是「可预测的行为」，而解释型语言的灵活性恰恰以牺牲可预测性为代价。这与桌面软件「快糙猛」的口味相反，却完全符合同一条经济学规律：谁的错误代价高，谁就要把翻译与检查尽量提前。

辨析：「可移植」一词常被混用，分三个粒度说清——源码级可移植（高级语言 + 条件编译，跨平台要重新编译）；二进制可移植（字节码 + 虚拟机，如 Java/Python 的 .pyc：同一份中间码到哪台机器都认，代价是每台机器都要装虚拟机）；完全不可移植（机器码、汇编，换指令集即作废）。看到「跨平台」三个字，先问一句：跨的是源码还是成品？

再辨析：把谱系放回日常分工——一个真实系统里四层往往同时在场：固件里的汇编负责最早的启动与硬件初始化（此时连内存都未必就绪，高级语言还跑不起来）；C 负责操作系统内核与驱动这类「贴着硬件做精确控制」的部分；框架化的高级语言负责业务与应用；脚本语言负责把这一切黏合起来做自动化运维与测试。层次谱系不是历史博物馆，而是每天都在运转的分工现场——你手机里一次普通的联网操作，四层代码都在工作。

13.2高级语言「高」在哪：抽象的力量

「高级」不是指「更厉害」，而是指抽象层次更高。回顾第 12 章的「抽象」：每一层都对上一层藏起麻烦。高级语言把大量底层细节藏了起来：

• 你不用管「数据放在哪个寄存器、哪个内存地址」——变量替你管理。
• 你不用管「这条指令是 ADD 还是 MOV」——一句 a = a + b 就够了。
• 你不用管 CPU 的指令集差异——同一份代码理论上能跨平台。

抽象的「税」与「息」，还有藏不住的「脾气」

抽象不是免费的午餐，它更像一笔投资。收益（息）：开发效率——一行顶四条指令；正确性——编译器替你安排的指令序列经过千锤百炼，比手写更少出错；可移植性——源码不绑定具体 CPU。成本（税）：翻译损耗——同样的逻辑，高级语言展开的指令常常比高手手写的汇编多（编译器要照顾「通用正确」而非「此处的最快」）；控制力下降——你不再直接指定「用哪个寄存器、按什么顺序访存」，硬件的脾气被藏在了抽象底下。于是工程实践长出一条经验：外圈用厚抽象快速搭建，内圈关键路径允许穿透抽象手工优化（这与第 12 章的调度权衡是同一个思想）。

更要紧的是认识到：抽象会「漏水」。高级语言把二进制表示藏起来了，但 IEEE 754 浮点数的物理脾气（第 2 章埋的伏笔）并没有消失——它只是换了种方式出现在你面前，让你在「明明很简单的算术」上栽跟头。看下面这段在 Python 里实际运行的结果：

>>> 0.1 + 0.2 == 0.3
False
>>> 0.1 + 0.2
0.30000000000000004

这不是 Python 的 bug，更不是玄学：0.1 与 0.2 在二进制里是无限循环小数，装入 64 位浮点数时必须舍入；两个「已经各自近似」的数相加，误差就暴露在最后一比特。这就是经典的「抽象泄漏」（leaky abstraction）：抽象层藏住了复杂性，却藏不住复杂性的副作用。工程师的成熟标志之一，就是知道手上的抽象层哪里会漏——浮点比较要用容差、货币计算用整数分、舍入规则要显式声明。

工程视角：这个 0.1 + 0.2 的坑在真实系统里造成过事故级的失败——金融对账差一分钱、温控阈值误判。安全关键软件的编码规范干脆明令「禁止对浮点数做相等比较」「金额禁止用浮点」，把抽象泄漏处的地雷直接写进纪律。理解抽象在哪一层漏水，是「会用工具」与「驾驭工具」的分水岭。

辨析（衔接第 12 章）：「抽象」在本教材出现两次——第 12 章 OS 把硬件抽象成「文件」「进程」，本章语言把指令抽象成「表达式」「函数」。两次是同一个思想：给上一层一个干净的门面，把复杂性圈在自己身后。连起来看整台计算机：晶体管抽象成逻辑门（第 4 章）、逻辑门抽象成加法器（第 5 章）、运算部件抽象成指令集（第 11 章）、指令集抽象成高级语言（本章）、高级语言再抽象成框架与应用——每往上一层，能用一行表达的东西就多一分。计算机科学的第一生产力，就是这层层叠叠的封装。

13.3编译器：把高级语言翻译成机器语言

既然 CPU 只认机器语言，谁来把高级语言翻译过去？答案是 编译器（compiler）。

编译器是一个翻译程序：它读入你写的「源代码」（source code，如 a = a + b），整体检查、整体翻译，一次性生成一个完整的「可执行文件」（机器语言）。之后，CPU 直接运行这个可执行文件，编译器的使命就结束了。

编译器是「程序写程序」

编译器有个耐人寻味的身份：它本身就是一个程序——一个专门用来生产别的程序的程序。你用高级语言写源码，编译器（自己也是被编译出来的机器码）读入源码、吐出机器码。这带来两个重要推论。其一，编译器必须先于它编译的程序存在——最初的编译器是机器码手工写出来的（自举：用旧编译器编译出新编译器），如今的工具链是这条链上数十年积累的产物。其二，编译器自己也可能有 bug——所以安全关键软件领域有一门专门的学问：验证「编译器翻译得对不对」（形式化验证），一条指令翻错，飞控就可能在无人察觉的情况下越界，这就是把翻译官本身也纳入审查的原因。

「翻译发生在什么时候」由此产生一个强力变体：交叉编译（cross compilation）——在 A 机器上编译出 B 机器的机器码。你在笔记本上写代码，编译出洗衣机控制器（另一种指令集）的程序，笔记本不必能「运行」它，只需能「翻译」它。编译与运行的这种分离，正是「先翻译后运行」哲学的自然延伸：翻译产物绑机器，但翻译动作不必绑机器。

编译哲学最锋利的一刀是「把错误消灭在错误发生之前」。错误被发现的时刻越早，修复越便宜：词法错误（写错单词）编译器当场报错，改一个字符；类型错误（把字符串赋给整数）编译器也当场报错，改一行代码；若是同样的问题躲过编译、在运行期才爆发，那时它可能已经藏进了百万行机器码的行为里，排查要靠复现、看现场、逐层剥离——成本相差的不是几倍，是几个数量级。「尽早失败」因而成为编译型语言开发文化的底层信仰。

int a = 42, b = 58;   /* 初值已在内存 10、11 号单元 */
a = a + b;           /* 取出相加，存回 a */

LOAD  R1, 10   ; R1 ← 内存[10]，即 a=42
LOAD  R2, 11   ; R2 ← 内存[11]，即 b=58
ADD   R1, R2   ; R1 ← R1 + R2 = 42 + 58 = 100
STORE R1, 10   ; 内存[10] ← R1，a 更新为 100

LOAD  R1, 10   →  0010 0001 1010   = 0x21A
LOAD  R2, 11   →  0010 0010 1011   = 0x22B
ADD   R1, R2   →  0001 0001 0010   = 0x112
STORE R1, 10   →  0101 0001 1010   = 0x51A

工程视角：三层对照正是嵌入式开发的日常——工程师常常读的不是自己写的 C，而是编译器吐出的汇编与反汇编（机器码逆向回汇编）：核对关键时序、定位诡异的优化问题、审查编译器是否按预期翻译。安全关键软件的审查链条里，「源码 ↔ 汇编」的一致性核对是一个正式环节。能顺三层对照读懂一段汇编，是嵌入式工程师与安全审查员的看家本领。

辨析：编译器（compiler）与汇编器（assembler）都是翻译器，区别在输入的层次：汇编器的输入是汇编（每条指令与机器码一一对应，翻译基本是「查表替换」+标号解析，第 11 章已手工演过）；编译器的输入是高级语言（一句顶多条指令，翻译要做选择——用哪条指令、哪个寄存器、什么顺序，这是「算法」级的难度）。别把「编译」笼统叫「汇编」，也别以为编译器只是「高级版的查表」——它是不折不扣的语言学问题。

13.4编译的四步：词法→语法→语义→生成

编译器的翻译不是「看一句翻一句」，而是分阶段、层层深入，像人读文章：

1. 词法分析（lexical analysis）：把源码切成一个个「词」（token）——数字、变量名、运算符。相当于「认字」。
2. 语法分析（syntax analysis）：检查这些词按语法规则排列对不对，生成「语法树」。相当于「看句子通不通」。
3. 语义分析（semantic analysis）：检查意义对不对——类型是否匹配、变量是否定义。相当于「看意思通不通」。
4. 代码生成（code generation）：把验证无误的语法树，翻译成目标机器的指令。相当于「落笔成文」。

四步各自的机制：从字符流到指令流

把四步串起来看一个具体例子。对源码 total = price + 3.5 * count;：词法分析按「最长匹配」把连续字符切成 token 流——total、=、price、+、3.5、*、count、; 共 8 个词（它不关心语法对错，只管切词与分类：标识符、运算符、数字字面量）；语法分析按文法规则把这串词组织成语法树——乘法优先于是 3.5 * count 先结合成一个子树，加法再把它与 price 结合，整个右侧最后挂到 total = 之下（树一旦画对，运算顺序就定了）；语义分析查「意思」——price、count 定义过没有？类型对不对（浮点数乘整数，按规则提升为浮点）？有没有把数组当整数用？符号表在这步被填写与查询：每个变量叫什么、什么类型、作用域在哪；代码生成则把验证过的语法树按目标指令集「翻译落笔」，常常还带优化：能算的常量提前算（3.5 * 4 在编译期就算成 14）、重复的表达式只算一次、寄存器复用不浪费。

四步各有各的失败姿势，认得出来对调试极有用：词法错误——出现了语言词表里没有的东西（非法字符、写断的字符串）；语法错误——词都对、顺序不对（括号不配对、句末丢分号）；语义错误——句子通顺但意思不成立（未定义的变量、类型不匹配）；而逻辑错误连编译器都拦不住（句子完全合法，但算出来不是你要的）——它要靠测试与审查，是验证学科（而非编译器）的战场。报错信息之所以能精确到「第几行第几列」，正是因为词法分析时就为每个 token 记住了出生地址。

工程视角：读懂语法树有真实用处——IDE 的「重构」功能（安全重命名一个变量、把内部表达式抽成函数）之所以不会误伤同名局部变量，靠的就是 AST 的作用域信息而非字符串替换；静态分析工具（在运行前扫描源码找隐患）与代码格式化工具同样构建在「词法 + 语法树」这套机制上。你在编辑器里享受的每个「智能」，几乎都有一台小小的前端编译器在后台认字、看句子。

辨析：语法错与语义错的分界——「total = price + ;」缺操作数，语法分析阶段当场报错；「total = price + "abc";」（数字加字符串，视语言而定）语法树成立、语义分析拦下；「total = -price + 3.5 * count;」语义完全合法，却可能不是你想要的业务含义——前两者机器能查，第三种只有人与测试能查。编译器的四步流程把前两类错误挡在运行之前，这既是编译的胜利，也是它的边界。

13.5解释器：另一种执行方式

还有一条完全不同的路线：解释器（interpreter）不做「整体翻译」，而是读一句、翻译一句、执行一句，边走边做，像同声传译。

Python 就是典型的解释型语言：你写一行 print("你好")，解释器当场读、当场执行，不生成一个独立的可执行文件。每跑一次，都要解释器在场逐句翻译。

解释器也是被编译出来的

初学者常有一个错觉：「Python 是解释型语言，所以它跟机器语言没关系」。恰恰相反——解释器本身就是一个用 C 语言写成、被编译成机器码的大程序（CPython 解释器便是如此）。当你执行 print("你好") 时，真实发生的是：机器码形态的 Python 解释器在运行，它读入你的 .py 源文件，在自己的循环里取一句源码、分析、再调用自己内部的机器码去完成动作。你的程序没有直接指挥硬件，是解释器在替你指挥——这解释了为什么逐句翻译「较慢」：同样一步加法，编译型的 CPU 直接执行 1 条加法指令；解释型的 CPU 先执行解释器里几十条指令（取指、分派、查类型、决定动作），才轮到你的加法本身。翻译的功夫没有消失，只是被摊进了每一次执行。

「读一句、执行一句」的副产品是一整套交互能力：REPL（Read-Eval-Print Loop，读取—求值—打印—循环）让你敲一行、立即看到结果，像跟机器对话。数据探索、教学演示、快速原型都依赖这种「即改即跑」——试错周期以秒计。反观编译型语言：改一行 → 编译（秒到分钟）→ 运行，反馈回路天然更长。开发效率的差距，本质是反馈回路的长度之差。

工程视角：脚本语言在现代工程里牢牢占据「胶水层」：构建自动化、数据处理管线、测试脚本、运维批量操作——凡是「把若干现成工具串起来」的活，解释型语言改一行立即生效的优势无可替代。而性能关键的内核（编解码、数值库、数据库引擎）仍是编译型语言的领地。成熟的工程师按「这一层代码改动的频率与运行的次数」来选语言：频繁改、少运行的用解释；写定后高频跑的用编译。

辨析：「解释」不等于「不翻译」，而是「翻译不落地」——编译型的翻译结果保存为独立文件（可执行文件），解释型的翻译结果是临时的（翻一句、用一句、丢一句）。另外注意 Java 与 Python 的相似方案：Python 在导入模块时其实也会把 .py 编译成 .pyc 字节码文件缓存下来（避免每次重新翻译），但这层字节码仍由虚拟机逐条解释——「半落地」的中间态，说明纯编译/纯解释只是光谱的两端。

再辨析：「解释型语言天生慢」的说法也要分层看——慢的是「逐句翻译」这个环节，不是语言注定的命运。解释型语言的数值计算库常把重活交给底层编译好的 C 代码执行，一行操作跑出接近编译型的速度并不稀奇；被 JIT 装备起来的 JavaScript 驱动复杂网页界面也早不是「玩具速度」。判断性能，看的是热点代码最终由谁执行（解释器的循环，还是直接执行的机器码），而不是语言标签上的「解释型」三个字——这正为下一节「两者结合」埋下伏笔。

13.6编译 vs 解释：两种哲学

选型决策：什么场景用什么路线

把两种哲学落成一张决策清单，按「代码改动频率」与「运行次数」两个轴来看：系统软件、嵌入式、性能关键库——写定后跑千百万次，选编译（C/C++/Rust 一类），并享受编译期类型检查兜底；探索分析、自动化脚本、原型验证——改得勤、跑得少，选解释（Python/JavaScript 一类）；跨平台交付的大规模应用——既要「写一次到处跑」又要「跑得不太慢」，选中间路线（Java/Kotlin、C# 一类）：编译成字节码 + 各平台虚拟机。安全关键软件的选型还有第三条判据——「行为可预测、可静态审查」优先，语言层面能提前锁死的错误越多越好，这与「快速试错」的口味正好相反，再次印证：没有最好的语言，只有与错误代价匹配的语言。

现代主流平台的真实形态是「先整体编译成字节码，再由虚拟机解释执行，跑热了的代码段再即时编译成机器码」——Java 虚拟机（JVM）与主流 JavaScript 引擎都走这条「三段式」路线。为什么最后还要加一层「即时编译」（JIT）？因为纯粹的解释对热点代码太亏、纯粹的提前编译又太迟钝（运行时才能看到的信息——哪些代码高频、什么类型常出现——编译期看不到）。JIT 用一个聪明的门槛解决：先解释跑着，计数器盯着每段代码的执行次数，超过阈值的热点才触发即时编译——冷代码零额外成本，热代码享受接近编译型的速度，鱼与熊掌各取一半。

辨析（衔接下一章）：语言层走到这里，「翻译」的故事讲完了——高级语言最终都会变成机器指令。下一章的输入输出设备则回答另一半问题：机器指令执行完之后，结果如何走出 CPU、变成屏幕上的画面与打印纸上的字？抽象层的下一站，是人机对话的接口。