Change bold code snippets to inline code blocks

This commit is contained in:
James Gregory 2013-12-31 17:12:29 +11:00
commit 3c76d884ef
185 changed files with 1772 additions and 1772 deletions

View file

@ -14,22 +14,22 @@ Listing 9.1 implements the scan-on-first-character approach. Listing 9.2
scans for whatever character the caller specifies. Listing 9.3 is a test
program used to compare the two approaches. How much difference does
Rob's revelation make? Plenty. Even when the entire C function call to
**FindString** is timed—**strlen** calls, parameter pushing, calling,
setup, and all—the version of **FindString** in Listing 9.2, which is
`FindString` is timed—`strlen` calls, parameter pushing, calling,
setup, and all—the version of `FindString` in Listing 9.2, which is
directed by Listing 9.3 to scan for the infrequently-occurring "Q," is
about 40 percent faster on a 20 MHz cached 386 for the test search of
Listing 9.3 than is the version of **FindString** in Listing 9.1, which
Listing 9.3 than is the version of `FindString` in Listing 9.1, which
always scans for the first character, in this case "E." However, when
only the search loops (the code that actually does the searching) in the
two versions of **FindString** are compared, Listing 9.2 is more than
two versions of `FindString` are compared, Listing 9.2 is more than
*twice* as fast as Listing 9.1—a remarkable improvement over code that
already uses **REPNZ SCASB** and **REPZ CMPS**.
already uses `REPNZ SCASB` and `REPZ CMPS`.
What I like so much about Rob's approach is that it demonstrates that
optimization involves much more than instruction selection and cycle
counting. Listings 9.1 and 9.2 use pretty much the same instructions,
and even use the same approach of scanning with **REPNZ SCASB** and
using **REPZ CMPS** to check scanning matches.
and even use the same approach of scanning with `REPNZ SCASB` and
using `REPZ CMPS` to check scanning matches.
> ![](images/i.jpg)
> The difference between Listings 9.1 and 9.2 (which gives you more than a