The Art of 64-Bit Assembly Volume 2 – Book Overview and Hacker News Reaction
The Art of 64-Bit Assembly, Volume 2: Book Overview
The book teaches advanced assembly concepts using MASM on Windows, covering object‑oriented programming, Windows structured exception handling, concurrency, Unicode strings, and domain‑specific macro languages.
Key Topics Covered
The book’s chapters cover advanced macros, Unicode strings, transcendental functions, advanced procedures, concurrent programming, object‑oriented programming with MASM, exception handling, thunks and closures, advanced parameter implementation, iterators, and coroutines, generators, and fibers.
Author Background
Randall Hyde has decades of experience writing assembly for medical devices, nuclear systems, and embedded hardware, has taught assembly at the university level, and is the author of several assembly‑focused books from No Starch Press.
Hacker News Discussion: Main Themes
Commenters focused on the book’s marketing copy, the choice of MASM as the assembler, interest in a Linux‑equivalent text, and the impact of AI/LLMs on learning assembly.
Feedback on Marketing Copy and Opening Sentence
Some readers criticized the opening line that questions AI explanations of vtables, calling it off‑putting or seemingly AI‑generated.
"i'm sorry, starting with "you can ask AI to … [but it'll do an incomplete and bad job]" and then launching forth into a hundred words of AI-produced text is not very appetizing"
Discussion on Assembler Choice (MASM vs NASM/YASM/GAS)
Several commenters questioned the use of MASM, preferring NASM, YASM, or GAS, and compared macro features.
"Interesting to see that people are still spending much time on assembly languages :) I've had a lot of fun with it in recent years as well. (Shameless plug: I've written a few on LLVM integrated assembler regarding better fragments and improving expressions and relocations). When comparing GNU Assembler and MASM, GAS is missing many features: while loop, string processing (.e.g strlen) > page 3: "It’s important to understand that MASM converts macro invocation arguments to text values before doing the macro expansion" Like MASM, GAS uses call‑by‑name evaluation by default. While GAS's altmacro mode does allow for expression evaluation using syntax like %(1+2), it has strict limitations: it only supports absolute expressions and is restricted to argument positions. In contrast, MASM's % operator (page 8) looks far more general." — @MaskRay
"I'm sorry, MASM? All the cool kids use NASM or YASM." — @csense
"Weird title for a book on assembly - for x64 - on Windows - using MASM There are other 64-bit OSes, CPUs and assemblers for them, and people do use them." — @Someone
Interest in Linux Equivalent
One comment asked whether a Linux‑focused assembly book exists.
"Cool! Is there a linux equivalent book?" — @iamcreasy
Comments on AI, LLMs, and Assembly Learning
Commenters debated whether LLMs can replace assembly knowledge and whether the book’s content will affect future AI models.
"Is anyone still writing assembly in the age of LLMs? Asking seriously because most assembly is just doing one very simple thing very fast and because it's so simple conceptually, an LLM can easily code it without errors." — @amelius
"You can ask an AI to explain how vtables work in x86. It will give you something that sounds right. What it won’t give you is what Windows actually expects the vtable to look like, why method dispatch behaves the way it does at the instruction level, or what breaks when you deviate from convention. This volume of The Art of 64-Bit Assembly closes the gap between a plausible explanation and genuine understanding. Once LLMs are trained with the content of this book, then this statement will no longer be true. If this book becomes even a bit popular, these LLMs will get access for sure to the content of this book in their next training." — @rajeevk
"We need books like that now more than ever. AI makes us lazy, forgetting how it works "under the hood). We should be curious and keep asking questions, or we will not be able to understand all this geneated AI code slope." — @toplinesoftsys
"I don’t get it. I am this books target market. Part of this demographic is that if you challenge me, I will accept the challenge. So challenging me to figure out how to do this by using AI instead of buying this book seems like a serious fail." — @lowbloodsugar
Additional Community Remarks
Other remarks included praise for the author’s prior works, requests for PowerISA coverage, related book suggestions, and reflections on writing raw assembly versus building compilers.
"Wow, I can't believe that the author is still updating the book! I'd learnt protected mode assembly from an older version of this book, decades ago. And IIRC, there was an even older 16-bit version of the book back then." — @woadwarrior01
"Related; 1) All Assembly/C++ books by Daniel Kusswurm. 2) Low-level Programming: C, Assembly, and Program Execution on Intel 64 Architecture by Igor Zhirkov." — @rramadass
"If you need better performance than a higher level language affords you, I would not recommend programming directly in asm. Instead, I would write a compiler. Raw asm is seductive since the start up cost is relatively low. You can get started in an afternoon. The trouble is that writing correct assembly is much harder than high level code. You have to hold in your head the register state at all times. You have to know if the function you are calling will clobber registers that you need after the call and manually save/restore them. This will slow down your velocity and the resulting code will be long and difficult to read. It will also rely on a lot of undocumented information that only resided in your head while writing and has since been evicted. Good luck debugging a program written in assembly that no one has looked at for two months. On the other hand, if you write your own non optimizing compiler, you can avoid a lot of these problems by, for example, tracking what registers a function writes and ensuring they are saved before a call and restored after. Then you can actually get the raw performance of handwritten asm without the pitfalls (the resulting code would still he harder to read and maintain than equivalent high level code, but at least it would be tractable). Even better, you can write your own high level assembler that is actually portable to other architectures. For example, instead of directly modeling x86_64, your compiler can model a cpu with 16 general purpose registers and a set of instructions that map to x86_64 instructions. An arm port would be straightforward since arm also has 16 general purpose registers and you can model x86_64 instructions as one or more arm instructions (and you have extra registers for x86_64 instructions that must be modeled as multiple arm instructions). Or you could do the reverse and model 32 general purpose registers using arm instructions and use predefined memory slots as virtual registers on x86_64." — @norir
"I am more curious about how they would cleanly manage hierarchical labels (usually called "namespaces)), register naming, and stack management with deep register spilling, description of the register state on the various entries from the various dominators of a code block. I am doing all that with a basic C pre-processor in my assembly source code. But the more I think about this, the more I think I should write my own pre-processor, which "should" be much simpler than a C pre-processor in the end and would do a cleaner job since taylored for those usages (the "annoying" thing is the arithmetics expression evaluation). I would write this pre-processor in assembly, namely design a binary specification (that to be ready for other ISA implementations). Then, they are the really important things: for all micro-architectures, how to be friendly to conditional branch predicition, how to handle BTB entries layout in a cache line, show how important the "cache line" is ubiquitous, etc. I remember clearly one of the TheHeavyThing developers telling me than with a basic and naive hand compilation of gzip, he was beating the best compilers, at that time, by a consistent 10/15%. Let me remind people here of something: nobody is supposed to be able to beat a compiler on deep and hairy compilation units. If it is the case, something is wrong in that compiler." — @sylware
"Nice, I did not know author wrote so many different books about assembly coding." — @hollowonepl