Published on February 2017 | Categories: Documents | Downloads: 72 | Comments: 0 | Views: 604
of 8
Download PDF   Embed   Report



Page 1

Why Would Anyone Learn This Stuff? Forward

Am azing! You’re actually reading this. That puts you into one of three categories: a student who is
being forced to read this stuff for a class, som eone who picked up this book by accident (probably
because you have yet to be indoctrinated by the world at large), or one of the few who actually have an
interest in learning assem bly language.
Egads. W hat kind of book begins this way? W hat kind of author would begin the book with a forward
like this one? W ell, the truth is,


considered putting this stuff into the first chapter since m ost people never
bother reading the forward. A discussion of what’s right and what’s wrong with assem bly language is very
im portant and sticking it into a chapter m ight encourage som eone to read it. However, I quickly found
that university students can skip Chapter One as easily as they can skip a forward, so this stuff wound up
in a forward after all.
So why would anyone learn this stuff, anyway? W ell, there are several reasons which com e to m ind:
• Your m ajor requires a course in assem bly language; i.e., you’re here against your will.
• A program m er where you work quit. Most of the source code left behind was written
in assem bly language and you were elected to m aintain it.
• Your boss has the audacity to insist that you write your code in assem bly against your
strongest wishes.
• Your program s run just a little too slow, or are a little too large and you think assem bly
language m ight help you get your project under control.
• You want to understand how com puters actually work.
• You’re interested in learning how to write efficient code.
• You want to try som ething new.
W ell, whatever the reason you’re here, welcom e aboard. Let’s take a look at the subject you’re about
to study.

1 What’s Wrong With Assembly Language

Assem bly language has a pretty bad reputation. The com m on im pression about assem bly language
program m ers today is that they are all hackers or m isguided individuals who need enlightenm ent. Here
are the reasons people give for


using assem bly


• Assem bly is hard to learn.
• Assem bly is hard to read and understand.
• Assem bly is hard to debug.
• Assem bly is hard to m aintain.
• Assem bly is hard to write.
• Assem bly language program m ing is tim e consum ing.
• Im proved com piler technology has elim inated the need for assem bly language.
• Today, m achines are so fast that we no longer need to use assem bly.
• If you need m ore speed, you should use a better algorithm rather than switch to assem -
bly language.
• Machines have so m uch m em ory today, saving space using assem bly is not im portant.
• Assem bly language is not portable.

1. This text will use the term s “Assem bly language”and “assem bly”interchangeably.

Thi d t t d ith F M k 4 0 2

Page 2

These are som e strong statem ents indeed!
Given that this is a book which teaches assem bly language program m ing, written for college level
students, written by som eone who appears to know what he’s talking about, your natural tendency is to
believe som ething if it appears in print. Having just read the above, you’re starting to assum e that assem bly
m ust be pretty bad. And that, dear friend, is eighty percent of what’s wrong with assem bly language. That
is, people develop som e very strong m isconceptions about assem bly language based on what they’ve
heard from friends, instructors, articles, and books. Oh, assem bly language is certainly not perfect. It does
have m any real faults. Those faults, however, are blown com pletely out of proportion by those unfam iliar
with assem bly language. The next tim e som eone starts preaching about the evils of assem bly language,
ask, “how m any years of assem bly language program m ing experience do you have?”Of course assem bly
is hard to understand

if you don’t knowit.

It is surprising how m any people are willing to speak out
against assem bly language based only on conversations they’ve had or articles they’ve read.
Assem bly language users also use high level languages (HLLs); assem bly’s m ost outspoken oppo-
nents rarely use anything but HLLs. W ho would you believe, an expert well versed in both types of pro-
gram m ing languages or som eone who has never taken the tim e to learn assem bly language and develop
an honest opinion of its capabilities?
In a conversation with som eone, 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 statem ents. 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 statem ents.

Assembly is hard to learn.

So is any language you don’t already know. Try learning (really learn-
ing) APL, Prolog, or Sm alltalk som etim e. Once you learn Pascal, learning another language like C, BASIC,
FORTRAN, Modula-2, or Ada is fairly easy because these languages are quite sim ilar to Pascal. On the
other hand, learning a dissim ilar language like Prolog is not so sim ple. Assem bly 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 assem bly isn’t m uch m ore difficult than learning your first program m ing language.

Assembly is hard to read and understand.

