|
Chapter One (Part 1)
|
|
Chapter One (Part 1)
|
| Copyright 1996 by Randall Hyde
All rights reserved. Duplication other than for immediate display through a browser is prohibited by U.S. Copyright Law. This material is provided on-line as a beta-test of this text. It is for the personal use of the reader only. If you are interested in using this material as part of a course, please contact rhyde@cs.ucr.edu Supporting software and other materials are available via anonymous ftp from cs.ucr.edu. See the "/pub/pc/ibmpc" directory for details. Notes: This document was prepared by cutting and pasting data from Framemaker 4 into PageMill or by using Quadralay's Webworks Publisher (this is not an endorsement, btw). Since HTML does not support the rich formatting options available in Framemaker, this document is only an approximation of the actual chapter from the textbook. This document does not contain the laboratory exercises, programming assignments, exercises, or chapter summary. These portions were omitted for several reasons: either they wouldn't format properly, they contained hyperlinks that were too much work to resolve, they were under constant revision, or they were not included for security reasons. Such omission should have very little impact on the reader interested in learning this material or evaluating this document. A reasonable attempt was made to eliminate cross references to figures and page numbers. Some, however, may still exist in this document. Comments, bug reports, ratings, etc., should be reported to the above email address. |
| Amazing! 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, someone 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 assembly language. Egads. What kind of book begins this way? What kind of author would begin the book with a forward like this one? Well, the truth is, I considered putting this stuff into the first chapter since most people never bother reading the forward. A discussion of what's right and what's wrong with assembly language is very important and sticking it into a chapter might encourage someone 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? Well, there are several reasons which come to mind:
Well, whatever the reason you're here, welcome aboard. Let's take a look at the subject you're about to study. |
| 1. WHAT'S WRONG WITH ASSEMBLY LANGUAGE | Top |
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! |
| 2. WHAT'S RIGHT WITH ASSEMBLY LANGUAGE | Top |
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:
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.
| 3. ORGANIZATION OF THIS TEXT AND PEDAGOGICAL CONCERNS | Top |
This book is divided into seven main sections: a section on
machine organization and architecture, a section on basic assembly language, a section on
intermediate assembly language, a section on interrupts and resident programs, a section
covering IBM PC hardware peculiarities, a section on optimization, and various appendices.
It is doubtful that any single (even year-long) college course could cover all this
material, the final chapters were included to support compiler design, microcomputer
design, operating systems, 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 different ideas about how this course should be taught. Furthermore,
different schools spend differing amounts of time on this subject (one or two quarters, a
semester, or even a year). Furthermore, different schools cover different material in the
course. For example, some schools teach a "Machine Organization" course that
emphasizes hardware concepts and presents the assembly language instruction set, but does
not expect students to write real assembly language programs (that's the job of a
compiler). Other schools teach a "Machine Organization and Assembly Language"
course that combines hardware and software issues together into one course. Still others
teach a "Machine Organization" or "Digital Logic" course as a
prerequisite to an "Assembly Language" course. Still others teach "Assembly
Language Programming" as a course and leave the hardware for a "Computer
Architecture" course later in the curriculum. Finally, let us not forget that some
people will pick up this text and use it to learn machine organization or assembly
language programming on their own, without taking a formal course on the subject. A good textbook
in this subject area must be adaptable to the needs of the course, instructor, and
student. These requirements place enough demands on an author, but I wanted more 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 shame that many textbooks' value diminishes once the course is complete. I
sought to create a textbook that will explain many difficult concepts in as friendly a
manner as possible and will serve as a reference guide once you've mastered the
topic. By moving advanced material you probably won't cover in a typical college course
into later chapters and by organizing 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 volume attempts to satisfy the requirements of several different courses, as
well as provide an excellent reference, you will probably find that it contains far more
material than any single course would actually cover. For example, the first section of
this text covers machine organization. If you've already covered this material in a
previous course, your instructor may elect to skip the first four chapters or so. For
those courses that teach only assembly language, the instructor may decide to skip
chapters two and three. Schools operating on a ten-week quarter system may cover the
material in each chapter only briefly (about one week per chapter). Other schools may
cover the material in much greater depth because they have more time.
When writing this text, I choose to pick a subject and cover it in depth before proceeding
to the next topic. This pedagogy (teaching method) is unusual. Most assembly language
texts jump around to different topics, lightly touching on each one and returning to them
as further explanation is necessary. Unfortunately, such texts make poor references;
trying to lookup information in such a book is difficult, at best, because the information
is spread throughout the book. Since I want this text to serve as a reasonable reference
manual, such an organization was unappealing.
The problem with a straight reference manual is three-fold. First, reference manuals are
often organized in a manner that makes it easy to look something up, not in a logical
order that makes the material easy to learn. For example, most assembly language reference
manuals introduce the instruction set in alphabetical order. However, you do not learn the
instruction set in this manner. The second problem with a (good) reference manual is that
it presents the material in far greater depth than most beginners can handle; this is why
most texts keep returning to a subject, they add a little more depth on each return to the
subject. Finally, reference texts can present material in any order. The author need not
ensure that a discussion only include material appearing earlier in the text. Material in
the early chapters of a reference manual can refer to later chapters; a typical college
textbook should not do this.
To receive maximum benefit from this text, you need to read it understanding its
organization. This is not a text you read from front to back, making sure you
understand each and every little detail before proceeding to the next. I've covered many
topics in this text in considerable detail. Someone learning assembly language for the
first time will become overwhelmed with the material that appears in each chapter.
Typically, you will read over a chapter once to learn the basic essentials and then refer
back to each chapter learning additional material as you need it. Since it is unlikely
that you will know which material is basic or advanced, I've taken the liberty of
describing which sections are basic, intermediate, or advanced at the beginning of each
chapter. A ten-week course, covering this entire text for example, might only deal with
the basic topics. In a semester course, there is time to cover the intermediate material
as well. Depending on prerequisites and length of course, the instructor can elect to
teach this material at any level of detail (or even jump around in the text).
In the past, if a student left an assembly language class and could actually implement an
algorithm in assembly language, the instructor probably considered the course a success.
However, compiler technology has progressed to the point that simply "getting
something to work" in assembly language is pure folly. If you don't write your code
efficiently in assembly language, you may as well stick with HLLs. They're easy to use,
and the compiler will probably generate faster code than you if you're careless in the
coding process.
This text spends a great deal of time on machine and data organization. There are two
important reasons for this. First of all, to write efficient code on modern day processors
requires an intimate knowledge of what's going on in the hardware. Without this knowledge,
your programs on the 80486 and later could run at less than half their possible speed. To
write the best possible assembly language programs you must be familiar with how the
hardware operates. Another reason this text emphasizes computer organization is that most
colleges and universities are more interested in teaching machine organization than they
are a particular assembly language. While the typical college student won't have much need
for assembly language during the four years as an undergraduate, the machine organization
portion of the class is useful in several upper division classes. Classes like data
structures and algorithms, computer architecture, operating systems, programming language
design, and compilers all benefit from an introductory course in computer organization.
That's why this text devotes an entire section to that subject.
| 4. OBTAINING PROGRAMM SOURCE LISTINGS AND OTHER MATERIALS IN THIS TEXT | Top |
All of the software appearing in this text is available on
the companion diskette. The material for this text comes in two parts: source listings of
various examples presented in this text and the code for the UCR Standard Library for
80x86 Assembly Language Programmers. The UCR Standard Library is also available
electronically from several different sources (including Internet, BIX, and other on-line
services).
You may obtain the files electronically via ftp from the following Internet address:
ftp.cs.ucr.edu
Log onto ftp.cs.ucr.edu using the anonymous account name and any password. Switch to the
"/pub/pc/ibmpcdir" subdirectory (this is UNIX so make sure you use lowercase
letters). You will find the appropriate files by searching through this directory.
The exact filename(s) of this material may change with time, and different services use
different names for these files. Generally posting a message enquiring about the UCR
Standard Library or this text will generate appropriate responses.
back to Table of Content |
Chapter One (Part 1) |
This file last updated on 21/10/2000 at 16:46:01.
