From b68a375afc725f113cd941555e120657ccb1d487 Mon Sep 17 00:00:00 2001 From: "H. Peter Anvin (Intel)" Date: Tue, 30 Jun 2020 15:05:11 -0700 Subject: doc: index cleanups Signed-off-by: H. Peter Anvin (Intel) --- 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 -- cgit v1.2.1