Assembly Language Step By Step, for Linux!

Important Note! The Insight debugger front end package has been pulled from all Debian distributions, which means that you won't find it in Ubuntu starting with V10.04! I'll discuss this issue in more detail below.

Translations of this page on the Web:

Serbo-Croatian           By Jovana Milutinovich of Web Hosting Geeks

Additional translations are welcome and will be linked from here.

Boy. It took literally ten years, but the job is done, and the book is available: Assembly Language Step By Step, Third Edition. (John Wiley Publishing, 2009. ISBN 978-0-470-49702-9. 610 pp.) Far from a minor touchup, the third edition (3E, as we say in the trade) was a near-total rewrite. DOS is gone for good, and the entire book now focuses on assembly programming for x86 Linux, using free and open source tools that include the NASM assembler, the ld linker, the Kate editor, the Bless hex editor, and the Insight graphical front end to the foundational GNU debugger, gdb. (The gcc compiler is also involved when we start linking C libraries into your assembly programs.)

The idea behind the book, nutty as it might seem, is to teach assembly language as your first programming language. No previous programming experience required. When I wrote the very first edition of the book way back in 1988, I thought it was a bit of a reach, but 175,000 copies and countless fan letters later, I guess it actually worked.

How does it work? I start at the beginning, the real beginning, and explain what computers are and what they do. Assembly language must take the hardware into account (at least as far as memory addressing is concerned) so I talk at length about the Intel/AMD x86 hardware architecture. And when I finally get down to teaching assembly language itself, the emphasis is on memory addressing. In assembly language, if you know where your operands are, you're three quarters of the way to anywhere else you might want to go.

This is a radically different approach from most "intro" assembly books, which begin by teaching you the MOV instruction, and then perhaps the ADD instruction, with little or no discussion of the context in which assembly language operates. This is dumb. Instructions are probably 35% of the trick in assembly language. 50% is memory addressing, and the remaining 15% is odds'n'ends.

Downloading the Listings Archive...

...is easy. Just click here. The zip file is not large (180K) and should come down in just a few seconds on a broadband connection. Alas, my hosting service does not support anonymous FTP for security reasons, so you have to bring it down using HTTP and your Web browser.

Downloading the Table of Contents...

...is just as easy. I've posted the detailed table of contents for the book (in PDF format; 68K) to this site. To get it, click here. (There's a separate link to a sample chapter below.)

What's New?

Although the mission of the book hasn't changed, all of it has been heavily revised, and about 60% is brand-new material. DOS is gone, except as a historical footnote on the horrors of real-mode segmented model. The whole book now focuses on 32-bit protected-mode assembly language for x86 Linux. Although nothing in the book is distro-specific, some descriptions of the tools (and associated screen shots) assume the GNOME graphical shell. I am a Ubuntu user, so the book was written using a Ubuntu installation, but there's nothing Ubuntu-specific in the tutorial material.

Some highlights of the new edition:

What's Old?

What hasn't changed is the overall approach: A slow and patient cumulative tutorial method that above all else emphasizes how things work. ("Cumulative" means that it works best treated as a linear course: Start at the beginning and work through it until the end.) The first three chapters will be familiar to those who have used earlier editions of the book. The Game of Big Bux and the base-4 doo-wop Martians are all still here. The text is conversational and ever-so-slightly wry: You hear the book in your head pretty much the same way you'd hear it if I were at the front of your classroom, having the sort of fun a guy can only have teaching something that he has known and loved for most of his life.

How About A Sample Chapter?

Sure thing. The publisher has given me a PDF of one of the chapters to distribute without charge. Click here to get it. (291K PDF) Again, my hosting service does not allow anonymous FTP, so you'll have to bring it down with your Web browser.

Where to Buy the Book

Your larger bookstores will probably carry the book, and certainly the bigger technical shops like SoftPro Books will have it. If you can't find it locally, definitely look online:

Note well that there are three earlier versions of this book: Assembly Language From Square One (1989; from Scott, Foresman and not Wiley), Assembly Language Step By Step (1992), and Assembly Language Step By Step, Second Edition (2000). If you're buying a used copy of the 2009 edition, make very sure that you're ordering the right edition!

If You Have a 64-Bit PC...

