← #804

《64 位汇编的艺术》第二卷

文章摘要

这是 No Starch Press 出版的《The Art of 64-Bit Assembly, Volume 2: Machine-Level OOP, Exceptions, and Concurrency》（64 位汇编的艺术，第二卷：机器级面向对象、异常与并发）的图书页面。作者是 Randall Hyde，2026 年 6 月出版，792 页，ISBN 9781718504349，纸质书加电子书 79.99 美元。

出版方的宣传文案开门见山地把这本书定位为「对抗 AI 式理解」的产物：你可以让 AI 解释 x86 上的 vtable 是怎么工作的，它会给你一段听起来很对的东西；但它不会告诉你 Windows 实际期望的 vtable 长什么样、方法分派在指令级别为什么是那个行为、以及一旦偏离约定会坏在哪里。这一卷要填的，就是「听起来合理的解释」和「真正的理解」之间的鸿沟。

全书的方法论是统一的：每一章挑一个你在 C++、Python 或 Rust 里用惯了的语言构造，剥掉运行时，在 Windows 下用 MASM 从零重建它，把每一个决策都显式地摊开在指令层面。目录包括：高级宏（第 1 章，可免费下载试读）、Unicode 字符串、超越函数、高级过程、并发编程、用 MASM 做面向对象编程、异常处理、thunk 与闭包、高级参数实现、迭代器等。具体产出物包括：手工从零实现 MASM 里的 vtable、方法分派和继承；在指令级别安装和管理 Windows 结构化异常处理（SEH）；实现行为类似高阶函数的 thunk、闭包和迭代器；不借助高级语言实现协程、生成器和 fiber；直接用汇编写出带真正同步原语的并发程序；正确处理 Unicode 字符串；以及在 MASM 内部从第一性原理构建领域专用宏语言。文案的收尾是：「如果你已经懂汇编，并且想不再对那些难点抱着信任的态度，这本书就是为你写的。」

作者 Randall Hyde 数十年来为医疗设备、核系统和嵌入式硬件编写汇编——这些领域里正确性不是可选项。他曾在大学教授汇编语言课程，著有《The Art of Assembly Language》《The Art of ARM Assembly》以及《Write Great Code》系列，全部由 No Starch 出版。

HN 评论精华

必须先说明一件事，因为它本身成了讨论的一部分：skippyfish 在帖子后段发了一条元评论，精准概括了这场讨论的走向——「这是一本近 800 页、关于编程艺术的书，一个本该让我们心动的话题上的巨大工作量。可讨论居然只有三个主题：五十多条『我不喜欢宣传文案的第一句话』、『我不喜欢作者用的工具』、还有『如果拿这本书训练 LLM 会怎样』。有人读过试读章节吗？喜欢吗？这儿有人有第一卷并且能谈谈感想吗？」下面的内容大体印证了他的判断。

主线一：LLM 时代还有人写汇编吗