It sure is, if you don’t know it. Most people who m ake
this statem ent sim ply don’t know assem bly. Of course, it’s very easy to write im possible-to-read assem bly
language program s. It’s also quite easy to write im possible-to-read C, Prolog, and APL program s. W ith
experience, you will find assem bly as easy to read as other languages.

Assembly is hard to debug.

Sam e argum ent as above. If you don’t have m uch experience debug-
ging assem bly language program s, it’s going to be hard to debug them . Rem em ber what it was like finding
bugs in your first Pascal (or other HLL) program s? Anytim e you learn a new program m ing language you’ll
have problem s debugging program s in that language until you gain experience.

Assembly is hard to maintain.

C program s are hard to m aintain. Indeed,


are hard to
m aintain period. Inexperienced assem bly language program m ers tend to write hard to m aintain program s.
W riting m aintainable program s isn’t a talent. It’s a skill you develop through experience.

Assembly language is hard.

This statem ent actually has a ring of truth to it. For the longest tim e
assem bly language program m ers wrote their program s com pletely from scratch, often “re-inventing the
wheel.”HLL program m ers, especially C, Ada, and Modula-2 program m ers, have long enjoyed the benefits
of a

standard library

package which solves m any com m on program m ing problem s. Assem bly language
program m ers, on the other hand, have been known to rewrite an integer output routine every tim e they
need one. This book does


take that approach. Instead, it takes advantage of som e work done at the
University of California, Riverside: the

UCRStandard Library for 80x86 Assembly LanguageProgrammers.

These subroutines sim plify assem bly language just as the C standard library aids C program m ers. The
library source listings are available electronically via Internet and various other com m unication services as
well as on a com panion diskette.

Assembly language programmingis time consuming.

Software engineers estim ate that devel-
opers spend only about thirty percent of their tim e coding a solution to a problem . Even if it took twice as

Why Would Anyone Learn This Stuff?
Page 3

m uch tim e to write a program in assem bly versus som e HLL, there would only be a fifteen percent differ-
ence in the total project com pletion tim e. In fact,


assem bly language program m ers do not need twice
as m uch tim e to im plem ent som ething in assem bly language. It is true using a HLL will save


tim e;
however, the savings is insufficient to counter the benefits of using assem bly language.

Improved compiler technology has eliminated the need for assembly language.

This isn’t
true and probably never will be true. Optim izing com pilers are getting better every day. However, assem -
bly language program m ers get better perform ance by writing their code


than they would if they
were using som e HLL. If assem bly language program m ers wrote their program s in C and then translated
them m anually into assem bly, a good C com piler would produce equivalent, or even better, code. Those
who m ake this claim about com piler technology are com paring their


com piled code against that
produced by a com piler. Com pilers do a m uch better job of com piling than hum ans. Then again, you’ll
never catch an assem bly language program m er writing “C code with MOV instructions.”After all, that’s
why you use C com pilers.

Today, machines are so fast that we no longer need to use assembly.

It is am azing that people
will spend lots of m oney to buy a m achine slightly faster than the one they own, but they won’t spend any
extra tim e writing their code in assem bly so it runs faster on the sam e hardware. There are m any raging
debates about the speed of m achines versus the speed of the software, but one fact rem ains: users always
want m ore speed. On any given m achine, the fastest possible program s will be written in assem bly lan-



If you need more speed, you should use a better algorithmrather than switch to assembly

W hy can’t you use this better algorithm in assem bly language? W hat if you’re already using the
best algorithm you can find and it’s still too slow? This is a totally bogus argum ent against assem bly lan-
guage. Any algorithm you can im plem ent in a HLL you can im plem ent in assem bly. On the other hand,
there are m any algorithm s you can im plem ent in assem bly which you cannot im plem ent in a HLL



Machines have so much memory today, savingspace usingassembly is not important.

you give som eone an inch, they’ll take a m ile. Nowhere in program m ing does this saying have m ore appli-
cation than in program m em ory use. For the longest tim e, program m ers were quite happy with 4 Kbytes.
Later, m achines had 32 or even 64 Kilobytes. The program s filled up m em ory accordingly. Today, m any
m achines have 32 or 64


of m em ory installed and som e applications use it all. There are lots of
technical reasons why program m ers should strive to write shorter program s, though now is not the tim e to
go into that. Let’s just say that space


im portant and program m ers should strive to write program s as short
as possible regardless of how m uch m ain m em ory they have in their m achine.

Assembly language is not portable.

This is an undeniable fact. An 80x86 assem bly language pro-
gram written for an IBM PC will not run on an Apple Macintosh


