The No. 0 chapter is written in front
I don't want to exaggerate or belittle assembly language. But I want to say that assembly language changed the history of the 20th century. Compared to predecessors, our generation of programmers is happy enough, because we have a wide range of programming languages, we can operate the keyboard, sitting in front of the monitor, even using the mouse, speech recognition. Instead of sharing with a group of people a giant machine that uses bulky relays and switches, we can use the keyboard and mouse to harness the "personal computer". By contrast, our predecessors had to use machine language to write programs, they don't even have the simplest assembler to translate mnemonics into machine language, and we can choose one of the thousands of computer languages we like, and the Assembly, though not a "common" language with "rapid prototyping" capabilities, It is one of the languages we can choose.
Each computer has its own assembly language-there is no need to rely on assembly language portability, the choice of assembly, which means choosing performance rather than portability or ease of debugging. This document is about x86 assembly language, since the word "assembly language", if not explicitly expressed ia32 on the x86 assembly language.
Assembly language is a kind of easy to learn, but difficult to master languages. Back then, I learned from the beginner's compilation to write the first operational program, only in less than 4 hours, but today, I still dare not say that I am proficient in it. Writing a program that is fast, efficient, and can make the processor "very comfortable to execute" is a difficult task, and it usually takes 2-3 years to learn in your spare time. This textbook is not expected to teach you a lot of assembly language skills. For the reader, x86 assembly language "right here." However, do not rigidly confine yourself to the content of this textbook, as it can only tell you that assembly language is "such a thing". Learn assembly language, more to rely on a person's creativity in the perception, I can tell you I know the skills, but certainly it is not enough. One person who has had a major impact on my programming career once said to me:
Writing assembly Language program is not the most difficult part of assembly language, innovation is.
I think the person who is willing to read this document will not ask me "why to learn assembly language" such a question; however, I would like to say a few words: first, the assembly language is very useful, I personally advocate it as a C language first course, because by learning assembly language, you can learn how to effectively design data structures, Let the computer process faster, and use less storage space, at the same time, learning assembly language can let you familiar with the internal operation of the computer, and effectively improve debugging capabilities. As far as my personal experience is concerned, the difficulty of debugging an unstructured program is much more difficult than debugging a structured program because "structured" improves readability and scalability at the expense of operational efficiency, which is necessary to complete the coding phase of general software engineering. However, in some places, such as hardware drivers, the underlying operating system, or code that is often executed in a program, the benefits of structured programming are sometimes obliterated by its inefficiency. In addition, if you want to really control your program, only know the source code level debugging is not enough.
Impetuous people like to say, use C + + to write a program enough, even said, he not only master C + +, but also proficient in STL, MFC. I do not agree with this view, master the above is what every programmer should do, but C + + is our "common" language, it is not the whole programming. Low-level developers like to say, hey, how powerful C + + is, it can do anything-it's not true. Easy to maintain, debug, these are indeed our pursuit of goals, but, write procedures can not only pursue this goal, because our ultimate goal is to meet the design needs, rather than personal irrational ideals.
This textbook is suitable for readers who have studied a structured programming language. The content is based on the handouts I wrote in 1995 years when I was telling people about assembly language. Of course, as you would expect, it contains the latest features supported by the processor, as well as the corresponding content. I assume that the reader already knows some of the basic concepts of program design, because none of these are able to understand the assembly language programming, and I hope that the reader has a better basis for programming, because if you lack of knowledge of structured design, Writing assembly language programs is likely to quickly disrupt your structured programming habits, greatly reducing the readability and maintainability of your programs, and eventually leaving your program in a heap of code that has to be discarded.
Basically, the goal of writing this document is to be as easy as possible to learn. However, it has some requirements for you, although not very high, but I would emphasize.
Learn assembly language, you need
Guts. Don't be afraid to touch the internal working mechanisms of those computers.
Knowledge. Understand the computer systems commonly used, especially binary, 16, octal, and how the computer saves data.
Open. Accept the difference between an assembly language and a high-level language, rather than blaming it for its poor reading.
Experience. Requires you to have a little programming experience in any other programming language.
Mind.
Wish you a happy programming!
Introduction to the first chapter of assembly language
Let's start with something that doesn't really matter much with actual programming. Of course, if you are eager to see something more substantial, you can skip this chapter first.
Well, I think there may be a problem that is very important for beginners of the Assembly:
What exactly is assembly language?
Assembly language is a kind of coding language closest to the core of computer. Unlike any high-level language, assembly language can almost completely correspond to machine language one by one. Yes, we can write programs in machine language, but now people who write more than 1000 instructions in machine language, except those with no assembler, probably count as the victims of our "saints". After all, memorizing some short mnemonics, thinking about trivial coordination processes and checking errors by machines, is much better than remembering a lot of hexadecimal code that changes with the computer, and can be mistaken without any hint. Proficient assembly language coders can even read the general meaning of assembly language directly from the hexadecimal code. Of course, we have better tools--assembler and disassembler.
Simply put, assembly language is a form of machine language that can be read by others, but it is easier to remember. As for the macro assembly, it is the assembly language that contains the macro support, which allows you to be more focused on the program itself while programming, rather than busy computing and rewriting the code.
In addition to machine language, assembly language is closest to the computer hardware programming language. Because it is so close to computer hardware, it can maximize the performance of your computer's hardware. Programs written in assembly language tend to be faster than high-level languages and C + +--several times, dozens of times times, or even hundreds. Of course, the interpretation of language, such as the interpretation of Lisp, no use of JIT Java Virtual machine running Java, etc., its program speed is not the same as the assembly language program.
Never ignore the high speed of assembly language. In the actual application system, we often use the assembly to rewrite some of the frequently called parts in order to achieve higher performance. The application assembly may not improve the stability of your program, but at the very least, it will not degrade stability if you are very careful at the same time, it can greatly improve the speed of the program. I strongly recommend that all software products profile the entire code before the final release, and replace some of the advanced language code appropriately with the assembly. At the very least, assembly language knowledge can tell you something useful, such as how many registers you can use. Sometimes, manual optimizations are more efficient than compiler optimizations, and you can fully control the actual behavior of the program.
I think I'm talking a wordy. All in all, before we end this chapter, I want to say, don't put hope in the compiler at the time of optimization--realistically, a good compiler can't always produce the best code.