amelius 认真发问：汇编大多是把一件很简单的事做得很快，概念上如此简单，LLM 应该能轻松无误地写出来吧？回答几乎一边倒。sousousou：我的经验是 LLM 在简单汇编上都会绕圈子，修出一个慢两倍的版本，再用更慢的版本去修它；不过它们作为参考手册和大海捞针式找 bug 的工具确实很棒。sitzkrieg：我为小型硬实时 MCU 专业写 C 和汇编，LLM 给我的代码错个不停，完全不是效率倍增器。alain94040 给出了最有说服力的职业理由：汇编是我最后才会让 LLM 生成的东西，因为你需要写汇编的场合恰恰是关键路径——操作系统上下文切换、中断处理程序这类地方，99% 正确是不够的，必须 100% 对。
也有正面案例。ndesaulniers 用 Claude 把几千行汇编从一套语法+工具链翻译到另一套，过程是迭代式的，需要不断补充「别这么写……等价的模式是这样」之类的规则，但最终效果很好，帮他把大量单元测试从一个手搓的、破损的汇编器迁移到了现代生产工具链上。rescbr 说 GLM-5.2 写 ARM SIMD 代码相当不错，而且是极好的 radare2/rizin/ghidra 驱动器，猜测是因为它的安全相关能力没有被护栏封掉。derefr 提出了一个理论上很对的观点：「优化这段代码，让它在测试框架下用更少 CPU 周期」几乎是为 LLM 量身定做的问题——解空间极易探索、成功标准极易度量；只要迭代次数够多且无法作弊，它们最终会「用尽所有犯蠢的方式」。
更多回答落在「为什么」而不是「能不能」上。emptybits 的提醒被多人引用：答案就在标题的头两个词里——这是「汇编的艺术」，人类常常珍视亲手亲脑做一件平凡事所带来的吸收、精通、风格与约束感。eat 补充了最好的类比：你同样可以问「在编译器的时代还有人写汇编吗」，答案是一样的；而且显而易见的是，在自动演奏钢琴的时代人们依然弹钢琴——人是体验性的生物。breckinloggins：是的，理由和我在 LLM 时代仍然手写 C 或 Common Lisp 一样——这是爱好。sureglymop 指出还有硬性需求：实现协程、写 JIT 编译器这些事你必须下到汇编层。root-parent 留下了全场最短的一句：「LLM 不知道姜是什么味道。」
stevekemp 分享了一个具体项目：他最近写了个 Lisp 编译器，输出 Linux/amd64 汇编交给 nasm；因为不链接 glibc，「打印整数」「打印字符串」这些原语都得用裸汇编实现，还用汇编做了 stop&copy 垃圾回收器以及读取命令行参数、环境变量等 OS 接口。amelius 问他为什么不以 LLVM 为目标，他回答：想要一个能从头理解和实现的独立东西，而 LLVM 依赖很重且是个移动靶。
「人还能不能打败编译器」这个老话题又打了一轮。slashdave 认为除了少数边角情形，好工程师如今很难打败编译器。Keyframe：这话我听了二十来年了，可我每天都在看到相反的证据。zero-sharp 搬出 FFmpeg 两位核心开发者在 Lex Fridman 节目上讲的汇编性能收益。okanat 给了最平衡的结论：好工程师不是全知的神，而是知道什么时候该请出汇编；99% 的性能敏感代码不需要汇编，编译器在这一类上赢过人，因为 API 面太大太复杂；但对那 1% 的极热代码，或者对执行时长可预测性有要求的密码学代码（汇编能保证确定的执行时长），人写得更好——这来自专精和被大幅限制的自由度。

主线二：为什么是 MASM

csense 开了个玩笑：「不好意思，MASM？酷小孩都用 NASM 或 YASM。」由此掀起一波汇编器口味之争：mdp2021 和 sureglymop 力挺 FASM，sitzkrieg 说 FASM 在 Windows 上绝对是王者，anta40 指出 NASM/YASM 是 C 写的所以更可移植（在他的 ARM Mac 上工作正常），而 FASM 因为是用 32 位 x86 汇编写的，macOS 是二等公民。zerr 只回了两个字母：TASM。userbinator 感慨：「至少不是 HLA 或 GAS。还有谁记得 90 年代汇编程序员各派系之间的骂战？MASM vs TASM vs RosAsm vs HLA——基本没人把 GAS 当回事——某种程度上很像克莱斯勒 vs 福特 vs 通用的战争。」
rramadass 补了一段历史：DOS 时代 TASM 风头无两，快得离谱；Randall Hyde 当年发布 HLA（高级汇编）时他觉得是个好主意，因为它让大量高级语言程序员能借助熟悉的高级构造轻松入门汇编——那其实是一门真正的新语言，但汇编纯粹主义者群情激愤，Hyde 挨了很多在他看来并不公道的批评。
adrian_b 和 pjmlp 给出了一个关于 GAS 的结构性解释：GNU 汇编器本来就不是给人用的，它的目标是汇编编译器的输出；这对所有 Unix 汇编器都成立，它们从来没有「给人用」的文化，而是作为 C 编译器流水线的一环存在——至少从 Unix v4 起就是如此。MaskRay（LLVM 集成汇编器的贡献者）做了具体的功能比较：相比 MASM，GAS 缺了很多东西，比如 while 循环、字符串处理（如 strlen）；GAS 的 altmacro 模式虽然支持 %(1+2) 这样的表达式求值，但限制严格——只支持绝对表达式且仅限参数位置，而 MASM 的 % 运算符要通用得多。rurban 则反过来吐槽 Intel 语法在 binutils 里被搞坏了，逼得他把自己的 C 编译器 rcc 改成输出 AT&T 语法（GAS ≥2.45 在 Intel 语法下会拒绝对全局符号的直接跳转/调用）。
Someone 认为书名很奇怪——只讲 x64、只讲 Windows、只讲 MASM，而世上还有别的 64 位操作系统、CPU 和汇编器。agarren 火气不小地回击：这是本系列一贯的书名，Hyde 另有一本厚厚的 ARM 汇编书，他当然知道还有别的平台；任何一本汇编书都必须挑定具体平台，并指望读者能迁移技能。rramadass 附和：任何对汇编编程稍有兴趣的人都知道 Randall Hyde 和他的作品，他从 16 位时代就在做这件事，是少数有真正深度的作者之一。