. Indeed, assem bly language program s
written for the Apple Macintosh will not run on an Am iga, even though they share the sam e 680x0 m icro-
processor. If you need to run your program on different m achines, you’ll have to think long and hard
about using assem bly language. Using C (or som e other HLL) is no guarantee that your program will be
portable. C program s written for the IBM PC won’t com pile and run on a Macintosh. And even if they did,
m ost Mac owners wouldn’t accept the result.
Portability is probably the biggest com plaint people have against assem bly language. They refuse to
use assem bly because it is not portable, and then they turn around and write equally non-portable pro-
gram s in C.
Yes, there are lots of lies, m isconceptions, m yths, and half-truths concerning assem bly language.
W hatever you do, m ake sure you learn assem bly language before form ing your own opinions


. Speaking

2. That is not to im ply that assem bly language program s are always faster than HLL program s. A poorly written assem bly language program can run
m uch slower than an equivalent HLL program . On the other hand, if a program is written in an HLL it is certainly possible to write a faster one in
assem bly.
3. W e’ll see som e of these algorithm s later in the book. They deal with instruction sequencing and other tricks based on how the processor oper-
4. Strictly speaking, this is not true. There is a program called SoftPC which em ulates an IBM PC using an 80286


. However, 80x86 assem -
bly language program s will not run in native m ode on the Mac’s 680x0 m icroprocessor.

Page 4

out in ignorance m ay im press others who know less than you do, but it won’t im press those who know
the truth.

2 What’s Right With Assembly Language?

An old joke goes som ething like this: “There are three reasons for using assem bly language: speed,
speed, and m ore speed.”Even those who absolutely hate assem bly language will adm it that if speed is
your prim ary concern, assem bly language is the way to go. Assem bly language has several benefits:
• Speed. Assem bly language program s are generally the fastest program s around.
• Space. Assem bly language program s are often the sm allest.
• Capability. You can do things in assem bly which are difficult or im possible in HLLs.
• Knowledge. Your knowledge of assem bly language will help you write better pro-
gram s, even when using HLLs.
Assem bly language is the uncontested speed cham pion am ong program m ing languages. An expert
assem bly language program m er will alm ost always produce a faster program than an expert C program -
m er


. W hile certain program s m ay not benefit m uch from im plem entation in assem bly, you can speed up
m any program s by a factor of five or ten over their HLL counterparts by careful coding in assem bly lan-
guage; even greater im provem ent is possible if you’re not using an optim izing com piler. Alas, speedups
on the order of five to ten tim es are generally not achieved by beginning assem bly language program m ers.
However, if you spend the tim e to learn assem bly language really well, you too can achieve these im pres-
sive perform ance gains.
Despite som e people’s claim s that program m ers no longer have to worry about m em ory constraints,
there are m any program m ers who need to write sm aller program s. Assem bly language program s are often
less than one-half the size of com parable HLL program s. This is especially im pressive when you consider
the fact that data item s generally consum e the sam e am ount of space in both types of program s, and that
data is responsible for a good am ount of the space used by a typical application. Saving space saves
m oney. Pure and sim ple. If a program requires 1.5 m egabytes, it will not fit on a 1.44 Mbyte floppy. Like-
wise, if an application requires 2 m egabytes RAM, the user will have to install an extra m egabyte if there is
only one available in the m achine


. Even on big m achines with 32 or m ore m egabytes, writing gigantic
applications isn’t excusable. Most users put m ore than eight m egabytes in their m achines so they can run


program s from m em ory at one tim e. The bigger a program is, the fewer applications will be able
to coexist in m em ory with it. Virtual m em ory isn’t a particularly attractive solution either. W ith virtual
m em ory, 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 assem bly language. HLLs are an abstraction of a typical
m achine architecture. They are designed to be independent of the particular m achine architecture. As a
result, they rarely take into account any special features of the m achine, features which are available to
assem bly language program m ers. If you want to use such features, you will need to use assem bly lan-
guage. A really good exam ple is the input/output instructions available on the 80x86 m icroprocessors.
These instructions let you directly access certain I/O devices on the com puter. In general, such access is
not part of any high level language. Indeed, som e languages like C pride them selves on not supporting

5. Alas, a typical ten-week course is rarely sufficient to learn assem bly language well enough to develop an inform ed opinion on the subject. Prob-
ably three m onths of eight-hour days using the stuff would elevate you to the point where you could begin to m ake som e inform ed statem ents on
the subject. Most people wouldn’t be able to consider them selves “good”at assem bly language program s until they’ve been using the stuff for at
least a year.
6. There is absolutely no reason why an assem bly language program m er would produce a


