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

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

View file

@ -24,7 +24,7 @@
<!--CHAPTER=12//-->
<!--PAGES=237-241//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
<!--UNASSIGNED2//--></HEAD><body>
<CENTER>
<TABLE BORDER>
@ -42,7 +42,7 @@
<P>All this fuss over one cycle! You might well wonder how much difference one cycle could make. After all, on the 8088, effective address calculations take a <I>minimum</I> of 5 cycles. On the 486, however, 1 cycle is a big deal because many instructions, including most register-only instructions (<B>MOV</B>, <B>ADD</B>, <B>CMP</B>, and so on) execute in just 1 cycle. In particular, <B>MOV</B>s to and from memory execute in 1 cycle&mdash;if they&rsquo;re not hampered by something like indexed addressing, in which case they slow to half speed (or worse, as we will see shortly).</P>
<P>For example, consider the summing example shown earlier. The version that uses base+index ([BX+SI]) addressing executes in eight cycles per loop. As expected, the version that uses base ([SI]) addressing runs one cycle faster, at seven cycles per loop. However, the loop code executes so fast on the 486 that the single cycle saved by using base addressing makes the <I>whole loop</I> more than 14 percent faster.</P>
<P>In a key loop on the 486, 1 cycle can indeed matter.</P>
<H4 ALIGN="LEFT"><A NAME="Heading6"></A><FONT COLOR="#000077">Calculate Memory Pointers Ahead of Time</FONT></H4>
<H4 ALIGN="LEFT"><A NAME="Heading6"></A>Calculate Memory Pointers Ahead of Time</H4>
<P>Rule #2: Don&rsquo;t use a register as a memory pointer during the next two cycles after loading it.
</P>
<P>Intel states that if the destination of one instruction is used as the base addressing component of the next instruction, then a one-cycle penalty is imposed. This rule, unlike anything ever before seen in the x86 family, reflects the heavily pipelined nature of the 486. Apparently, the 486 starts each effective address calculation before the start of the instruction that will need it, as shown in Figure 12.1; this effectively makes the address calculation time vanish, because it happens while the preceding instruction executes.</P>
@ -82,7 +82,7 @@ LoopTop:
</P>
<P>Considering that <B>MOV</B> normally takes only one cycle total, that&rsquo;s quite a loss. For example, the postdecrement loop shown above is 2 full cycles faster than the preincrement loop, resulting in a 29 percent improvement in the performance of the entire loop. But wait, there&rsquo;s more. If a register is loaded 2 cycles (which generally means 2 instructions, but, because some 486 instructions take more than 1 cycle,</P>
<P><A NAME="Fig1"><!-- </A><A HREF="javascript:displayWindow('images/12-01.jpg',407,155 )"> --><IMG SRC="images/12-01.jpg"><BR><!-- </A>
<BR><A HREF="javascript:displayWindow('images/12-01.jpg',407,155)"> --><FONT COLOR="#000077"><B>Figure 12.1</B></FONT></A>&nbsp;&nbsp;<I>One-cycle-ahead address pipelining.</I>
<BR><A HREF="javascript:displayWindow('images/12-01.jpg',407,155)"> --><B>Figure 12.1</B></A>&nbsp;&nbsp;<I>One-cycle-ahead address pipelining.</I>
</P>
<P>the 2 are not always equivalent) before it&rsquo;s used to point to memory, 1 cycle is lost. Therefore, whereas this code
</P>
@ -121,9 +121,9 @@ jnz LoopTop
</P>
<P>Clearly, there&rsquo;s considerable optimization potential in careful rearrangement of 486 code.</P>
<P><A NAME="Fig2"><!-- </A><A HREF="javascript:displayWindow('images/12-02.jpg',411,158 )"> --><IMG SRC="images/12-02.jpg"><BR><!-- </A>
<BR><A HREF="javascript:displayWindow('images/12-02.jpg',411,158)"> --><FONT COLOR="#000077"><B>Figure 12.2</B></FONT></A>&nbsp;&nbsp;<I>Two-cycle-ahead address pipelining.</I>
<BR><A HREF="javascript:displayWindow('images/12-02.jpg',411,158)"> --><B>Figure 12.2</B></A>&nbsp;&nbsp;<I>Two-cycle-ahead address pipelining.</I>
</P>
<H3><A NAME="Heading7"></A><FONT COLOR="#000077">Caveat Programmor</FONT></H3>
<H3><A NAME="Heading7"></A>Caveat Programmor</H3>
<P>A caution: I&rsquo;m quite certain that the 2-cycle-ahead addressing pipeline interruption penalty I&rsquo;ve described exists in the two 486s I&rsquo;ve tested. However, there&rsquo;s no guarantee that Intel won&rsquo;t change this aspect of the 486 in the future, especially given that the documentation indicates otherwise. Perhaps the 2-cycle penalty is the result of a bug in the initial steps of the 486, and will revert to the documented 1-cycle penalty someday; likewise for the undocumented optimizations I&rsquo;ll describe below. Nonetheless, none of the optimizations I suggest would hurt performance even if the undocumented performance characteristics of the 486 were to vanish, and they certainly will help performance on at least some 486s right now, so I feel they&rsquo;re well worth using.
</P><P><BR></P>
<CENTER>
@ -138,7 +138,7 @@ jnz LoopTop
<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 -->