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

Remove colour attributes from body and strip most of the font tags out

Browse source
This commit is contained in:
James Gregory 2013-12-30 13:57:02 +11:00
commit c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
Download patch file Download diff file Expand all files Collapse all files

10
09-02.html
View file

@ -24,7 +24,7 @@
<!--CHAPTER=09//-->
<!--PAGES=172-175//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
<!--UNASSIGNED2//--></HEAD><body>
<CENTER>
<TABLE BORDER>
@ -76,7 +76,7 @@ SHL AX,2 ;*64
ADD AX,BX ;*80
</PRE>
<!-- END CODE SNIP //-->
<H4 ALIGN="LEFT"><A NAME="Heading5"></A><FONT COLOR="#000077">Speeding Up Multiplication</FONT></H4>
<H4 ALIGN="LEFT"><A NAME="Heading5"></A>Speeding Up Multiplication</H4>
<P>That brings us to multiplication, one of the slowest of x86 operations and one that allows for considerable optimization. One way to speed up multiplication is to use shift and add, <B>LEA</B>, or a lookup table to hard-code a multiplication operation for a fixed multiplier, as shown above. Another is to take advantage of the early-out feature of the 386 (and the 486, but in the interests of brevity I&rsquo;ll just say &ldquo;386&rdquo; from now on) by arranging your operands so that the multiplier (always the rightmost operand following <B>MUL</B> or <B>IMUL</B>) is no larger than the other operand.</P>
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>Why? Because the 386 processes one multiplier bit per cycle and immediately ends a multiplication when all significant bits of the multiplier have been processed, so fewer cycles are required to multiply a large multiplicand times a small multiplier than a small multiplicand times a large multiplier, by a factor of about 1 cycle for each significant multiplier bit eliminated.</I></SMALL>
</TABLE>
@ -88,10 +88,10 @@ ADD AX,BX ;*80
</TABLE>
<P>All in all, <B>MUL</B> and <B>IMUL</B> are reasonable performers on the 386, no longer to be avoided in most cases&mdash;and you can help that along by arranging your code to make the smaller operand the multiplier whenever you know which operand is smaller.</P>
<P>That doesn&rsquo;t mean that your code should test and swap operands to make sure the smaller one is the multiplier; that rarely pays off. I&rsquo;m speaking more of the case where you&rsquo;re scaling an array up by a value that&rsquo;s always in the range of, say, 2 to 10; because the scale value will always be small and the array elements may have any value, the scale value is the logical choice for the multiplier.</P>
<H4 ALIGN="LEFT"><A NAME="Heading6"></A><FONT COLOR="#000077">Optimizing Optimized Searching</FONT></H4>
<H4 ALIGN="LEFT"><A NAME="Heading6"></A>Optimizing Optimized Searching</H4>
<P>Rob Williams writes with a wonderful optimization to the <B>REPNZ SCASB-</B>based optimized searching routine I discussed in Chapter 5. As a quick refresher, I described searching a buffer for a text string as follows: Scan for the first byte of the text string with <B>REPNZ SCASB</B>, then use <B>REPZ CMPS</B> to check for a full match whenever <B>REPNZ SCASB</B> finds a match for the first character, as shown in Figure 9.1. The principle is that most buffer characters won&rsquo;t match the first character of any given string, so <B>REPNZ SCASB</B>, by far the fastest way to search on the PC, can be used to eliminate most potential matches; each remaining potential match can then be checked in its entirety with <B>REPZ CMPS</B>.</P>
<P><A NAME="Fig1"><!-- </A><A HREF="javascript:displayWindow('images/09-01.jpg',406,306 )"> --><IMG SRC="images/09-01.jpg"><BR><!-- </A>
<BR><A HREF="javascript:displayWindow('images/09-01.jpg',406,306)"> --><FONT COLOR="#000077"><B>Figure 9.1</B></FONT></A>&nbsp;&nbsp;<I>Simple searching method for locating a text string.</I>
<BR><A HREF="javascript:displayWindow('images/09-01.jpg',406,306)"> --><B>Figure 9.1</B></A>&nbsp;&nbsp;<I>Simple searching method for locating a text string.</I>
</P>
<P>Rob&rsquo;s revelation, which he credits without explanation to Edgar Allen Poe (search nevermore?), was that by far the slowest part of the whole deal is handling <B>REPNZ SCASB</B> matches, which require checking the remainder of the string with <B>REPZ CMPS</B> and restarting <B>REPNZ SCASB</B> if no match is found.</P>
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>Rob points out that the number of <B>REPNZ SCASB</B> matches can easily be reduced simply by scanning for the character in the searched-for string that appears least often in the buffer being searched.</I></SMALL>
@ -109,7 +109,7 @@ ADD AX,BX ;*80
<hr width="90%" size="1" noshade>
<div align="center">
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book &copy; 2001 Michael Abrash</font>
Graphics Programming Black Book &copy; 2001 Michael Abrash
</div>
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->