Change bold code snippets to inline code blocks

04-05.md

@@ -30,9 +30,9 @@ The truth is that it never hurts performance to reduce either the cycle
 count or the byte count of a given bit of code, but there's no guarantee
 that one or the other will improve performance either. For example,
 consider Listing 4.7, which consists of a series of 4-cycle, 2-byte
-**MOV AL,0** instructions, and which executes at the rate of 1.81 µs per
-instruction. Now consider Listing 4.8, which replaces the 4-cycle **MOV
-AL,0** with the 3-cycle (but still 2-byte) **SUB AL,AL,** Despite its
+`MOV AL,0` instructions, and which executes at the rate of 1.81 µs per
+instruction. Now consider Listing 4.8, which replaces the 4-cycle `MOV
+AL,0` with the 3-cycle (but still 2-byte) `SUB AL,AL,` Despite its
 1-cycle-per-instruction advantage, Listing 4.8 runs at exactly the same
 speed as Listing 4.7. The reason: Both instructions are 2 bytes long,
 and in both cases it is the 8-cycle instruction fetch time, not the 3 or
@@ -108,19 +108,19 @@ in this book, and use the Zen timer to measure your code.
 Don't think that because overall instruction execution time is
 determined by both instruction fetch time and Execution Unit execution
 time, the two times should be added together when estimating
-performance. For example, practically speaking, each **SHR** in Listing
+performance. For example, practically speaking, each `SHR` in Listing
 4.5 does not take 8 cycles of instruction fetch time plus 2 cycles of
 Execution Unit execution time to execute. Figure 4.3 shows that while a
-given **SHR** is executing, the fetch of the next **SHR** is starting,
+given `SHR` is executing, the fetch of the next `SHR` is starting,
 and since the two operations are overlapped for 2 cycles, there's no
 sense in charging the time to both instructions. You could think of the
-extra instruction fetch time for **SHR** in Listing 4.5 as being 6
+extra instruction fetch time for `SHR` in Listing 4.5 as being 6
 cycles, which yields an overall execution time of 8 cycles when added to
 the 2 cycles of Execution Unit execution time.
 
-Alternatively, you could think of each **SHR** in Listing 4.5 as taking
+Alternatively, you could think of each `SHR` in Listing 4.5 as taking
 8 cycles to fetch, and then executing in effectively 0 cycles while the
-next **SHR** is being fetched. Whichever perspective you prefer is fine.
+next `SHR` is being fetched. Whichever perspective you prefer is fine.
 The important point is that the time during which the execution of one
 instruction and the fetching of the next instruction overlap should only
 be counted toward the overall execution time of one of the instructions.
@@ -150,7 +150,7 @@ While short instructions minimize overall prefetch time, ironically they
 actually often suffer more from the prefetch queue bottleneck than do
 long instructions. Short instructions generally have such fast execution
 times that they drain the prefetch queue despite their small size. For
-example, consider the **SHR** of Listing 4.5, which runs at only 25
+example, consider the `SHR` of Listing 4.5, which runs at only 25
 percent of its Execution Unit execution time even though it's only 2
 bytes long, thanks to the prefetch queue bottleneck. Short instructions
 are nonetheless generally faster than long instructions, thanks to the