program since that program m er could look at the
output of the C com piler and copy whatever code runs faster than the hand produced code. HLL program m ers don’t have an equivalent option.
7. You can substitute any num bers here you like. One fact rem ains though, program m ers are fam ous for assum ing users have m ore m em ory than
they really do.

Why Would Anyone Learn This Stuff?
Page 5

any specific I/O operations


. In assem bly language you have no such restrictions. Anything you can do on
the m achine you can do in assem bly language. This is definitely


the case with m ost HLLs.
Of course, another reason for learning assem bly language is just for the knowledge. Now som e of
you m ay be thinking, “Gee, that would be wonderful, but I’ve got lots to do. My tim e would be better
spent writing code than learning assem bly language.”There are som e practical reasons for learning assem -
bly, even if you never intend to write a single line of assem bly code. If you know assem bly language well,
you’ll have an appreciation for the com piler, and you’ll know exactly what the com piler is doing with all
those HLL statem ents. Once you see how com pilers translate seem ingly innocuous statem ents into a ton of
m achine code, you’ll want to search for better ways to accom plish the sam e thing. Good assem bly lan-
guage program m ers m ake better HLL program m ers because they understand the lim itations of the com -
piler and they know what it’s doing with their code. Those who don’t know assem bly language will accept
the poor perform ance their com piler produces and sim ply shrug it off.
Yes, assem bly 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 m ore than you ever dream ed you would. That is a com m on
m alady am ong assem bly language program m ers. Seem s they can’t stand what the com pilers are doing
with their program s.

3 Organization of This Text and Pedagogical Concerns

This book is divided into seven m ain sections: a section on m achine organization and architecture, a
section on basic assem bly language, a section on interm ediate assem bly language, a section on interrupts
and resident program s, a section covering IBM PC hardware peculiarities, a section on optim ization, and
various appendices. It is doubtful that any single (even year-long) college course could cover all this m ate-
rial, the final chapters were included to support com piler design, m icrocom puter design, operating sys-
tem s, and other courses often found in a typical CS program .
Developing a text such as this one is a very difficult task. First of all, different universities have differ-
ent ideas about how this course should be taught. Furtherm ore, different schools spend differing am ounts
of tim e on this subject (one or two quarters, a sem ester, or even a year). Furtherm ore, different schools
cover different m aterial in the course. For exam ple, som e schools teach a “Machine Organization”course
that em phasizes hardware concepts and presents the assem bly language instruction set, but does not
expect students to write real assem bly language program s (that’s the job of a com piler). Other schools
teach a “Machine Organization and Assem bly Language”course that com bines hardware and software
issues together into one course. Still others teach a “Machine Organization”or “Digital Logic”course as a
prerequisite to an “Assem bly Language”course. Still others teach “Assem bly Language Program m ing”as a
course and leave the hardware for a “Com puter Architecture”course later in the curriculum . Finally, let us
not forget that som e people will pick up this text and use it to learn m achine organization or assem bly lan-
guage program m ing on their own, without taking a form al course on the subject. A good


in this
subject area m ust be adaptable to the needs of the course, instructor, and student. These requirem ents
place enough dem ands on an author, but I wanted m ore for this text. Many textbooks teach a particular
subject well, but once you’ve read and understood them , they do not serve well as a reference guide.
Given the cost of textbooks today, it is a real sham e that m any textbooks’value dim inishes once the
course is com plete. I sought to create a textbook that will explain m any difficult concepts in as friendly a
m anner as possible


will serve as a reference guide once you’ve m astered the topic. By m oving
advanced m aterial you probably won’t cover in a typical college course into later chapters and by organiz-
ing this text so you can continue using it once the course is over, I hope to provide you with an excellent
value in this text.
Since this volum e attem pts to satisfy the requirem ents of several different courses, as well as provide
an excellent reference, you will probably find that it contains far m ore m aterial than any single course

8. Certain languages on the PC support extensions to access the I/O devices since this is such an obvious lim itation of the language. However, such
extensions are not part of the actual language.

Page 6

