alt.hn

8/1/2026 at 2:09:00 PM

The Art of 64-bit Assembly

 https://nostarch.com/art-64-bit-assembly-v2

by 0x54MUR41

8/1/2026 at 6:55:40 PM

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?

by skippyfish

8/1/2026 at 9:10:55 PM

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.

by lexicality

8/1/2026 at 11:36:22 PM

Yeah, I'd second a recommendation of at least the first two volumes of Write Great Code. I've long suggested those to juniors who have come out of bootcamps, self-taught, or other backgrounds outside a typical CS degree and didn't have much exposure to lower level machine concepts. I was a bit let down by the third volume... not that it was bad per se, but I feel like the sw engineering process stuff it covered both strayed outside his core strengths and had been done better elsewhere already.

by abeyer

8/1/2026 at 11:42:37 PM

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

Not bad advice, but the Fasm forums used to be pretty good for asking questions, no clue if they are around and active still, but there were a lot of programs people had written and even a few simple OSs(including KolibriOS) which had a ton of code to read through that mostly was commented. Once you get the basics it is pretty easy to do stuff, and most of learning is doing stuff.

by gregdaniels421

8/1/2026 at 11:39:36 PM

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

by gregdaniels421

8/2/2026 at 10:56:08 AM

> gas syntax which is like nails on a chalkboard

That's weird, GNU as should default to AT&T syntax. Maybe the author switched to Intel syntax by adding the .intel_syntax directive at the beginning of the code?

by tmtvl

8/2/2026 at 12:24:50 PM

Have you checked out paul carters assembly language book. it is free online. i'm not sure it has stuff for Linux.But you can check. also , it may be , for sixteen or thirty two bit. since I noticed it online long back. sorry voice typing.

Edit: i checked. it is for 32 bit. works on Linux. and uses Nasm.

https://pacman128.github.io/pcasm/

by fuzztester

8/2/2026 at 3:40:12 AM

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.

by dripdry45

8/2/2026 at 10:50:51 AM

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.

by t-3

8/1/2026 at 8:45:29 PM

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>

by mathisfun123

8/2/2026 at 4:45:10 AM

Really? I have quite the opposite impression. HN is one of the few places I can come to where intelligent conversations can be found. Sure, sometimes discussions run off the rails into the weeds, but snark is rare, and when conversations stay on track, they often add significantly to the post.

by ternaryoperator

8/2/2026 at 4:33:25 AM

dang diddles kids

by yesitcan

8/2/2026 at 12:21:41 AM

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.

by dinkumthinkum

8/1/2026 at 7:09:14 PM

[flagged]

by roundwego

8/1/2026 at 8:35:25 PM

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.

by MaskRay

8/2/2026 at 7:15:29 AM

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.

by adrian_b

8/3/2026 at 7:58:54 AM

That is true of all UNIX assemblers, they never had the "used by humans" culture, rather being part of a C compiler pipeline approach.

At least since UNIX v4.

All good Assemblers have come from Amiga, Atari, PC world.

by pjmlp

8/1/2026 at 4:11:51 PM

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

by tensegrist

8/1/2026 at 6:15:30 PM

This text doesn’t seem AI generated to me.

by asibahi

8/1/2026 at 6:31:53 PM

We've really gotten to the point that certain styles seem AI generated in many cases because many folks are poor writers and anything past a high school level is difficult for them. I'm not speaking in this case specifically, just in general.

It's also one of the reasons its insanely popular in ESL countries and frustrating/disliked in English-speaking countries because it makes things easier in one and harder in the other.

It was never the goal, but it is the reality. The same style people call AI, was often called being a pedant or being wordy 10 years ago.

by boondongle

8/1/2026 at 7:10:53 PM

This publisher copy is neither pedantic nor wordy. It is just a market blurb for the book.

The thing that frustrates me the most about AI is how every thread in every forum spend half the time arguing whether an article is AI or not, as if bad writing only started to exist with AI. Just fucking don't read it.

by asibahi

8/1/2026 at 10:50:42 PM

It does not even have to be slop, the compulsion to call out AI-involvement in writing is out of control, esp. on HN.

Em-dashes as the signal is the most-upsetting for me. I have been using them properly and frequently for decades.