Note that the book was written for the commonest PC hardware, based on Intel/AMD 32-bit CPUs. I had hoped to get some 64-bit coverage in there, but the publisher set a hard limit on the length of the book for cost reasons. I'm going to try and twist their arms to give me another 100 pages for the next edition, but in the meantime, it's a 32-bit book.

That said, 64-bit PCs are now all over the place, and there's an issue involving the nature of an executable code file. To produce a genuine 64-bit assembly language executable, you must tell NASM to generate a linkable file in the 64-bit  linkable format, elf64. On a 64-bit PC, the linker expects a 64-bit elf64 file by default, and will complain if you hand it a 32-bit elf file without warning. (elf and elf32 are synonyms in NASM, even if you're using a 64-bit PC.)

There are two ways to go on a 64-bit PC:

Creating a 32-bit executable on a 64-bit PC requires that you "warn" the linker that a 32-bit elf file is coming:

nasm -f elf -g -F stabs eat.asm
ld -o eat eat.o -melf_i386

That's what the melf_i386 directive does: It tells ld that the eat.o file is an elf32 linkable object file. The invocation of NASM is the same as you'd use on a 32-bit PC.

Creating a 64-bit executable requires that you tell NASM explicitly to generate a 64-bit linkable file:

nasm -f elf64 -g -F stabs eat.asm
ld -o eat eat.o

Here, using elf64 instead of elf tells NASM to generate a 64-bit linkable file. The linker invocation is the same as the one in the book because on a 64-bit PC, ld expects that the .o file you hand it will be 64-bit by default.

Is there any advantage in creating 64-bit executables? Not for the small programs you'll write while you're learning assembly (especially since 64-bit executables are a little larger than 32-bit executables) but once you're doing ambitious programming in assembly you'll have the entire 64-bit x86-64 architecture at your command, with additional 64-bit registers, 64-bit instruction modes, and "long mode" memory addressing.

Many thanks to Gary Albers for alerting me to this problem, since I wrote all my example code on a 32-bit box and didn't give sufficient thought to what might happen using default assembler and linker invocations on a 64-bit PC. He's set up a whole page discussing the issue, and it's worth a close read:

http://www.stepbystep.ishipaco.com/

With any luck at all, I'll have the space to cover 64-bit assembly programming in the next edition of the book.

Gary also discusses his experiences using Kdbg instead of Insight. Which brings us to one of the lousiest pieces of bad timing I've ever experienced:

Insight Is Now Missing from Ubuntu!

This took me completely by surprise. Late in 2009 (and not long after the book was published!) a decision was made to remove the Insight debugger front end package from Debian Linux, on which Ubuntu is based. So you will no longer find Insight preinstalled in Ubuntu, starting with V10.04, Lucid Lynx. If you bring up a terminal and try to run it, Ubuntu won't find it.

This is a weird problem, especially since I've had no luck recompiling Insight from source. There must be some deeper issue, but if the developers of the package aren't maintaining it, there may not be much any of us can do going forward.

At this point, you have several options:

Installing Kate Under Fedora 13

Note that under Fedora 13 and Gnome, you won't be able to find the Kate editor by searching for "kate" using Add/Remove programs. Instead, you must install the entire KDE SDK package, which you can find by searching for "kdesdk". Installing the KDE SDK installs Kate as part of the toolset. If you installed Fedora with the KDE UI, you've already got Kate.

Now, installing Kate isn't quite enough. You also have to install Konsole, because Kate invokes Konsole when you click Kate's "Terminal" button to run a program that you're editing in Kate.Just as Kate is part of a larger package called kdesdk, Konsole is part of a larger package called kdebase. Search for "kdebase" using Add/Remove Programs and install it. This actually pulls in quite a lot of stuff (most of it that you won't need, alas) but it will install Konsole.

To install Insight, search for "insight" using Add/Remove programs and install it. Insight isn't really a part of any larger group of programs, so it installs quickly.

The bottom line is that Insight likely isn't coming back to Debian, and thus it's not coming back to Ubuntu. If I can discover a reliable way to install Insight manually under Ubuntu 10.04 and later I'll post it here. In the meantime, your best bet is installing a copy of Ubuntu 9.10 either in a separate partition or in a virtual machine, and using that copy for your assembly learning projects.

Again, Gary Albers has much to say about the Insight problem on his Web page.

Errata for the Third Edition