Assembly Language Step-by-Step Programming with Linux (2009)
by Academia Educational
Submitted by
Z
zero 
4649c 6.05
Ranked
Assembly Language Step-by-Step Programming with Linux
by Jeff Duntemann
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 x86 memory addressing, skip Chapter 4.⏎⇥ No. Stop. Scratch that. Even if you already understand x86 memory addressing, read Chapter 4.⏎⇥ Point 5 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 lick. 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. 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 begin to make sense to you. Try different approaches. Try things that I don't mention. Be audacious. Nay, go nuts - bits don't have feelings, and the worst thing that can happen is that Linux throws a segmentation fault, which may hurt your program (and perhaps your self esteem) but does not hurt Linux. (They don't call it "protected mode" for nothing!) The only catch is that when you try something, understand why it doesn't work as clearly as you understand all the other things that do. Take notes.⏎⇥ That is, ultimately, what I'm after: to show you the way to understand what every however distant corner of your machine is doing, and how all its many pieces work together. This doesn't mean I explain every corner of it myself - no one will live long enough to do that. Computing isn't simple anymore, but if you develop the discipline of patient research and experimentation, you can probably work it out for yourself. Ultimately, that's the only way to learn it: by yourself. The guidance you find - in friends, on the Net, in books like this - is only guidance, and grease on the axles. You have to decide who is to be the master, you or the machine, and make it so. Assembly programmers are the only programmers who can truly claim to be the masters, and that's a truth worth meditating on.⏎ A Note on Capitalization Conventions⏎ Assembly language is peculiar among programming languages in that there is no universal standard for case sensitivity. In the C language, all identifiers are case sensitive, and I have seen assemblers that do not recognize differences in case at all. NASM, the assembler I present in this book, is case sensitive only for programmer-defined identifiers. The instruction mnemonics and the names of registers, however, are not case sensitive.⏎⇥ There are customs in the literature on assembly language, and one of those customs is to treat CPU instruction mnemonics and register names as uppercase in the text, and in lowercase in source code files and code snippets interspersed in the text. I'll be following that custom here. Within discussion text, I'll speak of MOV and registers EAX and EFLAGS. In example code, it will be mov and eax and eflags.⏎⇥ There are two reasons for this:⏎ In text discussions, the mnemonics and registers need to stand out. It's too easy to lose track of them amid a torrent of ordinary words.⏎ In order to read and learn from existing documents and source code outside of this one book, you need to be able to easily read assembly language whether it's in uppercase, lowercase, or mixed case. Getting comfortable with different ways of expressing the same thing is important.⏎⇥ This will grate on some people in the Unix community, for whom lowercase characters are something of a fetish. I apologize in advance for the irritation, while insisting to the end that it's still a fetish, and a fairly childish one at that.⏎ Why Am I Here Again?⏎ Wherever you choose to start the book, it's time to get under way. Just remember that whatever gets in your face, be it the weasels, the machine, or your own inexperience, the thing to keep in the forefront of your mind is this:⏎ You're in it to figure out how it works.⏎⇥ Let's go.🏁
Submitted by zero - 01/25/2026
Academia Educational 6.05 Ranked
Global Leaderboard
| # | Player | Time | Duration | Accuracy | WPM | pp | ||
|---|---|---|---|---|---|---|---|---|
| 1 | ||||||||
| 2 | ||||||||
| 3 | ||||||||
| 4 | ||||||||
| 5 | ||||||||
| 6 | ||||||||
| 7 | ||||||||
| 8 | ||||||||
| 9 | ||||||||
| 10 |
Assembly Language Step-by-Step Programming with Linux
by Jeff Duntemann
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 x86 memory addressing, skip Chapter 4.⏎⇥ No. Stop. Scratch that. Even if you already understand x86 memory addressing, read Chapter 4.⏎⇥ Point 5 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 lick. 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. 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 begin to make sense to you. Try different approaches. Try things that I don't mention. Be audacious. Nay, go nuts - bits don't have feelings, and the worst thing that can happen is that Linux throws a segmentation fault, which may hurt your program (and perhaps your self esteem) but does not hurt Linux. (They don't call it "protected mode" for nothing!) The only catch is that when you try something, understand why it doesn't work as clearly as you understand all the other things that do. Take notes.⏎⇥ That is, ultimately, what I'm after: to show you the way to understand what every however distant corner of your machine is doing, and how all its many pieces work together. This doesn't mean I explain every corner of it myself - no one will live long enough to do that. Computing isn't simple anymore, but if you develop the discipline of patient research and experimentation, you can probably work it out for yourself. Ultimately, that's the only way to learn it: by yourself. The guidance you find - in friends, on the Net, in books like this - is only guidance, and grease on the axles. You have to decide who is to be the master, you or the machine, and make it so. Assembly programmers are the only programmers who can truly claim to be the masters, and that's a truth worth meditating on.⏎ A Note on Capitalization Conventions⏎ Assembly language is peculiar among programming languages in that there is no universal standard for case sensitivity. In the C language, all identifiers are case sensitive, and I have seen assemblers that do not recognize differences in case at all. NASM, the assembler I present in this book, is case sensitive only for programmer-defined identifiers. The instruction mnemonics and the names of registers, however, are not case sensitive.⏎⇥ There are customs in the literature on assembly language, and one of those customs is to treat CPU instruction mnemonics and register names as uppercase in the text, and in lowercase in source code files and code snippets interspersed in the text. I'll be following that custom here. Within discussion text, I'll speak of MOV and registers EAX and EFLAGS. In example code, it will be mov and eax and eflags.⏎⇥ There are two reasons for this:⏎ In text discussions, the mnemonics and registers need to stand out. It's too easy to lose track of them amid a torrent of ordinary words.⏎ In order to read and learn from existing documents and source code outside of this one book, you need to be able to easily read assembly language whether it's in uppercase, lowercase, or mixed case. Getting comfortable with different ways of expressing the same thing is important.⏎⇥ This will grate on some people in the Unix community, for whom lowercase characters are something of a fetish. I apologize in advance for the irritation, while insisting to the end that it's still a fetish, and a fairly childish one at that.⏎ Why Am I Here Again?⏎ Wherever you choose to start the book, it's time to get under way. Just remember that whatever gets in your face, be it the weasels, the machine, or your own inexperience, the thing to keep in the forefront of your mind is this:⏎ You're in it to figure out how it works.⏎⇥ Let's go.🏁
Submitted by zero - 01/25/2026
Academia Educational 6.05 Ranked