Change bold code snippets to inline code blocks

04-07.md

@@ -14,7 +14,7 @@ pages: 097-099
 
 Let's look at examples from opposite ends of the spectrum in terms of
 the impact of DRAM refresh on code performance. First, consider the
-series of **MUL** instructions in Listing 4.9. Since a 16-bit **MUL** on
+series of `MUL` instructions in Listing 4.9. Since a 16-bit `MUL` on
 the 8088 executes in between 118 and 133 cycles and is only 2 bytes
 long, there should be plenty of time for the prefetch queue to fill
 after each instruction, even after DRAM refresh has taken its slice of
@@ -42,15 +42,15 @@ request a memory access from the Bus Interface Unit.)
      call ZTimerOff
 ```
 
-Running Listing 4.9, we find that each **MUL** executes in 24.72 µs, or
-exactly 118 cycles. Since that's the shortest time in which **MUL** can
+Running Listing 4.9, we find that each `MUL` executes in 24.72 µs, or
+exactly 118 cycles. Since that's the shortest time in which `MUL` can
 execute, we can see that no performance is lost to DRAM refresh. Listing
 4.9 clearly illustrates that DRAM refresh only affects code performance
 when a DRAM refresh forces the Execution Unit of the 8088 to wait for a
 memory access.
 
-Now let's look at the series of **SHR** instructions shown in Listing
-4.10. Since **SHR** executes in 2 cycles but is 2 bytes long, the
+Now let's look at the series of `SHR` instructions shown in Listing
+4.10. Since `SHR` executes in 2 cycles but is 2 bytes long, the
 prefetch queue should be empty while Listing 4.10 executes, with the
 8088 prefetching instruction bytes non-stop. As a result, the time per
 instruction of Listing 4.10 should precisely reflect the time required
@@ -71,8 +71,8 @@ to fetch the instruction bytes.
 ```
 
 Since 4 cycles are required to read each instruction byte, we'd expect
-each **SHR** to execute in 8 cycles, or 1.676 µs, if there were no DRAM
-refresh. In fact, each **SHR** in Listing 4.10 executes in 1.81 µs,
+each `SHR` to execute in 8 cycles, or 1.676 µs, if there were no DRAM
+refresh. In fact, each `SHR` in Listing 4.10 executes in 1.81 µs,
 indicating that DRAM refresh is taking 7.4 percent of the program's
 execution time. That's nearly 2 percent more than our worst-case
 estimate of the loss to DRAM refresh overhead! In fact, the result
@@ -84,7 +84,7 @@ accesses for as many as 6 cycles, depending on the timing of the DRAM
 refresh's DMA request relative to the 8088's internal instruction
 execution state. When the code in Listing 4.10 runs, each DRAM refresh
 holds up the CPU for either 5 or 6 cycles, depending on where the 8088
-is in executing the current **SHR** instruction when the refresh request
+is in executing the current `SHR` instruction when the refresh request
 occurs. Now we see that things can get even worse than we thought: *DRAM
 refresh can steal as much as 8.33 percent of available memory access
 time—6 out of every 72 cycles—from the 8088.*