back
115 comments
I know that we're discouraged from meta-comments, but what is going on in this thread? It's a nearly 800-page book about the art of programming. A huge amount of work on a topic that should be dear to our hearts. News for hackers, right?

But somehow, the discussion has three themes. It's 50+ comments of "I don't like the first sentence of the marketing copy", "I don't like the tool the author is using", and "what would happen if we train an LLM on this book?". Has anyone read the sample chapter? Did you like it? Anyone here owns volume 1 and has opinions about that?

I own volume 1 and when it first arrived I dropped it on my foot and had to go to the doctor. I have not got around to reading it again. His original x86 ASM book was good though.

I also read his Write Great Code series and generally found it to have some pretty good advice, but it was also full of things like recommendations to never trust compilers and to write lots of arcane unreadable magic code to unlock ultimate speedy hacker cred.

That being said, if you want to learn about ASM in TYOOL 2026 then you could do a lot worse than learning it from someone who doesn't trust compilers and does everything themselves.

His earlier 32bit book was pretty decent, but super windows focused, I wish a similar work using a reasonable syntax existed for Linux, but the linux equivalent(some kind of foundations of programming or something similar assembly book) used gas syntax which is like nails on a chalkboard. Fasm is also so much nicer these days to use(masm is neglected by microsoft, but is the tool the author has used for everything).
Volume 1 is actually a really good book. Randall Hyde is a great author on this subject. HN has changed a lot from what it once was. It's just filled with a lot of this kind of snark and nonsense. What else would you expect when the most common take on AI on HN is this insane idea that "LLMs are just like a compiler was?" But, its not everyone. If you're interested in this topic then I think it will be worth working through.
I’ve been concerned seeing this in too many threads.

A Marketing and propaganda rule is that the very first thing people read/see sets the tone for the entire discussion. If you get everyone off track right from the jump it degrades the entire discussion and, ultimately, the usefulness of hacker news.

I read v1. It's good, but I prefer Ray Seyfarth's book. Not much interest in v2 - I haven't touched Windows in nearly 20 years and this seems much less OS-generic than the previous volume.
this is what almost every hn post is: lowbrow reflexive/reactionary responses. it's been like this for years. try to call it out and you'll be censured by dang or one of the other police officers for being "uncharitable" or something like that <shrug>
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

i hope this is the publisher's fault and the author replaces it with something decent of their own. contrary to the opinions i've heard around (including elsewhere on this thread) learning asm is still meaningful today and it's something i'd like to get better at so i will consider getting this book or one like it once $work is a bit less hectic

This text doesn’t seem AI generated to me.
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.

The GNU assembler is not intended to be used by humans, but its goal is to assemble the output of compilers.

On Linux, the "standard" assembler for humans is "nasm", though there are also others.

For anyone writing a non-negligible amount of code in an assembly language it is essential to develop or get from elsewhere a comprehensive library of macros, for avoiding to write huge amounts of boilerplate.

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.

What a weird, low-effort comment.

Randell’s got another (large) book on ARM assembly. He’s also got a handful of other great books on software engineering in general - he’s more than aware that “there are other 64-bit OSes, CPUs and assemblers for them, and people do use them.”

This particular title, “the art of assembly” has been around for a while. This x64 version is the latest iteration - it’s a great book compared to the previous version which introduced and focused on “high-level-assembly”, basically a collection of masm macros that effectively constituted a small language.

It’s fair to say that anyone even remotely interested on x86/64 assembly is aware of AoA.

It's the result of seeking to maintain consistency with the titles of the previous books in the series. And while the platform coverage this time is very narrow, any book on assembly in general is going to have to pick some specific platforms and hope that the reader will be able to transfer the skills acquired to others as necessary.
If you're actually writing software in assembly (as opposed to merely optimizing hot functions in an otherwise high-level codebase), in my experience MASM is the most pleasant tool for the job.
Not exactly weird... I mean x64 Windows is still pretty popular. And pretty much any Windows dev will have Visual Studio installed (to get MASM).

Unless, you want to use open source MASM-compatible assemblers like JWASM or UASM.

Yes I understand, other folks may prefer Linux/BSD, NASM/FASM, ARM etc etc.

I built compiler that compiles to 16bit x86 via MASM. This books feel like a natural next step, but I was wondering if there is a linux equivalent book I can choose instead?
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.

I'm... confused. Don't we use macro assemblers anymore?
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.

