109 lines
No EOL
6.9 KiB
Markdown
109 lines
No EOL
6.9 KiB
Markdown
### The Flexible Mind {#Heading8}
|
|
|
|
Is the never-ending collection of information all there is to the
|
|
assembly optimization, then? Hardly. Knowledge is simply a necessary
|
|
base on which to build. Let's take a moment to examine the objectives of
|
|
good assembly programming, and the remainder of the forces that act on
|
|
assembly optimization will fall into place.
|
|
|
|
Basically, there are only two possible objectives to high-performance
|
|
assembly programming: Given the requirements of the application, keep to
|
|
a minimum either the number of processor cycles the program takes to
|
|
run, or the number of bytes in the program, or some combination of both.
|
|
We'll look at ways to achieve both objectives, but we'll more often be
|
|
concerned with saving cycles than saving bytes, for the PC generally
|
|
offers relatively more memory than it does processing horsepower. In
|
|
fact, we'll find that two-to-three times performance improvements *over
|
|
already tight assembly code* are often possible if we're willing to
|
|
spend additional bytes in order to save cycles. It's not always
|
|
desirable to use such techniques to speed up code, due to the heavy
|
|
memory requirements—but it is almost always *possible*.
|
|
|
|
You will notice that my short list of objectives for high-performance
|
|
assembly programming does not include traditional objectives such as
|
|
easy maintenance and speed of development. Those are indeed important
|
|
considerations—to persons and companies that develop and distribute
|
|
software. People who actually *buy* software, on the other hand, care
|
|
only about how well that software performs, not how it was developed nor
|
|
how it is maintained. These days, developers spend so much time focusing
|
|
on such admittedly important issues as code maintainability and
|
|
reusability, source code control, choice of development environment, and
|
|
the like that they often forget rule \#1: From the user's perspective,
|
|
*performance is fundamental*.
|
|
|
|
------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
 *Comment your code, design it carefully, and write non-time-critical portions in a high-level language, if you wish—but when you write the portions that interact with the user and/or affect response time, performance must be your paramount objective, and assembly is the path to that goal*.
|
|
------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
|
|
Knowledge of the sort described earlier is absolutely essential to
|
|
fulfilling either of the objectives of assembly programming. What that
|
|
knowledge doesn't do by itself is meet the need to write code that both
|
|
performs to the requirements of the application at hand and also
|
|
operates as efficiently as possible in the PC environment. Knowledge
|
|
makes that possible, but your programming instincts make it happen. And
|
|
it is that intuitive, on-the-fly integration of a program specification
|
|
and a sea of facts about the PC that is the heart of the Zen-class
|
|
assembly optimization.
|
|
|
|
As with Zen of any sort, mastering that Zen of assembly language is more
|
|
a matter of learning than of being taught. You will have to find your
|
|
own path of learning, although I will start you on your way with this
|
|
book. The subtle facts and examples I provide will help you gain the
|
|
necessary experience, but you must continue the journey on your own.
|
|
Each program you create will expand your programming horizons and
|
|
increase the options available to you in meeting the next challenge. The
|
|
ability of your mind to find surprising new and better ways to craft
|
|
superior code from a concept—the flexible mind, if you will—is the
|
|
linchpin of good assembler code, and you will develop this skill only by
|
|
doing.
|
|
|
|
Never underestimate the importance of the flexible mind. Good assembly
|
|
code is better than good compiled code. Many people would have you
|
|
believe otherwise, but they're wrong. That doesn't mean that high-level
|
|
languages are useless; far from it. High-level languages are the best
|
|
choice for the majority of programmers, and for the bulk of the code of
|
|
most applications. When the *best* code—the fastest or smallest code
|
|
possible—is needed, though, assembly is the only way to go.
|
|
|
|
Simple logic dictates that no compiler can know as much about what a
|
|
piece of code needs to do or adapt as well to those needs as the person
|
|
who wrote the code. Given that superior information and adaptability, an
|
|
assembly language programmer can generate better code than a compiler,
|
|
all the more so given that compilers are constrained by the limitations
|
|
of high-level languages and by the process of transformation from
|
|
high-level to machine language. Consequently, carefully optimized
|
|
assembly is not just the language of choice but the *only* choice for
|
|
the 1percent to 10 percent of code—usually consisting of small,
|
|
well-defined subroutines—that determines overall program performance,
|
|
and it is the only choice for code that must be as compact as possible,
|
|
as well. In the run-of-the-mill, non-time-critical portions of your
|
|
programs, it makes no sense to waste time and effort on writing
|
|
optimized assembly code—concentrate your efforts on loops and the like
|
|
instead; but in those areas where you need the finest code quality,
|
|
accept no substitutes.
|
|
|
|
Note that I said that an assembly programmer *can* generate better code
|
|
than a compiler, not *will* generate better code. While it is true that
|
|
good assembly code is better than good compiled code, it is also true
|
|
that bad assembly code is often much worse than bad compiled code; since
|
|
the assembly programmer has so much control over the program, he or she
|
|
has virtually unlimited opportunities to waste cycles and bytes. The
|
|
sword cuts both ways, and good assembly code requires more, not less,
|
|
forethought and planning than good code written in a high-level
|
|
language.
|
|
|
|
The gist of all this is simply that good assembly programming is done in
|
|
the context of a solid overall framework unique to each program, and the
|
|
flexible mind is the key to creating that framework and holding it
|
|
together.
|
|
|
|
#### Where to Begin? {#Heading9}
|
|
|
|
To summarize, the skill of assembly language optimization is a
|
|
combination of knowledge, perspective, and a way of thought that makes
|
|
possible the genesis of absolutely the fastest or the smallest code.
|
|
With that in mind, what should the first step be? Development of the
|
|
flexible mind is an obvious step. Still, the flexible mind is no better
|
|
than the knowledge at its disposal. The first step in the journey toward
|
|
mastering optimization at that exalted level, then, would seem to be
|
|
learning how to learn. |