Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Change bold code snippets to inline code blocks

Browse source
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
Download patch file Download diff file Expand all files Collapse all files

14
08-02.md
View file

@ -53,14 +53,14 @@ over C is that it allows the use of all forms of instructions and all
registers in all ways, whereas C compilers tend to use a subset of
registers and instructions in a limited number of ways. Yes and no. It's
true that C compilers typically don't generate instructions such as
**XLAT,** rotates, or the string instructions. On the other hand,
**XLAT** and rotates are useful in a limited set of circumstances, and
`XLAT`, rotates, or the string instructions. On the other hand,
`XLAT` and rotates are useful in a limited set of circumstances, and
string instructions *are* used in the C library functions. In fact, C
library code is likely to be carefully optimized by experts, and may be
much better than equivalent code you'd produce yourself.
Am I saying that C compilers produce better code than you do? No, I'm
saying that they *can,* unless you use assembly language properly.
saying that they *can*, unless you use assembly language properly.
Writing code in assembly language rather than C guarantees nothing.
> ![](images/i.jpg)
@ -83,7 +83,7 @@ to something like Figure 8.1A. You might look at that and tweak it to
the code shown in Figure 8.1B.
Congratulations! You've successfully eliminated all stack frame access,
you've used **LOOP** (although **DEC SI/JNZ** is actually faster on 386
you've used `LOOP` (although `DEC SI/JNZ` is actually faster on 386
and later machines, as I explained in the last chapter), and you've used
a string instruction. Unfortunately, the new code isn't going to run
very much faster. Maybe 25 percent faster, maybe a little more. Big
@ -107,13 +107,13 @@ of better assembly language code in the small section of code that most
affects overall performance. For example, consider that the data
searched in the last example is stored in an array of structures, with
each structure in the array containing other information as well. In
this situation, **REP SCASW** couldn't be used because the data searched
this situation, `REP SCASW` couldn't be used because the data searched
through wouldn't be contiguous.
However, if the need for performance in searching the array is urgent
enough, there's no reason why you can't reorganize the data. This might
mean removing the array elements from the structures and storing them in
their own array so that **REP SCASW** *could* be used.
their own array so that `REP SCASW` *could* be used.
> ![](images/i.jpg)
> Organizing a program's data so that the performance of the critical
@ -145,5 +145,5 @@ That said, let me show some of these precepts in action.
Listing 8.1 is the sample C application I'm going to use to examine
optimization in action. Listing 8.1 isn't really complete—it doesn't
handle the "no-matches" case well, and it assumes that the sum of all
matches will fit into an **int—**but it will do just fine as an
matches will fit into an `int`-but it will do just fine as an
optimization example.