Change bold code snippets to inline code blocks

22-01.md

@@ -92,25 +92,25 @@ Bye:mov      sp,bp                   ;restore original stack pointer
 ClearS       endp
 ```
 
-The first thing you'll notice about Listing 22.1 is that **ClearS** uses
-a **REP STOSW** instruction. That means that we're not going to improve
+The first thing you'll notice about Listing 22.1 is that `ClearS` uses
+a `REP STOSW` instruction. That means that we're not going to improve
 performance by any great amount, no matter how clever we are. While we
-can eliminate some cycles, the bulk of the work in **ClearS** is done by
+can eliminate some cycles, the bulk of the work in `ClearS` is done by
 that one repeated string instruction, and there's no way to improve on
 that.
 
 Does that mean that Listing 22.1 is as good as it can be? Hardly. While
-the speed of **ClearS** is very good, there's another side to the
-optimization equation: size. The whole of **ClearS** is 52 bytes long as
+the speed of `ClearS` is very good, there's another side to the
+optimization equation: size. The whole of `ClearS` is 52 bytes long as
 it stands—but, as we'll see, that size is hardly set in stone.
 
-Where do we begin with **ClearS**? For starters, there's an instruction
-in there that serves no earthly purpose—**MOV SP,BP**. SP is guaranteed
+Where do we begin with `ClearS`? For starters, there's an instruction
+in there that serves no earthly purpose—`MOV SP,BP`. SP is guaranteed
 to be equal to BP at that point anyway, so why reload it with the same
 value? Removing that instruction saves us two bytes.
 
 Well, that was certainly easy enough! We're not going to find any more
-totally non-functional instructions in **ClearS**, however, so let's get
+totally non-functional instructions in `ClearS`, however, so let's get
 on to some serious optimizing. We'll look first for cases where we know
 of better instructions for particular tasks than those that were chosen.
 For example, there's no need to load any register, whether segment or