64 位汇编的艺术
《The Art of 64-Bit Assembly》这一新卷聚焦 Windows x64 和 MASM，引发了更广泛的讨论：在强大编译器和大型语言模型时代，学习并手写汇编是否仍然有价值。许多评论者认为，汇编对于理解系统、编写关键底层代码，以及在狭窄热点中实现极致性能仍然不可或缺；另一些人则指出，现代编译器通常胜过人类，只有在高度专门化的场景中例外。讨论还涉及 ABI 和调用约定细节、汇编器工具偏好（MASM vs NASM/FASM/GAS），以及人们对 AI 和营销争论常常掩盖技术丰富书籍的实质内容感到不满。
C++ ABI、虚表与 Windows 约定
- 讨论澄清：vtable 布局属于 C++ 编译器 ABI（MSVC vs Itanium），而不是内核 ABI。
- Windows 用户态 API 使用 C 语言链接约定；vtable 和 COM 是用户空间约定。
- COM vtable 与语言无关：前几个条目是特定方法，全部使用
__stdcall，其布局实际上与受限的 C++ 子集相匹配。 - 像 MSYS2/Cygwin 这样的工具链会混合调用约定：内部使用 SysV/Itanium，在 API 边界使用 Windows 约定。
- 结论：互操作性取决于理解每个组件使用的是哪种 ABI 和调用约定。
在 LLM 时代，汇编还会被编写吗？
- 许多人认为是的：用于操作系统上下文切换、中断处理程序、实时 MCU、JIT、协程、运行时，以及非常热点或对时序敏感的循环。
- 也有人把汇编视为一种爱好，以及深入理解系统的一种方式。
- 一些人表示 LLM 在汇编器之间的转换、ARM SIMD 以及作为逆向工程工具的辅助上表现良好。
- 另一些人则认为 LLM 生成的汇编不可靠且更慢，不会将其用于关键代码。
- 共识是：对于大多数代码，编译器通常胜过人类；但在人类可以凭借小型、高度专用、性能关键的内核取得更好结果的场景中，仍然有优势。
AI、理解，以及这本书的定位
- 围绕一条营销式表述展开争论：AI 对 vtable 的解释缺乏“真正的理解”。
- 有人认为这是反 AI 营销；也有人认为，即使模型接受过这本书的训练，也不会可靠地应用其中内容，也不会像亲自阅读那样获得同等理解。
- 还有人担心讨论会被“这是 AI 生成的吗？”所主导，而不是技术内容本身。
汇编器、工具链，以及宏/预处理器的使用
- 对 MASM 与 NASM/YASM/FASM/GAS 存在强烈意见；MASM 因功能丰富而受到称赞，但也因过于 Windows 中心化和可用性受限而被批评。
- GAS 被认为更偏向编译器导向，宏能力较弱；有些人依赖外部预处理器或功能强大的宏汇编器来管理命名空间、寄存器/栈状态以及可移植性。
- 人们回忆起历史上的“汇编器战争”；现代实践往往会混用多种汇编器，并大量使用宏库。
围绕 x86/ARM 汇编的书籍与生态
- 推荐了多本其他汇编和底层编程书籍（x86-64、ARM、Linux 方向）。
- 多位评论者称赞了《Art of Assembly》系列前几版以及相关底层编码书籍，但也指出其强烈偏向 Windows，并对编译器有一定不信任。