主线三：文案是不是 AI 写的，以及「训练进去就没用了吧」

tensegrist 开了第一枪：以「你可以问 AI……但它会做得不完整不好」开头，然后接着来一百多个词的 AI 生成文字，这不太开胃；他希望这是出版社的锅。asibahi 反对：这段文字在他看来不像 AI 写的，就是一段图书宣传语，既不掉书袋也不啰嗦；「AI 最让我沮丧的一点，就是现在每个论坛的每个帖子都要花一半时间争论一篇文章是不是 AI 写的，好像糟糕的写作是 AI 发明的一样。不想读就别读。」rustyminnow 给了更细的判断：整体人机中立，唯一让他起疑的是「closes the gap between a plausible explanation and genuine understanding」这句——「closes the gap」是 AI 的偏爱短语，而「plausible explanation / genuine understanding」这对措辞在这个语境下戏剧性过强；他猜整体是人写+AI 润色或反之的混合体。tanseydavid 则抱怨这种「揪出 AI 参与」的冲动已经失控，尤其在 HN 上，「拿破折号当信号」最让他难受，他正确且频繁地使用破折号已经几十年了。
rajeevk 提出了另一个角度：一旦 LLM 用这本书的内容训练过，这段宣传语的说法就不再成立了；这本书只要有点流行度，下一轮训练必定会拿到它。反驳很密集。jagged-chisel：但它会把这些信息的优先级排在现有知识和自己的幻觉之上吗？dinkumthinkum：训练过一本书不等于能在未来所有提示和问题上完美实施书里的原则；而且这句话更根本的意思是关于你这个读者——你可以问 AI 并得到回应，但那个回应很难完整到让你在自己的用例上获得等同于专家的理解。adamddev1 给了一个真实观察：LLM 确实被训练过某本讲某种低资源语言语法的关键著作，它们会挪用书里的信息、术语和概念来解释，但依然没有理解，会自信地把那门语言弄得一塌糊涂，同时抄袭书的内容。fasterik 则怀疑这句话本身就站不住：模型不太可能没被训练过大量 x86 和 Windows 内核资料，这更像是针对反 AI 情绪的营销文案。

关于书本身的少数实质评价

lexicality 有第一卷，「刚到货时我把它砸到了脚上，得去看医生，之后就一直没再翻开」。不过他读过 Hyde 的《Write Great Code》系列，觉得建议大体不错，但也充满了「永远别信编译器」和写一堆晦涩魔法代码来解锁终极黑客速度之类的内容——「话说回来，如果你想在 2026 这个年份学汇编，跟一个不信任编译器、什么都自己来的人学，绝不算差的选择。」abeyer 同样推荐《Write Great Code》前两卷，常拿它们推荐给训练营出身或自学的初级工程师补底层机器概念，但第三卷让他失望——不是差，而是那些软件工程流程内容既偏离了作者的核心强项，别人也已经写得更好了。t-3 读过第一卷，觉得好，但更偏爱 Ray Seyfarth 的书；对第二卷兴趣不大，因为他近二十年没碰过 Windows，而这一卷显然比上一卷更绑定操作系统。dinkumthinkum：第一卷确实是本好书，Hyde 在这个主题上是位很棒的作者。
norir 提出了一个值得单独一读的技术意见：如果你需要比高级语言更好的性能，他不建议直接写汇编，而建议写一个编译器。裸汇编很诱人是因为启动成本低——一个下午就能开始；麻烦在于写正确的汇编比写高级代码难得多，你得时刻在脑子里维护寄存器状态，得知道被调用的函数会不会破坏你之后还要用的寄存器并手动保存/恢复，产出的代码又长又难读，还依赖大量只存在于你写作当时脑中、事后已被清除的隐含信息——两个月后没人能调试它。反过来，写一个非优化编译器就能避开这些：比如自动追踪函数写了哪些寄存器并确保调用前保存、调用后恢复；甚至可以让你的编译器建模一个有 16 个通用寄存器的抽象 CPU，这样移植到 ARM 就很直接。
若干延伸书单：rramadass 推荐 Daniel Kusswurm 的全部汇编/C++ 书、Igor Zhirkov 的《Low-level Programming》、Ed Jorgensen 的《x86-64 Assembly Language Programming with Ubuntu》（免费开放教材）、Larry Pyeatt 的 ARM 汇编书，以及经典的《ARM System Developer’s Guide》。fuzztester 推荐 Paul Carter 的免费在线汇编教材（32 位、Linux、NASM）。mparnisari 认为 33 号那个 200ms 页面像是《High Performance Browser Networking》的网页版。