Normal quotes

11-07.md

@@ -24,7 +24,7 @@
             endm
             call    ZTimerOff
 
-What’s going on? Simply this: Instruction fetching is controlling
+What's going on? Simply this: Instruction fetching is controlling
 overall execution time on *both* processors. Both the 8088 in a PC and
 the 286 in an AT can execute the bytes of the instructions in Listings
 11.4 and 11.5 faster than they can be fetched. Since the instructions
@@ -44,13 +44,13 @@ memory-accessing instructions on the 286 and 386 are much faster
 Given the system wait states prevalent on 286 and 386 computers,
 however, the prefetch queue is likely to be empty quite a bit,
 especially when code consisting of instructions with short EU execution
-times is executed. Of course, that’s just the sort of code we’re likely
-to write when we’re optimizing, so the performance of high-speed code is
+times is executed. Of course, that's just the sort of code we're likely
+to write when we're optimizing, so the performance of high-speed code is
 more likely to be controlled by instruction size than by EU execution
 time on most 286 and 386 computers, just as it is on the PC.
 
 All of which is just a way of saying that faster memory access and EA
-calculation notwithstanding, it’s just as desirable to keep instructions
+calculation notwithstanding, it's just as desirable to keep instructions
 short and memory accesses to a minimum on the 286 and 386 as it is on
 the 8088. And the way to do that is to use the registers as heavily as
 possible, use string instructions, use short forms of instructions, and
@@ -60,45 +60,45 @@ The more things change, the more they remain the same....
 
 #### POPF and the 286 {#Heading17}
 
-We’ve one final 286-related item to discuss: the hardware malfunction of
+We've one final 286-related item to discuss: the hardware malfunction of
 **POPF** under certain circumstances on the 286.
 
 The problem is this: Sometimes **POPF** permits interrupts to occur when
 interrupts are initially off and the setting popped into the Interrupt
 flag from the stack keeps interrupts off. In other words, an interrupt
 can happen even though the Interrupt flag is never set to 1. Now, I
-don’t want to blow this particular bug out of proportion. It only causes
+don't want to blow this particular bug out of proportion. It only causes
 problems in code that cannot tolerate interrupts under any
-circumstances, and that’s a rare sort of code, especially in user
+circumstances, and that's a rare sort of code, especially in user
 programs. However, some code really does need to have interrupts
 absolutely disabled, with no chance of an interrupt sneaking through.
 For example, a critical portion of a disk BIOS might need to retrieve
 data from the disk controller the instant it becomes available; even a
-few hundred microseconds of delay could result in a sector’s worth of
+few hundred microseconds of delay could result in a sector's worth of
 data misread. In this case, one misplaced interrupt during a **POPF**
 could result in a trashed hard disk if that interrupt occurs while the
 disk BIOS is reading a sector of the File Allocation Table.
 
 There is a workaround for the **POPF** bug. While the workaround is easy
-to use, it’s considerably slower than **POPF**, and costs a few bytes as
-well, so you won’t want to use it in code that can tolerate interrupts.
+to use, it's considerably slower than **POPF**, and costs a few bytes as
+well, so you won't want to use it in code that can tolerate interrupts.
 On the other hand, in code that truly cannot be interrupted, you should
 view those extra cycles and bytes as cheap insurance against mysterious
 and erratic program crashes.
 
-One obvious reason to discuss the **POPF** workaround is that it’s
+One obvious reason to discuss the **POPF** workaround is that it's
 useful. Another reason is that the workaround is an excellent example of
-Zen-level assembly coding, in that there’s a well-defined goal to be
+Zen-level assembly coding, in that there's a well-defined goal to be
 achieved but no obvious way to do so. The goal is to reproduce the
 functionality of the **POPF** instruction without using **POPF**, and
 the place to start is by asking exactly what **POPF** does.
 
 All **POPF** does is pop the word on top of the stack into the FLAGS
 register, as shown in Figure 11.4. How can we do that without **POPF**?
-Of course, the 286’s designers intended us to use **POPF** for this
-purpose, and didn’t intentionally provide any alternative approach, so
-we’ll have to devise an alternative approach of our own. To do that,
-we’ll have to search for instructions that contain some of the same
+Of course, the 286's designers intended us to use **POPF** for this
+purpose, and didn't intentionally provide any alternative approach, so
+we'll have to devise an alternative approach of our own. To do that,
+we'll have to search for instructions that contain some of the same
 functionality as **POPF**, in the hope that one of those instructions
 can be used in some way to replace **POPF**.