Change bold code snippets to inline code blocks

11-03.md

@@ -84,15 +84,15 @@ different workaround, we'll consider it to be a new cycle-eater.)
 The way to deal with the data alignment cycle-eater is straightforward:
 *Don't perform word-sized accesses to odd addresses on the 286 if you
 can help it*. The easiest way to avoid the data alignment cycle-eater is
-to place the directive **EVEN** before each of your word-sized
-variables. **EVEN** forces the offset of the next byte assembled to be
-even by inserting a **NOP** if the current offset is odd; consequently,
+to place the directive `EVEN` before each of your word-sized
+variables. `EVEN` forces the offset of the next byte assembled to be
+even by inserting a `NOP` if the current offset is odd; consequently,
 you can ensure that any word-sized variable can be accessed efficiently
-by the 286 simply by preceding it with **EVEN**.
+by the 286 simply by preceding it with `EVEN`.
 
 Listing 11.2, which accesses memory a word at a time with each word
 starting at an odd address, runs on a 10 MHz AT clone in 1.27 ms per
-repetition of **MOVSW**, or 0.64 ms per word-sized memory access. That's
+repetition of `MOVSW`, or 0.64 ms per word-sized memory access. That's
 6-plus cycles per word-sized access, which breaks down to two separate
 memory accesses—3 cycles to access the high byte of each word and 3
 cycles to access the low byte of each word, the inevitable result of
@@ -123,7 +123,7 @@ Skip:
 
 On the other hand, Listing 11.3, which is exactly the same as Listing
 11.2 save that the memory accesses are word-aligned (start at even
-addresses), runs in 0.64 ms per repetition of **MOVSW**, or 0.32 µs per
+addresses), runs in 0.64 ms per repetition of `MOVSW`, or 0.32 µs per
 word-sized memory access. That's 3 cycles per word-sized access—exactly
 twice as fast as the non-word-aligned accesses of Listing 11.2, just as
 we predicted.