“Learning assembly language is about learning how the processor itself thinks about your code. It is about gaining the mind of the machine.”

Jonathan Bartlett, Learn to Program with Assembly: Foundational Learning for New Programmers, p. 1

Jonathan Bartlett is a man of many talents: an engineer, a software developer, a mathematician, a researcher and writer. He has been a faithful contributor here at Mind Matters News for many years, on topics ranging from programming and coding to math to education to technology. His books have become required reading at Princeton and DeVry Universities.

Now, he has written a new book, Learn to Program with Assembly: Foundational Learning for New Programmers, and he sat down with Mind Matters to talk about it.

Q: Tell us about your new book.

Bartlett: The book on its face is about assembly language programming. However, more generally, it is about how your computer works and how programs and operating systems work with each other.

Q: What is assembly language?

Bartlett: Assembly language is the programming language that the computer itself understands. In most languages, you write code, and that code gets compiled into the computer’s own language, and the programmer never sees what that looks like. In assembly language, the instructions you use are the instructions that the computer understands. There is a tiny bit of translation, which allows you to write “MOV” instead of the computer’s number for it (which actually varies a bit, but one of them is “88”). But nonetheless, you are issuing the instructions that match what the computer is reading.

Q: Why did you decide to write a book on assembly language?

Bartlett: In computer programming there is a distinction between high-level and low-level languages. Low-level languages are those that are closer to the computer hardware, and high-level languages try to abstract the hardware away to make the features of the programming language more directly tied to solving problems than dealing with hardware. Assembly language is the lowest-level language there is that is still readable. 

Most programmers program in high-level languages for good reason — it takes a lot less time to do so. However, I have found that many modern programmers have only programmed in high-level languages. The problem there is that it removes any sense of the computer that they are using to program with. They don’t understand why certain features are fast or slow, where certain programming constraints come from, and are totally baffled by many error messages they receive when something goes wrong on a lower level. The lack of experience with low-level languages means that many programmers today are basically ignorant of how their computer works.

If I drive a family car, usually I only care about the steering wheel, the gas pedal, the brake pedal, and maybe a few other features that allow me to get where I’m going. I don’t need to know anything about the carburetor or the engine to help me out. However, a NASCAR driver, despite the fact that he himself probably doesn’t do the maintenance on the car, will know everything about how the internals work. Despite the fact that he is still driving using the same basic interface as your family car, he can make better driving decisions that get the most out of his car since he knows more clearly how it is working under the hood. 

The same is true of assembly language. Most programmers will never need to program in assembly language. However, knowing assembly language will give them familiarity with how the computer really works. Knowing assembly language will give programmers a better intuition about what is actually going on in the higher-level languages and help programmers make better decisions regarding implementation and tradeoffs. And when things aren’t working, they will have a better sense of what might be the problem under the hood.

Q: So where is assembly language currently used?

Bartlett: As I mentioned, most programmers aren’t going to use assembly language themselves directly, but knowing it is foundational to the rest of what they do. However, there are still some cases where assembly language is the best option. If you want to write a new programming language, or want to build a compiler for an old or new language, assembly language is usually what is generated from these systems, so you have to be fluent in it to get it to work. Also, if you work on the operating system itself, there are often tasks which require knowledge of assembly language. If you write code for small devices, sometimes in those cases assembly language is not only required, it is sometimes easier than writing higher level code, because the things you are dealing with are hardware. There are some microprocessors for devices (such as the PIC10F220) that don’t even have enough writeable memory to fit the text of the words “small microprocessor” in them, and so you need assembly language to be able to take control over every byte available. Occasionally, people will also write very time-critical parts of their code in assembly language just to guarantee that it is fast. For instance, there are some graphics code libraries and math code libraries that have some of the functions implemented directly in assembly language to make them faster.

Q: Do you cover other topics in your book?

Bartlett: The book is organized into four parts. The first part is just the basics of assembly language — what assembly language instructions look like, how to put them together into a program, etc. The second part is about interfacing with your operating system. It covers how to call the operating system to deal with operating system tasks such as accessing files. It shows how to make use of the system code library so you can re-use other people’s code, even if it is not written in assembly language. It also shows how to write code so that it can be used from other programs and other languages. The third part shows how concepts from other programming languages are implemented in assembly language. What does object-oriented programming, exception handling, and memory management look like from an assembly language perspective? Short implementations of each of these are given. Finally, there are the appendices, many of which are short tutorials. For instance, one of the appendices is on floating-point and vector programming. Another appendix is on using a debugger to find errors in your program. That sort of thing.

