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?

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.

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

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.

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.

> what Windows actually expects the vtable to look like

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

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

I'm sorry, MASM? All the cool kids use NASM or YASM.

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.

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.

[dead]

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.

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.