Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Normal quotes

Browse source
This commit is contained in:
James Gregory 2013-12-30 18:34:31 +11:00
commit 18011c595a
352 changed files with 6040 additions and 6040 deletions
Download patch file Download diff file Expand all files Collapse all files

16
02-03.md
View file

@ -6,7 +6,7 @@
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
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.
@ -14,12 +14,12 @@ 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
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
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*.
@ -32,7 +32,7 @@ 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,
the like that they often forget rule \#1: From the user's perspective,
*performance is fundamental*.
------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
@ -41,7 +41,7 @@ the like that they often forget rule \#1: From the user’s perspective,
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
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
@ -63,7 +63,7 @@ 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
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