Make tables valid markdown

This commit is contained in:
James Gregory 2013-12-31 07:30:12 +11:00
commit 2091516544
13 changed files with 156 additions and 1002 deletions

View file

@ -10,89 +10,15 @@ chapter: '01'
pages: 010-013
---
* * * * *
| Listing | Borland | Microsoft | Borland | Microsoft | Assembly | Optimization Ratio |
|---------------------------------------|----------|-----------|---------|-----------|----------|--------------------|
| | (no opt) | (no opt) | (opt) | (opt) | | |
| 1 | 166.9 | 166.8 | 167.0 | 165.8 | 155.1 | 1.08 |
| 4 | 13.5 | 13.6 | 13.5 | 13.5 | ... | 1.01 |
| 5 | 4.7 | 5.5 | 3.8 | 3.4 | 2.7 | 2.04 |
| Ratio best designed to worst designed | 35.51 | 30.33 | 43.95 | 48.76 | 57.44 | |
Listing
Borland
Microsoft
Borland
Microsoft
Assembly
Optimization\
Ratio
* * * * *
(no opt)
(no opt)
(opt)
(opt)
1
166.9
166.8
167.0
165.8
155.1
1.08
4
13.5
13.6
13.5
13.5
...
1.01
5
4.7
5.5
3.8
3.4
2.7
2.04
Ratio best\
designed\
to worst\
designed
35.51
30.33
43.95
48.76
57.44
Table: Table 1.1 Execution Times for WordPerfect Checksum.
**Note:** The execution times (in seconds) for this chapter's listings
were timed when the compiled listings were run on the WordPerfect 4.2
@ -102,12 +28,6 @@ and off (no opt). All times were measured with Paradigm Systems' TIMER
program on a 10 MHz 1-wait-state AT clone with a 28-ms hard disk, with
disk caching turned off.
* * * * *
Table 1.1 Execution Times for WordPerfect Checksum.
* * * * *
**LISTING 1.2 L1-2.C**
/*

View file

@ -38,51 +38,14 @@ optimization, isn't it?
.code
public _FindIDAverage
* * * * *
| | On 20 MHz 386 | On 10 MHz 286 |
|------------------------------------------------------------|------------------|------------------|
| **Listing 8.1** (MSC with maximum optimization) | 294 microseconds | 768 microseconds |
| **Listing 8.3** (Assembly) | 265 | 644 |
| **Listing 8.4** (Optimized assembly) | 212 | 486 |
| **Listing 8.6** (Optimized assembly with reorganized data) | 100 | 207 |
On 20 MHz 386
On 10 MHz 286
* * * * *
**Listing 8.1**
294 microseconds
768 microseconds
(MSC with maximum optimization)
**Listing 8.3**
265
644
(Assembly)
**Listing 8.4**
212
486
(Optimized assembly)
**Listing 8.6**
100
207
(Optimized assembly with reorganized data)
* * * * *
Table 8.1 Execution Times of FindIDAverage.
* * * * *
Table: Table 8.1 Execution Times of FindIDAverage.
_FindIDAverage proc near
push bp ;Save caller's stack frame

138
10-02.md
View file

@ -42,130 +42,18 @@ poor when iS is large.
![](images/10-01.jpg)\
**Figure 10.1**  *Using a brute-force algorithm to find a GCD.*
* * * * *
**Integer pairs for which to find GCD**
Integer pairs for which to find GCD
| | 90 & 27 | 42 & 998 | 453 & 121 | 27432 & 165 | 27432 & 17550 |
|----------------------------------------------------------------------------------------|-------------|--------------|--------------|--------------|----------------|
| **Listing 10.1** (Brute force) | 60µs (100%) | 110µs (100%) | 311ms (100%) | 426µs (100%) | 43580µs (100%) |
| **Listing 10.2** (Subtraction) | 25 (42%) | 72 (65%) | 67 (22%) | 280 (66%) | 72 (0.16%) |
| **Listing 10.3** (Division: code recursive Euclid's algorithm) | 20 (33%) | 33 (30%) | 48 (15%) | 32 (8%) | 53 (0.12%) |
| **Listing 10.4** (C version of data recursive Euclid's algorithm; normal optimization) | 12 (20%) | 17 (15%) | 25 (8%) | 16 (4%) | 26 (0.06%) |
| **Listing 10.4** (/Ox = maximumoptimization) | 12 (20%) | 16 (15%) | 20 (6%) | 15 (4%) | 23 (0.05%) |
| **Listing 10.5** (Assembly version of data recursive Euclid's algorithm) | 10 (17%) | 10 (9%) | 15 (5%) | 10 (2%) | 17 (0.04%) |
90 & 27
42 & 998
453 & 121
27432 & 165
27432 & 17550
* * * * *
**Listing 10.1**\
(Brute force)
60µs\
(100%)
110µs\
(100%)
311ms\
(100%)
426µs\
(100%)
43580µs\
(100%)
**Listing 10.2**\
(Subtraction)
25\
(42%)
72\
(65%)
67\
(22%)
280\
(66%)
72\
(0.16%)
**Listing 10.3**\
(Division: code recursive\
Euclid's algorithm)
20\
(33%)
33\
(30%)
48\
(15%)
32\
(8%)
53\
(0.12%)
**Listing 10.4**\
(C version of data recursive Euclid's algorithm; normal optimization)
12\
(20%)
17\
(15%)
25\
(8%)
16\
(4%)
26\
(0.06%)
**Listing 10.4**\
(/Ox = maximumoptimization)
12\
(20%)
16\
(15)
20\
(6%)
15\
(4%)
23\
(0.05%)
**Listing 10.5**\
(Assembly version of data recursive Euclid's algorithm)
10\
(17%)
10\
(9%)
15\
(5%)
10\
(2%)
17\
(0.04%)
Table: Table 10.1 Performance of GCD algorithm implementations.
**Note:** Performance of Listings 10.1 through 10.5 in finding the
greatest common divisors of various pairs of integers. Times are in
@ -175,12 +63,6 @@ the execution time of Listing 10.1 for the same integer pair. Listings
default optimization was used. All times measured with the Zen timer
(from Chapter 3) on a 20 MHz cached 386.
* * * * *
Table 10.1 Performance of GCD algorithm implementations.
* * * * *
**LISTING 10.1 L10-1.C**
/* Finds and returns the greatest common divisor of two positive

128
14-03.md
View file

@ -24,130 +24,22 @@ somewhat faster. Regardless, the far superior performance of **REPNZ
SCASB** clearly indicates that assembly language is in order at this
point.
* * * * *
| | "g;" | "Yogi" | "igoY" | "Adrian" | "Conclusion" | "You don't know what you know" |
|--------------------------------------------------------------------|-------|--------|--------|----------|--------------|--------------------------------|
| Searching approach | (16K) | (16K) | (16K) | (\<1K) | (16K) | (16K) |
| REPNZ SCASB on first char a (Listing 9.1) | 8.2 | 7.5 | 9.7 | 0.4 | 7.4 | 8.1 |
| REPNZ SCASB on least common char (Listing 9.2) | 7.6 | 7.5 | 7.5 | 0.5 | 7.5 | 7.5 |
| Boyer-Moore in C (Listing 14.1) | 71.0 | 38.4 | 37.7 | 1.8 | 18.2 | 9.2 |
| Standard Boyer-Moore in ASM (code not shown) | 38.5 | 21.0 | 20.5 | 0.8 | 9.4 | 4.8 |
| Quick handling of first mismatch Boyer-Moore in ASM (Listing 14.3) | 14.1 | 8.9 | 7.7 | 0.4 | 4.0 | 2.0 |
| \<=255 pattern length + sentinelBoyer-Moore in ASM (Listing 14.4) | 8.1 | 5.2 | 4.6 | 0.3 | 2.6 | 1.2 |
"g;"
"Yogi"
"igoY"
"Adrian"
"Conclusion"
"You don't know what you know"
* * * * *
Searching approach
(16K)
(16K)
(16K)
(\<1K)
(16K)
(16K)
REPNZ SCASB on first char a(Listing 9.1)
8.2
7.5
9.7
0.4
7.4
8.1
REPNZ SCASB on least common char (Listing 9.2)
7.6
7.5
7.5
0.5
7.5
7.5
Boyer-Moore in C (Listing 14.1)
71.0
38.4
37.7
1.8
18.2
9.2
Standard Boyer-Moore in ASM(code not shown)
38.5
21.0
20.5
0.8
9.4
4.8
Quick handling of first mismatch Boyer-Moore in ASM(Listing 14.3)
14.1
8.9
7.7
0.4
4.0
2.0
\<=255 pattern length + sentinelBoyer-Moore in ASM(Listing 14.4)
8.1
5.2
4.6
0.3
2.6
1.2
Table: Table 14.1 Comparison of searching techniques.
Search pattern (approximate distance searched before match is shown in
parentheses).\
Times are in milliseconds; shorter is better.
* * * * *
Table 14.1 Comparison of searching techniques.
* * * * *
The entry "Standard Boyer-Moore in ASM" in Table 14.1 refers to
straight-forward hand optimization of Listing 14.1, code that is not
included in this chapter for the perfectly good reason that it is slower

View file

@ -85,33 +85,17 @@ consistent times—no seek times, rotational latency, or cache to muddy
the waters—and partly to highlight word-counting speed rather than disk
access speed.
* * * * *
| Listing | Time to Count Words |
|------------------------------|---------------------|
| 16.1 (C) | 4.6 seconds |
| 16.2 & 16.3 (C+ASM) | 2.4 seconds |
| 16.2 & 16.4 (C+ASM w/lookup) | 1.6 seconds |
Listing
Time to Count Words
* * * * *
16.1 (C)
4.6 seconds
16.2 & 16.3 (C+ASM)
2.4 seconds
16.2 & 16.4 (C+ASM w/lookup)
1.6 seconds
Table: Table 16.1 Word count timings.
These are the times taken to search a file containing 104,448 words,
timed from a RAM disk on a 20 MHz 386.
Table 16.1 Word count timings.
* * * * *
**LISTING 16.1 L16-1.C**
/* Word-counting program. Tested with Borland C++ in C

View file

@ -18,70 +18,22 @@ the time perceived by the user, but the second value best reflects the
quality of the optimization in each entry, since the rest of the overall
execution time is fixed.
* * * * *
**Word-Counting Time**
Word-Counting Time
| Name | Overall time | (ScanBuffer only) |
|-------------------------------------------|--------------|-------------------|
| David Stafford Listing 16.5 | 0.61 seconds | 0.33 seconds |
| Dave Methvin | 0.66 | 0.39 |
| Mick Brown | 0.70 | 0.41 |
| Wendell Neubert | 0.92 | 0.65 |
| **For Comparison:** | | |
| Michael Abrash assembly code Listing 16.1 | 1.73 | 1.44 |
| Michael Abrash C code Listing 16.4 | 4.70 | 4.43 |
Name
Overall time
(ScanBuffer only)
* * * * *
David Stafford Listing 16.5
0.61 seconds
0.33 seconds
Dave Methvin
0.66
0.39
Mick Brown
0.70
0.41
Wendell Neubert
0.92
0.65
**For Comparison:**
Michael Abrash
1.73
1.44
assembly code
Listing 16.1
Michael Abrash
4.70
4.43
C code
Listing 16.4
Table: Table 16.2 The top four word-counting entries.
**Note:** All times measured on a 20 MHz cached 386 DX.
Table 16.2 The top four word-counting entries.
* * * * *
**LISTING 16.5 QSCAN3.ASM**
; QSCAN3.ASM

View file

@ -33,85 +33,18 @@ gains out of going to a Ping-Pong arrangement so that I didn't have to
copy the new cellmap back to **current\_map** after calculating the next
generation.
* * * * *
| | Listing 17.1 | Listing 17.3 | Listing 17.4 |
|--------------------------|--------------|--------------|--------------|
| **Total execution time** | 340 secs | 94 secs | 45 secs |
| **cell\_state()** | 275 | 21 | — |
| **next\_generation()** | 60 | 14 | 40 |
| **count\_neighbors()** | — | 54 | — |
| **draw\_pixel()** | 2 | 2 | 2 |
| **set\_cell()** | <1 | <1 | <1 |
| **clear\_cell()** | <1 | <1 | <1 |
| **copy\_cells()** | <1 | <1 | <1 |
Listing 17.1
Listing 17.3
Listing 17.4
* * * * *
**Total execution time**
340 secs
94 secs
45 secs
**cell\_state()**
275
21
**next\_generation()**
60
14
40
**count\_neighbors()**
54
**draw\_pixel()**
2
2
2
**set\_cell()**
\<1
\<1
\<1
**clear\_cell()**
\<1
\<1
\<1
**copy\_cells()**
\<1
\<1
\<1
* * * * *
Table 17.1 Execution times for the game of life.
* * * * *
Table: Table 17.1 Execution times for the game of life.
I was wrong. Wrong, wrong, wrong. (But at least I was smart enough to
use a profiler before actually writing any new code.) Table 17.1 shows

View file

@ -45,8 +45,6 @@ to QLIFE.ASM, and look at the assembly code in that file. This code is
the entirety of David's generation engine, and it's almost impossible to
visualize its operation without actually seeing it.
> * * * * *
>
> How To Build Qlife
>
> QLIFE is written for Borland C++, but it shouldn't be too difficult to
@ -54,13 +52,13 @@ visualize its operation without actually seeing it.
> BUILD.BAT batch file with the size of the life grid on the command
> line (see below). The command-line options are:
>
> -- ----------- -------------------------------------------------------------
> WIDTH 32 Sets the width of the life grid to 96 cells (divided by 3).
> HEIGHT 96 Sets the height of the life grid to 96 cells.
> NOCOUNTER Turns off the generation counter (optional).
> NODRAW Turns off drawing of the cell map (optional).
> GEN 1000 Calculates 1,000 generations (optional).
> -- ----------- -------------------------------------------------------------
> --------- -----------------------------------------------------------
> WIDTH 32 Sets the width of the life grid to 96 cells (divided by 3).
> HEIGHT 96 Sets the height of the life grid to 96 cells.
> NOCOUNTER Turns off the generation counter (optional).
> NODRAW Turns off drawing of the cell map (optional).
> GEN 1000 Calculates 1,000 generations (optional).
> --------- -----------------------------------------------------------
>
> These *must* be in uppercase. For example, the minimum you really need
> is "WIDTH 40 HEIGHT 120." I used "WIDTH 46 HEIGHT 138 NOCOUNTER NODRAW
@ -85,6 +83,4 @@ visualize its operation without actually seeing it.
> earlier CPUs if you wish. QLIFE works best if you have a large CPU
> cache (256K is recommended).
>
> —*David Stafford*
>
> * * * * *
> —*David Stafford*

View file

@ -49,75 +49,25 @@ every **OUT** to 3C0H, and resets to Index mode (in which the Index
register is programmed by the next **OUT** to 3C0H) on every read from
the Input Status 1 register (3DAH when the VGA is in a color mode,
* * * * *
| Register | Address |
|---------------------------------------------|--------------------------|
| AC Index/Data register | 3C0H (write with toggle) |
| AC Index register | 3C0H (read) |
| AC Data register | 3C1H (read) |
| Miscellaneous Output register | 3C2H (write) |
| | 3CCH (read) |
| Input Status 0 register | 3C2H (read) |
| SC Index register | 3C4H (read/write) |
| SC Data register | 3C5H (read/write) |
| GC Index register | 3CEH (read/write) |
| GC Data register | 3CFH (read/write) |
| CRTC Index register | 3B4H/3D4H (read/write) |
| CRTC Data register | 3B5H/3D5H (read/write) |
| Input Status 1 register/AC Index/Data reset | 3 BAH/3DAH (read) |
| Feature Control | 3BAH/3DAH (write) |
| | 3CAH (read) |
Register
Address
* * * * *
AC Index/Data register
3C0H (write with toggle)
AC Index register
3C0H (read)
AC Data register
3C1H (read)
Miscellaneous Output register
3C2H (write)
3CCH (read)
Input Status 0 register
3C2H (read)
SC Index register
3C4H (read/write)
SC Data register
3C5H (read/write)
GC Index register
3CEH (read/write)
GC Data register
3CFH (read/write)
CRTC Index register
3B4H/3D4H (read/write)
CRTC Data register
3B5H/3D5H (read/write)
Input Status 1 register/
AC Index/Data reset
3 BAH/3DAH (read)
Feature Control
3BAH/3DAH (write)
3CAH (read)
Table 1.1 The Ports through which the VGA is controlled.
* * * * *
Table: Table 1.1 The Ports through which the VGA is controlled.
3BAH in monochrome modes). Note that all CRTC registers are addressed at
either 3DXH or 3BXH, the former in color modes and the latter in

131
39-02.md
View file

@ -21,120 +21,19 @@ with Borland C++, but may not work with other compilers, for it relies
on the aforementioned interaction between memset and the selected memory
model.
* * * * *
| Implementation | Total Polygon Filling Time | DrawHorizontal LineList | ScanEdge | FillConvex Polygon |
|-----------------------------------------------------------------------------|----------------------------|-----------------------------|------------|--------------------|
| Drawing to display memory in mode 13h | | | | |
| C floating point scan/DrawPixel drawing code from Chapter 38, (small model) | 11.69 | 5.80 seconds (50% of total) | 5.86 (50%) | 0.03 (<1%) |
| C floating point scan/memset drawing (Listing 39.1, compact model) | 6.64 | 0.49 (7%) | 6.11 (92%) | 0.04 (<1%) |
| C integer scan/memset drawing (Listing 39.1 & Listing 39.2, compact model) | 0.60 | 0.49 (82%) | 0.07 (12%) | 0.04 (7%) |
| C integer scan/ASM drawing (Listing 39.2 & Listing 39.3, small model) | 0.45 | 0.36 (80%) | 0.06 (13%) | 0.03 (7%) |
| ASM integer scan/ASM drawing (Listing 40.3 & Listing 40.4, small model) | 0.42 | 0.36 (86%) | 0.03 (7%) | 0.03 (7%) |
| Drawing to system memory | | | | |
| C integer scan/memset drawing (Listing 39.1 & Listing 39.2, compact model) | 0.31 | 0.20 (65%) | 0.07 (23%) | 0.04 (13%) |
| ASM integer scan/ASM drawing (Listing 39.3 & Listing 39.4, small model) | 0.13 | 0.07 (54%) | 0.03 (23%) | 0.03 (23%) |
Implementation
Total Polygon\
Filling Time
DrawHorizontal\
LineList
ScanEdge
FillConvex\
Polygon
* * * * *
Drawing to display memory in mode 13h
C floating point scan/DrawPixel drawing code from Chapter 38, (small
model)
11.69
5.80 seconds\
(50% of total)
5.86\
(50%)
0.03\
(\<1%)
C floating point scan/memset drawing (Listing 39.1, compact model)
6.64
0.49\
(7%)
6.11\
(92%)
0.04\
(\<1%)
C integer scan/memset drawing (Listing 39.1 & Listing 39.2, compact
model)
0.60
0.49\
(82%)
0.07\
(12%)
0.04\
(7%)
C integer scan/ASM drawing (Listing 39.2 & Listing 39.3, small model)
0.45
0.36\
(80%)
0.06\
(13%)
0.03\
(7%)
ASM integer scan/ASM drawing (Listing 40.3 & Listing 40.4,small model)
0.42
0.36\
(86%)
0.03\
(7%)
0.03\
(7%)
Drawing to system memory
C integer scan/memset drawing (Listing 39.1 & Listing 39.2,compact
model)
0.31
0.20\
(65%)
0.07\
(23%)
0.04\
(13%)
ASM integer scan/ASM drawing (Listing 39.3 & Listing 39.4,small model)
0.13
0.07\
(54%)
0.03\
(23%)
0.03\
(23%)
Table: Table 39.1 Polygon fill performance.
All times are in seconds, as measured with Turbo Profiler on a 20-MHz
cached 386 with no math coprocessor installed. Note that time spent in
@ -144,12 +43,6 @@ assembled with TASM. Percentages of combined times are rounded to the
nearest percent, so the sum of the three percentages does not always
equal 100.
* * * * *
Table 39.1 Polygon fill performance.
* * * * *
**LISTING 39.1 L39-1.C**
/* Draws all pixels in the list of horizontal lines passed in, in

131
43-02.md
View file

@ -53,118 +53,27 @@ want, which is an approach that keeps images in one plane from
interfering with images in other planes while providing precedence and
transparency.
* * * * *
| Bit Value For Plane\
3 2 1 0 | Palette Register | Register setting |
|-----------------------------|------------------|------------------|
| 0 0 0 0 | 0 | 00H (black) |
| 0 0 0 1 | 1 | 3CH (red) |
| 0 0 1 0 | 2 | 3AH (green) |
| 0 0 1 1 | 3 | 3CH (red) |
| 0 1 0 0 | 4 | 39H (blue) |
| 0 1 0 1 | 5 | 3CH (red) |
| 0 1 1 0 | 6 | 3AH (green) |
| 0 1 1 1 | 7 | 3CH (red) |
| 1 0 0 0 | 8 | 3FH (white) |
| 1 0 0 1 | 9 | 3CH (red) |
| 1 0 1 0 | 10 | 3AH (green) |
| 1 0 1 1 | 11 | 3CH (red) |
| 1 1 0 0 | 12 | 39H (blue) |
| 1 1 0 1 | 13 | 3CH (red) |
| 1 1 1 0 | 14 | 3AH (green) |
| 1 1 1 1 | 15 | 3CH (red) |
Bit Value For Plane\
3 2 1 0
Palette Register
Register setting
* * * * *
0 0 0 0
0
00H (black)
0 0 0 1
1
3CH (red)
0 0 1 0
2
3AH (green)
0 0 1 1
3
3CH (red)
0 1 0 0
4
39H (blue)
0 1 0 1
5
3CH (red)
0 1 1 0
6
3AH (green)
0 1 1 1
7
3CH (red)
1 0 0 0
8
3FH (white)
1 0 0 1
9
3CH (red)
1 0 1 0
10
3AH (green)
1 0 1 1
11
3CH (red)
1 1 0 0
12
39H (blue)
1 1 0 1
13
3CH (red)
1 1 1 0
14
3AH (green)
1 1 1 1
15
3CH (red)
* * * * *
Table 43.1 Palette RAM settings for bit-plane animation.
* * * * *
Table: Table 43.1 Palette RAM settings for bit-plane animation.
![](images/43-04.jpg)\
**Figure 43.4**  *How pixel precedence works.*

View file

@ -14,83 +14,26 @@ Another limitation of bit-plane animation is that it's best if images
stored in the same plane never cross each other. Why? Because when
images do cross, the blank fringe
* * * * *
| Palette Register | Register Setting |
|------------------|------------------|
| 0 | 00H (black) |
| 1 | 01H (blue) |
| 2 | 02H (green) |
| 3 | 03H (cyan) |
| 4 | 04H (red) |
| 5 | 05H (magenta) |
| 6 | 14H (brown) |
| 7 | 07H (light gray) |
| 8 | 3EH (yellow) |
| 9 | 3EH (yellow) |
| 10 | 3EH (yellow) |
| 11 | 13EH (yellow) |
| 12 | 3EH (yellow) |
| 13 | 3EH (yellow) |
| 14 | 3EH (yellow) |
| 15 | 3EH (yellow) |
Palette Register
Register Setting
* * * * *
0
00H (black)
1
01H (blue)
2
02H (green)
3
03H (cyan)
4
04H (red)
5
05H (magenta)
6
14H (brown)
7
07H (light gray)
8
3EH (yellow)
9
3EH (yellow)
10
3EH (yellow)
1
13EH (yellow)
12
3EH (yellow)
13
3EH (yellow)
14
3EH (yellow)
15
3EH (yellow)
* * * * *
Table 43.2 Palette RAM settings for two-plane animation.
* * * * *
Table: Table 43.2 Palette RAM settings for two-plane animation.
around each image can temporarily erase the overlapped parts of the
other image or images, resulting in momentary flicker. While that's not

View file

@ -24,80 +24,17 @@ thumb for VGA reads, although there's considerable variation. So VGA
memory tends not to be as bad as VGA I/O, but lord knows it isn't
*good*.
* * * * *
**OUT Time in Microseconds and Cycles**
OUT Time in Microseconds and Cycles
| OUT Instruction | Official Time | 486 #1/16-bit VGA #1 | 486 #2/16-bit VGA #2 |
|-----------------|---------------|----------------------|----------------------|
| OUT DX,AL repeated 1,000 times nonstop (maximum byte access) | 0.300s 10 cycles | 2.546s 84 cycles | 0.813s 27 cycles |
| OUT DX,AX repeated 1,000 times nonstop (maximum word access) | 0.300s 10 cycles | 3.820s 126 cycles | 1.066s 35 cycles |
| OUT DX,AL repeated 1,000 times, but interspersed with MULs (random byte access) | 0.300s 10 cycles | 1.610s 53 cycles | 0.780s 26 cycles |
| OUT DX,AX repeated 1,000 times, but interspersed with MULs (random word access) | 0.300s 10 cycles | 2.830s 93 cycles | 1.010s 33 cycles |
OUT Instruction
Official Time
486 \#1/16-bit VGA \#1
486 \#2/16-bit VGA \#2
* * * * *
OUT DX,AL
repeated 1,000 times nonstop\
(maximum byte access)
0.300 s\
10 cycles
2.546 s\
84 cycles
0.813 s\
27 cycles
OUT DX,AX
repeated 1,000 times nonstop\
(maximum word access)
0.300 s\
10 cycles
3.820 s\
126 cycles
1.066 s\
35 cycles
OUT DX,AL
repeated 1,000 times,\
but interspersed with MULs\
(random byte access)
0.300 s\
10 cycles
1.610 s\
53 cycles
0.780 s\
26 cycles
OUT DX,AX
repeated 1,000 times,\
but interspersed with MULs\
(random word access)
0.300 s\
10 cycles
2.830 s\
93 cycles
1.010 s\
33 cycles
**Table 45.1 Results of I/O performance tests run under the Phar
Lap386|DOS-Extender.**
Table: Table 45.1 Results of I/O performance tests run under the Phar
Lap386|DOS-Extender.
* * * * *