3) x86-64 Assembly Language Programming with Ubuntu by Ed Jorgensen - https://open.umn.edu/opentextbooks/textbooks/x86-64-assembly...
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.
I'm just gonna be the weirdo in this comment thread and say: yay! Assembly! The most god forsaken language i ever had to learn. But still very very useful
I'm sorry, MASM? All the cool kids use NASM or YASM.
At least it's not HLA or GAS.

Who else remembers the flamewars of the 90s between all the different factions of Asm programmers? MASM vs TASM vs RosAsm vs HLA (basically no one took GAS seriously at all)... it was in some ways quite similar to the Chrysler vs Ford vs GM wars.

Some still like FASM. Why NASM or YASM?
The Linux kernel prefers GAS (or clang) w/ the C preprocessor. Luckily most of clang's assembler unit tests (and LLVM's MC layer unit tests) also use GAS style syntax.
I agree MASM is not easily available.
TASM.
> what Windows actually expects the vtable to look like

I'm not a Windows-knower, are vtable layouts part of the user<->kernel ABI?

All of the major kernel ABIs are using C function interfaces as their stable ABI (except Linux, which uses an assembly syscall instruction as the stable interface, although you still rely on a lot of the ancillary C ABI for things like struct layout or stack layout).

For C++ ABIs, there are really only 2.5 major ABIs: the MSVC ABI, used by MSVC and clang wanting to be compatible with MSVC, and the Itanium ABI, used for everything else. There are some slight variants on the Itanium ABI which makes the ".5": ARM uses a different layout for exception handling tables, and there are some flags you can set to use a more compressed vtable layout (32-bit offsets instead of 64-bit pointers). (There are other older ABIs, but either companies stopped making a C++ compiler or they switched to Itanium.)

Windows COM APIs (which isn't part of the kernel, they're still userspace libraries) rely on an IDL which is meant to be directly compatible with the C++ vtable. That said, they also use a restricted subset of C++ that all of the ABIs are going to agree on for vtable layout--if you don't overload any functions, and you don't have any virtual inheritance, there's pretty much only one possible sane vtable layout, and everyone does that.

It’s part of the MSVC x64 ABI, not a part of the kernel ABI. The kernel and user mode (Win32) APIs all use C linkage so vtables are not relevant and the ABI is a convention of the compiler not the OS. Practically speaking though if your software runs on Windows it will probably use the MSVC ABI.
Thoroughly Understanding C++ ABI - https://news.ycombinator.com/item?id=49145259
Yes, you either follow Itanium ABI (non Win) or MSVC ABI. Technically nothing stops _your_ compiler from implementing totally own conventions but it will only be compatible with itself
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.
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.
Nice, I did not know author wrote so many different books about assembly coding.
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.

Great, follow up with The Art of 64-bit Assembly for PowerISA
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.
Yep. In my experience, LLMs easily go in circles with even simple assembly, creating fixes that result in 2x slower code and then fixing those with even slower code. They are pretty great as a reference or finding needle in the haystack bugs though!
I wrote a lisp compiler recently, and that involved generating assembly language.

My output is linux/amd64 assembly language which is compiled by nasm. I don't link to glibc, so I had to implement my "print int", "print string", and similar primitives in raw assembly.

I successfully implemented a stop&copy garbage collector, and other interfaces to the OS such as reading command-line arguments, environmental variables, and so on. All in assembly. Though my compiler is written in golang the runtime, and all supporting functions have to be in assembly to make sure that the binaries it produced are static.

(I wrote a lisp interpreter which can be compiled, and which can be used to run itself, so I got an indirect REPL.)

> Is anyone still writing assembly in the age of LLMs ...

Yes. Its "simplicity" is exactly why we pick and assemble piece by hand - we imagine the leanest way.

LLMs are (not just in Assembly, but especially) very precious as a natural language manual.

> an LLM can easily code it without errors

One day it will probably also be able to have sex, and yet we think we will not pass on the experience - unless, like some kind of coding, it will be a "strictly professional only for money" operation (like in Monty Python's Argument sketch).

Edit: as esteemed emptybits wrote above, rephrasing: it's /the Art of/ Assembly.

I'm not being flippant but I think part of your answer is in the first two words of the title.

IME while LLMs may help delivery utility in a finished work, humans often value the absorption, mastery, style, or constraint of performing a mundane activity hands-on and brains-on.

>> 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.