【正文】 ge programs, it39。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 you39。ll have problems debugging programs in that language until you gain experience. 3 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 isn39。t a talent. It39。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 pletely from scratch, often reinventing the wheel. HLL programmers, especially C, Ada, and Modula2 programmers, have long enjoyed the benefits of a standard library package which solves many mon 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 Inter and various other munication services as well as on a panion 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 pletion 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 piler technology has eliminated the need for assembly language. This isn39。t true and probably never will be true. Optimizing pilers 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 piler would produce equivalent, or even better, code. Those who make this claim about piler technology are paring their handpiled code against that produced by a piler. Compilers do a much better job of piling than humans. Then again, you39。ll never catch an assembly language programmer writing C code with MOV instructions. After all, that39。s why you use C 4 pilers. 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 won39。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 can39。t you use this better algorithm in assembly language? What if you39。re already using the best algorithm you can find and it39。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 no