153 lines
9.2 KiB
HTML
153 lines
9.2 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<META name=vsisbn content="1576101746">
|
|
<META name=vstitle content="Michael Abrash's Graphics Programming Black Book, Special Edition">
|
|
<META name=vsauthor content="Michael Abrash">
|
|
<META name=vspublisher content="The Coriolis Group">
|
|
<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.//-->
|
|
<!--CHAPTER=12//-->
|
|
<!--PAGES=237-241//-->
|
|
<!--UNASSIGNED1//-->
|
|
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
|
|
|
|
<CENTER>
|
|
<TABLE BORDER>
|
|
<TR>
|
|
<TD><A HREF="12-01.html">Previous</A></TD>
|
|
<TD><A HREF="index.html">Table of Contents</A></TD>
|
|
<TD><A HREF="12-03.html">Next</A></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CENTER>
|
|
<P><BR></P>
|
|
<P>which calculates the same sum and leaves the registers in the same state as the first example, but avoids indexed addressing.
|
|
</P>
|
|
<P>In protected mode, the definition of indexed addressing is a tad more complex. The use of two registers to address memory, as in <B>MOV EAX, [EDX+EDI]</B>, still qualifies for the one-cycle penalty. In addition, the use of 386/486 scaled addressing, as in <B>MOV [ECX*2],EAX</B>, also constitutes indexed addressing, even if only one register is used to point to memory.</P>
|
|
<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—if they’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>
|
|
<P>Rule #2: Don’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>
|
|
<P>Of course, the 486 <I>can’t</I> perform an effective address calculation for a target instruction ahead of time if one of the address components isn’t known until the instruction starts, and that’s exactly the case when the preceding instruction modifies one of the target instruction’s addressing registers. For example, in the code</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
MOV BX,OFFSET MemVar
|
|
MOV AX,[BX]
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>there’s no way that the 486 can calculate the address referenced by <B>MOV AX,[BX]</B> until <B>MOV BX,OFFSET MemVar</B> finishes, so pipelining that calculation ahead of time is not possible. A good workaround is rearranging your code so that at least one instruction lies between the loading of the memory pointer and its use. For example, postdecrementing, as in the following</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
LoopTop:
|
|
add ax,[si]
|
|
add si,2
|
|
dec cx
|
|
jnz LoopTop
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>is faster than preincrementing, as in:
|
|
</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
LoopTop:
|
|
add si,2
|
|
add ax,[SI]
|
|
dec cx
|
|
jnz LoopTop
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>Now that we understand what Intel means by this rule, let me make a very important comment: My observations indicate that for real-mode code, the documentation understates the extent of the penalty for interrupting the address calculation pipeline by loading a memory pointer just before it’s used.
|
|
</P>
|
|
<TABLE WIDTH="100%"><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="5%"><IMG SRC="images/12-03i.jpg"><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="95%"><SMALL><I>The truth of the matter appears to be that if a register is the destination of one instruction and is then used by the next instruction to address memory in real mode, not one but two cycles are lost!</I></SMALL>
|
|
</TABLE>
|
|
<P>In 32-bit protected mode, however, the penalty is, in fact, the 1 cycle that Intel .
|
|
</P>
|
|
<P>Considering that <B>MOV</B> normally takes only one cycle total, that’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’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> <I>One-cycle-ahead address pipelining.</I>
|
|
</P>
|
|
<P>the 2 are not always equivalent) before it’s used to point to memory, 1 cycle is lost. Therefore, whereas this code
|
|
</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
mov bx,offset MemVar
|
|
mov ax,[bx]
|
|
inc dx
|
|
dec cx
|
|
jnz LoopTop
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>loses two cycles from interrupting the address calculation pipeline, this code
|
|
</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
mov bx,offset MemVar
|
|
inc dx
|
|
mov ax,[bx]
|
|
dec cx
|
|
jnz LoopTop
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>loses only one cycle, and this code
|
|
</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
mov bx,offset MemVar
|
|
inc dx
|
|
dec cx
|
|
mov ax,[bx]
|
|
jnz LoopTop
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>loses no cycles at all. Apparently, the 486’s addressing calculation pipeline actually starts 2 cycles ahead, as shown in Figure 12.2. (In truth, my best guess at the moment is that the addressing pipeline really does start only 1 cycle ahead; the additional cycle crops up when the addressing pipeline has to wait for a register to be written into the register file before it can read it out for use in addressing calculations. However, I’m guessing here, and the 2-cycle-ahead model in Figure 12.2 will do just fine for optimization purposes.)
|
|
</P>
|
|
<P>Clearly, there’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> <I>Two-cycle-ahead address pipelining.</I>
|
|
</P>
|
|
<H3><A NAME="Heading7"></A><FONT COLOR="#000077">Caveat Programmor</FONT></H3>
|
|
<P>A caution: I’m quite certain that the 2-cycle-ahead addressing pipeline interruption penalty I’ve described exists in the two 486s I’ve tested. However, there’s no guarantee that Intel won’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’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’re well worth using.
|
|
</P><P><BR></P>
|
|
<CENTER>
|
|
<TABLE BORDER>
|
|
<TR>
|
|
<TD><A HREF="12-01.html">Previous</A></TD>
|
|
<TD><A HREF="index.html">Table of Contents</A></TD>
|
|
<TD><A HREF="12-03.html">Next</A></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CENTER>
|
|
|
|
<hr width="90%" size="1" noshade>
|
|
<div align="center">
|
|
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book © 2001 Michael Abrash</font>
|
|
</div>
|
|
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
|
|
<!-- reference_subfoot = footer -->
|
|
<!-- reference_footer = subfoot -->
|
|
|
|
<!-- BEGIN SUB FOOTER -->
|
|
</BODY>
|
|
</HTML>
|
|
|
|
<!-- END FOOTER -->
|
|
|
|
|