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

Deduped images

Browse source
This commit is contained in:
James Gregory 2013-12-30 12:25:34 +11:00
commit 9e52de9586
233 changed files with 128 additions and 128 deletions
Download patch file Download diff file Expand all files Collapse all files

4
11-04.html
View file

@ -67,7 +67,7 @@ LoopTop:
</PRE>
<!-- END CODE SNIP //-->
<P>While word-aligning branch destinations can improve branching performance, it&#146;s a nuisance and can increase code size a good deal, so it&#146;s not worth doing in most code. Besides, <B>EVEN</B> inserts a <B>NOP</B> instruction if necessary, and the time required to execute a <B>NOP</B> can sometimes cancel the performance advantage of having a word-aligned branch destination.</P>
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/11-03i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>Consequently, it&#146;s best to word-align only those branch destinations that can be reached solely by branching.</I></SMALL>
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>Consequently, it&#146;s best to word-align only those branch destinations that can be reached solely by branching.</I></SMALL>
</TABLE>
<P>I recommend that you only go out of your way to word-align the start offsets of your subroutines, as in:
</P>
@ -88,7 +88,7 @@ FindChar proc near
<H4 ALIGN="CENTER"><A NAME="Heading10"></A><FONT COLOR="#000077">Alignment and the Stack</FONT></H4>
<P>One side-effect of the data alignment cycle-eater of the 286 and 386 is that you should <I>never</I> allow the stack pointer to become odd. (You can make the stack pointer odd by adding an odd value to it or subtracting an odd value from it, or by loading it with an odd value.) An odd stack pointer on the 286 or 386 (or a non-doubleword-aligned stack in 32-bit protected mode on the 386, 486, or Pentium) will significantly reduce the performance of <B>PUSH,</B> <B>POP,</B> <B>CALL</B>, and <B>RET</B>, as well as <B>INT</B> and <B>IRET</B>, which are executed to invoke DOS and BIOS functions, handle keystrokes and incoming serial characters, and manage the mouse. I know of a Forth programmer who vastly improved the performance of a complex application on the AT simply by forcing the Forth interpreter to maintain an even stack pointer at all times.</P>
<P>An interesting corollary to this rule is that you shouldn&#146;t <B>INC SP</B> twice to add 2, even though that takes fewer bytes than <B>ADD SP,2</B>. The stack pointer is odd between the first and second <B>INC</B>, so any interrupt occurring between the two instructions will be serviced more slowly than it normally would. The same goes for decrementing twice; use <B>SUB SP,2</B> instead.</P>
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/11-04i.jpg"><TD WIDTH="95%" ALIGN="LEFT" VALIGN="TOP"><SMALL><I>Keep the stack pointer aligned at all times.</I></SMALL>
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/i.jpg"><TD WIDTH="95%" ALIGN="LEFT" VALIGN="TOP"><SMALL><I>Keep the stack pointer aligned at all times.</I></SMALL>
</TABLE>
<H4 ALIGN="CENTER"><A NAME="Heading11"></A><FONT COLOR="#000077">The DRAM Refresh Cycle-Eater: Still an Act of God</FONT></H4>
<P>The DRAM refresh cycle-eater is the cycle-eater that&#146;s least changed from its 8088 form on the 286 and 386. In the AT, DRAM refresh uses a little over five percent of all available memory accesses, slightly less than it uses in the PC, but in the same ballpark. While the DRAM refresh penalty varies somewhat on various AT clones and 386 computers (in fact, a few computers are built around static RAM, which requires no refresh at all; likewise, caches are made of static RAM so cached systems generally suffer less from DRAM refresh), the 5 percent figure is a good rule of thumb.