Introduction

"Why Would You Want to Do That?"

It was 1985, and I was in a chartered bus in New York City, heading for a press reception with a bunch of other restless media egomaniacs. I was only beginning my tech journalist career (as technical editor for PC Tech Journal), and my first book was still months in the future. I happened to be sitting next to an established programming writer/guru, with whom I was impressed and to whom I was babbling about one thing or another. I would like to eliminate this statement; it adds little to the book, and as annoying as he is, even though we don't name him, I now understand why he's so annoying: He lives and works in a completely different culture than I do.

During our chat, I happened to let slip that I was a Turbo Pascal fanatic, and what I really wanted to do was learn how to write Turbo Pascal programs that made use of the brand new Microsoft Windows user interface. He wrinkled his nose and grimaced wryly, before speaking the Infamous Question:

"Why would you want to do that?"

I had never heard the question before (though I would hear it many times thereafter), and it took me aback. Why? Because, well, because.I wanted to know how it worked.

"Heh. That's what C is for."

Further discussion got me nowhere in a Pascal direction. But some probing led me to understand that you couldn't write Windows apps in Turbo Pascal. It was impossible. Or.the programming writer/guru didn't know how. Maybe both. I never learned the truth as it stood in 1985. (Delphi answered the question once and for all in 1995.) But I did learn the meaning of the Infamous Question.

Note well: When somebody asks you, "Why would you want to do that?" what it really means is this: "You've asked me how to do something that is either impossible using tools that I favor or completely outside my experience, but I don't want to lose face by admitting it. So.how 'bout those Blackhawks?"

I heard it again and again over the years:

• Q: How can I set up a C string so that I can read its length without scanning it?
• A: Why would you want to do that?
• Q: How can I write an assembly language subroutine callable from Turbo Pascal?
• A: Why would you want to do that?
• Q: How can I write Windows apps in assembly language?
• A: Why would you want to do that?

You get the idea. The answer to the Infamous Question is always the same, and if the weasels ever ask it of you, snap back as quickly as possible: because I want to know how it works.

That is a completely sufficient answer. It's the answer I've used every single time, except for one occasion a considerable number of years ago, when I put forth that I wanted to write a book that taught people how to program in assembly language as their first experience in programming.

• Q: Good grief, why would you want to do that?
• A: Because it's the best way there is to build the skills required to understand how all the rest of the programming universe works.

Being a programmer is one thing above all else: It is understanding how things work. Learning to be a programmer, furthermore, is almost entirely a process of learning how things work. This can be done at various levels, depending on the tools you're using. If you're programming in Visual Basic, you have to understand how certain things work, but those things are by and large confined to Visual Basic itself. A great deal of machinery is hidden by the layer that Visual Basic places between the programmer and the computer. (The same is true of Delphi, Lazarus, Java, Python, and many other very high-level programming environments.) If you're using a C compiler, you're a lot closer to the machine, so you see a lot more of that machinery-and must, therefore, understand how it works to be able to use it. However, quite a bit remains hidden, even from the hardened C programmer.

If, on the other hand, you're working in assembly language, you're as close to the machine as you can get. Assembly language hides nothing, and withholds no power. The flipside, of course, is that no magical layer between you and the machine will absolve any ignorance and "take care of" things for you. If you don't understand how something works, you're dead in the water-unless you know enough to be able to figure it out on your own.

That's a key point: My goal in creating this book is not entirely to teach you assembly language per se. If this book has a prime directive at all, it is to impart a certain disciplined curiosity about the underlying machine, along with some basic context from which you can begin to explore the machine at its very lowest levels-that, and the confidence to give it your best shot. This is difficult stuff, but it's nothing you can't master given some concentration, patience, and the time it requires-which, I caution, may be considerable.

In truth, what I'm really teaching you here is how to learn.

What You'll Need

To program as I intend to teach, you're going to need a 64-bit Intel computer running a 64-bit distribution of Linux. The one I used in preparing this book is Linux Mint Cinnamon V20. 3 Una. "Una" here is a code name for this version of Linux Mint. It's nothing more than a short way of saying "Linux Mint 20.3." I recommend Mint; it's thrown me fewer curves than any other distro I've ever used-and I've used Linux here and there ever since it first appeared. I don't think which graphical shell you use matters a great deal. I like Cinnamon, but you can use whatever you like or are familiar with.

You need to be reasonably proficient with Linux at the user level. I can't teach you how to install, configure, and run Linux in this book. If you're not already familiar with Linux, get a tutorial text and work through it. There are many such online.

You'll need a piece of free software called SASM, which is a simple interactive development environment (IDE) for programming in assembly. Basically, it consists of an editor, a build system, and a front end to the standard Linux debugger gdb. You'll also need a free assembler called NASM.

You don't have to know how to download, install, and configure these tools in advance because, at the appropriate times, I'll cover all necessary tool installation and configuration.

Do note that other Unix implementations not based on the Linux kernel may not function precisely the same way under the hood. BSD Unix uses different conventions for making system calls, for example, and other Unix versions like Solaris are outside my experience.

Remember that this book is about the x64 architecture. To the extent that x64 contains x86, I will also be teaching elements of the x86 architecture. The gulf between 32-bit x86 and 64-bit x64 is a lot narrower than the gulf between 16-bit x86 and 32-bit x86. If you already have a firm grounding in 32-bit x86, you'll breeze through most of this book at a gallop. If you can do that, cool-just please remember that the book is for those who are just starting out in programming on Intel CPUs.

Also remember that this book is limited in size by its publisher: Paper, ink, and cover stock aren't free. That means I have to narrow the scope of what I teach and explain within those limits. I wish I had the space to cover the AVX math subsystem. I don't. But I'll bet that once you go through this book, you can figure much of it out by yourself.

The Master Plan

This book starts at the beginning, and I mean the beginning. Maybe you're already there, or well past it. I respect that. I still think that it wouldn't hurt to start at the first chapter and read through all the chapters in order. Review is useful, and hey-you may realize that you didn't know quite as much as you thought you did. (Happens to me all the time!)

But if time is at a premium, here's the cheat sheet:

• If you already understand the fundamental ideas of computer programming, skip Chapter 1.
• If you already understand the ideas behind number bases other than decimal (especially hexadecimal and binary), skip Chapter 2.
• If you already have a grip on the nature of computer internals (memory, CPU architectures, and so on) skip Chapter 3.
• If you already understand x64 memory addressing, skip Chapter 4.
• No. Stop. Scratch that. Even if you already understand x64 memory addressing, read Chapter 4.

The last bullet is there, and emphatic, for a reason: Assembly language programming is about memory addressing. If you don't understand memory addressing, nothing else you learn in assembly will help you one.bit. So, don't skip Chapter 4 no matter what else you know or think you know. Start from there, and see it through to the end. Memory addressing comes up regularly throughout the rest of the book. It's really the heart of the topic.

Load every example program, assemble each one, and run them all. Strive to understand every single line in every program. Take nothing on faith. Furthermore, don't stop there. Change the example programs as things...