资源描述
The Art of Assembly Language
1. What's Wrong With Assembly Language？
2. What's Right With Assembly Language？
1. What's Wrong With Assembly Language
Assembly language has a pretty bad reputation. The common impression about assembly language
programmers today is that they are all hackers or misguided individuals who need enlightenment.
Here are the reasons people give for not using assembly:
（1）Assembly is hard to learn.
（2）Assembly is hard to read and understand.
（3）Assembly is hard to debug.
（4）Assembly is hard to maintain.
（5）Assembly is hard to write.
（6）Assembly language programming is time consuming.
（7）Improved compiler technology has eliminated the need for assembly language.
（8）Today, machines are so fast that we no longer need to use assembly.
（9）If you need more speed, you should use a better algorithm rather than switch to assembly language.
（10）Machines have so much memory today, saving space using assembly is not important.
（11）Assembly language is not portable.
These are some strong statements indeed!
Given that this is a book which teaches assembly language programming, written for college level students, written by someone who appears to know what he's talking about, your natural tendency is to believe something if it appears in print. Having just read the above, you're starting to assume that assembly must be pretty bad. And that, dear friend, is eighty percent of what's wrong with assembly language. That is, people develop some very strong misconceptions about assembly language based on what they've heard from friends, instructors, articles, and books. Oh, assembly language is certainly not perfect. It does have many real faults. Those faults, however, are blown completely out of proportion by those unfamiliar with assembly language. The next time someone starts preaching about the evils of assembly language, ask, "how many years of assembly language programming experience do you have?" Of course assembly is hard to understand if you don't know it. It is surprising how many people are willing to speak out against assembly language based only on conversations they've had or articles they've read.
Assembly language users also use high level languages (HLLs); assembly's most outspoken opponents rarely use anything but HLLs. Who would you believe, an expert well versed in both types of programming languages or someone who has never taken the time to learn assembly language and develop an honest opinion of its capabilities?
In a conversation with someone, I would go to great lengths to address each of the above issues.Indeed, in a rough draft of this chapter I spent about ten pages explaining what is wrong with each of the above statements. However, this book is long enough and I felt that very little was gained
by going on and on about these points. Nonetheless, a brief rebuttal to each of the above points is in order, if for no other reason than to keep you from thinking there isn't a decent defense for these statements.
Assembly is hard to learn. So is any language you don't already know. Try learning (really learning) APL, Prolog, or Smalltalk sometime. Once you learn Pascal, learning another language like C, BASIC, FORTRAN, Modula-2, or Ada is fairly easy because these languages are quite similar to Pascal. On the other hand, learning a dissimilar language like Prolog is not so simple.Assembly language is also quite different from Pascal. It will be a little harder to learn than one of the other Pascal-like languages. However, learning assembly isn't much more difficult than learning your first programming language.
Assembly is hard to read and understand. It sure is, if you don't know it. Most people who make this statement simply don't know assembly. Of course, it's very easy to write impossible-to-read assembly language programs. It's also quite easy to write impossible-to-read C, Prolog, and APL programs. With experience, you will find assembly as easy to read as other languages.
Assembly is hard to debug. Same argument as above. If you don't have much experience debugging assembly language programs, it's going to be hard to debug them. Remember what it was like finding bugs in your first Pascal (or other HLL) programs? Anytime you learn a new programming language you'll have problems debugging programs in that language until you gain
experience.
Assembly is hard to maintain. C programs are hard to maintain. Indeed, programs are hard to maintain period. Inexperienced assembly language programmers tend to write hard to maintain programs. Writing maintainable programs isn't a talent. It's a skill you develop through experience.
Assembly language is hard. This statement actually has a ring of truth to it. For the longest time assembly language programmers wrote their programs completely from scratch, often "re-inventing the wheel." HLL programmers, especially C, Ada, and Modula-2 programmers, have long enjoyed the benefits of a standard library package which solves many common programming problems. Assembly language programmers, on the other hand, have been known to rewrite an integer output routine every time they need one. This book does not take that approach. Instead, it takes advantage of some work done at the University of California, Riverside: the UCR Standard Library for 80x86 Assembly Language Programmers. These subroutines simplify assembly language just as the C standard library aids C programmers. The library source listings are available electronically via Internet and various other communication services as well as on a
companion diskette.
Assembly language programming is time consuming. Software engineers estimate that developers spend only about thirty percent of their time coding a solution to a problem. Even if it took twice as much time to write a program in assembly versus some HLL, there would only be a fifteen percent difference in the total project completion time. In fact, good assembly language programmers do not need twice as much time to implement something in assembly language. It is true using a HLL will save some time; however, the savings is insufficient to counter the benefits of using assembly language.
Improved compiler technology has eliminated the need for assembly language. This isn't true and probably never will be true. Optimizing compilers are getting better every day. However, assembly language programmers get better performance by writing their code differently than they would if they were using some HLL. If assembly language programmers wrote their programs in C and then translated them manually into assembly, a good C compiler would produce equivalent, or even better, code. Those who make this claim about compiler technology are comparing their
hand-compiled code against that produced by a compiler. Compilers do a much better job of compiling than humans. Then again, you'll never catch an assembly language programmer writing "C code with MOV instructions." After all, that's why you use C compilers.
Today, machines are so fast that we no longer need to use assembly. It is amazing that people will spend lots of money to buy a machine slightly faster than the one they own, but they won't spend any extra time writing their code in assembly so it runs faster on the same hardware. There
are many raging debates about the speed of machines versus the speed of the software, but one fact remains: users always want more speed. On any given machine, the fastest possible programs will be written in assembly language.
If you need more speed, you should use a better algorithm rather than switch to assembly language. Why can't you use this better algorithm in assembly language? What if you're already using the best algorithm you can find and it's still too slow? This is a totally bogus argument
against assembly language. Any algorithm you can implement in a HLL you can implement in assembly. On the other hand, there are many algorithms you can implement in assembly which you cannot implement in a HLL.
Assembly language is not portable. This is an undeniable fact. An 80x86 assembly language program written for an IBM PC will not run on an Apple Macintosh. Indeed, assembly language programs written for the Apple Macintosh will not run on an Amiga, even though they share the same 680x0 microprocessor. If you need to run your program on different machines, you'll have to think long and hard about using assembly language. Using C (or some other HLL) is no guarantee that your program will be portable. C programs written for the IBM PC won't compile and run on a Macintosh. And even if they did, most Mac owners wouldn't accept the result.
Portability is probably the biggest complaint people have against assembly language. They refuse to use assembly because it is not portable, and then they turn around and write equally non-portable programs in C.
Yes, there are lots of lies, misconceptions, myths, and half-truths concerning assembly language. Whatever you do, make sure you learn assembly language before forming your own opinions. Speaking out in ignorance may impress others who know less than you do, but it won't impress those who know the truth.
2 What's Right With Assembly Language?
An old joke goes something like this: "There are three reasons for using assembly language: speed,
speed, and more speed." Even those who absolutely hate assembly language will admit that if
speed is your primary concern, assembly language is the way to go. Assembly language has several benefits:
（1）Speed. Assembly language programs are generally the fastest programs around.
（2）Space. Assembly language programs are often the smallest.
（3）Capability. You can do things in assembly which are difficult or impossible in HLLs.
（4）Knowledge. Your knowledge of assembly language will help you write better programs, even when using HLLs.
Assembly language is the uncontested speed champion among programming languages. An expert
assembly language programmer will almost always produce a faster program than an expert C programmer. While certain programs may not benefit much from implementation in assembly, you can speed up many programs by a factor of five or ten over their HLL counterparts by careful coding in assembly language; even greater improvement is possible if you're not using an
optimizing compiler. Alas, speedups on the order of five to ten times are generally not achieved by beginning assembly language programmers. However, if you spend the time to learn assembly language really well, you too can achieve these impressive performance gains. Despite some people's claims that programmers no longer have to worry about memory
constraints, there are many programmers who need to write smaller programs. Assembly language programs are often less than one-half the size of comparable HLL programs. This is especially impressive when you consider the fact that data items generally consume the same amount of space in both types of programs, and that data is responsible for a good amount of the space used by a typical application. Saving space saves money. Pure and simple. If a program requires 1.5 megabytes, it will not fit on a 1.44 Mbyte floppy. Likewise, if an application requires 2 megabytes RAM, the user will have to install an extra megabyte if there is only one available in the machine. Even on big machines with 32 or more megabytes, writing gigantic applications isn't excusable. Most users put more than eight megabytes in their machines so they can run multiple programs from memory at one time. The bigger a program is, the fewer applications will be able to coexist in memory with it. Virtual memory isn't a particularly attractive solution either. With virtual memory, the bigger an application is, the slower the system will run as a result of that program's size.
Capability is another reason people resort to assembly language. HLLs are an abstraction of a typical machine architecture. They are designed to be independent of the particular machine architecture. As a result, they rarely take into account any special features of the machine, features
which are available to assembly language programmers. If you want to use such features, you will need to use assembly language. A really good example is the input/output instructions available on the 80x86 microprocessors. These instructions let you directly access certain I/O devices on the computer. In general, such access is not part of any high level language. Indeed, some languages like C pride themselves on not supporting any specific I/O operations. In assembly language you have no such restrictions. Anything you can do on the machine you can do in assembly language. This is definitely not the case with most HLLs.
Of course, another reason for learning assembly language is just for the knowledge. Now some of you may be thinking, "Gee, that would be wonderful, but I've got lots to do. My time would be better spent writing code than learning assembly language." There are some practical reasons for
learning assembly, even if you never intend to write a single line of assembly code. If you know assembly language well, you'll have an appreciation for the compiler, and you'll know exactly what the compiler is doing with all those HLL statements. Once you see how compilers translate seemingly innocuous statements into a ton of machine code, you'll want to search for better ways to accomplish the same thing. Good assembly language programmers make better HLL programmers because they understand the limitations of the compiler and they know what it's
doing with their code. Those who don't know assembly language will accept the poor performance their compiler produces and simply shrug it off.
Yes, assembly language is definitely worth the effort. The only scary thing is that once you learn it really well, you'll probably start using it far more than you ever dreamed you would. That is a common malady among assembly language programmers. Seems they can't stand what the compilers are doing with their programs.
译文
汇编语言的艺术
1.汇编语言的不足之处是什么？
2.汇编语言的优势是什么？
1.汇编语言的不足是什么
汇编语言现在的名声很不好，人们对汇编程序员普遍的印象是：他们不是黑客就是一些受到错误思想指引的，需要别人开导的人。下面是人们所给出的若干条不使用汇编语言的理由：
（1）汇编语言学起来很困难；
（2）阅读和理解汇编程序很困难；
（3）调试汇编程序很困难；
（4）汇编程序难维护；
（5）编写汇编程序很困难；
（6）编写汇编程序很耗费时间；
（7）日益改进的编译技术使得汇编语言已不再重要；
（8）目前计算机的运行速度已经足够快了，再去使用汇编语言已显得多余；
（9）如果你想要追求更快的计算机运行速度，你应该去使用一个更高效的算法而不是转向去借助于汇编语言；
（10）目前计算机的内存容量已经足够大了，通过使用汇编语言来达到节省内存的这种做法已不再可取；
（11）汇编语言依赖于具体的机器硬件环境，不具备良好的移植性。
假如这是一本为具有大学水平的读者编写的汇编程序设计的教材，并且看上去该书作者的写作意图明确，因此作为一名读者，你会自然而然地去相信书中所写的内容，读者们，当你们读到这里的时候，你们肯定会开始去猜测到汇编语言一定有许多不尽如人意的地方了。确实，汇编语言80%的不足之处就在于人们根据从他们的朋友，老师或者一些与汇编语言有关的文章或书籍中所获得的信息对汇编语言形成了一些错误的看法。诚然，汇编语言确实存在着许多的不足之处，但是，这些不足在那些对汇编语言的错误认识影响下被严重夸大了。究竟有多少人愿意根据他们对汇编语言的了解或者所读过的有关汇编语言的文章来发表对汇编语言的看法是令人想知道的。
汇编语言的使用者也使用一些高级语言，而那些对汇编语言的反对者却很少使用汇编语言。那么，谁又会相信，一个精通多种编程语言但却没有花时间去学习汇编语言的人能够形成对汇编语言如实、客观的评价呢？
当我和别人交谈时，我会尽可能的表达出我的以上观点，在本章的前言中，我准备花十页纸去逐个解释前面列出的每一种观点，
展开阅读全文
浙ICP备2021020529号-1 | 浙B2-20240490 
