Normal quotes

This commit is contained in:
James Gregory 2013-12-30 18:34:31 +11:00
commit 18011c595a
352 changed files with 6040 additions and 6040 deletions

View file

@ -34,12 +34,12 @@
.code
public _Div
_Divprocnear
push bp ;preserve caller’s stack frame
push bp ;preserve caller's stack frame
mov bp,sp ;point to our stack frame
push si ;preserve caller’s register variables
push si ;preserve caller's register variables
push di
std ;we’re working from msb to lsb
std ;we're working from msb to lsb
mov ax,ds
mov es,ax ;for STOS
mov cx,[bp+DividendLength]
@ -64,9 +64,9 @@
loop DivLoop
mov ax,dx ;return the remainder
cld ;restore default Direction flag setting
pop di ;restore caller’s register variables
pop di ;restore caller's register variables
pop si
pop bp ;restore caller’s stack frame
pop bp ;restore caller's stack frame
ret
_Divendp
end
@ -74,7 +74,7 @@
**LISTING 9.6 L9-6.C**
/* Sample use of Div function to perform division when the result
doesn’t fit in 16 bits */
doesn't fit in 16 bits */
#include <stdio.h>
@ -87,15 +87,15 @@
unsigned int k, j = 0x10;
k = Div((unsigned int *)&i, sizeof(i), j, (unsigned int *)&m);
printf(“%lu / %u = %lu r %u\n”, i, j, m, k);
printf("%lu / %u = %lu r %u\n", i, j, m, k);
}
#### Sweet Spot Revisited {#Heading9}
Way back in Volume 1, Number 1 of *PC TECHNIQUES*, (April/May 1990) I
wrote the very first of that magazine’s HAX (\#1), which extolled the
wrote the very first of that magazine's HAX (\#1), which extolled the
virtues of placing your most commonly-used automatic (stack-based)
variables within the stack’s “sweet spot,” the area between +127 to -128
variables within the stack's "sweet spot," the area between +127 to -128
bytes away from BP, the stack frame pointer. The reason was that the
8088 can store addressing displacements that fall within that range in a
single byte; larger displacements require a full word of storage,
@ -117,19 +117,19 @@ on the processor, the memory architecture, and the code mix. On a 486,
prefix bytes often cost a cycle; on a 386SX, increased code size often
slows performance because instructions must be fetched through the
half-pint 16-bit bus; on a 386, the effect depends on the instruction
mix and whether there’s a cache.
mix and whether there's a cache.
------------------- ----------------------------------------------------------------------------------------------------------------------------------------------
![](images/i.jpg) *On balance, though, it’s as important to keep your most-used variables in the stack’s sweet spot in 386 native mode as it was on the 8088.*
![](images/i.jpg) *On balance, though, it's as important to keep your most-used variables in the stack's sweet spot in 386 native mode as it was on the 8088.*
------------------- ----------------------------------------------------------------------------------------------------------------------------------------------
In assembly, it’s easy to control the organization of your stack frame.
In C, however, you’ll have to figure out the allocation scheme your
In assembly, it's easy to control the organization of your stack frame.
In C, however, you'll have to figure out the allocation scheme your
compiler uses to allocate automatic variables, and declare automatics
appropriately to produce the desired effect. It can be done: I did it in
Turbo C some years back, and trimmed the size of a program (admittedly,
a large one) by several K—not bad, when you consider that the “sweet
spot” optimization is essentially free, with no code reorganization,
a large one) by several K—not bad, when you consider that the "sweet
spot" optimization is essentially free, with no code reorganization,
change in logic, or heavy thinking involved.
------------------------ --------------------------------- --------------------