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
11-03.html
View file

@ -24,7 +24,7 @@
<!--CHAPTER=11//-->
<!--PAGES=212-216//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
<!--UNASSIGNED2//--></HEAD><body>
<CENTER>
<TABLE BORDER>
@ -55,7 +55,7 @@
</ul>
<P>Of course, those are exactly the rules that apply to 8088 optimization as well. Isn&rsquo;t it convenient that the same general rules apply across the board?
</P>
<H4 ALIGN="CENTER"><A NAME="Heading7"></A><FONT COLOR="#000077">Data Alignment</FONT></H4>
<H4 ALIGN="CENTER"><A NAME="Heading7"></A>Data Alignment</H4>
<P>Thanks to its 16-bit bus, the 286 can access word-sized memory variables just as fast as byte-sized variables. There&rsquo;s a catch, however: That&rsquo;s only true for word-sized variables that start at even addresses. When the 286 is asked to perform a word-sized access starting at an odd address, it actually performs two separate accesses, each of which fetches 1 byte, just as the 8088 does for all word-sized accesses.
</P>
<P>Figure 11.1 illustrates this phenomenon. The conversion of word-sized accesses to odd addresses into double byte-sized accesses is transparent to memory-accessing instructions; all any instruction knows is that the requested word has been accessed, no matter whether 1 word-sized access or 2 byte-sized accesses were required to accomplish it.</P>
@ -65,7 +65,7 @@
<P>That, in a nutshell, is the data alignment cycle-eater, the one new cycle-eater of the 286 and 386. (The data alignment cycle-eater is a close relative of the 8088&rsquo;s 8-bit bus cycle-eater, but since it behaves differently&mdash;occurring only at odd addresses&mdash;and is avoided with a different workaround, we&rsquo;ll consider it to be a new cycle-eater.)
</P>
<P><A NAME="Fig1"><!-- </A><A HREF="javascript:displayWindow('images/11-01.jpg',409,328 )"> --><IMG SRC="images/11-01.jpg"><BR><!-- </A>
<BR><A HREF="javascript:displayWindow('images/11-01.jpg',409,328)"> --><FONT COLOR="#000077"><B>Figure 11.1</B></FONT></A>&nbsp;&nbsp;<I>The data alignment cycle-eater.</I>
<BR><A HREF="javascript:displayWindow('images/11-01.jpg',409,328)"> --><B>Figure 11.1</B></A>&nbsp;&nbsp;<I>The data alignment cycle-eater.</I>
</P>
<P>The way to deal with the data alignment cycle-eater is straightforward: <I>Don&rsquo;t perform word-sized accesses to odd addresses on the 286 if you can help it</I>. The easiest way to avoid the data alignment cycle-eater is to place the directive <B>EVEN</B> before each of your word-sized variables. <B>EVEN</B> forces the offset of the next byte assembled to be even by inserting a <B>NOP</B> if the current offset is odd; consequently, you can ensure that any word-sized variable can be accessed efficiently by the 286 simply by preceding it with <B>EVEN</B>.</P>
<P>Listing 11.2, which accesses memory a word at a time with each word starting at an odd address, runs on a 10 MHz AT clone in 1.27 ms per repetition of <B>MOVSW</B>, or 0.64 ms per word-sized memory access. That&rsquo;s 6-plus cycles per word-sized access, which breaks down to two separate memory accesses&mdash;3 cycles to access the high byte of each word and 3 cycles to access the low byte of each word, the inevitable result of non-word-aligned word-sized memory accesses&mdash;plus a bit extra for DRAM refresh.</P>
@ -115,7 +115,7 @@ Skip:
<!-- END CODE //-->
<P>The data alignment cycle-eater has intriguing implications for speeding up 286/386 code. The expenditure of a little care and a few bytes to make sure that word-sized variables and memory blocks are word-aligned can literally double the performance of certain code running on the 286. Even if it doesn&rsquo;t double performance, word alignment usually helps and never hurts.
</P>
<H4 ALIGN="LEFT"><A NAME="Heading8"></A><FONT COLOR="#000077">Code Alignment</FONT></H4>
<H4 ALIGN="LEFT"><A NAME="Heading8"></A>Code Alignment</H4>
<P>Lack of word alignment can also interfere with instruction fetching on the 286, although not to the extent that it interferes with access to word-sized memory variables. The 286 prefetches instructions a word at a time; even if a given instruction doesn&rsquo;t begin at an even address, the 286 simply fetches the first byte of that instruction at the same time that it fetches the last byte of the previous instruction, as shown in Figure 11.2, then separates the bytes internally. That means that in most cases, instructions run just as fast whether they&rsquo;re word-aligned or not.
</P>
<P>There is, however, a non-word-alignment penalty on <I>branches</I> to odd addresses. On a branch to an odd address, the 286 is only able to fetch 1 useful byte with the first instruction fetch following the branch, as shown in Figure 11.3. In other words, lack of word alignment of the target instruction for any branch effectively cuts the instruction-fetching power of the 286 in half for the first instruction fetch after that branch. While that may not sound like much, you&rsquo;d be surprised at what it can do to tight loops; in fact, a brief story is in order.</P><P><BR></P>
@ -131,7 +131,7 @@ Skip:
<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 -->