Initial conversion to markdown

02-03.md

@@ -0,0 +1,121 @@
+  ------------------------ --------------------------------- --------------------
+  [Previous](02-02.html)   [Table of Contents](index.html)   [Next](03-01.html)
+  ------------------------ --------------------------------- --------------------
+
+### 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*.
+
+  ------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+  ![](images/i.jpg)   *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.
+
+  ------------------------ --------------------------------- --------------------
+  [Previous](02-02.html)   [Table of Contents](index.html)   [Next](03-01.html)
+  ------------------------ --------------------------------- --------------------
+
+* * * * *
+
+Graphics Programming Black Book © 2001 Michael Abrash