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.
I write all my code by hand for one simple reason: LLMs suck at programming, and I am both better and faster than they are. When that changes (not bloody likely), I'll consider changing my approach. Until then, I'm going to be over here kicking ass the way I've been doing for years.
What do you think about Linus Torvalds' recent opinion about LLMs?
There are other questions around AI (like what the
economy of it will actually look like in the end),
but "is it useful" is no longer one of those
questions. Anybody who doubts that clearly hasn't
actually used it.
And no, AI isn't perfect. But Christ, anybody who
points to the problems at AI had better be looking
in the mirror and pointing at themselves at the
same time.
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
>> 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.
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.
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.
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 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’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.
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.
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'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
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.
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.
29 comments
[ 3.2 ms ] story [ 31.3 ms ] threadI'm not a Windows-knower, are vtable layouts part of the user<->kernel ABI?
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
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.
- for x64
- on Windows
- using MASM
There are other 64-bit OSes, CPUs and assemblers for them, and people do use them.
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.
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.
1) All Assembly/C++ books by Daniel Kusswurm.
2) Low-level Programming: C, Assembly, and Program Execution on Intel 64 Architecture by Igor Zhirkov.
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?
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.
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.
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.
At least since UNIX v4.
All good Assemblers have come from Amiga, Atari, PC world.