[nasm:nasm-2.15.xx] doc: index cleanups
nasm-bot for H. Peter Anvin (Intel)
hpa at zytor.com
Tue Jun 30 17:03:17 PDT 2020
Commit-ID: b68a375afc725f113cd941555e120657ccb1d487
Gitweb: http://repo.or.cz/w/nasm.git?a=commitdiff;h=b68a375afc725f113cd941555e120657ccb1d487
Author: H. Peter Anvin (Intel) <hpa at zytor.com>
AuthorDate: Tue, 30 Jun 2020 15:05:11 -0700
Committer: H. Peter Anvin (Intel) <hpa at zytor.com>
CommitDate: Tue, 30 Jun 2020 15:05:20 -0700
doc: index cleanups
Signed-off-by: H. Peter Anvin (Intel) <hpa at zytor.com>
---
doc/nasmdoc.src | 224 +++++++++++++++++++++++++++++---------------------------
1 file changed, 117 insertions(+), 107 deletions(-)
diff --git a/doc/nasmdoc.src b/doc/nasmdoc.src
index 04cf8a87..eb49d1a8 100644
--- a/doc/nasmdoc.src
+++ b/doc/nasmdoc.src
@@ -126,7 +126,13 @@
\IR{+ modifier} \c{+} modifier
\IR{- opsubtraction} \c{-} operator, binary
\IR{- opunary} \c{-} operator, unary
-\IR{! opunary} \c{!} operator, unary
+\IR{! opunary} \c{!} operator
+\IA{A16}{a16}
+\IA{A32}{a32}
+\IA{A64}{a64}
+\IA{O16}{o16}
+\IA{O32}{o32}
+\IA{O64}{o64}
\IR{alignment, in bin sections} alignment, in \c{bin} sections
\IR{alignment, in elf sections} alignment, in ELF sections
\IR{alignment, in win32 sections} alignment, in \c{win32} sections
@@ -152,10 +158,9 @@ variables
\IA{case-sensitive}{case sensitive}
\IA{case-insensitive}{case sensitive}
\IA{character constants}{character constant}
-\IR{codeview} CodeView debugging format
+\IR{codeview debugging format} CodeView debugging format
\IR{common object file format} Common Object File Format
-\IR{common variables, alignment in elf} common variables, alignment
-in ELF
+\IR{common variables, alignment in elf} common variables, alignment in ELF
\IR{common, elf extensions to} \c{COMMON}, ELF extensions to
\IR{common, obj extensions to} \c{COMMON}, \c{obj} extensions to
\IR{declaring structure} declaring structures
@@ -165,15 +170,12 @@ in ELF
\IR{dll symbols, exporting} DLL symbols, exporting
\IR{dll symbols, importing} DLL symbols, importing
\IR{dos} DOS
-\IR{dos archive} DOS archive
-\IR{dos source archive} DOS source archive
-\IR{dup} \c{DUP}
\IA{effective address}{effective addresses}
\IA{effective-address}{effective addresses}
\IR{elf} ELF
\IR{elf, 16-bit code} ELF, 16-bit code
\IR{elf, debug formats} ELF, debug formats
-\IR{elf shared libraries} ELF, shared libraries
+\IR{elf shared library} ELF, shared libraries
\IR{elf32} \c{elf32}
\IR{elf64} \c{elf64}
\IR{elfx32} \c{elfx32}
@@ -186,8 +188,7 @@ in ELF
\IR{freebsd} FreeBSD
\IR{freelink} FreeLink
\IR{functions, c calling convention} functions, C calling convention
-\IR{functions, pascal calling convention} functions, Pascal calling
-convention
+\IR{functions, pascal calling convention} functions, \c{PASCAL} calling convention
\IR{global, aoutb extensions to} \c{GLOBAL}, \c{aoutb} extensions to
\IR{global, elf extensions to} \c{GLOBAL}, ELF extensions to
\IR{global, rdf extensions to} \c{GLOBAL}, \c{rdf} extensions to
@@ -199,9 +200,6 @@ convention
\IR{linux, elf} Linux, ELF
\IR{linux, a.out} Linux, \c{a.out}
\IR{linux, as86} Linux, \c{as86}
-\IR{logical and} logical AND
-\IR{logical or} logical OR
-\IR{logical xor} logical XOR
\IR{mach object file format} Mach, object file format
\IA{mach-o}{macho}
\IR{mach-o} Mach-O, object file format
@@ -215,24 +213,30 @@ convention
\IA{misc directory}{misc subdirectory}
\IR{misc subdirectory} \c{misc} subdirectory
\IR{microsoft omf} Microsoft OMF
-\IR{mmx registers} MMX registers
-\IA{modr/m}{modr/m byte}
-\IR{modr/m byte} ModR/M byte
\IR{ms-dos} MS-DOS
\IR{ms-dos device drivers} MS-DOS device drivers
\IR{multipush} \c{multipush} macro
\IR{nan} NaN
\IR{nasm version} NASM version
+\IR{nasm version history} NASM version, history
+\IR{nasm version macros} NASM version, macros
+\IR{nasm version id} NASM version, ID macro
+\IR{nasm version string} NASM version, string macro
+\IR{arithmetic negation} negation, arithmetic
+\IR{bitwise negation} negation, bitwise
+\IR{boolean negation} negation, boolean
+\IR{boolean and} boolean, AND
+\IR{boolean or} boolean, OR
+\IR{boolean xor} boolean, XOR
\IR{netbsd} NetBSD
\IR{nsis} NSIS
\IR{nullsoft scriptable installer} Nullsoft Scriptable Installer
+\IA{.OBJ}{.obj}
\IR{omf} OMF
\IR{openbsd} OpenBSD
\IR{operating system} operating system
\IR{os/2} OS/2
-\IR{pascal calling convention}Pascal calling convention
-\IR{passes} passes, assembly
-\IR{perl} Perl
+\IR{pascal calling convention} Pascal calling convention
\IR{pic} PIC
\IR{pharlap} PharLap
\IR{plt} PLT
@@ -253,14 +257,16 @@ Object File Format
\IR{section alignment, in win32} section alignment, in \c{win32}
\IR{section, elf extensions to} \c{SECTION}, ELF extensions to
\IR{section, macho extensions to} \c{SECTION}, \c{macho} extensions to
-\IR{section, win32 extensions to} \c{SECTION}, \c{win32} extensions to
+\IR{section, windows extensions to} \c{SECTION}, Windows extensions to
\IR{segment alignment, in bin} segment alignment, in \c{bin}
\IR{segment alignment, in obj} segment alignment, in \c{obj}
-\IR{segment, obj extensions to} \c{SEGMENT}, ELF extensions to
+\IR{segment, obj extensions to} \c{SEGMENT}, \c{obj} extensions to
\IR{segment names, borland pascal} segment names, Borland Pascal
\IR{shift command} \c{shift} command
-\IA{sib}{sib byte}
-\IR{sib byte} SIB byte
+\IA{string constant}{string constants}
+\IR{string constants} string, constants
+\IR{string length} string, length
+\IR{string manipulation in macros} string, manipulation in macros
\IR{align, smart} \c{ALIGN}, smart
\IA{sectalign}{sectalign}
\IR{solaris x86} Solaris x86
@@ -271,7 +277,9 @@ Object File Format
\IR{thread local storage in elf} thread local storage, in ELF
\IR{thread local storage in mach-o} thread local storage, in \c{macho}
\IR{tlink} \c{TLINK}
+\IR{unconditionally importing symbols} importing symbols, unconditionally
\IR{underscore, in c symbols} underscore, in C symbols
+\IA{uninitialized storage}{storage, uninitialized}
\IR{unicode} Unicode
\IR{unix} Unix
\IR{utf-8} UTF-8
@@ -279,20 +287,16 @@ Object File Format
\IR{utf-32} UTF-32
\IA{sco unix}{unix, sco}
\IR{unix, sco} Unix, SCO
-\IA{unix source archive}{unix, source archive}
-\IR{unix, source archive} Unix, source archive
\IA{unix system v}{unix, system v}
\IR{unix, system v} Unix, System V
\IR{unixware} UnixWare
\IR{val} VAL
-\IR{version number of nasm} version number of NASM
+\IA{version number of nasm}{nasm, version}
\IR{visual c++} Visual C++
-\IR{www page} WWW page
\IR{win32} Win32
-\IR{win32} Win64
+\IR{win64} Win64
\IR{windows} Windows
-\IR{windows 95} Windows 95
-\IR{windows nt} Windows NT
+\IR{windows debugging formats} Windows, debugging formats
\# \IC{program entry point}{entry point, program}
\# \IC{program entry point}{start point, program}
\# \IC{MS-DOS device drivers}{device drivers, MS-DOS}
@@ -433,7 +437,7 @@ an intervening space. For example:
\c nasm -f bin driver.asm -odriver.sys
Note that this is a small o, and is different from a capital O , which
-is used to specify the number of optimisation passes required. See \k{opt-O}.
+is used to specify the number of optimization passes required. See \k{opt-O}.
\S{opt-f} The \i\c{-f} Option: Specifying the \i{Output File Format}
@@ -1195,21 +1199,21 @@ defines a symbol called \c{eax}, you can refer to \c{$eax} in NASM
code to distinguish the symbol from the register. Maximum length of
an identifier is 4095 characters.
-The instruction field may contain any machine instruction: Pentium
-and P6 instructions, FPU instructions, MMX instructions and even
+The instruction field may contain any machine instruction: Pentium and
+P6 instructions, FPU instructions, MMX instructions and even
undocumented instructions are all supported. The instruction may be
prefixed by \c{LOCK}, \c{REP}, \c{REPE}/\c{REPZ}, \c{REPNE}/\c{REPNZ},
-\c{XACQUIRE}/\c{XRELEASE} or \c{BND}/\c{NOBND}, in the usual way. Explicit
-\I{address-size prefixes}address-size and \i{operand-size prefixes} \i\c{A16},
-\i\c{A32}, \i\c{A64}, \i\c{O16} and \i\c{O32}, \i\c{O64} are provided - one example of their use
-is given in \k{mixsize}. You can also use the name of a \I{segment
-override}segment register as an instruction prefix: coding
-\c{es mov [bx],ax} is equivalent to coding \c{mov [es:bx],ax}. We
-recommend the latter syntax, since it is consistent with other
-syntactic features of the language, but for instructions such as
-\c{LODSB}, which has no operands and yet can require a segment
-override, there is no clean syntactic way to proceed apart from
-\c{es lodsb}.
+\c{XACQUIRE}/\c{XRELEASE} or \c{BND}/\c{NOBND}, in the usual
+way. Explicit \I{address-size prefixes}address-size and
+\i{operand-size prefixes} \i\c{A16}, \i\c{A32}, \i\c{A64}, \i\c{O16}
+and \i\c{O32}, \i\c{O64} are provided - one example of their use is
+given in \k{mixsize}. You can also use the name of a \I{segment
+override}segment register as an instruction prefix: coding \c{es mov
+[bx],ax} is equivalent to coding \c{mov [es:bx],ax}. We recommend the
+latter syntax, since it is consistent with other syntactic features of
+the language, but for instructions such as \c{LODSB}, which has no
+operands and yet can require a segment override, there is no clean
+syntactic way to proceed apart from \c{es lodsb}.
An instruction is not required to use a prefix: prefixes such as
\c{CS}, \c{A32}, \c{LOCK} or \c{REPE} can appear on a line by
@@ -1250,10 +1254,11 @@ Pseudo-instructions are things which, though not real x86 machine
instructions, are used in the instruction field anyway because that's
the most convenient place to put them. The current pseudo-instructions
are \i\c{DB}, \i\c{DW}, \i\c{DD}, \i\c{DQ}, \i\c{DT}, \i\c{DO},
-\i\c{DY} and \i\c\{DZ}; their \i{uninitialized} counterparts
-\i\c{RESB}, \i\c{RESW}, \i\c{RESD}, \i\c{RESQ}, \i\c{REST},
-\i\c{RESO}, \i\c{RESY} and \i\c\{RESZ}; the \i\c{INCBIN} command, the
-\i\c{EQU} command, and the \i\c{TIMES} prefix.
+\i\c{DY} and \i\c\{DZ}; their \I{storage,
+uninitialized}\i{uninitialized} counterparts \i\c{RESB}, \i\c{RESW},
+\i\c{RESD}, \i\c{RESQ}, \i\c{REST}, \i\c{RESO}, \i\c{RESY} and
+\i\c\{RESZ}; the \i\c{INCBIN} command, the \i\c{EQU} command, and the
+\i\c{TIMES} prefix.
\S{db} \c{DB} and Friends: Declaring Initialized Data
@@ -1280,12 +1285,12 @@ the output file. They can be invoked in a wide range of ways:
\c{DT}, \c{DO}, \c{DY} and \c{DZ} do not accept \i{numeric constants}
as operands.
-\I{masmdb} Starting in NASM 2.15, a the following MASM-like features
+\I{masmdb} Starting in NASM 2.15, a the following \i{MASM}-like features
have been implemented:
-\b A \I{?db}\c{?} argument to declare uninitialized data:
+\b A \I{?db}\c{?} argument to declare \i{uninitialized storage}:
-\c db ? ; uninitialized data
+\c db ? ; uninitialized
\b A superset of the \i\c{DUP} syntax. The NASM version of this has
the following syntax specification; capital letters indicate literal
@@ -1573,7 +1578,7 @@ Some examples (all producing exactly the same code):
\c mov ax,0b1100_1000 ; same binary constant yet again
\c mov ax,0y1100_1000 ; same binary constant yet again
-\S{strings} \I{Strings}\i{Character Strings}
+\S{strings} \I{string}\I{string constants}\i{Character Strings}
A character string consists of up to eight characters enclosed in
either single quotes (\c{'...'}), double quotes (\c{"..."}) or
@@ -1883,15 +1888,15 @@ The \c{|} operator gives a bitwise OR, exactly as performed by the
\S{expshift} \i{Bit Shift} Operators
\i\c{<<} gives a bit-shift to the left, just as it does in C. So
-\c{5<<3} evaluates to 5 times 8, or 40. \i\c{>>} gives an \e{unsigned}
-(logical) bit-shift to the right; the bits shifted in from the left
-are set to zero.
+\c{5<<3} evaluates to 5 times 8, or 40. \i\c{>>} gives an \I{unsigned,
+bit shift}\e{unsigned} (logical) bit-shift to the right; the bits
+shifted in from the left are set to zero.
\i\c{<<<} gives a bit-shift to the left, exactly equivalent to the
\c{<<} operator; it is included for completeness. \i\c{>>>} gives an
-\e{signed} (arithmetic) bit-shift to the right; the bits shifted in
-from the left are filled with copies of the most significant (sign)
-bit.
+\I{signed, bit shift}\e{signed} (arithmetic) bit-shift to the right;
+the bits shifted in from the left are filled with copies of the most
+significant (sign) bit.
\S{expplmi} \I{+ opaddition}\c{+} and \I{- opsubtraction}\c{-}:
@@ -1905,11 +1910,13 @@ subtraction.
\i\c{*} is the multiplication operator.
-\i\c{/} and \i\c{//} are both division operators: \c{/} is \i{unsigned
-division} and \c{//} is \i{signed division}.
+\i\c{/} and \i\c{//} are both division operators: \c{/} is
+\I{division, unsigned}\I{unsigned, division}unsigned division and \c{//} is
+\I{division, signed}\I{signed, division}signed division.
-Similarly, \i\c{%} and \i\c{%%} provide \I{unsigned modulo}\I{modulo
-operators} unsigned and \i{signed modulo} operators respectively.
+Similarly, \i\c{%} and \i\c{%%} provide \I{modulo,
+unsigned}\I{unsigned, modulo}unsigned and \I{modulo, signed}\I{signed,
+modulo}signed modulo operators respectively.
Since the \c{%} character is used extensively by the macro
\i{preprocessor}, you should ensure that both the signed and unsigned
@@ -1922,22 +1929,27 @@ the signed division operator, such that:
\c b * (a // b) + (a %% b) = a (b != 0)
-\S{expmul} \i{Unary Operators}
+\S{expmul} \I{operators, unary}\i{Unary Operators}
The highest-priority operators in NASM's expression grammar are those
-which only apply to one argument. These are \I{+ opunary}\c{+}, \I{-
-opunary}\c{-}, \i\c{~}, \I{! opunary}\c{!}, \i\c{SEG}, and the
-\i{integer functions} operators.
+which only apply to one argument. These are:
+
+\b \I{- opunary}\c{-} \I{arithmetic negation}negates (\i{2's complement}) its
+operand.
+
+\b \I{+ opunary}\c{+} does nothing; it's provided for symmetry with \c{-}.
+
+\b \I{~ opunary}\c{~} computes the \I{negation, bitwise}\i{bitwise
+negation} (\i{1's complement}) of its operand.
-\c{-} negates its operand, \c{+} does nothing (it's provided for
-symmetry with \c{-}), \c{~} computes the \i{one's complement} of its
-operand, \c{!} is the \i{logical negation} operator.
+\b \I{! opunary}\c{!} is the \I{negation, boolean}\i{boolean negation}
+operator. It evaluates to 1 if the argument is 0, otherwise 0.
-\c{SEG} provides the \i{segment address}
-of its operand (explained in more detail in \k{segwrt}).
+\b \c{SEG} provides the \i{segment address} of its operand (explained in
+more detail in \k{segwrt}).
-A set of additional operators with leading and trailing double
-underscores are used to implement the integer functions of the
+\b A set of additional operators with leading and trailing double
+underscores are used to implement the \c{integer functions} of the
\c{ifunc} macro package, see \k{pkg_ifunc}.
@@ -4108,10 +4120,9 @@ be assembled with no pre-defined macros, you can use the \i\c{%clear}
directive to empty the preprocessor of everything but context-local
preprocessor variables and single-line macros, see \k{clear}.
-Most \i{user-level assembler directives} (see \k{directive}) are
-implemented as macros which invoke primitive directives; these are
-described in \k{directive}. The rest of the standard macro set is
-described here.
+Most \i{user-level directives} (see \k{directive}) are implemented as
+macros which invoke primitive directives; these are described in
+\k{directive}. The rest of the standard macro set is described here.
For compability with NASM versions before NASM 2.15, most standard
macros of the form \c{__?foo?__} have aliases of form \c{__foo__} (see
@@ -4119,15 +4130,15 @@ macros of the form \c{__?foo?__} have aliases of form \c{__foo__} (see
defalias}.
-\H{stdmacver} \i{NASM Version} Macros
+\H{stdmacver} \i{NASM Version Macros}
The single-line macros \i\c{__?NASM_MAJOR?__}, \i\c{__?NASM_MINOR?__},
-\i\c{__?NASM_SUBMINOR?__} and \i\c{__?_NASM_PATCHLEVEL?__} expand to the
+\i\c{__?NASM_SUBMINOR?__} and \i\c{__?NASM_PATCHLEVEL?__} expand to the
major, minor, subminor and patch level parts of the \i{version
number of NASM} being used. So, under NASM 0.98.32p1 for
example, \c{__?NASM_MAJOR?__} would be defined to be 0, \c{__?NASM_MINOR?__}
would be defined as 98, \c{__?NASM_SUBMINOR?__} would be defined to 32,
-and \c{__?_NASM_PATCHLEVEL?__} would be defined as 1.
+and \c{__?NASM_PATCHLEVEL?__} would be defined as 1.
Additionally, the macro \i\c{__?NASM_SNAPSHOT?__} is defined for
automatically generated snapshot releases \e{only}.
@@ -4138,7 +4149,7 @@ automatically generated snapshot releases \e{only}.
The single-line macro \c{__?NASM_VERSION_ID?__} expands to a dword integer
representing the full version number of the version of nasm being used.
The value is the equivalent to \c{__?NASM_MAJOR?__}, \c{__?NASM_MINOR?__},
-\c{__?NASM_SUBMINOR?__} and \c{__?_NASM_PATCHLEVEL?__} concatenated to
+\c{__?NASM_SUBMINOR?__} and \c{__?NASM_PATCHLEVEL?__} concatenated to
produce a single doubleword. Hence, for 0.98.32p1, the returned number
would be equivalent to:
@@ -4153,7 +4164,7 @@ line is used just to give an indication of the order that the separate
values will be present in memory.
-\S{stdmacverstr} \i\c{__?NASM_VER?__}: \i{NASM Version string}
+\S{stdmacverstr} \i\c{__?NASM_VER?__}: \i{NASM Version String}
The single-line macro \c{__?NASM_VER?__} expands to a string which defines
the version number of nasm being used. So, under NASM 0.98.32 for example,
@@ -4952,13 +4963,12 @@ declared as \c{EXTERN} and then defined, it will be treated as
\c{EXTERN}, it will be treated as \c{COMMON}.
-\H{required} \i\c{REQUIRED}: \i{Importing Symbols} from Other Modules
+\H{required} \i\c{REQUIRED}: \i{Unconditionally Importing Symbols} from Other Modules
-The \c{REQUIRED} keyword is similar to \c{EXTERN} one. The difference is that
-the \c{EXTERN} keyword as of version 2.15 does not generate unknown symbols, as
-this behavior is highly undesirable when using common header files,
-because it might cause the linker to pull in a bunch of unnecessary modules,
-depending on how smart the linker is.
+The \c{REQUIRED} keyword is similar to \c{EXTERN} one. The difference
+is that the \c{EXTERN} keyword as of version 2.15 does not generate
+unknown symbols as that prevents using common header files, as it
+might cause the linker to pull in a bunch of unnecessary modules.
If the old behavior is required, use \c{REQUIRED} keyword instead.
@@ -5247,7 +5257,7 @@ does. See \k{proborg} for further comments.
\S{binseg} \c{bin} Extensions to the \c{SECTION}
-Directive\I{SECTION, bin extensions to}
+Directive\I{\c{SECTION}, \c{bin} extensions to}
The \c{bin} output format extends the \c{SECTION} (or \c{SEGMENT})
directive to allow you to specify the alignment requirements of
@@ -5560,7 +5570,7 @@ be specified, even if it is the same as the internal name. The
available attributes are:
\b \c{resident} indicates that the exported name is to be kept
-resident by the system loader. This is an optimisation for
+resident by the system loader. This is an optimization for
frequently used symbols imported by name.
\b \c{nodata} indicates that the exported symbol is a function which
@@ -5704,7 +5714,7 @@ files that Win32 linkers can generate correct output from.
\S{win32sect} \c{win32} Extensions to the \c{SECTION}
-Directive\I{SECTION, win32 extensions to}
+Directive\I{SECTION, Windows extensions to}
Like the \c{obj} format, \c{win32} allows you to specify additional
information on the \c{SECTION} directive line, to control the type
@@ -5850,8 +5860,8 @@ later can still be linked by earlier versions or non-Microsoft linkers.
\S{codeview} Debugging formats for Windows
\I{Windows debugging formats}
-The \c{win32} and \c{win64} formats support the Microsoft CodeView
-debugging format. Currently CodeView version 8 format is supported
+The \c{win32} and \c{win64} formats support the Microsoft \i{CodeView
+debugging format}. Currently CodeView version 8 format is supported
(\i\c{cv8}), but newer versions of the CodeView debugger should be
able to handle this format as well.
@@ -6423,14 +6433,14 @@ of the symbol with code such as:
\S{elfglob} \c{elf} Extensions to the \c{GLOBAL} Directive\I{GLOBAL,
elf extensions to}\I{GLOBAL, aoutb extensions to}
-\c{ELF} object files can contain more information about a global symbol
-than just its address: they can contain the \I{symbol sizes,
-specifying}\I{size, of symbols}size of the symbol and its \I{symbol
-types, specifying}\I{type, of symbols}type as well. These are not
-merely debugger conveniences, but are actually necessary when the
-program being written is a \i{shared library}. NASM therefore
-supports some extensions to the \c{GLOBAL} directive, allowing you
-to specify these features.
+\c{ELF} object files can contain more information about a global
+symbol than just its address: they can contain the \I{symbols,
+specifying sizes}\I{size, of symbols}size of the symbol and its
+\I{symbols, specifying types}\I{type, of symbols}type as well. These
+are not merely debugger conveniences, but are actually necessary when
+the program being written is a \I{elf shared library}shared
+library. NASM therefore supports some extensions to the \c{GLOBAL}
+directive, allowing you to specify these features.
You can specify whether a global variable is a function or a data
object by suffixing the name with a colon and the word
@@ -6734,7 +6744,7 @@ also, have to be built as \c{.EXE} files, since Windows does not
support the \c{.COM} format.
In general, you generate \c{.EXE} files by using the \c{obj} output
-format to produce one or more \i\c{.OBJ} files, and then linking
+format to produce one or more \i\c{.obj} files, and then linking
them together using a linker. However, NASM also supports the direct
generation of simple DOS \c{.EXE} files using the \c{bin} output
format (by using \c{DB} and \c{DW} to construct the \c{.EXE} file
@@ -8063,7 +8073,7 @@ and create \c{library.so.1} as a symbolic link to it.
This chapter tries to cover some of the issues, largely related to
unusual forms of addressing and jump instructions, encountered when
-writing operating system code such as protected-mode initialisation
+writing operating system code such as protected-mode initialization
routines, which require code that operates in mixed segment sizes,
such as code in a 16-bit segment trying to modify data in a 32-bit
one, or jumps between different-size segments.
@@ -8574,7 +8584,7 @@ Hence, to disassemble a \c{.COM} file:
will do the trick.
-\S{ndissync} Code Following Data: Synchronisation
+\S{ndissync} Code Following Data: Synchronization
Suppose you are disassembling a file which contains some data which
isn't machine code, and \e{then} contains some machine code. NDISASM
@@ -8593,8 +8603,8 @@ then the correct first instruction in the code section will not be
seen because the starting point skipped over it. This isn't really
ideal.
-To avoid this, you can specify a `\i{synchronisation}' point, or indeed
-as many synchronisation points as you like (although NDISASM can
+To avoid this, you can specify a `\i{synchronization}' point, or indeed
+as many synchronization points as you like (although NDISASM can
only handle 2147483647 sync points internally). The definition of a sync
point is this: NDISASM guarantees to hit sync points exactly during
disassembly. If it is thinking about generating an instruction which
@@ -8618,7 +8628,7 @@ As stated above, you can specify multiple sync markers if you need
to, just by repeating the \c{-s} option.
-\S{ndisisync} Mixed Code and Data: Automatic (Intelligent) Synchronisation
+\S{ndisisync} Mixed Code and Data: Automatic (Intelligent) Synchronization
\I\c{auto-sync}
Suppose you are disassembling the boot sector of a \c{DOS} floppy (maybe
More information about the Nasm-commits
mailing list