Change bold code snippets to inline code blocks

04-04.md

@@ -12,7 +12,7 @@ pages: 087-090
 
 #### Official Execution Times Are Only Part of the Story {#Heading10}
 
-The sequence of 5 **SHR** instructions in the last example is 10 bytes
+The sequence of 5 `SHR` instructions in the last example is 10 bytes
 long. That means that it can never execute in less than 24 cycles even
 if the 4-byte prefetch queue is full when it starts, since 6 instruction
 bytes would still remain to be fetched, at 4 cycles per fetch. If the
@@ -90,17 +90,17 @@ that), and some of the other prefetch states may well produce distinctly
 different results.
 
 For example, consider the code in Listings 4.5 and 4.6. Listing 4.5
-shows our familiar **SHR** case. Here, because the prefetch queue is
+shows our familiar `SHR` case. Here, because the prefetch queue is
 always empty, execution time should work out to about 4 cycles per byte,
-or 8 cycles per **SHR,** as shown in Figure 4.3. (Figure 4.3 illustrates
+or 8 cycles per `SHR`, as shown in Figure 4.3. (Figure 4.3 illustrates
 the relationship between instruction fetching and execution in a
 simplified way, and is not intended to show the exact timings of 8088
 operations.) That's quite a contrast to the official 2-cycle execution
-time of **SHR**. In fact, the Zen timer reports that Listing 4.5
+time of `SHR`. In fact, the Zen timer reports that Listing 4.5
 executes in 1.81µs per byte, or slightly *more* than 4 cycles per byte.
 (The extra time is the result of the dynamic RAM refresh cycle-eater,
 which we'll discuss shortly.) Going by Listing 4.5, we would conclude
-that the "true" execution time of **SHR** is 8.64 cycles.
+that the "true" execution time of `SHR` is 8.64 cycles.
 
 **LISTING 4.5 LST4-5.ASM**
 
@@ -138,27 +138,27 @@ that the "true" execution time of **SHR** is 8.64 cycles.
 ![**Figure 4.3**  *Execution and instruction prefetching sequence for
 Listing 4.5.*](images/04-03.jpg)
 
-Now let's examine Listing 4.6. Here each **SHR** follows a **MUL**
-instruction. Since **MUL** instructions take so long to execute that the
-prefetch queue is always full when they finish, each **SHR** should be
-ready and waiting in the prefetch queue when the preceding **MUL** ends.
-As a result, we'd expect that each **SHR** would execute in 2 cycles;
+Now let's examine Listing 4.6. Here each `SHR` follows a `MUL`
+instruction. Since `MUL` instructions take so long to execute that the
+prefetch queue is always full when they finish, each `SHR` should be
+ready and waiting in the prefetch queue when the preceding `MUL` ends.
+As a result, we'd expect that each `SHR` would execute in 2 cycles;
 together with the 118-cycle execution time of multiplying 0 times 0, the
-total execution time should come to 120 cycles per **SHR/MUL** pair, as
+total execution time should come to 120 cycles per `SHR/MUL` pair, as
 shown in Figure 4.4. And, by God, when we run Listing 4.6 we get an
-execution time of 25.14 µs per **SHR/MUL** pair, or *exactly* 120
-cycles! According to these results, the "true" execution time of **SHR**
+execution time of 25.14 µs per `SHR/MUL` pair, or *exactly* 120
+cycles! According to these results, the "true" execution time of `SHR`
 would seem to be 2 cycles, quite a change from the conclusion we drew
 from Listing 4.5.
 
-The key point is this: We've seen one code sequence in which **SHR**
+The key point is this: We've seen one code sequence in which `SHR`
 took 8-plus cycles to execute, and another in which it took only 2
-cycles. Are we talking about two different forms of **SHR** here? Of
+cycles. Are we talking about two different forms of `SHR` here? Of
 course not—the difference is purely a reflection of the differing states
 in which the preceding code left the prefetch queue. In Listing 4.5,
-each **SHR** after the first few follows a slew of other **SHR**
+each `SHR` after the first few follows a slew of other `SHR`
 instructions which have sucked the prefetch queue dry, so overall
-performance reflects instruction fetch time. By contrast, each **SHR**
-in Listing 4.6 follows a **MUL** instruction which leaves the prefetch
+performance reflects instruction fetch time. By contrast, each `SHR`
+in Listing 4.6 follows a `MUL` instruction which leaves the prefetch
 queue full, so overall performance reflects Execution Unit execution
 time.