Jeff Duntemann's Contrapositive Diary Rotating Header Image

In Pursuit of x64

You may be wondering where I am, given that I haven’t posted a Contra entry for over a month. I didn’t want May to conclude with zero entries posted, so I figured I’d take a break here and get you up to speed.

Here’s the deal: My publisher has asked for a Fourth Edition of Assembly Language Step-By-Step. It’s been thirteen years since the Third Edition came out, so it’s well past time. The idea here is to bring the book up to date on the x64 architecture. In fact, so that no one will mistake what’s going on, the title of the new edition will be x64 Assembly Language Step-By-Step, Fourth Edition. Whether they keep the “x” in lowercase remains to be seen.

So I’m off and editing, writing new code and checking every code snippet in a SASM sandbox, and making sure that I don’t forget and talk about EAX and other 32-bits-and-down entities without good reason. (There are good reasons. Even AH and AL are still with us and used for certain things.) Make no mistake: This is going to be a lot of work. The Third Edition is 600 pages long, which isn’t the longest book I’ve ever written (that honor belongs to Borland Pascal 7 From Square One, at 810 pages) but it’s right up there.

My great fear has been the possibility of needing to add a lot of new material that would make the book even longer, but in truth, that won’t be a huge problem. Here’s why: Some things that I spent a lot of pages on can be cut way back. Good example: In 32-bit Linux, system calls are made through the INT 80H call gate. In the Third Edition I went into considerable detail about how software interrupts work in a general sense. Now, x64 Linux uses a new x64 instruction, SYSCALL, to make calls into the OS. I’m not completely sure, but I don’t think it’s possible to use software interrupts at all in userspace programming anymore. I do have to explain SYSCALL, but there’s just not as much there there, and it won’t take nearly as many words and diagrams.

Oh, and of course, segments are pretty much a thing of the past. Segment management (such that it is) belongs to the OS now, and for userspace programming, at least, you can forget about them. I’m leaving a little description of the old segment/offset memory model for historical context, but not nearly as much as in previous editions.

I also dumped the Game of Big Bux, which doesn’t pull its weight in the explanation department, and isn’t nearly as funny now as it was in 1990. But have faith: The Martians are still with us.

My guess is that from a page count standpoint, it will pretty much be a wash.

It’s going to take me awhile. I don’t know how long, in truth. Especially since I am going to try to keep my fiction output from drying up completely. The book will slow me down, but (for a change) the publisher is not in a huge hurry and I think they’ll give me the time I need. I have 56,000 words down on The Everything Machine, and don’t intend to put it on ice for months and months. I’m not sure how well that’s going to work. We’ll see.


  1. Jeff,

    This is awesome. Your dedication to the fine points of coding – when most coders now use graphical “drag and drop” methods to achieve their goals, is a tribute to efficient programming. Good coders will at least use Assembly Language to improve essential snippets and functions and make them more effective.

    I often hear that cheap memory and faster processors obviate the need for coding efficiency – that kind of thinking will eventually reach an impasse where the next barrier will be the limitations of processor speed and memory. Good coding will be the answer to that.

    I am a firm believer in the concept that we must have a strong cadre of programmer/coders who actually understand the workings of the microprocessors that form the basis of our modern digital environment.

    Your updated book will surely contribute to that.

    1. Jason Bucata says:

      You might want to check out Daniel Lemire’s blog:

      He’s a professor in Quebec and he blogs about doing assembly routines to speed up common tasks, specifically using SIMD instructions which compiler optimizers don’t often use well, or at all. He has recently looked at parsing JSON at gigabytes per second, for example. Plain assembly might not make a big resurgence for ordinary coding but SIMD might get more popular.

  2. Spencer Arnold says:

    Looking forward to it, my progress in learning assembly using 3rd edition has stalled as work-related demands ramp up (new employer, new technology).

    You do know the old errata website for Gary Albers is down? Any plans for dedicated resources to accompany learning (errata, github etc)?

    1. Gary’s whole domain is now some Japanese thing. I see an obituary for a Gary Albers who died in 2018. I haven’t heard from him in quite a while and hope that wasn’t his obituary.

      I have an errata listing for the current edition here:

      I will create a separate page for the new edition (including errata and source code files) and keep them both online, since both books are likely to be in circulation for awhile.

  3. Thom Denholm says:

    Can’t wait!
    Got bogged down IRL and never finished my runthrough of 3rd edition (I was translating to syscall and x64 as needed). Learned a lot about Linux .ASM, but want to come back and finish it.
    Hope one of your options is WSL, a widely available Linux option for many of your readers.

    1. I haven’t tried WSL yet, though it’s on my (long) do-it list. I’ve had success installing Linux in a VM. It works.

      On the other hand, used desktop PCs are a glut on the market. I bought a used Dell Optiplex 990 quadcore, reformatted the disk, and installed Mint 20.3 on it. I bought it on eBay for under $100. That way there’s no chance of messing up my primary Windows instance, on which I do all my writing and numerous other things.

      However, if anybody has WSL installed, I’m pretty sure they can use it to go through the book. I’ll probably put it up on a spare Windows machine before I finish the update, just to make sure.

  4. Jason Bucata says:

    For those of us with a summer ahead of us and who might be impatient, is it worth trying to learn using the previous edition, just to get some experience, and then grabbing the new edition to learn the updates?

    If and when I ever do assembly other than for fun, 32-bit x86 is unlikely to be it. If it’s not x64 then it might be 6809 or 6502 or ARM or RISC-V before it would be 32-bit x86. 😀 Is it worthwhile to just wait for your updated output in that case?

    No rush or anything ;D

    1. You can learn a lot from x86, and learning x64 on top of x86 won’t hurt and won’t even be that hard. x64 keeps a great deal of x86 around for the sake of backward compatibility. X64 gives you some additional registers (and enlarges the others) plus a lot of new math capability. In 64-bit long mode (the native mode) you lose PUSHA and POPA and have to preserve registers individually. Segmented memory is history, and the segment registers are now the sole property of the OS and can be ignored in userspace programming. This simplifies assembly a lot. There’s a new way to make system calls, and lots of relatively small things scattered throughout. The Big Picture is mostly the same as 32-bit, except that the 4 GB barrier is gone.

      Keep in mind that this is a true beginner book, as it always has been. If you know any x86 assembly at all, it’ll be a breeze. My assumption going in is that the reader does not understand programming concepts well, and I start from the very beginning. My suggestion is to get the 2009 edition and start going through it, skipping ahead when you hit material that you already know.

      I have no idea yet how long this is going to take me, so if you wait for the new edition you may be waiting awhile. But I do very much appreciate the vote of confidence!

Leave a Reply

Your email address will not be published.