Strip comments and inline ids onto h*

This commit is contained in:
James Gregory 2013-12-30 15:11:04 +11:00
commit 0f5f617adb
362 changed files with 2519 additions and 6694 deletions

View file

@ -10,16 +10,9 @@
<meta name="vspubdate" content="07/01/97" />
<meta name="vscategory" content="Web and Software Development: Game Development,Web and Software Development: Graphics and Multimedia Development" />
<title>Michael Abrash's Graphics Programming Black Book Special Edition: Pushing the 486</title><!-- HEADER -->
<!-- Empty Reference Subhead -->
<!--ISBN=1576101746//-->
<!--TITLE=Michael Abrash's Graphics Programming Black Book Special Edition//-->
<!--AUTHOR=Michael Abrash//-->
<!--PUBLISHER=The Coriolis Group, Inc.//-->
<title>Michael Abrash's Graphics Programming Black Book Special Edition: Pushing the 486</title>
<meta name="chapter" content="12" />
<meta name="pages" content="233-237" />
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//-->
</head>
<body>
@ -37,10 +30,10 @@
<p><br /></p>
<h2><a id="Heading1"></a>Chapter 12<br />
<h2 id="Heading1">Chapter 12<br />
Pushing the 486</h2>
<h3><a id="Heading2"></a>It&rsquo;s Not Just a Bigger 386</h3>
<h3 id="Heading2">It&rsquo;s Not Just a Bigger 386</h3>
<p>So this traveling salesman is walking down a road, and he sees a group of men digging a ditch with their bare hands. &ldquo;Whoa, there!&rdquo; he says. &ldquo;What you guys need is a Model 8088 ditch digger!&rdquo; And he whips out a trowel and sells it to them.</p>
@ -52,13 +45,13 @@
<p>Substitute &ldquo;processor&rdquo; for the various digging implements, and you get an idea of just how different the optimization rules for the 486 are from what you&rsquo;re used to. Okay, it&rsquo;s not quite <i>that</i> bad&mdash;but upon encountering a processor where string instructions are often to be avoided and memory-to-register <b>MOV</b>s are frequently as fast as register-to-register <b>MOV</b>s, Dorothy was heard to exclaim (before she sank out of sight in a swirl of hopelessly mixed metaphors), &ldquo;I don&rsquo;t think we&rsquo;re in Kansas anymore, Toto.&rdquo;</p>
<h4 align="left"><a id="Heading3"></a>Enter the 486</h4>
<h4 align="left" id="Heading3">Enter the 486</h4>
<p>No chip that is a direct, fully compatible descendant of the 8088, 286, and 386 could ever be called a RISC chip, but the 486 certainly contains RISC elements, and it&rsquo;s those elements that are most responsible for making 486 optimization unique. Simple, common instructions are executed in a single cycle by a RISC-like core processor, but other instructions are executed pretty much as they were on the 386, where every instruction takes at least 2 cycles. For example, <b>MOV AL, [TestChar]</b> takes only 1 cycle on the 486, assuming both instruction and data are in the cache&mdash;3 cycles faster than the 386&mdash;but <b>STOSB</b> takes 5 cycles, 1 cycle <i>slower</i> than on the 386. The floating-point execution unit inside the 486 is also much faster than the 387 math coprocessor, largely because, being in the same silicon as the CPU (the 486 has a math coprocessor built in), it is more tightly coupled. The results are sometimes startling: <b>FMUL</b> (floating point multiply) is usually faster on the 486 than <b>IMUL</b> (integer multiply)!</p>
<p>An encyclopedic approach to 486 optimization would take a book all by itself, so in this chapter I&rsquo;m only going to hit the highlights of 486 optimization, touching on several optimization rules, some documented, some not. You might also want to check out the following sources of 486 information: <i>i486 Microprocessor Programmer&rsquo;s Reference Manual,</i> from Intel; &ldquo;8086 Optimization: Aim Down the Middle and Pray,&rdquo; in the March, 1991 <i>Dr. Dobb&rsquo;s Journal</i>; and &ldquo;Peak Performance: On to the 486,&rdquo; in the November, 1990 <i>Programmer&rsquo;s Journal.</i></p>
<h3><a id="Heading4"></a>Rules to Optimize By</h3>
<h3 id="Heading4">Rules to Optimize By</h3>
<p>In Appendix G of the <i>i486 Microprocessor Programmer</i>&rsquo;<i>s</i> <i>Reference Manual</i>, Intel lists a number of optimization techniques for the 486. While neither exhaustive (we&rsquo;ll look at two undocumented optimizations shortly) nor entirely accurate (we&rsquo;ll correct two of the rules here), Intel&rsquo;s list is certainly a good starting point. In particular, the list conveys the extent to which 486 optimization differs from optimization for earlier x86 processors. Generally, I&rsquo;ll be discussing optimization for real mode (it being the most widely used mode at the moment), although many of the rules should apply to protected mode as well.</p>
@ -72,7 +65,7 @@
<p>In other words, for cached code (which time-critical code almost always is), performance is predictable and can be calculated with good precision, and those calculations will apply on any 486. However, &ldquo;predictable&rdquo; doesn&rsquo;t mean &ldquo;trivial&rdquo;; the cycle times printed for the various instructions are not the whole story. You must be aware of all the rules, documented and undocumented, that go into calculating actual execution times&mdash;and uncovering some of those rules is exactly what this chapter is about.</p>
<h4 align="left"><a id="Heading5"></a>The Hazards of Indexed Addressing</h4>
<h4 align="left" id="Heading5">The Hazards of Indexed Addressing</h4>
<p>Rule #1: Avoid indexed addressing (that is, try not to use either two registers or scaled addressing to point to memory).</p>
@ -88,16 +81,16 @@
</tr>
</table>
<p>As an example, you might adhere to this rule by replacing the code</p><!-- CODE SNIP //-->
<p>As an example, you might adhere to this rule by replacing the code</p>
<pre>
LoopTop:
add ax,[bx+si]
add si,2
dec cx
jnz LoopTop
</pre><!-- END CODE SNIP //-->
</pre>
<p>with this</p><!-- CODE SNIP //-->
<p>with this</p>
<pre>
add si,bx
LoopTop:
@ -106,7 +99,7 @@ LoopTop:
dec cx
jnz LoopTop
sub si,bx
</pre><!-- END CODE SNIP //-->
</pre>
<p><br /></p>
@ -125,10 +118,6 @@ LoopTop:
<div align="center">
Graphics Programming Black Book &copy; 2001 Michael Abrash
</div><!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->
<!-- reference_footer = subfoot -->
<!-- BEGIN SUB FOOTER -->
<!-- END FOOTER -->
</div>
</body>
</html>