Normal quotes

11-04.md

@@ -41,14 +41,14 @@ cycles per loop:
       call  ZTimerOff
 
 While word-aligning branch destinations can improve branching
-performance, it’s a nuisance and can increase code size a good deal, so
-it’s not worth doing in most code. Besides, **EVEN** inserts a **NOP**
+performance, it's a nuisance and can increase code size a good deal, so
+it's not worth doing in most code. Besides, **EVEN** inserts a **NOP**
 instruction if necessary, and the time required to execute a **NOP** can
 sometimes cancel the performance advantage of having a word-aligned
 branch destination.
 
   ------------------- -----------------------------------------------------------------------------------------------------------------
-  ![](images/i.jpg)   *Consequently, it’s best to word-align only those branch destinations that can be reached solely by branching.*
+  ![](images/i.jpg)   *Consequently, it's best to word-align only those branch destinations that can be reached solely by branching.*
   ------------------- -----------------------------------------------------------------------------------------------------------------
 
 I recommend that you only go out of your way to word-align the start
@@ -65,16 +65,16 @@ time-critical loops.
 
 #### Alignment and the 386 {#Heading9 align="center"}
 
-So far we’ve only discussed alignment as it pertains to the 286. What,
+So far we've only discussed alignment as it pertains to the 286. What,
 you may well ask, of the 386?
 
 The 386 adds the issue of *doubleword* alignment (that is, alignment to
 addresses that are multiples of four.) The rule for the 386 is:
-Word-sized memory accesses should be word-aligned (it’s impossible for
+Word-sized memory accesses should be word-aligned (it's impossible for
 word-aligned word-sized accesses to cross doubleword boundaries), and
 doubleword-sized memory accesses should be doubleword-aligned. However,
 in real (as opposed to 32-bit protected) mode, doubleword-sized memory
-accesses are rare, so the simple word-alignment rule we’ve developed for
+accesses are rare, so the simple word-alignment rule we've developed for
 the 286 serves for the 386 in real mode as well.
 
 As for code alignment...the subroutine-start word-alignment rule of the
@@ -99,7 +99,7 @@ the mouse. I know of a Forth programmer who vastly improved the
 performance of a complex application on the AT simply by forcing the
 Forth interpreter to maintain an even stack pointer at all times.
 
-An interesting corollary to this rule is that you shouldn’t **INC SP**
+An interesting corollary to this rule is that you shouldn't **INC SP**
 twice to add 2, even though that takes fewer bytes than **ADD SP,2**.
 The stack pointer is odd between the first and second **INC**, so any
 interrupt occurring between the two instructions will be serviced more
@@ -112,7 +112,7 @@ slowly than it normally would. The same goes for decrementing twice; use
 
 #### The DRAM Refresh Cycle-Eater: Still an Act of God {#Heading11 align="center"}
 
-The DRAM refresh cycle-eater is the cycle-eater that’s least changed
+The DRAM refresh cycle-eater is the cycle-eater that's least changed
 from its 8088 form on the 286 and 386. In the AT, DRAM refresh uses a
 little over five percent of all available memory accesses, slightly less
 than it uses in the PC, but in the same ballpark. While the DRAM refresh
@@ -123,16 +123,16 @@ generally suffer less from DRAM refresh), the 5 percent figure is a good
 rule of thumb.
 
 Basically, the effect of the DRAM refresh cycle-eater is pretty much the
-same throughout the PC-compatible world: fairly small, so it doesn’t
-greatly affect performance; unavoidable, so there’s no point in worrying
+same throughout the PC-compatible world: fairly small, so it doesn't
+greatly affect performance; unavoidable, so there's no point in worrying
 about it anyway; and a nuisance since it results in fractional cycle
 counts when using the Zen timer. Just as with the PC, a given code
 sequence on the AT can execute at varying speeds at different times as a
 result of the interaction between the code and DRAM refresh.
 
-There’s nothing much new with DRAM refresh on 286/386 computers, then.
-Be aware of it, but don’t overly concern yourself—DRAM refresh is still
-an act of God, and there’s not a blessed thing you can do about it.
+There's nothing much new with DRAM refresh on 286/386 computers, then.
+Be aware of it, but don't overly concern yourself—DRAM refresh is still
+an act of God, and there's not a blessed thing you can do about it.
 Happily, the internal caches of the 486 and Pentium make DRAM refresh
 largely a performance non-issue on those processors.
 
@@ -140,8 +140,8 @@ largely a performance non-issue on those processors.
 
 Finally we come to the last of the cycle-eaters, the display adapter
 cycle-eater. There are two ways of looking at this cycle-eater on
-286/386 computers: (1) It’s much worse than it was on the PC, or (2)
-it’s just about the same as it was on the PC.
+286/386 computers: (1) It's much worse than it was on the PC, or (2)
+it's just about the same as it was on the PC.
 
 Either way, the display adapter cycle-eater is extremely bad news on
 286/386 computers and on 486s and Pentiums as well. In fact, this
@@ -149,14 +149,14 @@ cycle-eater on those systems is largely responsible for the popularity
 of VESA local bus (VLB).
 
 The two ways of looking at the display adapter cycle-eater on 286/386
-computers are actually the same. As you’ll recall from my earlier
+computers are actually the same. As you'll recall from my earlier
 discussion of the matter in Chapter 4, display adapters offer only a
 limited number of accesses to display memory during any given period of
 time. The 8088 is capable of making use of most but not all of those
 slots with **REP MOVSW**, so the number of memory accesses allowed by a
 display adapter such as a standard VGA is reasonably well-matched to an
-8088’s memory access speed. Granted, access to a VGA slows the 8088 down
-considerably—but, as we’re about to find out, “considerably” is a
+8088's memory access speed. Granted, access to a VGA slows the 8088 down
+considerably—but, as we're about to find out, "considerably" is a
 relative term. What a VGA does to PC performance is nothing compared to
 what it does to faster computers.