Q: What operating system do you use for the book?

Bartlett: The book is geared towards the Linux operating system. However, I created a Docker image which is set up specifically with the book in mind which you can use to make the same programs run under Windows or Linux. The only requirement is a 64-bit computer, which is pretty common these days. Most current computers are 64-bit.

Q: Didn’t you write another book on assembly language?

Bartlett: Actually, my very first book, Programming from the Ground Up, was on assembly language. This book is essentially a rewrite of that book, but focused on more modern, 64-bit computers. A lot has changed since 2004, so this book reflects a lot of those changes. Additionally, the new book goes further. The original book didn’t talk about floating point, object-oriented programming, exception handling, or garbage collection. This one does. There is even a garbage collector written in assembly language so that readers have a better idea about how that works at the lowest levels.

When it was first released, Programming from the Ground Up developed a bit of a cult following, for a variety of reasons. First of all, it was one of the first open-source textbooks. Second, it was at the start of the Linux craze, so being Linux-oriented added to its appeal. Finally, I actually wrote it as your first programming book. A lot of people view assembly language programming as “hard,” but I remember learning it as a teenager back before there were any real programming languages available. So I decided to make a much more accessible assembly language book that anyone at any level could program in.

It made quite a splash when the technology blog Slashdot picked up the story. There were over a thousand comments on the article, with quite a debate over whether I was crazy to attempt such a feat. In all, I found that very few people used the book as their first programming book, but a lot of people appreciate the fact that it was written with an accessible style.

Q: How does this fit in with other books you’ve written?

Bartlett: I spend a lot of time writing what I call “books that people don’t know they need to read.” Some people write for what’s popular. I’m not opposed to that — people need books on the topics they are interested in. However, I’ve found that there’s a lot of things that people need to know that they don’t realize they need to know. It makes marketing difficult because, not only do you have to convince people that your book is interesting, you sometimes have to convince them to be interested in the topic at all. Nonetheless, I think it is an important space for someone to be in. 

The way that I generally approach my books is to think from two perspectives simultaneously — that of someone who doesn’t know anything, and that of someone who does this professionally — and try to connect those two together. Some books are so focused on the basics or mechanics of their subject that you would never see how it is used in the wider arena. Others assume that you already have all the knowledge you need. My goal is to help people cross the chasm. It’s introductory enough that you can start there, but the goal is to help you develop the intuitions necessary to be a practitioner.

For instance, in my Electronics for Beginners book, I recognized that many electronics books were either “projects only” so you weren’t taught how someone fits everything together, or were essentially graduate level physics texts that required advanced mathematics. And even these advanced texts didn’t contain much about the art of doing electronics. In order to know that, you basically just had to do it a lot. So I wrote the book to take someone from the “I don’t know anything stage” to the “beginning artful practitioner” stage. Now, there’s only so much you can do in one book, but my goal is to help someone so they can really speak the language that practitioners talk in, and understand what is happening in circuit schematics that they might see “in the wild.” 

So that’s essentially what’s happening with this book. Most programmers don’t recognize that they need to know assembly language, and most books on assembly language are more about the mechanics of it than helping someone think about things from an assembly language perspective. I tried to cover the middle ground — helping someone go from knowing nothing to being confident in what they do. Again, there’s only so much you can cover in one book, but I think I covered enough that someone can easily know enough to look up the rest, or understand someone’s answers if they ask around. By the end of the book you can do most programming tasks in assembly language, and recognize how higher level languages are implemented using assembly language underneath. The goal is to make you more intuitive about how the computer is actually working, and I think the book hits the goal quite well.

You can purchase Learn to Program with Asssembly at Amazon, Barnes & Noble, WalMart, and from the publisher Springer Link. You can explore Bartlett’s other books at Amazon, and a collection of his academic papers at Blyth Institute.

Here are some of Bartlett’s most recent writings on software and programming at Mind Matters News:

The Myth of “No Code” Software. “No code” software has its place, but not as a replacement for programmers. In order to make a secure app with a “no code” tool, one needs to be able to understand the deep implications of what one is building.

The Search for the Universal Algorithm Continues. Why does machine learning always seem to be rounding a corner, only to eventually hit a wall? Universal algorithms are limited by the axioms supplied to them, which is why universal algorithms are just not possible.

Code Debt Is Not Real Debt. Equating code debt with monetary debt can lead to strategic technology mistakes. The term “code debt” helps us remember the fact that certain decisions mean that we are saving time now in order to spend time later.