Normal quotes

01-01.md

@@ -18,16 +18,16 @@ proper care, however, and those ugly boxes are capable of miracles. The
 key is this: Only on microcomputers do you have the run of the whole
 machine, without layers of operating systems, drivers, and the like
 getting in the way. You can do *anything* you want, and you can
-understand everything that’s going on, if you so wish.
+understand everything that's going on, if you so wish.
 
-As we’ll see shortly, you should indeed so wish.
+As we'll see shortly, you should indeed so wish.
 
 Is performance still an issue in this era of cheap 486 computers and
 super-fast Pentium computers? You bet. How many programs that *you* use
-really run so fast that you wouldn’t be happier if they ran faster?
-We’re so used to slow software that when a compile-and-link sequence
+really run so fast that you wouldn't be happier if they ran faster?
+We're so used to slow software that when a compile-and-link sequence
 that took two minutes on a PC takes just ten seconds on a 486 computer,
-we’re ecstatic—when in truth we should be settling for nothing less than
+we're ecstatic—when in truth we should be settling for nothing less than
 instantaneous response.
 
 Impossible, you say? Not with the proper design, including incremental
@@ -35,13 +35,13 @@ compilation and linking, use of extended and/or expanded memory, and
 well-crafted code. PCs can do just about anything you can imagine (with
 a few obvious exceptions, such as applications involving
 super-computer-class number-crunching) if you believe that it can be
-done, if you understand the computer inside and out, and if you’re
+done, if you understand the computer inside and out, and if you're
 willing to think past the obvious solution to unconventional but
 potentially more fruitful approaches.
 
-My point is simply this: PCs can work wonders. It’s not easy coaxing
-them into doing that, but it’s rewarding—and it’s sure as heck fun. In
-this book, we’re going to work some of those wonders, starting...
+My point is simply this: PCs can work wonders. It's not easy coaxing
+them into doing that, but it's rewarding—and it's sure as heck fun. In
+this book, we're going to work some of those wonders, starting...
 
 ...now.
 
@@ -58,14 +58,14 @@ pointless.
 Notice that the above definition most emphatically does *not* say
 anything about making the software as fast as possible. It also does not
 say anything about using assembly language, or an optimizing compiler,
-or, for that matter, a compiler at all. It also doesn’t say anything
+or, for that matter, a compiler at all. It also doesn't say anything
 about how the code was designed and written. What it does say is that
-high-performance code shouldn’t get in the user’s way—and that’s *all*.
+high-performance code shouldn't get in the user's way—and that's *all*.
 
-That’s an important distinction, because all too many programmers think
+That's an important distinction, because all too many programmers think
 that assembly language, or the right compiler, or a particular
 high-level language, or a certain design approach is the answer to
-creating high-performance code. They’re not, any more than choosing a
+creating high-performance code. They're not, any more than choosing a
 certain set of tools is the key to building a house. You do indeed need
 tools to build a house, but any of many sets of tools will do. You also
 need a blueprint, an understanding of everything that goes into a house,
@@ -80,13 +80,13 @@ assembly language. The optimization at the end is just the finishing
 touch, however.
 
   ------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  ![](images/i.jpg)   *Without good design, good algorithms, and complete understanding of the program’s operation, your carefully optimized code will amount to one of mankind’s least fruitful creations—a fast slow program*.
+  ![](images/i.jpg)   *Without good design, good algorithms, and complete understanding of the program's operation, your carefully optimized code will amount to one of mankind's least fruitful creations—a fast slow program*.
   ------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
-“What’s a fast slow program?” you ask. That’s a good question, and a
+"What's a fast slow program?" you ask. That's a good question, and a
 brief (true) story is perhaps the best answer.
 
-#### When Fast Isn’t Fast {#Heading4}
+#### When Fast Isn't Fast {#Heading4}
 
 In the early 1970s, as the first hand-held calculators were hitting the
 market, I knew a fellow named Irwin. He was a good student, and was
@@ -98,21 +98,21 @@ calculator to a duel—and won, becoming a local legend in the process.
 When you get right down to it, though, Irwin was spitting into the wind.
 In a few short years his hard-earned slipstick skills would be
 worthless, and the entire discipline would be essentially wiped from the
-face of the earth. What’s more, anyone with half a brain could see that
+face of the earth. What's more, anyone with half a brain could see that
 changeover coming. Irwin had basically wasted the considerable effort
 and time he had spent optimizing his soon-to-be-obsolete skills.
 
 What does all this have to do with programming? Plenty. When you spend
 time optimizing poorly-designed assembly code, or when you count on an
-optimizing compiler to make your code fast, you’re wasting the
-optimization, much as Irwin did. Particularly in assembly, you’ll find
+optimizing compiler to make your code fast, you're wasting the
+optimization, much as Irwin did. Particularly in assembly, you'll find
 that without proper up-front design and everything else that goes into
-high-performance design, you’ll waste considerable effort and time on
+high-performance design, you'll waste considerable effort and time on
 making an inherently slow program as fast as possible—which is still
 slow—when you could easily have improved performance a great deal more
-with just a little thought. As we’ll see, handcrafted assembly language
+with just a little thought. As we'll see, handcrafted assembly language
 and optimizing compilers matter, but less than you might think, in the
-grand scheme of things—and they scarcely matter at all unless they’re
+grand scheme of things—and they scarcely matter at all unless they're
 used in the context of a good design and a thorough understanding of
 both the task at hand and the PC.