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

Change bold code snippets to inline code blocks

Browse source
This commit is contained in:
James Gregory 2013-12-31 17:12:29 +11:00
commit 3c76d884ef
185 changed files with 1772 additions and 1772 deletions
Download patch file Download diff file Expand all files Collapse all files

26
39-04.md
View file

@ -14,7 +14,7 @@ And indeed it does. When the test program is modified to draw to a local
buffer, both the C and assembly language versions get 0.29 seconds
faster, that being a measure of the time taken by display memory wait
states. With those wait states factored out, the assembly language
version of **DrawHorizontalLineList** becomes almost three times as fast
version of `DrawHorizontalLineList` becomes almost three times as fast
as the C code.
> ![](images/i.jpg)
@ -123,32 +123,32 @@ _DrawHorizontalLineList endp
#### Maximizing REP STOS {#Heading7}
Listing 39.3 doesn't take the easy way out and use **REP STOSB** to fill
each scan line; instead, it uses **REP STOSW** to fill as many pixel
pairs as possible via word-sized accesses, using **STOSB** only to do
Listing 39.3 doesn't take the easy way out and use `REP STOSB` to fill
each scan line; instead, it uses `REP STOSW` to fill as many pixel
pairs as possible via word-sized accesses, using `STOSB` only to do
odd bytes. Word accesses to odd addresses are always split by the
processor into 2-byte accesses. Such word accesses take twice as long as
word accesses to even addresses, so Listing 39.3 makes sure that all
word accesses occur at even addresses, by performing a leading **STOSB**
word accesses occur at even addresses, by performing a leading `STOSB`
first if necessary.
Listing 39.3 is another case in which it's worth knowing the environment
in which your code will run. Extra code is required to perform aligned
word-at-a-time filling, resulting in extra overhead. For very small or
narrow polygons, that overhead might overwhelm the advantage of drawing
a word at a time, making plain old **REP STOSB** faster.
a word at a time, making plain old `REP STOSB` faster.
### Faster Edge Tracing {#Heading8}
Finally, Listing 39.4 is an assembly language version of **ScanEdge**.
Finally, Listing 39.4 is an assembly language version of `ScanEdge`.
Listing 39.4 is a relatively straightforward translation from C to
assembly, but is nonetheless about twice as fast as Listing 39.2.
The version of **ScanEdge** in Listing 39.4 could certainly be sped up
still further by unrolling the loops. **FillConvexPolygon**, the overall
The version of `ScanEdge` in Listing 39.4 could certainly be sped up
still further by unrolling the loops. `FillConvexPolygon`, the overall
coordination routine, hasn't even been converted to assembly language,
so that could be sped up as well. I haven't bothered with these
optimizations because all code other than **DrawHorizontalLineList**
optimizations because all code other than `DrawHorizontalLineList`
takes only 14 percent of the overall polygon filling time when drawing
to display memory; the potential return on optimizing nondrawing code
simply isn't great enough to justify the effort. Part of the value of a
@ -162,9 +162,9 @@ overall time.
Again, *know where the cycles go* .
By the way, note that all the versions of **ScanEdge** and
**FillConvexPolygon** that we've looked at are adapter-independent, and
By the way, note that all the versions of `ScanEdge` and
`FillConvexPolygon` that we've looked at are adapter-independent, and
that the C code is also machine-independent; all adapter-specific code
is isolated in **DrawHorizontalLineList**. This makes it easy to add
is isolated in `DrawHorizontalLineList`. This makes it easy to add
support for other graphics systems, such as the 8514/A, the XGA, or, for
that matter, a completely non-PC system.