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

Convert notes into blockquotes

Browse source
This commit is contained in:
James Gregory 2013-12-31 11:06:31 +11:00
commit 8ed9dea394
105 changed files with 884 additions and 411 deletions
Download patch file Download diff file Expand all files Collapse all files

25
08-02.md
View file

@ -37,9 +37,11 @@ for the duration of the loop. But two far pointers used in the same loop
confuse every compiler I've seen, causing the full segment:offset
address to be reloaded each time either pointer is used.
------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
![](images/i.jpg) *This particularly affects performance in 286 protected mode (under OS/2 1.X or the Rational DOS Extender, for example) because segment loads in protected mode take a minimum of 17 cycles, versus a mere 2 cycles in real mode.*
------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> ![](images/i.jpg)
> This particularly affects performance in 286 protected mode (under OS/2
> 1.X or the Rational DOS Extender, for example) because segment loads in
> protected mode take a minimum of 17 cycles, versus a mere 2 cycles in
> real mode.
In assembly language you have full control over segments. Use it, and,
if necessary, reorganize your code to minimize segment loading.
@ -61,9 +63,11 @@ Am I saying that C compilers produce better code than you do? No, I'm
saying that they *can,* unless you use assembly language properly.
Writing code in assembly language rather than C guarantees nothing.
------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
![](images/i.jpg) *You can write good assembly, bad assembly, or assembly that is virtually indistinguishable from compiled code; you are more likely than not to write the latter if you think that optimization consists of tweaking compiled C code.*
------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> ![](images/i.jpg)
> You can write good assembly, bad assembly, or assembly that is virtually
> indistinguishable from compiled code; you are more likely than not to
> write the latter if you think that optimization consists of tweaking
> compiled C code.
Sure, you can probably use the registers more efficiently and take
advantage of an instruction or two that the compiler missed, but the
@ -109,9 +113,12 @@ enough, there's no reason why you can't reorganize the data. This might
mean removing the array elements from the structures and storing them in
their own array so that **REP SCASW** *could* be used.
------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
![](images/i.jpg) *Organizing a program's data so that the performance of the critical sections can be optimized is a key part of design, and one that's easily shortchanged unless, during the design stage, you thoroughly understand and work to bring together your data needs, the critical sections of your program, and potential assembly language optimizations.*
------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> ![](images/i.jpg)
> Organizing a program's data so that the performance of the critical
> sections can be optimized is a key part of design, and one that's easily
> shortchanged unless, during the design stage, you thoroughly understand
> and work to bring together your data needs, the critical sections of
> your program, and potential assembly language optimizations.
More on this shortly.