would actually cover. For exam ple, the first section of this text covers m achine organization. If you’ve
already covered this m aterial in a previous course, your instructor m ay elect to skip the first four chapters
or so. For those courses that teach only assem bly language, the instructor m ay decide to skip chapters two
and three. Schools operating on a ten-week quarter system m ay cover the m aterial in each chapter only
briefly (about one week per chapter). Other schools m ay cover the m aterial in m uch greater depth
because they have m ore tim e.
W hen writing this text, I choose to pick a subject and cover it in depth before proceeding to the next
topic. This pedagogy (teaching m ethod) is unusual. Most assem bly language texts jum p around to differ-
ent topics, lightly touching on each one and returning to them as further explanation is necessary. Unfor-
tunately, such texts m ake poor references; trying to lookup inform ation in such a book is difficult, at best,
because the inform ation is spread throughout the book. Since I want this text to serve as a reasonable ref-
erence m anual, such an organization was unappealing.
The problem with a straight reference m anual is three-fold. First, reference m anuals are often orga-
nized in a m anner that m akes it easy to look som ething up, not in a logical order that m akes the m aterial
easy to learn. For exam ple, m ost assem bly language reference m anuals introduce the instruction set in
alphabetical order. However, you do not learn the instruction set in this m anner. The second problem with
a (good) reference m anual is that it presents the m aterial in far greater depth than m ost beginners can han-
dle; this is why m ost texts keep returning to a subject, they add a little m ore depth on each return to the
subject. Finally, reference texts can present m aterial in any order. The author need not ensure that a dis-
cussion only include m aterial appearing earlier in the text. Material in the early chapters of a reference
m anual can refer to later chapters; a typical college textbook should


do this.
To receive m axim um benefit from this text, you need to read it understanding its organization. This is


a text you read from front to back, m aking sure you understand each and every little detail before pro-
ceeding to the next. I’ve covered m any topics in this text in considerable detail. Som eone learning assem -
bly language for the first tim e will becom e overwhelm ed with the m aterial that appears in each chapter.
Typically, you will read over a chapter once to learn the basic essentials and then refer back to each chap-
ter learning additional m aterial as you need it. Since it is unlikely that you will know which m aterial is
basic or advanced, I’ve taken the liberty of describing which sections are basic, interm ediate, or advanced
at the beginning of each chapter. A ten-week course, covering this entire text for exam ple, m ight only deal
with the basic topics. In a sem ester course, there is tim e to cover the interm ediate m aterial as well.
Depending on prerequisites and length of course, the instructor can elect to teach this m aterial at any level
of detail (or even jum p around in the text).
In the past, if a student left an assem bly language class and could actually im plem ent an algorithm in
assem bly language, the instructor probably considered the course a success. However, com piler technol-
ogy has progressed to the point that sim ply “getting som ething to work”in assem bly language is pure
folly. If you don’t write your code efficiently in assem bly language, you m ay as well stick with HLLs.
They’re easy to use, and the com piler will probably generate faster code than you if you’re careless in the
coding process.
This text spends a great deal of tim e on m achine and data organization. There are two im portant rea-
sons for this. First of all, to write efficient code on m odern day processors requires an intim ate knowledge
of what’s going on in the hardware. W ithout this knowledge, your program s on the 80486 and later could
run at less than half their possible speed. To write the best possible assem bly language program s you m ust
be fam iliar with how the hardware operates. Another reason this text em phasizes com puter organization is
that m ost colleges and universities are m ore interested in teaching m achine organization than they are a
particular assem bly language. W hile the typical college student won’t have m uch need for assem bly lan-
guage during the four years as an undergraduate, the m achine organization portion of the class is useful in
several upper division classes. Classes like data structures and algorithm s, com puter architecture, operat-
ing system s, program m ing language design, and com pilers all benefit from an introductory course in com -
puter organization. That’s why this text devotes an entire section to that subject.

Why Would Anyone Learn This Stuff?
Page 7

4 Obtaining Program Source Listings and Other Materials in This Text

All of the software appearing in this text is available on the com panion diskette. The m aterial for this
text com es in two parts: source listings of various exam ples presented in this text and the code for the

Standard Library for 80x86 Assembly LanguageProgrammers

. The UCR Standard Library is also available
electronically from several different sources (including Internet, BIX, and other on-line services).
You m ay obtain the files electronically via ftp from the following Internet address:
Log onto using the anonym ous account nam e and any password. Switch to the “/pub/pc/
ibm pcdir”subdirectory (this is UNIX so m ake sure you use lowercase letters). You will find the appropri-
ate files by searching through this directory.
The exact filenam e(s) of this m aterial m ay change with tim e, and different services use different
nam es for these files. Generally posting a m essage enquiring about the UCR Standard Library or this text
will generate appropriate responses.

Page 8

Sponsor Documents

Or use your account on


Forgot your password?

Or register your new account on


Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in