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:
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 oppo-nents
rarely use anything but HLLs. Who would you believe, an expert well versed in both types of pro-gramming
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 learn-ing)
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 dif-ferent
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 debug-ging
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 devel-opers
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 differ-ence
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, assem-bly
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 lan-guage.
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
Machines have so much memory today, saving space using assembly is not important. If
you give someone an inch, they'll take a mile. Nowhere in programming does this saying have more appli-cation
than in program memory use. For the longest time, programmers were quite happy with 4 Kbytes.
Later, machines had 32 or even 64 Kilobytes. The programs filled up memory accordingly. Today, many
machines have 32 or 64 megabytes of memory installed and some applications use it all. There are lots of
technical reasons why programmers should strive to write shorter programs, though now is not the time to
go into that. Let's just say that space is important and programmers should strive to write programs as short
as possible regardless of how much main memory they have in their machine.
Assembly language is not portable. This is an undeniable fact. An 80x86 assembly language pro-gram
written for an IBM PC will not run on an Apple Macintosh 4 . Indeed, assembly language programs
written for the Apple Macintosh will not run on an Amiga, even though they share the same 680x0 micro-processor.
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 pro-grams
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.
Back to EAS home