Slop is slop. If it is AI-slop then fine, go ahead and call it out.

by tanseydavid

8/1/2026 at 9:49:44 PM

(disclaimer: I'm not anti-ai nor do I think ai automatically makes something bad, _but_...)

To me, it's all fairly human-ai neutral except for this sentence which is oh-so AI cliche and casts doubt on the rest of it:

> This volume of The Art of 64-Bit Assembly closes the gap between a plausible explanation and genuine understanding.

"closes the gap" is a favored phrase by our artificial friends and the phrases "plausible explanation" and "genuine understanding" are just... so ... dramatic for the context.

The rest of it is pretty tame in comparison. In my armchair opinion, I'd guess it's mostly a composite of (professional) human-written/ai-revised and/or vice versa. Which is not necessarily a bad thing.

by rustyminnow

8/1/2026 at 4:21:25 PM

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.

by Someone

8/1/2026 at 6:48:06 PM

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.

by agarren

8/1/2026 at 10:36:01 PM

You mean this:

https://www.amazon.com/Art-ARM-Assembly-Randall-Hyde/dp/1718... ?

Mmm nice. Will give it a try since ARM-based Mac is my main working environment nowadays.

by anta40

8/2/2026 at 4:33:23 AM

You might also want to checkout the Assembly books by Larry Pyeatt (ARM only) and Daniel Kusswurm (x86 + ARM).

Another excellent classic which you should checkout if you are interested in all things ARM is ARM System Developer's Guide: Designing and Optimizing System Software by Sloss, Symes and Wright. It is old and so does not cover newer ARM architectures but will give you a solid foundation for system programming.

by rramadass

8/2/2026 at 8:50:25 AM

Mr Kusswurm's x86 book is excellent. Didn't know he also write on for ARM. Thank you!

by anta40

8/2/2026 at 4:20:35 AM

You are quite right.

Anybody who is even cursorily interested in Assembly Programming knows of Randall Hyde and his works since he has been at it since the 16-bit days. One of the few authors with truly great depth.

Makes me think that most people commenting here know nothing about assembly and are simply posting empty comments for the heck of it. This has been a trend on HN lately of similar meaningless/useless comments on any topic.

by rramadass

8/1/2026 at 6:44:02 PM

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.

by leoc

8/1/2026 at 6:26:38 PM

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.

by Retr0id

8/2/2026 at 7:22:42 AM

MASM was a decent assembler, but it also had some syntax choices that lead to excessive verbosity.

In any case, today nasm is mostly equivalent with it, if not better, while being kept much more up-to-date with the Intel-AMD ISA extensions.

by adrian_b

8/2/2026 at 1:39:59 PM

Out of idle curiosity: can NASM emit Windows unwind information? For the matter, can any assembler do so automatically?

by not_a9

8/1/2026 at 6:50:28 PM

The most pleasant is the one you're most familiar with. I still use gas with at&t syntax.

by b5n

8/1/2026 at 7:22:57 PM

MASM's niceties go far beyond just syntax, though

by Retr0id

8/1/2026 at 9:06:02 PM

I last used MASM back in about 1989 (with MS C on OS/2 1.0). Do you have any hints on how it has changed since then? What is nice about it, and why does the debugger not match up to CodeView?

by tengwar2

8/1/2026 at 10:30:55 PM

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.

by anta40

8/1/2026 at 10:08:21 PM

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?

by iamcreasy

8/1/2026 at 4:42:33 PM

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.

by sylware

8/1/2026 at 4:45:09 PM

I'm... confused. Don't we use macro assemblers anymore?

by slashdave

8/1/2026 at 4:52:40 PM

The pre-processor of an assembler is specific to that very assembler.

For instance, with a C pre-processor, I have a very lean C pre-processor dialect which allows me to assemble simple x86_64 code with... fasmg[12] or nasm(probably yasm) or gas(intel syntax).

A big project which was bitten by specific pre-processor abuse: ffmpeg with nasm (but it is still much less toxic than to start to be hard dependent on advanced and specific C compiler extensions... look a the failure from linux on that matter).

by sylware

8/1/2026 at 4:50:23 PM

We do. I always use fasmg and it's amazing!!

by sureglymop

8/1/2026 at 4:54:47 PM

fasmg[12] is much more powerful than gas or nasm(~yasm): it is not a classic pre-processor. With CALM, it is basically a language able to implement assemblers supporting various binary file formats.

by sylware

8/1/2026 at 4:52:18 PM

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.

by rramadass

8/1/2026 at 6:45:57 PM

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.

by woadwarrior01

8/2/2026 at 2:24:24 AM

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

by yotsubaNishiki

8/1/2026 at 4:17:25 PM

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

by csense

8/2/2026 at 3:13:25 AM

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.

by userbinator

8/2/2026 at 9:54:42 AM

Comparison of assemblers - https://en.wikipedia.org/wiki/Comparison_of_assemblers

I remember during the DOS era TASM was all the rage; it was wicked fast. Unfortunately didn't get an opportunity to do much assembly programming after moving to Windows/Unix.

When Randall Hyde published his HLA (https://en.wikipedia.org/wiki/High_Level_Assembly) i remember thinking it was a good idea since it allowed many high-level language programmers to easily learn assembly programming as it included all the well-known higher-level programming constructs. It was a proper new language, but the assembly purists were all outraged and Hyde caught a lot of flak which i think was unjustified.

by rramadass

8/1/2026 at 4:18:51 PM

Some still like FASM. Why NASM or YASM?

by mdp2021

8/1/2026 at 10:47:34 PM

Since NASM/YASM is written in C, it's more portable. On my ARM Mac, NASM works fine.

FASM is cool (and still being development), but since it's written in 32-bit x86 asm, let's just say macOS is a 2nd class citizen.

by anta40

8/1/2026 at 4:54:27 PM

I prefer FASM but NASM is a strong second choice. But at the end of the day it really doesn't matter.. purely preference.

by sureglymop

8/1/2026 at 5:16:13 PM

fasm absolutely rules on windows

by sitzkrieg

8/1/2026 at 4:54:41 PM

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.

by ndesaulniers

8/2/2026 at 5:49:12 PM

Because the Intel syntax is limited, and pretty broken by binutils. I had to change my C compiler rcc to emit AT&T GAS, instead of Intel syntax, even if Intel syntax looks easier on the eye.

GNU Assembler (GAS) ≥2.45 on x86-64: call and jmp to global labels in Intel syntax cause operand type mismatch errors. RCC emits .intel_syntax noprefix by default, but GAS ≥2.45 rejects direct branches to global symbols in this mode. Local labels (.L.xxx) work fine. Tests with user-defined function calls (bitops-1, fprintf-1, etc.) may fail to assemble under these versions. Root cause: rcc emits lea r11, [rip + sI] but GAS requires AT&T sI(%rip) for globals.

by rurban

8/2/2026 at 4:43:37 AM

I agree MASM is not easily available.

by fithisux

8/1/2026 at 11:14:31 PM

TASM.

by zerr

8/2/2026 at 5:49:10 AM

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.

by toplinesoftsys

8/1/2026 at 3:21:05 PM

> what Windows actually expects the vtable to look like

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

by Retr0id

8/1/2026 at 5:22:33 PM

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.

by jcranmer

8/1/2026 at 6:51:37 PM

Being pedantic, the COM vtable layout is defined independently of C++. The Windows headers used to (and maybe still do) have macros that could declare COM vtables as explicit structs so you could use Windows COM interfaces from C.

That used to be the case anyway. It's possible they binned the C support in the switch to 64-bit. I haven't looked since.

by masfuerte

8/1/2026 at 11:59:40 PM

Yes the support is still there, although official MS documentation no longer mentions it. Some of those headers rather flagrantly violate C's strict aliasing rules, which I suspect is the reason MSVC never implemented type-based aliasing optimizations.

by wasmperson

8/2/2026 at 10:16:19 AM

COM is still a language-independent binary standard. The first three entries in the vtable must always be IUnknown methods and all methods must use __stdcall calling convention.

The Layout of a COM Object by Raymond Chen - https://devblogs.microsoft.com/oldnewthing/20040205-00/?p=40...

by rramadass

8/1/2026 at 3:48:06 PM

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.

by invokestatic

8/1/2026 at 4:07:37 PM

Last time I checked, software compiled with both Cygwin and MSYS2 internally uses SysV calling convention, only switching to WINAPI when calling, well, Win32 API.

by Joker_vD

8/1/2026 at 10:37:19 PM

It is more complicated than that. MSYS2 isn't just Cygwin. It has different environments.

MSYS environment is just Cygwin and it uses Itanium IIRC for C and C++ non-Win32 calls since it emulates POSIX. If it links with Windows C runtime they use __cdecl. Win32 API calls always use __stdcall convention / ABI.

However, Mingw environments (Mingw64, UCRT, CLANG etc.) are intended for native Windows development, hence, they use normal MSVC __cdecl ABI for C library calls and internal function calls too. Win32 calls are again __stdcall.

Unlike C, for C++ all MSYS environments use Itanium ABI since they link with GNU libstdc++ or Clang libc++. I think it is possible to use MSVC C++ ABI with Clang but it could be complicated since it requires recompilation of at least libc++.

by okanat

8/2/2026 at 6:12:34 AM

TL;DR: You can mix and match calling conventions as long as you actually track what piece of (compiled) software uses what convention.

by Joker_vD

8/1/2026 at 3:39:09 PM

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

by boguscoder

8/1/2026 at 4:05:56 PM

GHC uses its own calling convention yet it's compatible with Win API just fine. The secret, of course, is to implement not only your bespoke calling convention, but also the other ones that you care to interoperate with.

by Joker_vD

8/2/2026 at 10:00:37 AM

Nice, I did not know author wrote so many different books about assembly coding.

by hollowonepl

8/1/2026 at 4:30:48 PM

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.

by norir

8/1/2026 at 9:26:57 PM

Great, follow up with The Art of 64-bit Assembly for PowerISA

by climate_denier_

8/2/2026 at 6:05:09 AM

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.

by lowbloodsugar

8/1/2026 at 3:30:28 PM

[dead]

by EtienneDeLyon

8/1/2026 at 4:01:40 PM

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.

by amelius

8/1/2026 at 4:06:58 PM

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!

by sousousou

8/1/2026 at 6:33:10 PM

Is that with or without the LLM being able to assemble + profile its hypotheses itself? Because “optimize this code to execute in fewer CPU cycles under the test harness” seems like one of those perfect self-contained problems for LLMs (their equivalent of an “embarrassingly parallel problem”: an “embarrassingly-easily-explored solution space with embarrassingly-easily-measured objective success criteria.”)

Sure, they might make all sorts of dumb hypotheses at first, but as long as the results of those stay in their context, they do seem to eventually “run out of ways to be stupid.” (Which is to say, LLMs seem to experience in-context learning even via self-directed trial-and-error, if given a sufficiently-large number of iterations and no way to cheat.)

by derefr

8/1/2026 at 4:58:24 PM

I was able to use Claude to translate a few thousand lines of assembler from one syntax+toolchain to another. Process was definitely iterative; had to keep adding a few rules along the lines of "don't do this...here's the equivalent pattern." But in the end it did a good job and saved me a ton of time. Allowed me to move a ton of unit tests off a hand rolled broken+bad assembler to a modern production toolchain.

by ndesaulniers

8/1/2026 at 8:09:32 PM

This is definitely not my experience with GLM-5.2. It is writing pretty good ARM SIMD code.

It also is an excellent radare2/rizin/ghidra driver as well. Maybe it's because its ~cyber~ capabilities (pretty much linked with assembly-level knowledge) aren't guardrailed off?

by rescbr

8/1/2026 at 6:21:55 PM

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

by stevekemp

8/1/2026 at 8:00:55 PM

An efficient concurrent garbage collector would be something I would buy a book for. (In fact I have one GC book on my bookshelf).

But assembly? I'm not sure, honestly. Architectures change, and you can easily converge to good code by talking to an LLM.

May I ask why you didn't use LLVM as a target?

by amelius

8/2/2026 at 7:10:04 AM

I wanted something standalone I could implement and understand from the ground-up, that's why I did everything myself, rather than using LLVM.

In the future I might try to repeat the process with QBE, or similar, but LLVM is a big dependency and a bit of a moving target too.

I'm only writing toy languages for fun, and for local problem solving. I have no delusions of grandeur and expect that for every compiler/language I come up with I'll have one user at the most, possibly two.

by stevekemp

8/1/2026 at 4:11:43 PM

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

by mdp2021

8/1/2026 at 5:40:36 PM

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

Professionally, assembly is the last thing I would let an LLM generate for me. That's because if you need to write something in assembly, it's because it's critical: operating system context switch, interrupt handler, that kind of thing. You don't want to be 99% correct, you need that code to be 100% good.

I can imagine some other professional scenarios that I'm less familiar with, where you want to write a tight numeric loop of NEON64 assembly and let the LLM do it, because it's frankly a pain to do by hand, and you can test it to some degree of confidence.

by alain94040

8/1/2026 at 4:14:15 PM

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.

by emptybits

8/1/2026 at 4:56:31 PM

Yes. Mostly for learning purposes and for fun. Also, there are things you must drop down to assembly level in order to achieve. Implementing coroutines, a JIT compiler, etc. It's fun to learn about these.

by sureglymop

8/1/2026 at 4:49:16 PM

Yes. And for the same reason I still write in C or Common Lisp - by hand - in the age of LLMs.

It’s a hobby.

by breckinloggins

8/1/2026 at 4:14:58 PM

You could've also asked if people still wrote assembly in the age of compilers, and the answer would be the same. Sometimes we want/need to control or understand what is emitted by the tool.

However, I want to point out the obvious fact that people are still playing the piano in the age of the self-playing piano. Humans are experiential creatures, and we enjoy a wide range of activities for their own sake that may have nothing to do with efficiency of output.

by eat

8/1/2026 at 4:19:46 PM

I do now and then, for bits of code that is not expressible in the language. Things like special instructions, or special fixups.

by WalterBright

8/1/2026 at 5:17:24 PM

yes, i write c and asm professionally for small hard real-time mcus. llms give me wrong code nonstop in what little i have tried in my field. not a force multiplier

by sitzkrieg

8/1/2026 at 4:16:08 PM

an LLM can easily code it without errors

can't tell if sarcasm or not. Just in case it's not.. in that case why don't we all vibe everything in assembly? No need for abstractions anymore since that's a human concept. LLM can do it without errors, as you say, and we'll reap the benefits of speed!

by Keyframe

8/1/2026 at 4:23:50 PM

Because it's not portable. The world we find ourselves in is at least x86 and ARM, and assembly for one isn't good for the other. LLVM has a hardware agnostic intermediate representation (IR) that one could use though.

by fragmede

8/1/2026 at 6:13:41 PM

you're not thinking vibe enough. Your prompts are now the program, that's your abstraction. Ideally, if it would work, LLM would be the one then producing each platform's output. Maybe even compiling from higher languages to gather some compiler optimization hints and then doing full salvo of asm. Ideally.

by Keyframe

8/1/2026 at 4:21:40 PM

> why don't we all vibe everything in assembly

I really loved this retort, but we have to reply: from that cone of perspective, it would be probably better to "vibecode" in C and not hope that the LLM does a better job than the compiler (for efficiency, not for absence of bugs as per the original). (Edit: for clarity: some compilers of low level languages are specialized in ASM optimization - the LLM will hardly beat them.)

by mdp2021

8/1/2026 at 4:49:44 PM

Except for some odd corner cases, it is very hard for a good engineer to beat compilers these days (they are very good now). Not to mention, tuning depends on the platform, and often the exact model of chip.

by slashdave

8/1/2026 at 6:15:15 PM

* it is very hard for a good engineer to beat compilers these days (they are very good now).*

I keep hearing this for the last 20 odd years, yet I see evidence to the contrary each and every day. It is hard and honest work though.

by Keyframe

8/1/2026 at 10:51:25 PM

A good engineer isn't a godlike entity who knows all. They know when to bring in assembly and when to be satisfied with C / C++ / Rust compilers and steer the compiler.

Assembly has unique advantages like guaranteed execution duration for cryptography or exact optimization of hot-loop computation.

99% of the even performance-sensive code doesn't need assembly and compilers beat good engineers in this category since API surface is big and complicated. For 1% very hot code or very sensitive code due to execution duration / predictability / throughput, humans usually code better than compilers. This is due to specialization and limited DoF problems that can be solved and optimized to hell.

by okanat

8/3/2026 at 4:52:14 AM

Indeed. Compilers do have to make compromises, and it is not possible from code alone to understand the tradeoffs.

by slashdave

8/2/2026 at 5:55:24 PM

Certainly not. Every hand-optimized tight loop or lookup beats every compiler still. Compilers are extremely stupid, and esp. the language designers.

by rurban

8/1/2026 at 5:07:26 PM

there were two lead developers from FFMPEG on Lex Fridman's youtube channel who talked about performance gain from assembly. They claimed the opposite

https://www.youtube.com/watch?v=IUo0UwZOaRw

by zero-sharp

8/1/2026 at 5:53:18 PM

Yeah, a corner case (streaming) and good developers working very hard.

The original SSE (SIMD) extensions were actually written with this use case in mind. When they first came out, the compilers were awful. They've since caught up.

by slashdave

8/1/2026 at 6:25:54 PM

>> an LLM can easily code it without errors.

An LLM knowns nothing of the taste of ginger.

by root-parent

8/2/2026 at 4:45:14 AM

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.

by bigstrat2003

8/3/2026 at 6:53:24 AM

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.
https://lore.kernel.org/all/CAHk-%3Dwi4zC%2BZe8e%2Bp3tMv8TtG...

by simondotau

8/1/2026 at 4:19:44 PM

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

by rajeevk

8/1/2026 at 5:20:07 PM

I'm skeptical of that statement to begin with. I would be surprised if models weren't trained on plenty of x86 and Windows internals information. If nothing else, they could be prompted to download the relevant material and then write well-commented source code to explain the implementation details.

This reads more like marketing copy targeting anti-AI sentiment than anything.

by fasterik

8/1/2026 at 5:02:14 PM

One book probably doesn't do it. I know the LLMs have been trained on one particular book that explains some crucial things about the grammar of a low-resource language. The LLMs will sort of use the information, terms, and concepts in the book to explain things but they fail to understand and continue to confidently mangle the language and plagerize the content of that book.

by adamddev1

8/1/2026 at 4:24:33 PM

But will they prioritize this information over what they have currently, or over their own hallucinations?

by jagged-chisel

8/1/2026 at 4:25:35 PM

> Once LLMs are trained with the content of this book

I strongly believe that the "future" should be LLM+Corpus - something beyond LoRA or RAG or context, but what we need and will have will be a generally strong LLM augmented with the most proper learning from the "selected library of relevant material".

And in parallel, also the reasoner over the corpus will be implemented (something that properly studies, not just reads, and achieves the pinnacle of reflection over the corpus).

by mdp2021

8/1/2026 at 4:28:47 PM

Are you saying that people should then write books for LLMs only so that you can query them to get the summarized answer and not pay for the book?

by f3abfeca54812

8/1/2026 at 4:36:58 PM

I cannot get a faint idea about how you managed to get such a twisted misunderstanding.

Let us reformulate through the framework: the learned wrote books; the learners read them books, as many as possible in a ranked list; we may one day achieve automated learners; learned learners are our consultants; we benefit from the level of learning of them consultants; we would benefit greatly from the Perfected Learner; I gave a few lines of the general directions towards "thinking of them in view of building them" in the post above...

by mdp2021

8/1/2026 at 5:18:30 PM

Given the tricolon in that text, I think the content of the book may have come out of an LLM.

by astrange

8/1/2026 at 4:28:54 PM

You also don’t need it to be trained on it specifically, just give it some docs or links to docs or source code as reference

by oinoom

8/1/2026 at 4:46:13 PM

Show it the disassembler...

by slashdave

8/2/2026 at 12:39:05 AM

Are you a programmer because this doesn't logically follow. An LLM can be trained on a book but that doesn't mean it will perfectly implement the principles "learned" in in that book for all future prompts and problems. Also, I think what is more fundamentally being said here is more about you as the potential reader, yes you can prompt the AI for something and it will give you a response but it will likely not give you a complete enough of a response that would confer upon you an equivalent level of understanding as an expert for your use-case.

by dinkumthinkum

8/1/2026 at 4:27:39 PM

But even then your prompt has to be explicit enough to get that answer and not the 'wrong one'. Of course they will prioritize stuff that is more often in the training data. That's why AI will be a dead end long term

by f3abfeca54812