你有没有想过一个看起来特别费解的问题你明明写的是total price * 0.8这种人类友好语法CPU 凭什么能执行它CPU 不认任何人类语言它只认一串二进制数字。所谓高级语法在 CPU 眼里不是什么漂亮句子而是一道必须“翻译”才能执行的指令序列。《程序是怎样跑起来的》第 1.3 节讲的就是这件事——程序的“行为”究竟是怎么落到硬件上的。我把这本书的精读重点放在这里是因为太多人把“编程”理解成“写代码”却忽略了真正要紧的一半代码被 CPU 解释成行为的过程。这篇文章适合刚接触计算机原理的入门者、写了很久业务代码但没看过汇编的开发者也适合那些想搞清楚“为什么 Python 慢、C 快”的非科班选手。你不需要会汇编只要会一点任意高级语言就能顺着这条翻译链从变量名一路看到寄存器里的 0 和 1。1. 为什么 CPU 必须先“翻译”从机器码到指令集的那道鸿沟1.1 CPU 是个死脑筋只认写死在硬件里的指令表先纠正一个常见误解很多人以为 CPU 能“看懂”程序实际上 CPU 根本没有理解能力。它只是一个严格按照指令表工作的状态机每条指令都是硬件里固定的一个二进制模式。比如 x86 架构下0x90代表空操作 NOP0x55代表把 RBP 寄存器压栈0xC3代表从函数返回 RET。这些数字不是约定俗成的协议而是芯片设计时写入电路的编码规则。一条指令由两部分组成操作码说明“做什么”操作数说明“对谁做”。加、减、比较、跳转、从内存取值、把值写回内存CPU 能做的无非就是这些最基础的动作。一个复杂的程序几万行几十万行最终全部被拆解成这些基本动作的序列。这就是为什么程序能够“跑起来”的物理前提程序只是一段躺在内存里的机器码CPU 不停地把这些机器码取出来、翻译成控制信号、驱动运算器和寄存器工作。这里需要顺带提一下指令集的概念。x86、ARM、RISC-V 是不同的指令集相当于 CPU 各自不同的“母语”。你给 x86 CPU 一段为 ARM 编译的机器码它完全看不懂直接报错。这就像你给一个只懂闽南话的人发了一条粤语语音他听得见但完全不知道你在说什么。所以“程序在不同 CPU 上能不能跑”取决于这段机器码是用哪种“方言”编写的。1.2 高级语言是给人类写的机器语言是给硬件跑的既然 CPU 只认机器码那为什么不直接写机器码因为人记不住55 48 89 e5 c3这种东西。于是有了汇编语言它只是机器码的助记符一条汇编指令对应一条机器码。比如push rbp就是那个55ret就是那个c3。汇编仍然很啰嗦而且每种 CPU 的汇编不一样可移植性极差。高级语言的出现本质上是一次“抽象赌博”用变量名代替内存地址用函数代替跳转和栈操作用if和while代替条件跳转。但这些抽象 CPU 完全不认识。price这个名字在 CPU 里根本不存在0.8这种小数在 CPU 里也不是理所当然的格式。高级语法必须被翻译成一条条 CPU 指令这个翻译过程就是这一节的核心。打个比方你请一个只会做川菜的厨师帮你炒菜你给他一份英文菜谱是没用的。得先有一个人把它翻译成厨师能看懂的“操作步骤”每一步对应一个他练过无数遍的动作。编译器就是那个翻译官CPU 就是那个厨师它不看你的菜谱长什么样只按自己的动作清单执行。2. 翻译的两种路线编译和解释一次翻译与边看边译2.1 编译器把翻译工作提前做完执行时只管跑C、C、Go、Rust 这些语言走的是“编译器”路线。编译器一次性读完整个源码文件经过预处理、编译、汇编、链接四个阶段最终生成一个包含机器码的可执行文件。这个文件里的内容已经是目标 CPU 能直接执行的东西了运行时不需要再做任何语言层面的转换。这条路线的好处是执行快因为翻译成本已经预付了。坏处是可移植性差同一份 C 代码你得在 Windows 上编出一个 Windows 可执行文件在 Linux 上编出一个 Linux 可执行文件在 ARM 手机上编出一个 ARM 版本。你可以把一个程序比作菜谱但每个餐厅的厨房设备不一样你得针对每间厨房重新“翻译”一遍操作步骤。2.2 解释器边读边翻灵活但每次执行都要付出翻译开销Python、Ruby 这类语言走的是解释器路线。严格说现在的 Python 也不是纯“逐行解释”了解释器会先把源码编译成一种叫字节码的中间指令再逐条执行字节码。你会在__pycache__目录里看到一堆.pyc文件那些就是编译好的字节码缓存。解释器路线的优点是跨平台只要目标机器上有 Python 解释器同一份源码就能跑因为源码翻译成什么由解释器自己决定。缺点是运行时开销大因为翻译动作被分摊到了每次执行过程中。这就是为什么 Python 比 C 慢的底层原因之一C 的翻译成本在编译期支付一次Python 的翻译动作虽然在首次编译成字节码时也支付了但字节码仍然不是机器码解释器还得在运行时把每条字节码再“翻译”成对应的 CPU 操作。JavaScript 的 V8 引擎更聪明一点它一开始用解释器快速执行同时统计哪些代码被反复执行热点代码一旦发现热点就用 JIT即时编译把那一段字节码编译成机器码再缓存起来。所以现代 JS 的性能比早期好得多本质上是因为它把“解释”路线和“编译”路线结合了起来。2.3 字节码编译与解释的折中方案Java 是“字节码”方案的典型代表。javac把源码编译成.class字节码文件而不是直接编译成某个 CPU 的机器码。字节码是一种“面向虚拟机”的指令集JVM 在运行时再决定把字节码解释执行或者用 JIT 编译成宿主机 CPU 的机器码。用表格看三种路线会更清楚路线翻译时机执行速度跨平台能力代表语言一次性编译运行前快差需重新编译C、C、Go、Rust解释执行运行时逐条慢好有解释器即可Python、Ruby字节码JIT运行时混合较快较好需对应虚拟机Java、C#不管哪条路线最后真正在 CPU 上执行的都是机器码高级语法只是旅程的起点。理解了这一点你就不会再问“为什么 Python 程序不是直接在 CPU 上跑”这种问题了。3. 高级语法的五步翻译流水线从源码到机器码3.1 词法分析与语法分析先切碎再拼出结构编译器拿到源码后第一步是词法分析。就是把一串字符串切成有意义的“词”术语叫 token。以total price * 0.8;为例词法分析会把它切分成标识符total、赋值号、标识符price、乘号*、浮点字面量0.8、分号;。第二步是语法分析把这些 token 按语言规则组装成一棵抽象语法树AST。AST 大概是这样的Assign(total) └── Mul ├── Var(price) └── Const(0.8)这棵树表达了代码的结构把price和0.8相乘结果赋值给total。你在 IDE 里看到的“SyntaxError”绝大多数就是语法分析阶段发现这棵树拼不出来了。这一步只检查“句子通不通”不检查“意思对不对”。3.2 语义分析与中间代码检查类型再翻译到中间层语法通过后编译器进入语义分析。这里要检查类型一致性、作用域、变量是否存在等。比如price是 double0.8也是 double乘积是 double赋值给total如果是 int编译器就会警告精度损失。类型错误就是在这个阶段被拦下来的。之后编译器会把 AST 翻译成中间代码IR。中间代码比 AST 更接近机器指令但又不依赖具体 CPU。比如那句乘法可能变成三地址码t1 price * 0.8 total t1中间代码最大的价值是方便做优化。编译器会在这一层做常量折叠、死代码消除、循环不变式外提等操作。比如int a 200 * 2;在编译期直接算成400根本不会让 CPU 在运行时做乘法定义了却没用到的变量直接被删掉。这些优化直接影响最终机器码的数量也直接改变程序性能。3.3 目标代码生成把抽象语法落地到寄存器和内存优化完的中间代码会被翻译成目标 CPU 的汇编代码。我拿一段最简单的 C 代码来做示范先看不开优化的情况int main(void) { int a 10; int b a 5; return b; }用 x86-64 指令集简化后的汇编长这样main: push rbp mov rbp, rsp mov DWORD PTR [rbp-4], 10 # 把 10 存入局部变量 a 的内存位置 mov eax, DWORD PTR [rbp-4] # 把 a 的值读入 eax 寄存器 add eax, 5 # eax 加 5 mov DWORD PTR [rbp-8], eax # 把结果存入局部变量 b 的内存位置 mov eax, DWORD PTR [rbp-8] # 把 b 的值放入返回值寄存器 pop rbp ret注意几个细节。局部变量a和b并不存在于汇编里它们变成了栈上的内存地址[rbp-4]和[rbp-8]。rbp是栈帧基址指针函数一进入就通过push rbp保存上一层的基址然后把当前栈顶赋值给rbp。eax是通用寄存器这里既用来做加法运算也作为函数返回值的固定寄存器。这就是“高级语法落地”的真实样子变量名消失只剩下寄存器和内存地址。每条汇编指令最终会被汇编器翻译成一段二进制机器码。比如push rbp对应0x55ret对应0xC3。一个可执行文件里就是成千上万个这样的字节堆在一起。如果开了-O2优化编译器会直接算出这个函数返回值是 15然后生成mov eax, 15; ret两三条指令连中间变量都省了。这就是常量折叠和死代码消除联手后的效果。3.4 汇编与链接把散装零件拼成完整程序目标代码生成后编译器通常会先把 C 代码翻译成汇编文件.s再用汇编器把汇编翻译成目标文件.o。但单个.o文件还不能运行因为你的代码里调用了printf、malloc这些标准库函数这些函数的机器码在别的目标文件或动态库里。链接器的作用就是把一堆.o文件和你依赖的库合并成一个完整的可执行文件解析符号地址填好跳转目标。这就是为什么你点 IDE 里的“运行”按钮时背后其实跑了一整套工具链。你以为只是执行了你的代码实际上编译器把你的源码切碎、分析、优化、翻译、再拼装最终产物才轮到 CPU 去执行。4. 行为落地之后变量、函数与循环在 CPU 里是怎么活着的4.1 变量不是盒子是寄存器编号和内存地址很多入门教材把变量比喻成“盒子”这个比喻在高级语言层面没问题但到了 CPU 视角就失真了。CPU 没有“变量”这个概念只有两类存储位置寄存器CPU 内部几十个字节的临时存储和内存按字节编址的超大数组。局部变量通常放在栈上全局变量放在数据段动态分配的对象放在堆上。你说的“取出变量的值”在 CPU 眼里就是从某个内存地址读取数据到寄存器你说“给变量赋值”就是把寄存器里的数据写回某个内存地址。a取地址这个操作因此变得非常直白它就是拿到那个变量对应的内存编号。指针能做的事情本质都是内存寻址。理解了这一点你在学指针、引用、可变对象不可变对象时很多困惑会瞬间消失。比如 Python 里的a [1, 2, 3]a这个变量在解释器的内存里只是一个指向列表对象的指针列表本体在堆上。这也是高级语法被“翻译”成 CPU 行为时最容易产生认知落差的地方。4.2 函数调用压栈、跳转和返回函数调用在 CPU 层面是一个更加机械的过程。以 x86 为例call指令做两件事把返回地址当前指令的下一条指令地址压入栈然后跳转到函数入口。函数执行完后ret指令从栈顶弹出返回地址跳回去接着执行调用点之后的代码。这意味着每次函数调用都会消耗栈空间来存返回地址和局部变量。递归函数如果递归深度过大栈会被撑爆这就是你遇到过无数次的栈溢出Stack Overflow错误的来源。编译器对此有对策比如尾调用优化如果函数末尾直接返回另一个函数的调用结果编译器可以复用当前栈帧把递归优化成循环避免栈无限增长。但并不是所有递归都能做尾调用优化这取决于你的代码形态。4.3 if 和循环本质上都是跳转高级语言里的if、while、for翻译到汇编层面全是跳转指令。if (a 0) { ... }大致会变成mov eax, DWORD PTR [rbp-4] # 把变量 a 读入寄存器 cmp eax, 0 # 与 0 比较 jle label_else # 小于等于 0 就跳转到 else 分支 ; if 分支的指令 jmp label_end label_else: ; else 分支的指令 label_end:循环就更好理解了while的循环体最后会有一条无条件跳转跳回循环开头的比较指令。所以循环慢、函数调用慢不是玄学而是它们本来就对应更多条跳转指令而跳转可能打断 CPU 的流水线预取。编译器优化的一个重点就是把循环展开、把函数内联减少跳转次数让指令流更线性化。4.4 高级语法在 CPU 层面到底付出多少成本很多 Python 的“高级语法”本身不是魔法。装饰器不过是一个接收函数、返回函数的普通函数调用列表推导式本质上仍然是循环只是解释器对它的字节码做了专门优化让它比手动for循环略快一点点生成器则依赖解释器的挂起和恢复机制底层是更多状态保存。你可以用dis模块亲手验证看着那些LOAD_CONST、STORE_FAST、FOR_ITER字节码就会发现“高级”只是语法层面的事CPU 层永远只有指令序列。所以我一直觉得学习“高级语法的 CPU 翻译”最大的价值是让你在写代码时多一层敬畏。你写的每一行语法糖最终都会被翻译成若干条机器指令编译器优化能帮你抹平一部分成本但底层机制决定了它不可能消除全部。5. 实操亲手扒开高级语言的底裤看它怎么变成 CPU 指令5.1 用 gcc 和 objdump 看你的 C 代码翻译成了什么工具准备只需要一个装有 gcc 的 Linux 环境或者 Windows 下装好 MinGW。先写一个简单的demo.c然后执行gcc -S -O0 -masmintel demo.c-S让 gcc 只生成汇编文件不生成目标文件-O0关闭优化方便看清原始逻辑-masmintel把汇编切换成更易读的 Intel 风格。生成的demo.s文件就是你那段 C 代码翻译成的汇编代码。我强烈建议你实际跑一次再对比一下gcc -S -O2 -masmintel demo.c两次生成的汇编对比会让你直观看到优化器做了什么原来十几条指令的逻辑优化后可能只剩三四条。你之前觉得“编译器很神奇”现在看来其实是有章可循的。如果想从可执行文件逆推汇编用objdumpgcc demo.c -o demo objdump -d demo | lessobjdump -d会把机器码反汇编成汇编指令同时显示每个指令的地址。偶尔遇到线上程序只有崩溃栈没有源码这类反汇编工具就是你的第一排查依据。如果你不想搭环境网页版的 Compiler ExplorerGodbolt是神器。左边选语言写代码右边选编译器实时生成汇编并高亮对应源码行。我在排查循环性能问题和研究编译优化时基本都靠它。它还支持多种语言C、Rust、Go 都能看。5.2 用 Python 的 dis 模块看字节码Python 虽然没有 gcc 那么直接但同样能看到中间指令。dis模块可以把函数编译后的字节码打印出来import dis def demo(): total 200 * 2 return total dis.dis(demo)输出大致长这样3 0 LOAD_CONST 1 (400) 2 STORE_FAST 0 (total) 4 4 LOAD_FAST 0 (total) 6 RETURN_VALUE注意那个LOAD_CONST 1 (400)Python 解释器在编译时已经帮我们把200 * 2算成了400压根没打算运行时做乘法。这和 gcc 的常量折叠本质上是同一类优化。你再看一个列表推导式的字节码会发现它内部就是循环加LIST_APPEND指令所谓“更高级”只是写法的差异不是计算模型的变化。多拆几个函数你对 Python 性能的直觉会准很多。5.3 常见误区与排查速查我在带人入门时发现有几个误区几乎人人踩过列成表格方便保存误区真实情况建议Python 没有编译过程Python 有编译只是编译成字节码且自动缓存为 .pyc用 dis 模块观察字节码一行代码等于一条指令一行代码可能被翻译成几十上百条指令用 gcc -S 看汇编文件同一份可执行文件能在所有 CPU 上跑不同架构x86、ARM指令集不同且 x86 也有 SSE、AVX、x86-64-v2 等扩展差异老 CPU 可能跑不了新编译开的程序编译时指定目标平台发布前做兼容性测试高级语言代码写得好CPU 就跑得快编译器优化、运行时、内存布局的影响远大于代码行的“写法”差异用编译器和性能剖析工具说话源码就是程序的本质源码只是给人和编译器看的文本CPU 执行的是机器码理解可执行文件与源码的区别我们常常觉得“程序能跑就行”但当你真的去排查一个线上 CPU 占用 100% 的问题时最终都要落到“哪一段代码的哪些指令在反复执行”这个问题上。掌握了翻译链你就知道该用perf生成火焰图、看热点函数、再结合汇编或字节码判断瓶颈出在哪里。性能优化不是一个黑盒操作而是一路从高级语法拆到 CPU 指令的排查过程。6. 精读之后的一点个人体会《程序是怎样跑起来的》这本书好懂就好懂在它不急着给你堆术语而是先让你接受一个事实CPU 是个只会查表的傻子程序是它按表开工的流水线记录。精读到第 1.3 节时我脑子里那根一直连不上的线终于接上了——写代码的“我”和跑代码的“CPU”之间隔着一整套翻译机制。我自己的经验是学完这节后最值得做的一件事就是随便挑一个自己写过的小函数用 Godbolt 或 dis 模块拆一遍看看编译器怎么优化你的代码。第一次拆循环时我惊讶地发现我“精心优化”过的一版代码性能反而更差因为没有让编译器识别出循环不变式。后来我写代码刻意保持局部变量聚集、把不变量提出来、减少不必要的函数调用层次再看汇编时指令条数明显下降。这不是什么高深理论纯粹是在了解“CPU 翻译”之后形成的直觉。如果你刚看完这一节我的建议是别急着背指令集。先记住一句话就好所有高级语法最终都是 CPU 指令序列的“翻译产物”。带着这个视角回去读你手头的代码很多以前觉得莫名其妙的现象会开始变得顺理成章。
