Change bold code snippets to inline code blocks

22-03.md

@@ -37,7 +37,7 @@ pack both the attribute and the fill value into the same word, but
 that's not part of the specification for this particular routine.)
 
 Another nifty instruction-rearrangement trick saves 6 more bytes.
-**ClearS** checks to see whether the far pointer is null (zero) at the
+`ClearS` checks to see whether the far pointer is null (zero) at the
 start of the routine...then loads and uses that same far pointer later
 on. Let's get that pointer into registers and keep it there; that way we
 can check to see whether it's null with a single comparison, and can use
@@ -72,11 +72,11 @@ Realistically, how much smaller can we make this code?
 About one-third smaller yet, as it turns out—but in order to do that, we
 must stretch our minds and use the 8088's instructions in unusual ways.
 Let me ask you this: What do most of the instructions in the current
-version of **ClearS** do?
+version of `ClearS` do?
 
 They either load parameters from the stack frame or set up the registers
 so that the parameters can be accessed. Mind you, there's nothing wrong
-with the stack-frame-oriented instructions used in **ClearS**; those
+with the stack-frame-oriented instructions used in `ClearS`; those
 instructions access the stack frame in a highly efficient way, exactly
 as the designers of the 8088 intended, and just as the code generated by
 a high-level language would. That means that we aren't going to be able
@@ -90,12 +90,12 @@ stack...*the stack*...THE STACK!
 Ye gods! That's easy—we can use the *stack pointer* to address the stack
 rather than BP. While it's true that the stack pointer can't be used for
 *mod-reg-rm* addressing, as BP can, it *can* be used to pop data off the
-stack—and **POP** is a one-byte instruction. Instructions don't get any
+stack—and `POP` is a one-byte instruction. Instructions don't get any
 shorter than that.
 
 There is one detail to be taken care of before we can put our plan into
 action: The return address—the address of the calling code—is on top of
-the stack, so the parameters we want can't be reached with **POP**.
+the stack, so the parameters we want can't be reached with `POP`.
 That's easily solved, however—we'll just pop the return address into an
 unused register, then branch through that register when we're done, as
 we learned to do in Chapter 14. As we pop the parameters, we'll also be
@@ -103,7 +103,7 @@ removing them from the stack, thereby neatly avoiding the need to
 discard them when it's time to return.
 
 With that problem dealt with, Listing 22.7 shows the Zenned version of
-**ClearS**.
+`ClearS`.
 
 **LISTING 22.7 L22-7.ASM**
 
@@ -126,13 +126,13 @@ Bye:
 ClearS         endp
 ```
 
-At long last, we're down to the bare metal. This version of **ClearS**
+At long last, we're down to the bare metal. This version of `ClearS`
 is just 19 bytes long. That's just 37 percent as long as the original
 version, *without any change whatsoever in the functionality that
-**ClearS** makes available to the calling code*. The code is bound to
+`ClearS` makes available to the calling code*. The code is bound to
 run a bit faster too, given that there are far fewer instruction bytes
 and fewer memory accesses.
 
-All in all, the Zenned version of **ClearS** is a vast improvement over
+All in all, the Zenned version of `ClearS` is a vast improvement over
 the original. Probably not the best possible implementation—*never say
 never!*—but an awfully good one.