add directory Ref-docs
This commit is contained in:
gohigh
564
Ref-docs/nasmdoc/html/index.html
Normal file
564
Ref-docs/nasmdoc/html/index.html
Normal file
@@ -0,0 +1,564 @@
|
||||
<html><head><title>NASM Manual</title></head>
|
||||
<body><h1 align=center>The Netwide Assembler: NASM</h1>
|
||||
|
||||
<p>This manual documents NASM, the Netwide Assembler: an assembler
|
||||
targetting the Intel x86 series of processors, with portable source.
|
||||
<p><p><a href="nasmdoc1.html">Chapter 1: Introduction</a><br>
|
||||
<a href="nasmdoc1.html#section-1.1">Section 1.1: What Is NASM?</a><br>
|
||||
<a href="nasmdoc1.html#section-1.1.1">Section 1.1.1: Why Yet Another Assembler?</a><br>
|
||||
<a href="nasmdoc1.html#section-1.1.2">Section 1.1.2: Licence Conditions</a><br>
|
||||
<a href="nasmdoc1.html#section-1.2">Section 1.2: Contact Information</a><br>
|
||||
<a href="nasmdoc1.html#section-1.3">Section 1.3: Installation</a><br>
|
||||
<a href="nasmdoc1.html#section-1.3.1">Section 1.3.1: Installing NASM under MS-DOS or Windows</a><br>
|
||||
<a href="nasmdoc1.html#section-1.3.2">Section 1.3.2: Installing NASM under Unix</a><br>
|
||||
<p><a href="nasmdoc2.html">Chapter 2: Running NASM</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1">Section 2.1: NASM Command-Line Syntax</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.1">Section 2.1.1: The <code><nobr>-o</nobr></code> Option: Specifying the Output File Name</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.2">Section 2.1.2: The <code><nobr>-f</nobr></code> Option: Specifying the Output File Format</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.3">Section 2.1.3: The <code><nobr>-l</nobr></code> Option: Generating a Listing File</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.4">Section 2.1.4: The <code><nobr>-M</nobr></code> Option: Generate Makefile Dependencies.</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.5">Section 2.1.5: The <code><nobr>-F</nobr></code> Option: Selecting a Debug Information Format</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.6">Section 2.1.6: The <code><nobr>-g</nobr></code> Option: Enabling Debug Information.</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.7">Section 2.1.7: The <code><nobr>-X</nobr></code> Option: Selecting an Error Reporting Format</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.8">Section 2.1.8: The <code><nobr>-E</nobr></code> Option: Send Errors to a File</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.9">Section 2.1.9: The <code><nobr>-s</nobr></code> Option: Send Errors to <code><nobr>stdout</nobr></code></a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.10">Section 2.1.10: The <code><nobr>-i</nobr></code> Option: Include File Search Directories</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.11">Section 2.1.11: The <code><nobr>-p</nobr></code> Option: Pre-Include a File</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.12">Section 2.1.12: The <code><nobr>-d</nobr></code> Option: Pre-Define a Macro</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.13">Section 2.1.13: The <code><nobr>-u</nobr></code> Option: Undefine a Macro</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.14">Section 2.1.14: The <code><nobr>-e</nobr></code> Option: Preprocess Only</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.15">Section 2.1.15: The <code><nobr>-a</nobr></code> Option: Don't Preprocess At All</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.16">Section 2.1.16: The <code><nobr>-On</nobr></code> Option: Specifying Multipass Optimization.</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.17">Section 2.1.17: The <code><nobr>-t</nobr></code> option: Enable TASM Compatibility Mode</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.18">Section 2.1.18: The <code><nobr>-w</nobr></code> Option: Enable or Disable Assembly Warnings</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.19">Section 2.1.19: The <code><nobr>-v</nobr></code> Option: Display Version Info</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.20">Section 2.1.20: The <code><nobr>-y</nobr></code> Option: Display Available Debug Info Formats</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.21">Section 2.1.21: The <code><nobr>--prefix</nobr></code> and <code><nobr>--postfix</nobr></code> Options.</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.22">Section 2.1.22: The <code><nobr>NASMENV</nobr></code> Environment Variable</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2">Section 2.2: Quick Start for MASM Users</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.1">Section 2.2.1: NASM Is Case-Sensitive</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.2">Section 2.2.2: NASM Requires Square Brackets For Memory References</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.3">Section 2.2.3: NASM Doesn't Store Variable Types</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.4">Section 2.2.4: NASM Doesn't <code><nobr>ASSUME</nobr></code></a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.5">Section 2.2.5: NASM Doesn't Support Memory Models</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.6">Section 2.2.6: Floating-Point Differences</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.7">Section 2.2.7: Other Differences</a><br>
|
||||
<p><a href="nasmdoc3.html">Chapter 3: The NASM Language</a><br>
|
||||
<a href="nasmdoc3.html#section-3.1">Section 3.1: Layout of a NASM Source Line</a><br>
|
||||
<a href="nasmdoc3.html#section-3.2">Section 3.2: Pseudo-Instructions</a><br>
|
||||
<a href="nasmdoc3.html#section-3.2.1">Section 3.2.1: <code><nobr>DB</nobr></code> and friends: Declaring Initialised Data</a><br>
|
||||
<a href="nasmdoc3.html#section-3.2.2">Section 3.2.2: <code><nobr>RESB</nobr></code> and friends: Declaring Uninitialised Data</a><br>
|
||||
<a href="nasmdoc3.html#section-3.2.3">Section 3.2.3: <code><nobr>INCBIN</nobr></code>: Including External Binary Files</a><br>
|
||||
<a href="nasmdoc3.html#section-3.2.4">Section 3.2.4: <code><nobr>EQU</nobr></code>: Defining Constants</a><br>
|
||||
<a href="nasmdoc3.html#section-3.2.5">Section 3.2.5: <code><nobr>TIMES</nobr></code>: Repeating Instructions or Data</a><br>
|
||||
<a href="nasmdoc3.html#section-3.3">Section 3.3: Effective Addresses</a><br>
|
||||
<a href="nasmdoc3.html#section-3.4">Section 3.4: Constants</a><br>
|
||||
<a href="nasmdoc3.html#section-3.4.1">Section 3.4.1: Numeric Constants</a><br>
|
||||
<a href="nasmdoc3.html#section-3.4.2">Section 3.4.2: Character Constants</a><br>
|
||||
<a href="nasmdoc3.html#section-3.4.3">Section 3.4.3: String Constants</a><br>
|
||||
<a href="nasmdoc3.html#section-3.4.4">Section 3.4.4: Floating-Point Constants</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5">Section 3.5: Expressions</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.1">Section 3.5.1: <code><nobr>|</nobr></code>: Bitwise OR Operator</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.2">Section 3.5.2: <code><nobr>^</nobr></code>: Bitwise XOR Operator</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.3">Section 3.5.3: <code><nobr>&</nobr></code>: Bitwise AND Operator</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.4">Section 3.5.4: <code><nobr><<</nobr></code> and <code><nobr>>></nobr></code>: Bit Shift Operators</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.5">Section 3.5.5: <code><nobr>+</nobr></code> and <code><nobr>-</nobr></code>: Addition and Subtraction Operators</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.6">Section 3.5.6: <code><nobr>*</nobr></code>, <code><nobr>/</nobr></code>, <code><nobr>//</nobr></code>, <code><nobr>%</nobr></code> and <code><nobr>%%</nobr></code>: Multiplication and Division</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.7">Section 3.5.7: Unary Operators: <code><nobr>+</nobr></code>, <code><nobr>-</nobr></code>, <code><nobr>~</nobr></code> and <code><nobr>SEG</nobr></code></a><br>
|
||||
<a href="nasmdoc3.html#section-3.6">Section 3.6: <code><nobr>SEG</nobr></code> and <code><nobr>WRT</nobr></code></a><br>
|
||||
<a href="nasmdoc3.html#section-3.7">Section 3.7: <code><nobr>STRICT</nobr></code>: Inhibiting Optimization</a><br>
|
||||
<a href="nasmdoc3.html#section-3.8">Section 3.8: Critical Expressions</a><br>
|
||||
<a href="nasmdoc3.html#section-3.9">Section 3.9: Local Labels</a><br>
|
||||
<p><a href="nasmdoc4.html">Chapter 4: The NASM Preprocessor</a><br>
|
||||
<a href="nasmdoc4.html#section-4.1">Section 4.1: Single-Line Macros</a><br>
|
||||
<a href="nasmdoc4.html#section-4.1.1">Section 4.1.1: The Normal Way: <code><nobr>%define</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.1.2">Section 4.1.2: Enhancing %define: <code><nobr>%xdefine</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.1.3">Section 4.1.3: Concatenating Single Line Macro Tokens: <code><nobr>%+</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.1.4">Section 4.1.4: Undefining macros: <code><nobr>%undef</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.1.5">Section 4.1.5: Preprocessor Variables: <code><nobr>%assign</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.2">Section 4.2: String Handling in Macros: <code><nobr>%strlen</nobr></code> and <code><nobr>%substr</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.2.1">Section 4.2.1: String Length: <code><nobr>%strlen</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.2.2">Section 4.2.2: Sub-strings: <code><nobr>%substr</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.3">Section 4.3: Multi-Line Macros: <code><nobr>%macro</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.1">Section 4.3.1: Overloading Multi-Line Macros</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.2">Section 4.3.2: Macro-Local Labels</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.3">Section 4.3.3: Greedy Macro Parameters</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.4">Section 4.3.4: Default Macro Parameters</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.5">Section 4.3.5: <code><nobr>%0</nobr></code>: Macro Parameter Counter</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.6">Section 4.3.6: <code><nobr>%rotate</nobr></code>: Rotating Macro Parameters</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.7">Section 4.3.7: Concatenating Macro Parameters</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.8">Section 4.3.8: Condition Codes as Macro Parameters</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.9">Section 4.3.9: Disabling Listing Expansion</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4">Section 4.4: Conditional Assembly</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.1">Section 4.4.1: <code><nobr>%ifdef</nobr></code>: Testing Single-Line Macro Existence</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.2">Section 4.4.2: <code><nobr>ifmacro</nobr></code>: Testing Multi-Line Macro Existence</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.3">Section 4.4.3: <code><nobr>%ifctx</nobr></code>: Testing the Context Stack</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4: <code><nobr>%if</nobr></code>: Testing Arbitrary Numeric Expressions</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.5">Section 4.4.5: <code><nobr>%ifidn</nobr></code> and <code><nobr>%ifidni</nobr></code>: Testing Exact Text Identity</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6: <code><nobr>%ifid</nobr></code>, <code><nobr>%ifnum</nobr></code>, <code><nobr>%ifstr</nobr></code>: Testing Token Types</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.7">Section 4.4.7: <code><nobr>%error</nobr></code>: Reporting User-Defined Errors</a><br>
|
||||
<a href="nasmdoc4.html#section-4.5">Section 4.5: Preprocessor Loops: <code><nobr>%rep</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.6">Section 4.6: Including Other Files</a><br>
|
||||
<a href="nasmdoc4.html#section-4.7">Section 4.7: The Context Stack</a><br>
|
||||
<a href="nasmdoc4.html#section-4.7.1">Section 4.7.1: <code><nobr>%push</nobr></code> and <code><nobr>%pop</nobr></code>: Creating and Removing Contexts</a><br>
|
||||
<a href="nasmdoc4.html#section-4.7.2">Section 4.7.2: Context-Local Labels</a><br>
|
||||
<a href="nasmdoc4.html#section-4.7.3">Section 4.7.3: Context-Local Single-Line Macros</a><br>
|
||||
<a href="nasmdoc4.html#section-4.7.4">Section 4.7.4: <code><nobr>%repl</nobr></code>: Renaming a Context</a><br>
|
||||
<a href="nasmdoc4.html#section-4.7.5">Section 4.7.5: Example Use of the Context Stack: Block IFs</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8">Section 4.8: Standard Macros</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.1">Section 4.8.1: <code><nobr>__NASM_MAJOR__</nobr></code>, <code><nobr>__NASM_MINOR__</nobr></code>, <code><nobr>__NASM_SUBMINOR__</nobr></code> and <code><nobr>___NASM_PATCHLEVEL__</nobr></code>: NASM Version</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.2">Section 4.8.2: <code><nobr>__NASM_VERSION_ID__</nobr></code>: NASM Version ID</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.3">Section 4.8.3: <code><nobr>__NASM_VER__</nobr></code>: NASM Version string</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.4">Section 4.8.4: <code><nobr>__FILE__</nobr></code> and <code><nobr>__LINE__</nobr></code>: File Name and Line Number</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.5">Section 4.8.5: <code><nobr>STRUC</nobr></code> and <code><nobr>ENDSTRUC</nobr></code>: Declaring Structure Data Types</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.6">Section 4.8.6: <code><nobr>ISTRUC</nobr></code>, <code><nobr>AT</nobr></code> and <code><nobr>IEND</nobr></code>: Declaring Instances of Structures</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.7">Section 4.8.7: <code><nobr>ALIGN</nobr></code> and <code><nobr>ALIGNB</nobr></code>: Data Alignment</a><br>
|
||||
<a href="nasmdoc4.html#section-4.9">Section 4.9: TASM Compatible Preprocessor Directives</a><br>
|
||||
<a href="nasmdoc4.html#section-4.9.1">Section 4.9.1: <code><nobr>%arg</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc4.html#section-4.9.2">Section 4.9.2: <code><nobr>%stacksize</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc4.html#section-4.9.3">Section 4.9.3: <code><nobr>%local</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc4.html#section-4.10">Section 4.10: Other Preprocessor Directives</a><br>
|
||||
<a href="nasmdoc4.html#section-4.10.1">Section 4.10.1: <code><nobr>%line</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc4.html#section-4.10.2">Section 4.10.2: <code><nobr>%!</nobr></code><code><nobr><env></nobr></code>: Read an environment variable.</a><br>
|
||||
<p><a href="nasmdoc5.html">Chapter 5: Assembler Directives</a><br>
|
||||
<a href="nasmdoc5.html#section-5.1">Section 5.1: <code><nobr>BITS</nobr></code>: Specifying Target Processor Mode</a><br>
|
||||
<a href="nasmdoc5.html#section-5.1.1">Section 5.1.1: <code><nobr>USE16</nobr></code> & <code><nobr>USE32</nobr></code>: Aliases for BITS</a><br>
|
||||
<a href="nasmdoc5.html#section-5.2">Section 5.2: <code><nobr>SECTION</nobr></code> or <code><nobr>SEGMENT</nobr></code>: Changing and Defining Sections</a><br>
|
||||
<a href="nasmdoc5.html#section-5.2.1">Section 5.2.1: The <code><nobr>__SECT__</nobr></code> Macro</a><br>
|
||||
<a href="nasmdoc5.html#section-5.3">Section 5.3: <code><nobr>ABSOLUTE</nobr></code>: Defining Absolute Labels</a><br>
|
||||
<a href="nasmdoc5.html#section-5.4">Section 5.4: <code><nobr>EXTERN</nobr></code>: Importing Symbols from Other Modules</a><br>
|
||||
<a href="nasmdoc5.html#section-5.5">Section 5.5: <code><nobr>GLOBAL</nobr></code>: Exporting Symbols to Other Modules</a><br>
|
||||
<a href="nasmdoc5.html#section-5.6">Section 5.6: <code><nobr>COMMON</nobr></code>: Defining Common Data Areas</a><br>
|
||||
<a href="nasmdoc5.html#section-5.7">Section 5.7: <code><nobr>CPU</nobr></code>: Defining CPU Dependencies</a><br>
|
||||
<p><a href="nasmdoc6.html">Chapter 6: Output Formats</a><br>
|
||||
<a href="nasmdoc6.html#section-6.1">Section 6.1: <code><nobr>bin</nobr></code>: Flat-Form Binary Output</a><br>
|
||||
<a href="nasmdoc6.html#section-6.1.1">Section 6.1.1: <code><nobr>ORG</nobr></code>: Binary File Program Origin</a><br>
|
||||
<a href="nasmdoc6.html#section-6.1.2">Section 6.1.2: <code><nobr>bin</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.1.3">Section 6.1.3: <code><nobr>Multisection</nobr></code> support for the BIN format.</a><br>
|
||||
<a href="nasmdoc6.html#section-6.1.4">Section 6.1.4: Map files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2">Section 6.2: <code><nobr>obj</nobr></code>: Microsoft OMF Object Files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.1">Section 6.2.1: <code><nobr>obj</nobr></code> Extensions to the <code><nobr>SEGMENT</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.2">Section 6.2.2: <code><nobr>GROUP</nobr></code>: Defining Groups of Segments</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.3">Section 6.2.3: <code><nobr>UPPERCASE</nobr></code>: Disabling Case Sensitivity in Output</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.4">Section 6.2.4: <code><nobr>IMPORT</nobr></code>: Importing DLL Symbols</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.5">Section 6.2.5: <code><nobr>EXPORT</nobr></code>: Exporting DLL Symbols</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.6">Section 6.2.6: <code><nobr>..start</nobr></code>: Defining the Program Entry Point</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.7">Section 6.2.7: <code><nobr>obj</nobr></code> Extensions to the <code><nobr>EXTERN</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.8">Section 6.2.8: <code><nobr>obj</nobr></code> Extensions to the <code><nobr>COMMON</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.3">Section 6.3: <code><nobr>win32</nobr></code>: Microsoft Win32 Object Files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.3.1">Section 6.3.1: <code><nobr>win32</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.4">Section 6.4: <code><nobr>coff</nobr></code>: Common Object File Format</a><br>
|
||||
<a href="nasmdoc6.html#section-6.5">Section 6.5: <code><nobr>elf</nobr></code>: Executable and Linkable Format Object Files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.5.1">Section 6.5.1: <code><nobr>elf</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.5.2">Section 6.5.2: Position-Independent Code: <code><nobr>elf</nobr></code> Special Symbols and <code><nobr>WRT</nobr></code></a><br>
|
||||
<a href="nasmdoc6.html#section-6.5.3">Section 6.5.3: <code><nobr>elf</nobr></code> Extensions to the <code><nobr>GLOBAL</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.5.4">Section 6.5.4: <code><nobr>elf</nobr></code> Extensions to the <code><nobr>COMMON</nobr></code> Directive </a><br>
|
||||
<a href="nasmdoc6.html#section-6.5.5">Section 6.5.5: 16-bit code and ELF </a><br>
|
||||
<a href="nasmdoc6.html#section-6.6">Section 6.6: <code><nobr>aout</nobr></code>: Linux <code><nobr>a.out</nobr></code> Object Files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.7">Section 6.7: <code><nobr>aoutb</nobr></code>: NetBSD/FreeBSD/OpenBSD <code><nobr>a.out</nobr></code> Object Files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.8">Section 6.8: <code><nobr>as86</nobr></code>: Minix/Linux <code><nobr>as86</nobr></code> Object Files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.9">Section 6.9: <code><nobr>rdf</nobr></code>: Relocatable Dynamic Object File Format</a><br>
|
||||
<a href="nasmdoc6.html#section-6.9.1">Section 6.9.1: Requiring a Library: The <code><nobr>LIBRARY</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.9.2">Section 6.9.2: Specifying a Module Name: The <code><nobr>MODULE</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.9.3">Section 6.9.3: <code><nobr>rdf</nobr></code> Extensions to the <code><nobr>GLOBAL</nobr></code> directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.10">Section 6.10: <code><nobr>dbg</nobr></code>: Debugging Format</a><br>
|
||||
<p><a href="nasmdoc7.html">Chapter 7: Writing 16-bit Code (DOS, Windows 3/3.1)</a><br>
|
||||
<a href="nasmdoc7.html#section-7.1">Section 7.1: Producing <code><nobr>.EXE</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.1.1">Section 7.1.1: Using the <code><nobr>obj</nobr></code> Format To Generate <code><nobr>.EXE</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.1.2">Section 7.1.2: Using the <code><nobr>bin</nobr></code> Format To Generate <code><nobr>.EXE</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.2">Section 7.2: Producing <code><nobr>.COM</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.2.1">Section 7.2.1: Using the <code><nobr>bin</nobr></code> Format To Generate <code><nobr>.COM</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.2.2">Section 7.2.2: Using the <code><nobr>obj</nobr></code> Format To Generate <code><nobr>.COM</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.3">Section 7.3: Producing <code><nobr>.SYS</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.4">Section 7.4: Interfacing to 16-bit C Programs</a><br>
|
||||
<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1: External Symbol Names</a><br>
|
||||
<a href="nasmdoc7.html#section-7.4.2">Section 7.4.2: Memory Models</a><br>
|
||||
<a href="nasmdoc7.html#section-7.4.3">Section 7.4.3: Function Definitions and Function Calls</a><br>
|
||||
<a href="nasmdoc7.html#section-7.4.4">Section 7.4.4: Accessing Data Items</a><br>
|
||||
<a href="nasmdoc7.html#section-7.4.5">Section 7.4.5: <code><nobr>c16.mac</nobr></code>: Helper Macros for the 16-bit C Interface</a><br>
|
||||
<a href="nasmdoc7.html#section-7.5">Section 7.5: Interfacing to Borland Pascal Programs</a><br>
|
||||
<a href="nasmdoc7.html#section-7.5.1">Section 7.5.1: The Pascal Calling Convention</a><br>
|
||||
<a href="nasmdoc7.html#section-7.5.2">Section 7.5.2: Borland Pascal Segment Name Restrictions</a><br>
|
||||
<a href="nasmdoc7.html#section-7.5.3">Section 7.5.3: Using <code><nobr>c16.mac</nobr></code> With Pascal Programs</a><br>
|
||||
<p><a href="nasmdoc8.html">Chapter 8: Writing 32-bit Code (Unix, Win32, DJGPP)</a><br>
|
||||
<a href="nasmdoc8.html#section-8.1">Section 8.1: Interfacing to 32-bit C Programs</a><br>
|
||||
<a href="nasmdoc8.html#section-8.1.1">Section 8.1.1: External Symbol Names</a><br>
|
||||
<a href="nasmdoc8.html#section-8.1.2">Section 8.1.2: Function Definitions and Function Calls</a><br>
|
||||
<a href="nasmdoc8.html#section-8.1.3">Section 8.1.3: Accessing Data Items</a><br>
|
||||
<a href="nasmdoc8.html#section-8.1.4">Section 8.1.4: <code><nobr>c32.mac</nobr></code>: Helper Macros for the 32-bit C Interface</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2">Section 8.2: Writing NetBSD/FreeBSD/OpenBSD and Linux/ELF Shared Libraries</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2.1">Section 8.2.1: Obtaining the Address of the GOT</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2.2">Section 8.2.2: Finding Your Local Data Items</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2.3">Section 8.2.3: Finding External and Common Data Items</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2.4">Section 8.2.4: Exporting Symbols to the Library User</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2.5">Section 8.2.5: Calling Procedures Outside the Library</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2.6">Section 8.2.6: Generating the Library File</a><br>
|
||||
<p><a href="nasmdoc9.html">Chapter 9: Mixing 16 and 32 Bit Code</a><br>
|
||||
<a href="nasmdoc9.html#section-9.1">Section 9.1: Mixed-Size Jumps</a><br>
|
||||
<a href="nasmdoc9.html#section-9.2">Section 9.2: Addressing Between Different-Size Segments</a><br>
|
||||
<a href="nasmdoc9.html#section-9.3">Section 9.3: Other Mixed-Size Instructions</a><br>
|
||||
<p><a href="nasmdo10.html">Chapter 10: Troubleshooting</a><br>
|
||||
<a href="nasmdo10.html#section-10.1">Section 10.1: Common Problems</a><br>
|
||||
<a href="nasmdo10.html#section-10.1.1">Section 10.1.1: NASM Generates Inefficient Code</a><br>
|
||||
<a href="nasmdo10.html#section-10.1.2">Section 10.1.2: My Jumps are Out of Range</a><br>
|
||||
<a href="nasmdo10.html#section-10.1.3">Section 10.1.3: <code><nobr>ORG</nobr></code> Doesn't Work</a><br>
|
||||
<a href="nasmdo10.html#section-10.1.4">Section 10.1.4: <code><nobr>TIMES</nobr></code> Doesn't Work</a><br>
|
||||
<a href="nasmdo10.html#section-10.2">Section 10.2: Bugs</a><br>
|
||||
<p><a href="nasmdoca.html">Appendix A: Ndisasm</a><br>
|
||||
<a href="nasmdoca.html#section-A.1">Section A.1: Introduction</a><br>
|
||||
<a href="nasmdoca.html#section-A.2">Section A.2: Getting Started: Installation</a><br>
|
||||
<a href="nasmdoca.html#section-A.3">Section A.3: Running NDISASM</a><br>
|
||||
<a href="nasmdoca.html#section-A.3.1">Section A.3.1: COM Files: Specifying an Origin</a><br>
|
||||
<a href="nasmdoca.html#section-A.3.2">Section A.3.2: Code Following Data: Synchronisation</a><br>
|
||||
<a href="nasmdoca.html#section-A.3.3">Section A.3.3: Mixed Code and Data: Automatic (Intelligent) Synchronisation </a><br>
|
||||
<a href="nasmdoca.html#section-A.3.4">Section A.3.4: Other Options</a><br>
|
||||
<a href="nasmdoca.html#section-A.4">Section A.4: Bugs and Improvements</a><br>
|
||||
<p><a href="nasmdocb.html">Appendix B: x86 Instruction Reference</a><br>
|
||||
<a href="nasmdocb.html#section-B.1">Section B.1: Key to Operand Specifications</a><br>
|
||||
<a href="nasmdocb.html#section-B.2">Section B.2: Key to Opcode Descriptions</a><br>
|
||||
<a href="nasmdocb.html#section-B.2.1">Section B.2.1: Register Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.2.2">Section B.2.2: Condition Codes</a><br>
|
||||
<a href="nasmdocb.html#section-B.2.3">Section B.2.3: SSE Condition Predicates</a><br>
|
||||
<a href="nasmdocb.html#section-B.2.4">Section B.2.4: Status Flags</a><br>
|
||||
<a href="nasmdocb.html#section-B.2.5">Section B.2.5: Effective Address Encoding: ModR/M and SIB</a><br>
|
||||
<a href="nasmdocb.html#section-B.3">Section B.3: Key to Instruction Flags</a><br>
|
||||
<a href="nasmdocb.html#section-B.4">Section B.4: x86 Instruction Set</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.1">Section B.4.1: <code><nobr>AAA</nobr></code>, <code><nobr>AAS</nobr></code>, <code><nobr>AAM</nobr></code>, <code><nobr>AAD</nobr></code>: ASCII Adjustments</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.2">Section B.4.2: <code><nobr>ADC</nobr></code>: Add with Carry</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.3">Section B.4.3: <code><nobr>ADD</nobr></code>: Add Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.4">Section B.4.4: <code><nobr>ADDPD</nobr></code>: ADD Packed Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.5">Section B.4.5: <code><nobr>ADDPS</nobr></code>: ADD Packed Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.6">Section B.4.6: <code><nobr>ADDSD</nobr></code>: ADD Scalar Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.7">Section B.4.7: <code><nobr>ADDSS</nobr></code>: ADD Scalar Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.8">Section B.4.8: <code><nobr>AND</nobr></code>: Bitwise AND</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.9">Section B.4.9: <code><nobr>ANDNPD</nobr></code>: Bitwise Logical AND NOT of Packed Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.10">Section B.4.10: <code><nobr>ANDNPS</nobr></code>: Bitwise Logical AND NOT of Packed Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.11">Section B.4.11: <code><nobr>ANDPD</nobr></code>: Bitwise Logical AND For Single FP</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.12">Section B.4.12: <code><nobr>ANDPS</nobr></code>: Bitwise Logical AND For Single FP</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.13">Section B.4.13: <code><nobr>ARPL</nobr></code>: Adjust RPL Field of Selector</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.14">Section B.4.14: <code><nobr>BOUND</nobr></code>: Check Array Index against Bounds</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.15">Section B.4.15: <code><nobr>BSF</nobr></code>, <code><nobr>BSR</nobr></code>: Bit Scan</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.16">Section B.4.16: <code><nobr>BSWAP</nobr></code>: Byte Swap</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.17">Section B.4.17: <code><nobr>BT</nobr></code>, <code><nobr>BTC</nobr></code>, <code><nobr>BTR</nobr></code>, <code><nobr>BTS</nobr></code>: Bit Test</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.18">Section B.4.18: <code><nobr>CALL</nobr></code>: Call Subroutine</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.19">Section B.4.19: <code><nobr>CBW</nobr></code>, <code><nobr>CWD</nobr></code>, <code><nobr>CDQ</nobr></code>, <code><nobr>CWDE</nobr></code>: Sign Extensions</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.20">Section B.4.20: <code><nobr>CLC</nobr></code>, <code><nobr>CLD</nobr></code>, <code><nobr>CLI</nobr></code>, <code><nobr>CLTS</nobr></code>: Clear Flags</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.21">Section B.4.21: <code><nobr>CLFLUSH</nobr></code>: Flush Cache Line</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.22">Section B.4.22: <code><nobr>CMC</nobr></code>: Complement Carry Flag</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.23">Section B.4.23: <code><nobr>CMOVcc</nobr></code>: Conditional Move</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.24">Section B.4.24: <code><nobr>CMP</nobr></code>: Compare Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.25">Section B.4.25: <code><nobr>CMPccPD</nobr></code>: Packed Double-Precision FP Compare </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.26">Section B.4.26: <code><nobr>CMPccPS</nobr></code>: Packed Single-Precision FP Compare </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.27">Section B.4.27: <code><nobr>CMPSB</nobr></code>, <code><nobr>CMPSW</nobr></code>, <code><nobr>CMPSD</nobr></code>: Compare Strings</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.28">Section B.4.28: <code><nobr>CMPccSD</nobr></code>: Scalar Double-Precision FP Compare </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.29">Section B.4.29: <code><nobr>CMPccSS</nobr></code>: Scalar Single-Precision FP Compare </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.30">Section B.4.30: <code><nobr>CMPXCHG</nobr></code>, <code><nobr>CMPXCHG486</nobr></code>: Compare and Exchange</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.31">Section B.4.31: <code><nobr>CMPXCHG8B</nobr></code>: Compare and Exchange Eight Bytes</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.32">Section B.4.32: <code><nobr>COMISD</nobr></code>: Scalar Ordered Double-Precision FP Compare and Set EFLAGS</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.33">Section B.4.33: <code><nobr>COMISS</nobr></code>: Scalar Ordered Single-Precision FP Compare and Set EFLAGS</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.34">Section B.4.34: <code><nobr>CPUID</nobr></code>: Get CPU Identification Code</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.35">Section B.4.35: <code><nobr>CVTDQ2PD</nobr></code>: Packed Signed INT32 to Packed Double-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.36">Section B.4.36: <code><nobr>CVTDQ2PS</nobr></code>: Packed Signed INT32 to Packed Single-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.37">Section B.4.37: <code><nobr>CVTPD2DQ</nobr></code>: Packed Double-Precision FP to Packed Signed INT32 Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.38">Section B.4.38: <code><nobr>CVTPD2PI</nobr></code>: Packed Double-Precision FP to Packed Signed INT32 Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.39">Section B.4.39: <code><nobr>CVTPD2PS</nobr></code>: Packed Double-Precision FP to Packed Single-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.40">Section B.4.40: <code><nobr>CVTPI2PD</nobr></code>: Packed Signed INT32 to Packed Double-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.41">Section B.4.41: <code><nobr>CVTPI2PS</nobr></code>: Packed Signed INT32 to Packed Single-FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.42">Section B.4.42: <code><nobr>CVTPS2DQ</nobr></code>: Packed Single-Precision FP to Packed Signed INT32 Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.43">Section B.4.43: <code><nobr>CVTPS2PD</nobr></code>: Packed Single-Precision FP to Packed Double-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.44">Section B.4.44: <code><nobr>CVTPS2PI</nobr></code>: Packed Single-Precision FP to Packed Signed INT32 Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.45">Section B.4.45: <code><nobr>CVTSD2SI</nobr></code>: Scalar Double-Precision FP to Signed INT32 Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.46">Section B.4.46: <code><nobr>CVTSD2SS</nobr></code>: Scalar Double-Precision FP to Scalar Single-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.47">Section B.4.47: <code><nobr>CVTSI2SD</nobr></code>: Signed INT32 to Scalar Double-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.48">Section B.4.48: <code><nobr>CVTSI2SS</nobr></code>: Signed INT32 to Scalar Single-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.49">Section B.4.49: <code><nobr>CVTSS2SD</nobr></code>: Scalar Single-Precision FP to Scalar Double-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.50">Section B.4.50: <code><nobr>CVTSS2SI</nobr></code>: Scalar Single-Precision FP to Signed INT32 Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.51">Section B.4.51: <code><nobr>CVTTPD2DQ</nobr></code>: Packed Double-Precision FP to Packed Signed INT32 Conversion with Truncation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.52">Section B.4.52: <code><nobr>CVTTPD2PI</nobr></code>: Packed Double-Precision FP to Packed Signed INT32 Conversion with Truncation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.53">Section B.4.53: <code><nobr>CVTTPS2DQ</nobr></code>: Packed Single-Precision FP to Packed Signed INT32 Conversion with Truncation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.54">Section B.4.54: <code><nobr>CVTTPS2PI</nobr></code>: Packed Single-Precision FP to Packed Signed INT32 Conversion with Truncation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.55">Section B.4.55: <code><nobr>CVTTSD2SI</nobr></code>: Scalar Double-Precision FP to Signed INT32 Conversion with Truncation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.56">Section B.4.56: <code><nobr>CVTTSS2SI</nobr></code>: Scalar Single-Precision FP to Signed INT32 Conversion with Truncation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.57">Section B.4.57: <code><nobr>DAA</nobr></code>, <code><nobr>DAS</nobr></code>: Decimal Adjustments</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.58">Section B.4.58: <code><nobr>DEC</nobr></code>: Decrement Integer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.59">Section B.4.59: <code><nobr>DIV</nobr></code>: Unsigned Integer Divide</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.60">Section B.4.60: <code><nobr>DIVPD</nobr></code>: Packed Double-Precision FP Divide</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.61">Section B.4.61: <code><nobr>DIVPS</nobr></code>: Packed Single-Precision FP Divide</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.62">Section B.4.62: <code><nobr>DIVSD</nobr></code>: Scalar Double-Precision FP Divide</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.63">Section B.4.63: <code><nobr>DIVSS</nobr></code>: Scalar Single-Precision FP Divide</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.64">Section B.4.64: <code><nobr>EMMS</nobr></code>: Empty MMX State</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.65">Section B.4.65: <code><nobr>ENTER</nobr></code>: Create Stack Frame</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.66">Section B.4.66: <code><nobr>F2XM1</nobr></code>: Calculate 2**X-1</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.67">Section B.4.67: <code><nobr>FABS</nobr></code>: Floating-Point Absolute Value</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.68">Section B.4.68: <code><nobr>FADD</nobr></code>, <code><nobr>FADDP</nobr></code>: Floating-Point Addition</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.69">Section B.4.69: <code><nobr>FBLD</nobr></code>, <code><nobr>FBSTP</nobr></code>: BCD Floating-Point Load and Store</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.70">Section B.4.70: <code><nobr>FCHS</nobr></code>: Floating-Point Change Sign</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.71">Section B.4.71: <code><nobr>FCLEX</nobr></code>, <code><nobr>FNCLEX</nobr></code>: Clear Floating-Point Exceptions</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.72">Section B.4.72: <code><nobr>FCMOVcc</nobr></code>: Floating-Point Conditional Move</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.73">Section B.4.73: <code><nobr>FCOM</nobr></code>, <code><nobr>FCOMP</nobr></code>, <code><nobr>FCOMPP</nobr></code>, <code><nobr>FCOMI</nobr></code>, <code><nobr>FCOMIP</nobr></code>: Floating-Point Compare</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.74">Section B.4.74: <code><nobr>FCOS</nobr></code>: Cosine</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.75">Section B.4.75: <code><nobr>FDECSTP</nobr></code>: Decrement Floating-Point Stack Pointer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.76">Section B.4.76: <code><nobr>FxDISI</nobr></code>, <code><nobr>FxENI</nobr></code>: Disable and Enable Floating-Point Interrupts</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.77">Section B.4.77: <code><nobr>FDIV</nobr></code>, <code><nobr>FDIVP</nobr></code>, <code><nobr>FDIVR</nobr></code>, <code><nobr>FDIVRP</nobr></code>: Floating-Point Division</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.78">Section B.4.78: <code><nobr>FEMMS</nobr></code>: Faster Enter/Exit of the MMX or floating-point state</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.79">Section B.4.79: <code><nobr>FFREE</nobr></code>: Flag Floating-Point Register as Unused</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.80">Section B.4.80: <code><nobr>FIADD</nobr></code>: Floating-Point/Integer Addition</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.81">Section B.4.81: <code><nobr>FICOM</nobr></code>, <code><nobr>FICOMP</nobr></code>: Floating-Point/Integer Compare</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.82">Section B.4.82: <code><nobr>FIDIV</nobr></code>, <code><nobr>FIDIVR</nobr></code>: Floating-Point/Integer Division</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.83">Section B.4.83: <code><nobr>FILD</nobr></code>, <code><nobr>FIST</nobr></code>, <code><nobr>FISTP</nobr></code>: Floating-Point/Integer Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.84">Section B.4.84: <code><nobr>FIMUL</nobr></code>: Floating-Point/Integer Multiplication</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.85">Section B.4.85: <code><nobr>FINCSTP</nobr></code>: Increment Floating-Point Stack Pointer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.86">Section B.4.86: <code><nobr>FINIT</nobr></code>, <code><nobr>FNINIT</nobr></code>: Initialise Floating-Point Unit</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.87">Section B.4.87: <code><nobr>FISUB</nobr></code>: Floating-Point/Integer Subtraction</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.88">Section B.4.88: <code><nobr>FLD</nobr></code>: Floating-Point Load</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.89">Section B.4.89: <code><nobr>FLDxx</nobr></code>: Floating-Point Load Constants</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.90">Section B.4.90: <code><nobr>FLDCW</nobr></code>: Load Floating-Point Control Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.91">Section B.4.91: <code><nobr>FLDENV</nobr></code>: Load Floating-Point Environment</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.92">Section B.4.92: <code><nobr>FMUL</nobr></code>, <code><nobr>FMULP</nobr></code>: Floating-Point Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.93">Section B.4.93: <code><nobr>FNOP</nobr></code>: Floating-Point No Operation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.94">Section B.4.94: <code><nobr>FPATAN</nobr></code>, <code><nobr>FPTAN</nobr></code>: Arctangent and Tangent</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.95">Section B.4.95: <code><nobr>FPREM</nobr></code>, <code><nobr>FPREM1</nobr></code>: Floating-Point Partial Remainder</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.96">Section B.4.96: <code><nobr>FRNDINT</nobr></code>: Floating-Point Round to Integer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.97">Section B.4.97: <code><nobr>FSAVE</nobr></code>, <code><nobr>FRSTOR</nobr></code>: Save/Restore Floating-Point State</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.98">Section B.4.98: <code><nobr>FSCALE</nobr></code>: Scale Floating-Point Value by Power of Two</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.99">Section B.4.99: <code><nobr>FSETPM</nobr></code>: Set Protected Mode</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.100">Section B.4.100: <code><nobr>FSIN</nobr></code>, <code><nobr>FSINCOS</nobr></code>: Sine and Cosine</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.101">Section B.4.101: <code><nobr>FSQRT</nobr></code>: Floating-Point Square Root</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.102">Section B.4.102: <code><nobr>FST</nobr></code>, <code><nobr>FSTP</nobr></code>: Floating-Point Store</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.103">Section B.4.103: <code><nobr>FSTCW</nobr></code>: Store Floating-Point Control Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.104">Section B.4.104: <code><nobr>FSTENV</nobr></code>: Store Floating-Point Environment</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.105">Section B.4.105: <code><nobr>FSTSW</nobr></code>: Store Floating-Point Status Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.106">Section B.4.106: <code><nobr>FSUB</nobr></code>, <code><nobr>FSUBP</nobr></code>, <code><nobr>FSUBR</nobr></code>, <code><nobr>FSUBRP</nobr></code>: Floating-Point Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.107">Section B.4.107: <code><nobr>FTST</nobr></code>: Test <code><nobr>ST0</nobr></code> Against Zero</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.108">Section B.4.108: <code><nobr>FUCOMxx</nobr></code>: Floating-Point Unordered Compare</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.109">Section B.4.109: <code><nobr>FXAM</nobr></code>: Examine Class of Value in <code><nobr>ST0</nobr></code></a><br>
|
||||
<a href="nasmdocb.html#section-B.4.110">Section B.4.110: <code><nobr>FXCH</nobr></code>: Floating-Point Exchange</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.111">Section B.4.111: <code><nobr>FXRSTOR</nobr></code>: Restore <code><nobr>FP</nobr></code>, <code><nobr>MMX</nobr></code> and <code><nobr>SSE</nobr></code> State</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.112">Section B.4.112: <code><nobr>FXSAVE</nobr></code>: Store <code><nobr>FP</nobr></code>, <code><nobr>MMX</nobr></code> and <code><nobr>SSE</nobr></code> State</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.113">Section B.4.113: <code><nobr>FXTRACT</nobr></code>: Extract Exponent and Significand</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.114">Section B.4.114: <code><nobr>FYL2X</nobr></code>, <code><nobr>FYL2XP1</nobr></code>: Compute Y times Log2(X) or Log2(X+1)</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.115">Section B.4.115: <code><nobr>HLT</nobr></code>: Halt Processor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.116">Section B.4.116: <code><nobr>IBTS</nobr></code>: Insert Bit String</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.117">Section B.4.117: <code><nobr>IDIV</nobr></code>: Signed Integer Divide</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.118">Section B.4.118: <code><nobr>IMUL</nobr></code>: Signed Integer Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.119">Section B.4.119: <code><nobr>IN</nobr></code>: Input from I/O Port</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.120">Section B.4.120: <code><nobr>INC</nobr></code>: Increment Integer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.121">Section B.4.121: <code><nobr>INSB</nobr></code>, <code><nobr>INSW</nobr></code>, <code><nobr>INSD</nobr></code>: Input String from I/O Port</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.122">Section B.4.122: <code><nobr>INT</nobr></code>: Software Interrupt</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.123">Section B.4.123: <code><nobr>INT3</nobr></code>, <code><nobr>INT1</nobr></code>, <code><nobr>ICEBP</nobr></code>, <code><nobr>INT01</nobr></code>: Breakpoints</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.124">Section B.4.124: <code><nobr>INTO</nobr></code>: Interrupt if Overflow</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.125">Section B.4.125: <code><nobr>INVD</nobr></code>: Invalidate Internal Caches</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.126">Section B.4.126: <code><nobr>INVLPG</nobr></code>: Invalidate TLB Entry</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.127">Section B.4.127: <code><nobr>IRET</nobr></code>, <code><nobr>IRETW</nobr></code>, <code><nobr>IRETD</nobr></code>: Return from Interrupt</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.128">Section B.4.128: <code><nobr>Jcc</nobr></code>: Conditional Branch</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.129">Section B.4.129: <code><nobr>JCXZ</nobr></code>, <code><nobr>JECXZ</nobr></code>: Jump if CX/ECX Zero</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.130">Section B.4.130: <code><nobr>JMP</nobr></code>: Jump</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.131">Section B.4.131: <code><nobr>LAHF</nobr></code>: Load AH from Flags</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.132">Section B.4.132: <code><nobr>LAR</nobr></code>: Load Access Rights</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.133">Section B.4.133: <code><nobr>LDMXCSR</nobr></code>: Load Streaming SIMD Extension Control/Status</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.134">Section B.4.134: <code><nobr>LDS</nobr></code>, <code><nobr>LES</nobr></code>, <code><nobr>LFS</nobr></code>, <code><nobr>LGS</nobr></code>, <code><nobr>LSS</nobr></code>: Load Far Pointer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.135">Section B.4.135: <code><nobr>LEA</nobr></code>: Load Effective Address</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.136">Section B.4.136: <code><nobr>LEAVE</nobr></code>: Destroy Stack Frame</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.137">Section B.4.137: <code><nobr>LFENCE</nobr></code>: Load Fence</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.138">Section B.4.138: <code><nobr>LGDT</nobr></code>, <code><nobr>LIDT</nobr></code>, <code><nobr>LLDT</nobr></code>: Load Descriptor Tables</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.139">Section B.4.139: <code><nobr>LMSW</nobr></code>: Load/Store Machine Status Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.140">Section B.4.140: <code><nobr>LOADALL</nobr></code>, <code><nobr>LOADALL286</nobr></code>: Load Processor State</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.141">Section B.4.141: <code><nobr>LODSB</nobr></code>, <code><nobr>LODSW</nobr></code>, <code><nobr>LODSD</nobr></code>: Load from String</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.142">Section B.4.142: <code><nobr>LOOP</nobr></code>, <code><nobr>LOOPE</nobr></code>, <code><nobr>LOOPZ</nobr></code>, <code><nobr>LOOPNE</nobr></code>, <code><nobr>LOOPNZ</nobr></code>: Loop with Counter</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.143">Section B.4.143: <code><nobr>LSL</nobr></code>: Load Segment Limit</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.144">Section B.4.144: <code><nobr>LTR</nobr></code>: Load Task Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.145">Section B.4.145: <code><nobr>MASKMOVDQU</nobr></code>: Byte Mask Write</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.146">Section B.4.146: <code><nobr>MASKMOVQ</nobr></code>: Byte Mask Write</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.147">Section B.4.147: <code><nobr>MAXPD</nobr></code>: Return Packed Double-Precision FP Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.148">Section B.4.148: <code><nobr>MAXPS</nobr></code>: Return Packed Single-Precision FP Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.149">Section B.4.149: <code><nobr>MAXSD</nobr></code>: Return Scalar Double-Precision FP Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.150">Section B.4.150: <code><nobr>MAXSS</nobr></code>: Return Scalar Single-Precision FP Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.151">Section B.4.151: <code><nobr>MFENCE</nobr></code>: Memory Fence</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.152">Section B.4.152: <code><nobr>MINPD</nobr></code>: Return Packed Double-Precision FP Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.153">Section B.4.153: <code><nobr>MINPS</nobr></code>: Return Packed Single-Precision FP Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.154">Section B.4.154: <code><nobr>MINSD</nobr></code>: Return Scalar Double-Precision FP Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.155">Section B.4.155: <code><nobr>MINSS</nobr></code>: Return Scalar Single-Precision FP Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.156">Section B.4.156: <code><nobr>MOV</nobr></code>: Move Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.157">Section B.4.157: <code><nobr>MOVAPD</nobr></code>: Move Aligned Packed Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.158">Section B.4.158: <code><nobr>MOVAPS</nobr></code>: Move Aligned Packed Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.159">Section B.4.159: <code><nobr>MOVD</nobr></code>: Move Doubleword to/from MMX Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.160">Section B.4.160: <code><nobr>MOVDQ2Q</nobr></code>: Move Quadword from XMM to MMX register.</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.161">Section B.4.161: <code><nobr>MOVDQA</nobr></code>: Move Aligned Double Quadword</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.162">Section B.4.162: <code><nobr>MOVDQU</nobr></code>: Move Unaligned Double Quadword</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.163">Section B.4.163: <code><nobr>MOVHLPS</nobr></code>: Move Packed Single-Precision FP High to Low</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.164">Section B.4.164: <code><nobr>MOVHPD</nobr></code>: Move High Packed Double-Precision FP</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.165">Section B.4.165: <code><nobr>MOVHPS</nobr></code>: Move High Packed Single-Precision FP</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.166">Section B.4.166: <code><nobr>MOVLHPS</nobr></code>: Move Packed Single-Precision FP Low to High</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.167">Section B.4.167: <code><nobr>MOVLPD</nobr></code>: Move Low Packed Double-Precision FP</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.168">Section B.4.168: <code><nobr>MOVLPS</nobr></code>: Move Low Packed Single-Precision FP</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.169">Section B.4.169: <code><nobr>MOVMSKPD</nobr></code>: Extract Packed Double-Precision FP Sign Mask</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.170">Section B.4.170: <code><nobr>MOVMSKPS</nobr></code>: Extract Packed Single-Precision FP Sign Mask</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.171">Section B.4.171: <code><nobr>MOVNTDQ</nobr></code>: Move Double Quadword Non Temporal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.172">Section B.4.172: <code><nobr>MOVNTI</nobr></code>: Move Doubleword Non Temporal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.173">Section B.4.173: <code><nobr>MOVNTPD</nobr></code>: Move Aligned Four Packed Single-Precision FP Values Non Temporal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.174">Section B.4.174: <code><nobr>MOVNTPS</nobr></code>: Move Aligned Four Packed Single-Precision FP Values Non Temporal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.175">Section B.4.175: <code><nobr>MOVNTQ</nobr></code>: Move Quadword Non Temporal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.176">Section B.4.176: <code><nobr>MOVQ</nobr></code>: Move Quadword to/from MMX Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.177">Section B.4.177: <code><nobr>MOVQ2DQ</nobr></code>: Move Quadword from MMX to XMM register.</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.178">Section B.4.178: <code><nobr>MOVSB</nobr></code>, <code><nobr>MOVSW</nobr></code>, <code><nobr>MOVSD</nobr></code>: Move String</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.179">Section B.4.179: <code><nobr>MOVSD</nobr></code>: Move Scalar Double-Precision FP Value</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.180">Section B.4.180: <code><nobr>MOVSS</nobr></code>: Move Scalar Single-Precision FP Value</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.181">Section B.4.181: <code><nobr>MOVSX</nobr></code>, <code><nobr>MOVZX</nobr></code>: Move Data with Sign or Zero Extend</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.182">Section B.4.182: <code><nobr>MOVUPD</nobr></code>: Move Unaligned Packed Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.183">Section B.4.183: <code><nobr>MOVUPS</nobr></code>: Move Unaligned Packed Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.184">Section B.4.184: <code><nobr>MUL</nobr></code>: Unsigned Integer Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.185">Section B.4.185: <code><nobr>MULPD</nobr></code>: Packed Single-FP Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.186">Section B.4.186: <code><nobr>MULPS</nobr></code>: Packed Single-FP Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.187">Section B.4.187: <code><nobr>MULSD</nobr></code>: Scalar Single-FP Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.188">Section B.4.188: <code><nobr>MULSS</nobr></code>: Scalar Single-FP Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.189">Section B.4.189: <code><nobr>NEG</nobr></code>, <code><nobr>NOT</nobr></code>: Two's and One's Complement</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.190">Section B.4.190: <code><nobr>NOP</nobr></code>: No Operation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.191">Section B.4.191: <code><nobr>OR</nobr></code>: Bitwise OR</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.192">Section B.4.192: <code><nobr>ORPD</nobr></code>: Bit-wise Logical OR of Double-Precision FP Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.193">Section B.4.193: <code><nobr>ORPS</nobr></code>: Bit-wise Logical OR of Single-Precision FP Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.194">Section B.4.194: <code><nobr>OUT</nobr></code>: Output Data to I/O Port</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.195">Section B.4.195: <code><nobr>OUTSB</nobr></code>, <code><nobr>OUTSW</nobr></code>, <code><nobr>OUTSD</nobr></code>: Output String to I/O Port</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.196">Section B.4.196: <code><nobr>PACKSSDW</nobr></code>, <code><nobr>PACKSSWB</nobr></code>, <code><nobr>PACKUSWB</nobr></code>: Pack Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.197">Section B.4.197: <code><nobr>PADDB</nobr></code>, <code><nobr>PADDW</nobr></code>, <code><nobr>PADDD</nobr></code>: Add Packed Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.198">Section B.4.198: <code><nobr>PADDQ</nobr></code>: Add Packed Quadword Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.199">Section B.4.199: <code><nobr>PADDSB</nobr></code>, <code><nobr>PADDSW</nobr></code>: Add Packed Signed Integers With Saturation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.200">Section B.4.200: <code><nobr>PADDSIW</nobr></code>: MMX Packed Addition to Implicit Destination</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.201">Section B.4.201: <code><nobr>PADDUSB</nobr></code>, <code><nobr>PADDUSW</nobr></code>: Add Packed Unsigned Integers With Saturation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.202">Section B.4.202: <code><nobr>PAND</nobr></code>, <code><nobr>PANDN</nobr></code>: MMX Bitwise AND and AND-NOT</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.203">Section B.4.203: <code><nobr>PAUSE</nobr></code>: Spin Loop Hint</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.204">Section B.4.204: <code><nobr>PAVEB</nobr></code>: MMX Packed Average</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.205">Section B.4.205: <code><nobr>PAVGB</nobr></code> <code><nobr>PAVGW</nobr></code>: Average Packed Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.206">Section B.4.206: <code><nobr>PAVGUSB</nobr></code>: Average of unsigned packed 8-bit values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.207">Section B.4.207: <code><nobr>PCMPxx</nobr></code>: Compare Packed Integers.</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.208">Section B.4.208: <code><nobr>PDISTIB</nobr></code>: MMX Packed Distance and Accumulate with Implied Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.209">Section B.4.209: <code><nobr>PEXTRW</nobr></code>: Extract Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.210">Section B.4.210: <code><nobr>PF2ID</nobr></code>: Packed Single-Precision FP to Integer Convert</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.211">Section B.4.211: <code><nobr>PF2IW</nobr></code>: Packed Single-Precision FP to Integer Word Convert</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.212">Section B.4.212: <code><nobr>PFACC</nobr></code>: Packed Single-Precision FP Accumulate</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.213">Section B.4.213: <code><nobr>PFADD</nobr></code>: Packed Single-Precision FP Addition</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.214">Section B.4.214: <code><nobr>PFCMPxx</nobr></code>: Packed Single-Precision FP Compare </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.215">Section B.4.215: <code><nobr>PFMAX</nobr></code>: Packed Single-Precision FP Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.216">Section B.4.216: <code><nobr>PFMIN</nobr></code>: Packed Single-Precision FP Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.217">Section B.4.217: <code><nobr>PFMUL</nobr></code>: Packed Single-Precision FP Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.218">Section B.4.218: <code><nobr>PFNACC</nobr></code>: Packed Single-Precision FP Negative Accumulate</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.219">Section B.4.219: <code><nobr>PFPNACC</nobr></code>: Packed Single-Precision FP Mixed Accumulate</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.220">Section B.4.220: <code><nobr>PFRCP</nobr></code>: Packed Single-Precision FP Reciprocal Approximation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.221">Section B.4.221: <code><nobr>PFRCPIT1</nobr></code>: Packed Single-Precision FP Reciprocal, First Iteration Step</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.222">Section B.4.222: <code><nobr>PFRCPIT2</nobr></code>: Packed Single-Precision FP Reciprocal/ Reciprocal Square Root, Second Iteration Step</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.223">Section B.4.223: <code><nobr>PFRSQIT1</nobr></code>: Packed Single-Precision FP Reciprocal Square Root, First Iteration Step</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.224">Section B.4.224: <code><nobr>PFRSQRT</nobr></code>: Packed Single-Precision FP Reciprocal Square Root Approximation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.225">Section B.4.225: <code><nobr>PFSUB</nobr></code>: Packed Single-Precision FP Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.226">Section B.4.226: <code><nobr>PFSUBR</nobr></code>: Packed Single-Precision FP Reverse Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.227">Section B.4.227: <code><nobr>PI2FD</nobr></code>: Packed Doubleword Integer to Single-Precision FP Convert</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.228">Section B.4.228: <code><nobr>PF2IW</nobr></code>: Packed Word Integer to Single-Precision FP Convert</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.229">Section B.4.229: <code><nobr>PINSRW</nobr></code>: Insert Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.230">Section B.4.230: <code><nobr>PMACHRIW</nobr></code>: Packed Multiply and Accumulate with Rounding</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.231">Section B.4.231: <code><nobr>PMADDWD</nobr></code>: MMX Packed Multiply and Add</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.232">Section B.4.232: <code><nobr>PMAGW</nobr></code>: MMX Packed Magnitude</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.233">Section B.4.233: <code><nobr>PMAXSW</nobr></code>: Packed Signed Integer Word Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.234">Section B.4.234: <code><nobr>PMAXUB</nobr></code>: Packed Unsigned Integer Byte Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.235">Section B.4.235: <code><nobr>PMINSW</nobr></code>: Packed Signed Integer Word Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.236">Section B.4.236: <code><nobr>PMINUB</nobr></code>: Packed Unsigned Integer Byte Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.237">Section B.4.237: <code><nobr>PMOVMSKB</nobr></code>: Move Byte Mask To Integer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.238">Section B.4.238: <code><nobr>PMULHRWC</nobr></code>, <code><nobr>PMULHRIW</nobr></code>: Multiply Packed 16-bit Integers With Rounding, and Store High Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.239">Section B.4.239: <code><nobr>PMULHRWA</nobr></code>: Multiply Packed 16-bit Integers With Rounding, and Store High Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.240">Section B.4.240: <code><nobr>PMULHUW</nobr></code>: Multiply Packed 16-bit Integers, and Store High Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.241">Section B.4.241: <code><nobr>PMULHW</nobr></code>, <code><nobr>PMULLW</nobr></code>: Multiply Packed 16-bit Integers, and Store</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.242">Section B.4.242: <code><nobr>PMULUDQ</nobr></code>: Multiply Packed Unsigned 32-bit Integers, and Store.</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.243">Section B.4.243: <code><nobr>PMVccZB</nobr></code>: MMX Packed Conditional Move</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.244">Section B.4.244: <code><nobr>POP</nobr></code>: Pop Data from Stack</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.245">Section B.4.245: <code><nobr>POPAx</nobr></code>: Pop All General-Purpose Registers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.246">Section B.4.246: <code><nobr>POPFx</nobr></code>: Pop Flags Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.247">Section B.4.247: <code><nobr>POR</nobr></code>: MMX Bitwise OR</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.248">Section B.4.248: <code><nobr>PREFETCH</nobr></code>: Prefetch Data Into Caches</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.249">Section B.4.249: <code><nobr>PREFETCHh</nobr></code>: Prefetch Data Into Caches </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.250">Section B.4.250: <code><nobr>PSADBW</nobr></code>: Packed Sum of Absolute Differences</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.251">Section B.4.251: <code><nobr>PSHUFD</nobr></code>: Shuffle Packed Doublewords</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.252">Section B.4.252: <code><nobr>PSHUFHW</nobr></code>: Shuffle Packed High Words</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.253">Section B.4.253: <code><nobr>PSHUFLW</nobr></code>: Shuffle Packed Low Words</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.254">Section B.4.254: <code><nobr>PSHUFW</nobr></code>: Shuffle Packed Words</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.255">Section B.4.255: <code><nobr>PSLLx</nobr></code>: Packed Data Bit Shift Left Logical</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.256">Section B.4.256: <code><nobr>PSRAx</nobr></code>: Packed Data Bit Shift Right Arithmetic</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.257">Section B.4.257: <code><nobr>PSRLx</nobr></code>: Packed Data Bit Shift Right Logical</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.258">Section B.4.258: <code><nobr>PSUBx</nobr></code>: Subtract Packed Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.259">Section B.4.259: <code><nobr>PSUBSxx</nobr></code>, <code><nobr>PSUBUSx</nobr></code>: Subtract Packed Integers With Saturation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.260">Section B.4.260: <code><nobr>PSUBSIW</nobr></code>: MMX Packed Subtract with Saturation to Implied Destination</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.261">Section B.4.261: <code><nobr>PSWAPD</nobr></code>: Swap Packed Data </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.262">Section B.4.262: <code><nobr>PUNPCKxxx</nobr></code>: Unpack and Interleave Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.263">Section B.4.263: <code><nobr>PUSH</nobr></code>: Push Data on Stack</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.264">Section B.4.264: <code><nobr>PUSHAx</nobr></code>: Push All General-Purpose Registers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.265">Section B.4.265: <code><nobr>PUSHFx</nobr></code>: Push Flags Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.266">Section B.4.266: <code><nobr>PXOR</nobr></code>: MMX Bitwise XOR</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.267">Section B.4.267: <code><nobr>RCL</nobr></code>, <code><nobr>RCR</nobr></code>: Bitwise Rotate through Carry Bit</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.268">Section B.4.268: <code><nobr>RCPPS</nobr></code>: Packed Single-Precision FP Reciprocal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.269">Section B.4.269: <code><nobr>RCPSS</nobr></code>: Scalar Single-Precision FP Reciprocal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.270">Section B.4.270: <code><nobr>RDMSR</nobr></code>: Read Model-Specific Registers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.271">Section B.4.271: <code><nobr>RDPMC</nobr></code>: Read Performance-Monitoring Counters</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.272">Section B.4.272: <code><nobr>RDSHR</nobr></code>: Read SMM Header Pointer Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.273">Section B.4.273: <code><nobr>RDTSC</nobr></code>: Read Time-Stamp Counter</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.274">Section B.4.274: <code><nobr>RET</nobr></code>, <code><nobr>RETF</nobr></code>, <code><nobr>RETN</nobr></code>: Return from Procedure Call</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.275">Section B.4.275: <code><nobr>ROL</nobr></code>, <code><nobr>ROR</nobr></code>: Bitwise Rotate</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.276">Section B.4.276: <code><nobr>RSDC</nobr></code>: Restore Segment Register and Descriptor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.277">Section B.4.277: <code><nobr>RSLDT</nobr></code>: Restore Segment Register and Descriptor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.278">Section B.4.278: <code><nobr>RSM</nobr></code>: Resume from System-Management Mode</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.279">Section B.4.279: <code><nobr>RSQRTPS</nobr></code>: Packed Single-Precision FP Square Root Reciprocal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.280">Section B.4.280: <code><nobr>RSQRTSS</nobr></code>: Scalar Single-Precision FP Square Root Reciprocal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.281">Section B.4.281: <code><nobr>RSTS</nobr></code>: Restore TSR and Descriptor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.282">Section B.4.282: <code><nobr>SAHF</nobr></code>: Store AH to Flags</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.283">Section B.4.283: <code><nobr>SAL</nobr></code>, <code><nobr>SAR</nobr></code>: Bitwise Arithmetic Shifts</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.284">Section B.4.284: <code><nobr>SALC</nobr></code>: Set AL from Carry Flag</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.285">Section B.4.285: <code><nobr>SBB</nobr></code>: Subtract with Borrow</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.286">Section B.4.286: <code><nobr>SCASB</nobr></code>, <code><nobr>SCASW</nobr></code>, <code><nobr>SCASD</nobr></code>: Scan String</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.287">Section B.4.287: <code><nobr>SETcc</nobr></code>: Set Register from Condition</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.288">Section B.4.288: <code><nobr>SFENCE</nobr></code>: Store Fence</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.289">Section B.4.289: <code><nobr>SGDT</nobr></code>, <code><nobr>SIDT</nobr></code>, <code><nobr>SLDT</nobr></code>: Store Descriptor Table Pointers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.290">Section B.4.290: <code><nobr>SHL</nobr></code>, <code><nobr>SHR</nobr></code>: Bitwise Logical Shifts</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.291">Section B.4.291: <code><nobr>SHLD</nobr></code>, <code><nobr>SHRD</nobr></code>: Bitwise Double-Precision Shifts</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.292">Section B.4.292: <code><nobr>SHUFPD</nobr></code>: Shuffle Packed Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.293">Section B.4.293: <code><nobr>SHUFPS</nobr></code>: Shuffle Packed Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.294">Section B.4.294: <code><nobr>SMI</nobr></code>: System Management Interrupt</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.295">Section B.4.295: <code><nobr>SMINT</nobr></code>, <code><nobr>SMINTOLD</nobr></code>: Software SMM Entry (CYRIX)</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.296">Section B.4.296: <code><nobr>SMSW</nobr></code>: Store Machine Status Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.297">Section B.4.297: <code><nobr>SQRTPD</nobr></code>: Packed Double-Precision FP Square Root</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.298">Section B.4.298: <code><nobr>SQRTPS</nobr></code>: Packed Single-Precision FP Square Root</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.299">Section B.4.299: <code><nobr>SQRTSD</nobr></code>: Scalar Double-Precision FP Square Root</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.300">Section B.4.300: <code><nobr>SQRTSS</nobr></code>: Scalar Single-Precision FP Square Root</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.301">Section B.4.301: <code><nobr>STC</nobr></code>, <code><nobr>STD</nobr></code>, <code><nobr>STI</nobr></code>: Set Flags</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.302">Section B.4.302: <code><nobr>STMXCSR</nobr></code>: Store Streaming SIMD Extension Control/Status</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.303">Section B.4.303: <code><nobr>STOSB</nobr></code>, <code><nobr>STOSW</nobr></code>, <code><nobr>STOSD</nobr></code>: Store Byte to String</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.304">Section B.4.304: <code><nobr>STR</nobr></code>: Store Task Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.305">Section B.4.305: <code><nobr>SUB</nobr></code>: Subtract Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.306">Section B.4.306: <code><nobr>SUBPD</nobr></code>: Packed Double-Precision FP Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.307">Section B.4.307: <code><nobr>SUBPS</nobr></code>: Packed Single-Precision FP Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.308">Section B.4.308: <code><nobr>SUBSD</nobr></code>: Scalar Single-FP Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.309">Section B.4.309: <code><nobr>SUBSS</nobr></code>: Scalar Single-FP Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.310">Section B.4.310: <code><nobr>SVDC</nobr></code>: Save Segment Register and Descriptor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.311">Section B.4.311: <code><nobr>SVLDT</nobr></code>: Save LDTR and Descriptor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.312">Section B.4.312: <code><nobr>SVTS</nobr></code>: Save TSR and Descriptor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.313">Section B.4.313: <code><nobr>SYSCALL</nobr></code>: Call Operating System</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.314">Section B.4.314: <code><nobr>SYSENTER</nobr></code>: Fast System Call</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.315">Section B.4.315: <code><nobr>SYSEXIT</nobr></code>: Fast Return From System Call</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.316">Section B.4.316: <code><nobr>SYSRET</nobr></code>: Return From Operating System</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.317">Section B.4.317: <code><nobr>TEST</nobr></code>: Test Bits (notional bitwise AND)</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.318">Section B.4.318: <code><nobr>UCOMISD</nobr></code>: Unordered Scalar Double-Precision FP compare and set EFLAGS</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.319">Section B.4.319: <code><nobr>UCOMISS</nobr></code>: Unordered Scalar Single-Precision FP compare and set EFLAGS</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.320">Section B.4.320: <code><nobr>UD0</nobr></code>, <code><nobr>UD1</nobr></code>, <code><nobr>UD2</nobr></code>: Undefined Instruction</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.321">Section B.4.321: <code><nobr>UMOV</nobr></code>: User Move Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.322">Section B.4.322: <code><nobr>UNPCKHPD</nobr></code>: Unpack and Interleave High Packed Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.323">Section B.4.323: <code><nobr>UNPCKHPS</nobr></code>: Unpack and Interleave High Packed Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.324">Section B.4.324: <code><nobr>UNPCKLPD</nobr></code>: Unpack and Interleave Low Packed Double-Precision FP Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.325">Section B.4.325: <code><nobr>UNPCKLPS</nobr></code>: Unpack and Interleave Low Packed Single-Precision FP Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.326">Section B.4.326: <code><nobr>VERR</nobr></code>, <code><nobr>VERW</nobr></code>: Verify Segment Readability/Writability</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.327">Section B.4.327: <code><nobr>WAIT</nobr></code>: Wait for Floating-Point Processor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.328">Section B.4.328: <code><nobr>WBINVD</nobr></code>: Write Back and Invalidate Cache</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.329">Section B.4.329: <code><nobr>WRMSR</nobr></code>: Write Model-Specific Registers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.330">Section B.4.330: <code><nobr>WRSHR</nobr></code>: Write SMM Header Pointer Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.331">Section B.4.331: <code><nobr>XADD</nobr></code>: Exchange and Add</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.332">Section B.4.332: <code><nobr>XBTS</nobr></code>: Extract Bit String</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.333">Section B.4.333: <code><nobr>XCHG</nobr></code>: Exchange</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.334">Section B.4.334: <code><nobr>XLATB</nobr></code>: Translate Byte in Lookup Table</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.335">Section B.4.335: <code><nobr>XOR</nobr></code>: Bitwise Exclusive OR</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.336">Section B.4.336: <code><nobr>XORPD</nobr></code>: Bitwise Logical XOR of Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.337">Section B.4.337: <code><nobr>XORPS</nobr></code>: Bitwise Logical XOR of Single-Precision FP Values</a><br>
|
||||
<p><a href="nasmdoci.html">Index</a>
|
||||
</body></html>
|
||||
178
Ref-docs/nasmdoc/html/nasmdo10.html
Normal file
178
Ref-docs/nasmdoc/html/nasmdo10.html
Normal file
@@ -0,0 +1,178 @@
|
||||
<html><head><title>NASM Manual</title></head>
|
||||
<body><h1 align=center>The Netwide Assembler: NASM</h1>
|
||||
|
||||
<p align=center><a href="nasmdoca.html">Next Chapter</a> |
|
||||
<a href="nasmdoc9.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
<h2><a name="chapter-10">Chapter 10: Troubleshooting</a></h2>
|
||||
<p>This chapter describes some of the common problems that users have been
|
||||
known to encounter with NASM, and answers them. It also gives instructions
|
||||
for reporting bugs in NASM if you find a difficulty that isn't listed here.
|
||||
<h3><a name="section-10.1">10.1 Common Problems</a></h3>
|
||||
<h4><a name="section-10.1.1">10.1.1 NASM Generates Inefficient Code</a></h4>
|
||||
<p>We sometimes get `bug' reports about NASM generating inefficient, or
|
||||
even `wrong', code on instructions such as
|
||||
<code><nobr>ADD ESP,8</nobr></code>. This is a deliberate design feature,
|
||||
connected to predictability of output: NASM, on seeing
|
||||
<code><nobr>ADD ESP,8</nobr></code>, will generate the form of the
|
||||
instruction which leaves room for a 32-bit offset. You need to code
|
||||
<code><nobr>ADD ESP,BYTE 8</nobr></code> if you want the space-efficient
|
||||
form of the instruction. This isn't a bug, it's user error: if you prefer
|
||||
to have NASM produce the more efficient code automatically enable
|
||||
optimization with the <code><nobr>-On</nobr></code> option (see
|
||||
<a href="nasmdoc2.html#section-2.1.16">section 2.1.16</a>).
|
||||
<h4><a name="section-10.1.2">10.1.2 My Jumps are Out of Range</a></h4>
|
||||
<p>Similarly, people complain that when they issue conditional jumps (which
|
||||
are <code><nobr>SHORT</nobr></code> by default) that try to jump too far,
|
||||
NASM reports `short jump out of range' instead of making the jumps longer.
|
||||
<p>This, again, is partly a predictability issue, but in fact has a more
|
||||
practical reason as well. NASM has no means of being told what type of
|
||||
processor the code it is generating will be run on; so it cannot decide for
|
||||
itself that it should generate <code><nobr>Jcc NEAR</nobr></code> type
|
||||
instructions, because it doesn't know that it's working for a 386 or above.
|
||||
Alternatively, it could replace the out-of-range short
|
||||
<code><nobr>JNE</nobr></code> instruction with a very short
|
||||
<code><nobr>JE</nobr></code> instruction that jumps over a
|
||||
<code><nobr>JMP NEAR</nobr></code>; this is a sensible solution for
|
||||
processors below a 386, but hardly efficient on processors which have good
|
||||
branch prediction <em>and</em> could have used
|
||||
<code><nobr>JNE NEAR</nobr></code> instead. So, once again, it's up to the
|
||||
user, not the assembler, to decide what instructions should be generated.
|
||||
See <a href="nasmdoc2.html#section-2.1.16">section 2.1.16</a>.
|
||||
<h4><a name="section-10.1.3">10.1.3 <code><nobr>ORG</nobr></code> Doesn't Work</a></h4>
|
||||
<p>People writing boot sector programs in the <code><nobr>bin</nobr></code>
|
||||
format often complain that <code><nobr>ORG</nobr></code> doesn't work the
|
||||
way they'd like: in order to place the <code><nobr>0xAA55</nobr></code>
|
||||
signature word at the end of a 512-byte boot sector, people who are used to
|
||||
MASM tend to code
|
||||
<p><pre>
|
||||
ORG 0
|
||||
|
||||
; some boot sector code
|
||||
|
||||
ORG 510
|
||||
DW 0xAA55
|
||||
</pre>
|
||||
<p>This is not the intended use of the <code><nobr>ORG</nobr></code>
|
||||
directive in NASM, and will not work. The correct way to solve this problem
|
||||
in NASM is to use the <code><nobr>TIMES</nobr></code> directive, like this:
|
||||
<p><pre>
|
||||
ORG 0
|
||||
|
||||
; some boot sector code
|
||||
|
||||
TIMES 510-($-$$) DB 0
|
||||
DW 0xAA55
|
||||
</pre>
|
||||
<p>The <code><nobr>TIMES</nobr></code> directive will insert exactly enough
|
||||
zero bytes into the output to move the assembly point up to 510. This
|
||||
method also has the advantage that if you accidentally fill your boot
|
||||
sector too full, NASM will catch the problem at assembly time and report
|
||||
it, so you won't end up with a boot sector that you have to disassemble to
|
||||
find out what's wrong with it.
|
||||
<h4><a name="section-10.1.4">10.1.4 <code><nobr>TIMES</nobr></code> Doesn't Work</a></h4>
|
||||
<p>The other common problem with the above code is people who write the
|
||||
<code><nobr>TIMES</nobr></code> line as
|
||||
<p><pre>
|
||||
TIMES 510-$ DB 0
|
||||
</pre>
|
||||
<p>by reasoning that <code><nobr>$</nobr></code> should be a pure number,
|
||||
just like 510, so the difference between them is also a pure number and can
|
||||
happily be fed to <code><nobr>TIMES</nobr></code>.
|
||||
<p>NASM is a <em>modular</em> assembler: the various component parts are
|
||||
designed to be easily separable for re-use, so they don't exchange
|
||||
information unnecessarily. In consequence, the
|
||||
<code><nobr>bin</nobr></code> output format, even though it has been told
|
||||
by the <code><nobr>ORG</nobr></code> directive that the
|
||||
<code><nobr>.text</nobr></code> section should start at 0, does not pass
|
||||
that information back to the expression evaluator. So from the evaluator's
|
||||
point of view, <code><nobr>$</nobr></code> isn't a pure number: it's an
|
||||
offset from a section base. Therefore the difference between
|
||||
<code><nobr>$</nobr></code> and 510 is also not a pure number, but involves
|
||||
a section base. Values involving section bases cannot be passed as
|
||||
arguments to <code><nobr>TIMES</nobr></code>.
|
||||
<p>The solution, as in the previous section, is to code the
|
||||
<code><nobr>TIMES</nobr></code> line in the form
|
||||
<p><pre>
|
||||
TIMES 510-($-$$) DB 0
|
||||
</pre>
|
||||
<p>in which <code><nobr>$</nobr></code> and <code><nobr>$$</nobr></code>
|
||||
are offsets from the same section base, and so their difference is a pure
|
||||
number. This will solve the problem and generate sensible code.
|
||||
<h3><a name="section-10.2">10.2 Bugs</a></h3>
|
||||
<p>We have never yet released a version of NASM with any <em>known</em>
|
||||
bugs. That doesn't usually stop there being plenty we didn't know about,
|
||||
though. Any that you find should be reported firstly via the
|
||||
<code><nobr>bugtracker</nobr></code> at
|
||||
<a href="https://sourceforge.net/projects/nasm/"><code><nobr>https://sourceforge.net/projects/nasm/</nobr></code></a>
|
||||
(click on "Bugs"), or if that fails then through one of the contacts in
|
||||
<a href="nasmdoc1.html#section-1.2">section 1.2</a>.
|
||||
<p>Please read <a href="nasmdoc2.html#section-2.2">section 2.2</a> first,
|
||||
and don't report the bug if it's listed in there as a deliberate feature.
|
||||
(If you think the feature is badly thought out, feel free to send us
|
||||
reasons why you think it should be changed, but don't just send us mail
|
||||
saying `This is a bug' if the documentation says we did it on purpose.)
|
||||
Then read <a href="#section-10.1">section 10.1</a>, and don't bother
|
||||
reporting the bug if it's listed there.
|
||||
<p>If you do report a bug, <em>please</em> give us all of the following
|
||||
information:
|
||||
<ul>
|
||||
<li>What operating system you're running NASM under. DOS, Linux, NetBSD,
|
||||
Win16, Win32, VMS (I'd be impressed), whatever.
|
||||
<li>If you're running NASM under DOS or Win32, tell us whether you've
|
||||
compiled your own executable from the DOS source archive, or whether you
|
||||
were using the standard distribution binaries out of the archive. If you
|
||||
were using a locally built executable, try to reproduce the problem using
|
||||
one of the standard binaries, as this will make it easier for us to
|
||||
reproduce your problem prior to fixing it.
|
||||
<li>Which version of NASM you're using, and exactly how you invoked it.
|
||||
Give us the precise command line, and the contents of the
|
||||
<code><nobr>NASMENV</nobr></code> environment variable if any.
|
||||
<li>Which versions of any supplementary programs you're using, and how you
|
||||
invoked them. If the problem only becomes visible at link time, tell us
|
||||
what linker you're using, what version of it you've got, and the exact
|
||||
linker command line. If the problem involves linking against object files
|
||||
generated by a compiler, tell us what compiler, what version, and what
|
||||
command line or options you used. (If you're compiling in an IDE, please
|
||||
try to reproduce the problem with the command-line version of the
|
||||
compiler.)
|
||||
<li>If at all possible, send us a NASM source file which exhibits the
|
||||
problem. If this causes copyright problems (e.g. you can only reproduce the
|
||||
bug in restricted-distribution code) then bear in mind the following two
|
||||
points: firstly, we guarantee that any source code sent to us for the
|
||||
purposes of debugging NASM will be used <em>only</em> for the purposes of
|
||||
debugging NASM, and that we will delete all our copies of it as soon as we
|
||||
have found and fixed the bug or bugs in question; and secondly, we would
|
||||
prefer <em>not</em> to be mailed large chunks of code anyway. The smaller
|
||||
the file, the better. A three-line sample file that does nothing useful
|
||||
<em>except</em> demonstrate the problem is much easier to work with than a
|
||||
fully fledged ten-thousand-line program. (Of course, some errors
|
||||
<em>do</em> only crop up in large files, so this may not be possible.)
|
||||
<li>A description of what the problem actually <em>is</em>. `It doesn't
|
||||
work' is <em>not</em> a helpful description! Please describe exactly what
|
||||
is happening that shouldn't be, or what isn't happening that should.
|
||||
Examples might be: `NASM generates an error message saying Line 3 for an
|
||||
error that's actually on Line 5'; `NASM generates an error message that I
|
||||
believe it shouldn't be generating at all'; `NASM fails to generate an
|
||||
error message that I believe it <em>should</em> be generating'; `the object
|
||||
file produced from this source code crashes my linker'; `the ninth byte of
|
||||
the output file is 66 and I think it should be 77 instead'.
|
||||
<li>If you believe the output file from NASM to be faulty, send it to us.
|
||||
That allows us to determine whether our own copy of NASM generates the same
|
||||
file, or whether the problem is related to portability issues between our
|
||||
development platforms and yours. We can handle binary files mailed to us as
|
||||
MIME attachments, uuencoded, and even BinHex. Alternatively, we may be able
|
||||
to provide an FTP site you can upload the suspect files to; but mailing
|
||||
them is easier for us.
|
||||
<li>Any other information or data files that might be helpful. If, for
|
||||
example, the problem involves NASM failing to generate an object file while
|
||||
TASM can generate an equivalent file without trouble, then send us
|
||||
<em>both</em> object files, so we can see what TASM is doing differently
|
||||
from us.
|
||||
</ul>
|
||||
<p align=center><a href="nasmdoca.html">Next Chapter</a> |
|
||||
<a href="nasmdoc9.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
</body></html>
|
||||
564
Ref-docs/nasmdoc/html/nasmdoc0.html
Normal file
564
Ref-docs/nasmdoc/html/nasmdoc0.html
Normal file
@@ -0,0 +1,564 @@
|
||||
<html><head><title>NASM Manual</title></head>
|
||||
<body><h1 align=center>The Netwide Assembler: NASM</h1>
|
||||
|
||||
<p>This manual documents NASM, the Netwide Assembler: an assembler
|
||||
targetting the Intel x86 series of processors, with portable source.
|
||||
<p><p><a href="nasmdoc1.html">Chapter 1: Introduction</a><br>
|
||||
<a href="nasmdoc1.html#section-1.1">Section 1.1: What Is NASM?</a><br>
|
||||
<a href="nasmdoc1.html#section-1.1.1">Section 1.1.1: Why Yet Another Assembler?</a><br>
|
||||
<a href="nasmdoc1.html#section-1.1.2">Section 1.1.2: Licence Conditions</a><br>
|
||||
<a href="nasmdoc1.html#section-1.2">Section 1.2: Contact Information</a><br>
|
||||
<a href="nasmdoc1.html#section-1.3">Section 1.3: Installation</a><br>
|
||||
<a href="nasmdoc1.html#section-1.3.1">Section 1.3.1: Installing NASM under MS-DOS or Windows</a><br>
|
||||
<a href="nasmdoc1.html#section-1.3.2">Section 1.3.2: Installing NASM under Unix</a><br>
|
||||
<p><a href="nasmdoc2.html">Chapter 2: Running NASM</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1">Section 2.1: NASM Command-Line Syntax</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.1">Section 2.1.1: The <code><nobr>-o</nobr></code> Option: Specifying the Output File Name</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.2">Section 2.1.2: The <code><nobr>-f</nobr></code> Option: Specifying the Output File Format</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.3">Section 2.1.3: The <code><nobr>-l</nobr></code> Option: Generating a Listing File</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.4">Section 2.1.4: The <code><nobr>-M</nobr></code> Option: Generate Makefile Dependencies.</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.5">Section 2.1.5: The <code><nobr>-F</nobr></code> Option: Selecting a Debug Information Format</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.6">Section 2.1.6: The <code><nobr>-g</nobr></code> Option: Enabling Debug Information.</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.7">Section 2.1.7: The <code><nobr>-X</nobr></code> Option: Selecting an Error Reporting Format</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.8">Section 2.1.8: The <code><nobr>-E</nobr></code> Option: Send Errors to a File</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.9">Section 2.1.9: The <code><nobr>-s</nobr></code> Option: Send Errors to <code><nobr>stdout</nobr></code></a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.10">Section 2.1.10: The <code><nobr>-i</nobr></code> Option: Include File Search Directories</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.11">Section 2.1.11: The <code><nobr>-p</nobr></code> Option: Pre-Include a File</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.12">Section 2.1.12: The <code><nobr>-d</nobr></code> Option: Pre-Define a Macro</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.13">Section 2.1.13: The <code><nobr>-u</nobr></code> Option: Undefine a Macro</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.14">Section 2.1.14: The <code><nobr>-e</nobr></code> Option: Preprocess Only</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.15">Section 2.1.15: The <code><nobr>-a</nobr></code> Option: Don't Preprocess At All</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.16">Section 2.1.16: The <code><nobr>-On</nobr></code> Option: Specifying Multipass Optimization.</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.17">Section 2.1.17: The <code><nobr>-t</nobr></code> option: Enable TASM Compatibility Mode</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.18">Section 2.1.18: The <code><nobr>-w</nobr></code> Option: Enable or Disable Assembly Warnings</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.19">Section 2.1.19: The <code><nobr>-v</nobr></code> Option: Display Version Info</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.20">Section 2.1.20: The <code><nobr>-y</nobr></code> Option: Display Available Debug Info Formats</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.21">Section 2.1.21: The <code><nobr>--prefix</nobr></code> and <code><nobr>--postfix</nobr></code> Options.</a><br>
|
||||
<a href="nasmdoc2.html#section-2.1.22">Section 2.1.22: The <code><nobr>NASMENV</nobr></code> Environment Variable</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2">Section 2.2: Quick Start for MASM Users</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.1">Section 2.2.1: NASM Is Case-Sensitive</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.2">Section 2.2.2: NASM Requires Square Brackets For Memory References</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.3">Section 2.2.3: NASM Doesn't Store Variable Types</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.4">Section 2.2.4: NASM Doesn't <code><nobr>ASSUME</nobr></code></a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.5">Section 2.2.5: NASM Doesn't Support Memory Models</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.6">Section 2.2.6: Floating-Point Differences</a><br>
|
||||
<a href="nasmdoc2.html#section-2.2.7">Section 2.2.7: Other Differences</a><br>
|
||||
<p><a href="nasmdoc3.html">Chapter 3: The NASM Language</a><br>
|
||||
<a href="nasmdoc3.html#section-3.1">Section 3.1: Layout of a NASM Source Line</a><br>
|
||||
<a href="nasmdoc3.html#section-3.2">Section 3.2: Pseudo-Instructions</a><br>
|
||||
<a href="nasmdoc3.html#section-3.2.1">Section 3.2.1: <code><nobr>DB</nobr></code> and friends: Declaring Initialised Data</a><br>
|
||||
<a href="nasmdoc3.html#section-3.2.2">Section 3.2.2: <code><nobr>RESB</nobr></code> and friends: Declaring Uninitialised Data</a><br>
|
||||
<a href="nasmdoc3.html#section-3.2.3">Section 3.2.3: <code><nobr>INCBIN</nobr></code>: Including External Binary Files</a><br>
|
||||
<a href="nasmdoc3.html#section-3.2.4">Section 3.2.4: <code><nobr>EQU</nobr></code>: Defining Constants</a><br>
|
||||
<a href="nasmdoc3.html#section-3.2.5">Section 3.2.5: <code><nobr>TIMES</nobr></code>: Repeating Instructions or Data</a><br>
|
||||
<a href="nasmdoc3.html#section-3.3">Section 3.3: Effective Addresses</a><br>
|
||||
<a href="nasmdoc3.html#section-3.4">Section 3.4: Constants</a><br>
|
||||
<a href="nasmdoc3.html#section-3.4.1">Section 3.4.1: Numeric Constants</a><br>
|
||||
<a href="nasmdoc3.html#section-3.4.2">Section 3.4.2: Character Constants</a><br>
|
||||
<a href="nasmdoc3.html#section-3.4.3">Section 3.4.3: String Constants</a><br>
|
||||
<a href="nasmdoc3.html#section-3.4.4">Section 3.4.4: Floating-Point Constants</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5">Section 3.5: Expressions</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.1">Section 3.5.1: <code><nobr>|</nobr></code>: Bitwise OR Operator</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.2">Section 3.5.2: <code><nobr>^</nobr></code>: Bitwise XOR Operator</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.3">Section 3.5.3: <code><nobr>&</nobr></code>: Bitwise AND Operator</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.4">Section 3.5.4: <code><nobr><<</nobr></code> and <code><nobr>>></nobr></code>: Bit Shift Operators</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.5">Section 3.5.5: <code><nobr>+</nobr></code> and <code><nobr>-</nobr></code>: Addition and Subtraction Operators</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.6">Section 3.5.6: <code><nobr>*</nobr></code>, <code><nobr>/</nobr></code>, <code><nobr>//</nobr></code>, <code><nobr>%</nobr></code> and <code><nobr>%%</nobr></code>: Multiplication and Division</a><br>
|
||||
<a href="nasmdoc3.html#section-3.5.7">Section 3.5.7: Unary Operators: <code><nobr>+</nobr></code>, <code><nobr>-</nobr></code>, <code><nobr>~</nobr></code> and <code><nobr>SEG</nobr></code></a><br>
|
||||
<a href="nasmdoc3.html#section-3.6">Section 3.6: <code><nobr>SEG</nobr></code> and <code><nobr>WRT</nobr></code></a><br>
|
||||
<a href="nasmdoc3.html#section-3.7">Section 3.7: <code><nobr>STRICT</nobr></code>: Inhibiting Optimization</a><br>
|
||||
<a href="nasmdoc3.html#section-3.8">Section 3.8: Critical Expressions</a><br>
|
||||
<a href="nasmdoc3.html#section-3.9">Section 3.9: Local Labels</a><br>
|
||||
<p><a href="nasmdoc4.html">Chapter 4: The NASM Preprocessor</a><br>
|
||||
<a href="nasmdoc4.html#section-4.1">Section 4.1: Single-Line Macros</a><br>
|
||||
<a href="nasmdoc4.html#section-4.1.1">Section 4.1.1: The Normal Way: <code><nobr>%define</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.1.2">Section 4.1.2: Enhancing %define: <code><nobr>%xdefine</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.1.3">Section 4.1.3: Concatenating Single Line Macro Tokens: <code><nobr>%+</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.1.4">Section 4.1.4: Undefining macros: <code><nobr>%undef</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.1.5">Section 4.1.5: Preprocessor Variables: <code><nobr>%assign</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.2">Section 4.2: String Handling in Macros: <code><nobr>%strlen</nobr></code> and <code><nobr>%substr</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.2.1">Section 4.2.1: String Length: <code><nobr>%strlen</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.2.2">Section 4.2.2: Sub-strings: <code><nobr>%substr</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.3">Section 4.3: Multi-Line Macros: <code><nobr>%macro</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.1">Section 4.3.1: Overloading Multi-Line Macros</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.2">Section 4.3.2: Macro-Local Labels</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.3">Section 4.3.3: Greedy Macro Parameters</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.4">Section 4.3.4: Default Macro Parameters</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.5">Section 4.3.5: <code><nobr>%0</nobr></code>: Macro Parameter Counter</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.6">Section 4.3.6: <code><nobr>%rotate</nobr></code>: Rotating Macro Parameters</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.7">Section 4.3.7: Concatenating Macro Parameters</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.8">Section 4.3.8: Condition Codes as Macro Parameters</a><br>
|
||||
<a href="nasmdoc4.html#section-4.3.9">Section 4.3.9: Disabling Listing Expansion</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4">Section 4.4: Conditional Assembly</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.1">Section 4.4.1: <code><nobr>%ifdef</nobr></code>: Testing Single-Line Macro Existence</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.2">Section 4.4.2: <code><nobr>ifmacro</nobr></code>: Testing Multi-Line Macro Existence</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.3">Section 4.4.3: <code><nobr>%ifctx</nobr></code>: Testing the Context Stack</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4: <code><nobr>%if</nobr></code>: Testing Arbitrary Numeric Expressions</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.5">Section 4.4.5: <code><nobr>%ifidn</nobr></code> and <code><nobr>%ifidni</nobr></code>: Testing Exact Text Identity</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6: <code><nobr>%ifid</nobr></code>, <code><nobr>%ifnum</nobr></code>, <code><nobr>%ifstr</nobr></code>: Testing Token Types</a><br>
|
||||
<a href="nasmdoc4.html#section-4.4.7">Section 4.4.7: <code><nobr>%error</nobr></code>: Reporting User-Defined Errors</a><br>
|
||||
<a href="nasmdoc4.html#section-4.5">Section 4.5: Preprocessor Loops: <code><nobr>%rep</nobr></code></a><br>
|
||||
<a href="nasmdoc4.html#section-4.6">Section 4.6: Including Other Files</a><br>
|
||||
<a href="nasmdoc4.html#section-4.7">Section 4.7: The Context Stack</a><br>
|
||||
<a href="nasmdoc4.html#section-4.7.1">Section 4.7.1: <code><nobr>%push</nobr></code> and <code><nobr>%pop</nobr></code>: Creating and Removing Contexts</a><br>
|
||||
<a href="nasmdoc4.html#section-4.7.2">Section 4.7.2: Context-Local Labels</a><br>
|
||||
<a href="nasmdoc4.html#section-4.7.3">Section 4.7.3: Context-Local Single-Line Macros</a><br>
|
||||
<a href="nasmdoc4.html#section-4.7.4">Section 4.7.4: <code><nobr>%repl</nobr></code>: Renaming a Context</a><br>
|
||||
<a href="nasmdoc4.html#section-4.7.5">Section 4.7.5: Example Use of the Context Stack: Block IFs</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8">Section 4.8: Standard Macros</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.1">Section 4.8.1: <code><nobr>__NASM_MAJOR__</nobr></code>, <code><nobr>__NASM_MINOR__</nobr></code>, <code><nobr>__NASM_SUBMINOR__</nobr></code> and <code><nobr>___NASM_PATCHLEVEL__</nobr></code>: NASM Version</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.2">Section 4.8.2: <code><nobr>__NASM_VERSION_ID__</nobr></code>: NASM Version ID</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.3">Section 4.8.3: <code><nobr>__NASM_VER__</nobr></code>: NASM Version string</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.4">Section 4.8.4: <code><nobr>__FILE__</nobr></code> and <code><nobr>__LINE__</nobr></code>: File Name and Line Number</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.5">Section 4.8.5: <code><nobr>STRUC</nobr></code> and <code><nobr>ENDSTRUC</nobr></code>: Declaring Structure Data Types</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.6">Section 4.8.6: <code><nobr>ISTRUC</nobr></code>, <code><nobr>AT</nobr></code> and <code><nobr>IEND</nobr></code>: Declaring Instances of Structures</a><br>
|
||||
<a href="nasmdoc4.html#section-4.8.7">Section 4.8.7: <code><nobr>ALIGN</nobr></code> and <code><nobr>ALIGNB</nobr></code>: Data Alignment</a><br>
|
||||
<a href="nasmdoc4.html#section-4.9">Section 4.9: TASM Compatible Preprocessor Directives</a><br>
|
||||
<a href="nasmdoc4.html#section-4.9.1">Section 4.9.1: <code><nobr>%arg</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc4.html#section-4.9.2">Section 4.9.2: <code><nobr>%stacksize</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc4.html#section-4.9.3">Section 4.9.3: <code><nobr>%local</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc4.html#section-4.10">Section 4.10: Other Preprocessor Directives</a><br>
|
||||
<a href="nasmdoc4.html#section-4.10.1">Section 4.10.1: <code><nobr>%line</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc4.html#section-4.10.2">Section 4.10.2: <code><nobr>%!</nobr></code><code><nobr><env></nobr></code>: Read an environment variable.</a><br>
|
||||
<p><a href="nasmdoc5.html">Chapter 5: Assembler Directives</a><br>
|
||||
<a href="nasmdoc5.html#section-5.1">Section 5.1: <code><nobr>BITS</nobr></code>: Specifying Target Processor Mode</a><br>
|
||||
<a href="nasmdoc5.html#section-5.1.1">Section 5.1.1: <code><nobr>USE16</nobr></code> & <code><nobr>USE32</nobr></code>: Aliases for BITS</a><br>
|
||||
<a href="nasmdoc5.html#section-5.2">Section 5.2: <code><nobr>SECTION</nobr></code> or <code><nobr>SEGMENT</nobr></code>: Changing and Defining Sections</a><br>
|
||||
<a href="nasmdoc5.html#section-5.2.1">Section 5.2.1: The <code><nobr>__SECT__</nobr></code> Macro</a><br>
|
||||
<a href="nasmdoc5.html#section-5.3">Section 5.3: <code><nobr>ABSOLUTE</nobr></code>: Defining Absolute Labels</a><br>
|
||||
<a href="nasmdoc5.html#section-5.4">Section 5.4: <code><nobr>EXTERN</nobr></code>: Importing Symbols from Other Modules</a><br>
|
||||
<a href="nasmdoc5.html#section-5.5">Section 5.5: <code><nobr>GLOBAL</nobr></code>: Exporting Symbols to Other Modules</a><br>
|
||||
<a href="nasmdoc5.html#section-5.6">Section 5.6: <code><nobr>COMMON</nobr></code>: Defining Common Data Areas</a><br>
|
||||
<a href="nasmdoc5.html#section-5.7">Section 5.7: <code><nobr>CPU</nobr></code>: Defining CPU Dependencies</a><br>
|
||||
<p><a href="nasmdoc6.html">Chapter 6: Output Formats</a><br>
|
||||
<a href="nasmdoc6.html#section-6.1">Section 6.1: <code><nobr>bin</nobr></code>: Flat-Form Binary Output</a><br>
|
||||
<a href="nasmdoc6.html#section-6.1.1">Section 6.1.1: <code><nobr>ORG</nobr></code>: Binary File Program Origin</a><br>
|
||||
<a href="nasmdoc6.html#section-6.1.2">Section 6.1.2: <code><nobr>bin</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.1.3">Section 6.1.3: <code><nobr>Multisection</nobr></code> support for the BIN format.</a><br>
|
||||
<a href="nasmdoc6.html#section-6.1.4">Section 6.1.4: Map files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2">Section 6.2: <code><nobr>obj</nobr></code>: Microsoft OMF Object Files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.1">Section 6.2.1: <code><nobr>obj</nobr></code> Extensions to the <code><nobr>SEGMENT</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.2">Section 6.2.2: <code><nobr>GROUP</nobr></code>: Defining Groups of Segments</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.3">Section 6.2.3: <code><nobr>UPPERCASE</nobr></code>: Disabling Case Sensitivity in Output</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.4">Section 6.2.4: <code><nobr>IMPORT</nobr></code>: Importing DLL Symbols</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.5">Section 6.2.5: <code><nobr>EXPORT</nobr></code>: Exporting DLL Symbols</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.6">Section 6.2.6: <code><nobr>..start</nobr></code>: Defining the Program Entry Point</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.7">Section 6.2.7: <code><nobr>obj</nobr></code> Extensions to the <code><nobr>EXTERN</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.2.8">Section 6.2.8: <code><nobr>obj</nobr></code> Extensions to the <code><nobr>COMMON</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.3">Section 6.3: <code><nobr>win32</nobr></code>: Microsoft Win32 Object Files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.3.1">Section 6.3.1: <code><nobr>win32</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.4">Section 6.4: <code><nobr>coff</nobr></code>: Common Object File Format</a><br>
|
||||
<a href="nasmdoc6.html#section-6.5">Section 6.5: <code><nobr>elf</nobr></code>: Executable and Linkable Format Object Files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.5.1">Section 6.5.1: <code><nobr>elf</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.5.2">Section 6.5.2: Position-Independent Code: <code><nobr>elf</nobr></code> Special Symbols and <code><nobr>WRT</nobr></code></a><br>
|
||||
<a href="nasmdoc6.html#section-6.5.3">Section 6.5.3: <code><nobr>elf</nobr></code> Extensions to the <code><nobr>GLOBAL</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.5.4">Section 6.5.4: <code><nobr>elf</nobr></code> Extensions to the <code><nobr>COMMON</nobr></code> Directive </a><br>
|
||||
<a href="nasmdoc6.html#section-6.5.5">Section 6.5.5: 16-bit code and ELF </a><br>
|
||||
<a href="nasmdoc6.html#section-6.6">Section 6.6: <code><nobr>aout</nobr></code>: Linux <code><nobr>a.out</nobr></code> Object Files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.7">Section 6.7: <code><nobr>aoutb</nobr></code>: NetBSD/FreeBSD/OpenBSD <code><nobr>a.out</nobr></code> Object Files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.8">Section 6.8: <code><nobr>as86</nobr></code>: Minix/Linux <code><nobr>as86</nobr></code> Object Files</a><br>
|
||||
<a href="nasmdoc6.html#section-6.9">Section 6.9: <code><nobr>rdf</nobr></code>: Relocatable Dynamic Object File Format</a><br>
|
||||
<a href="nasmdoc6.html#section-6.9.1">Section 6.9.1: Requiring a Library: The <code><nobr>LIBRARY</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.9.2">Section 6.9.2: Specifying a Module Name: The <code><nobr>MODULE</nobr></code> Directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.9.3">Section 6.9.3: <code><nobr>rdf</nobr></code> Extensions to the <code><nobr>GLOBAL</nobr></code> directive</a><br>
|
||||
<a href="nasmdoc6.html#section-6.10">Section 6.10: <code><nobr>dbg</nobr></code>: Debugging Format</a><br>
|
||||
<p><a href="nasmdoc7.html">Chapter 7: Writing 16-bit Code (DOS, Windows 3/3.1)</a><br>
|
||||
<a href="nasmdoc7.html#section-7.1">Section 7.1: Producing <code><nobr>.EXE</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.1.1">Section 7.1.1: Using the <code><nobr>obj</nobr></code> Format To Generate <code><nobr>.EXE</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.1.2">Section 7.1.2: Using the <code><nobr>bin</nobr></code> Format To Generate <code><nobr>.EXE</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.2">Section 7.2: Producing <code><nobr>.COM</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.2.1">Section 7.2.1: Using the <code><nobr>bin</nobr></code> Format To Generate <code><nobr>.COM</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.2.2">Section 7.2.2: Using the <code><nobr>obj</nobr></code> Format To Generate <code><nobr>.COM</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.3">Section 7.3: Producing <code><nobr>.SYS</nobr></code> Files</a><br>
|
||||
<a href="nasmdoc7.html#section-7.4">Section 7.4: Interfacing to 16-bit C Programs</a><br>
|
||||
<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1: External Symbol Names</a><br>
|
||||
<a href="nasmdoc7.html#section-7.4.2">Section 7.4.2: Memory Models</a><br>
|
||||
<a href="nasmdoc7.html#section-7.4.3">Section 7.4.3: Function Definitions and Function Calls</a><br>
|
||||
<a href="nasmdoc7.html#section-7.4.4">Section 7.4.4: Accessing Data Items</a><br>
|
||||
<a href="nasmdoc7.html#section-7.4.5">Section 7.4.5: <code><nobr>c16.mac</nobr></code>: Helper Macros for the 16-bit C Interface</a><br>
|
||||
<a href="nasmdoc7.html#section-7.5">Section 7.5: Interfacing to Borland Pascal Programs</a><br>
|
||||
<a href="nasmdoc7.html#section-7.5.1">Section 7.5.1: The Pascal Calling Convention</a><br>
|
||||
<a href="nasmdoc7.html#section-7.5.2">Section 7.5.2: Borland Pascal Segment Name Restrictions</a><br>
|
||||
<a href="nasmdoc7.html#section-7.5.3">Section 7.5.3: Using <code><nobr>c16.mac</nobr></code> With Pascal Programs</a><br>
|
||||
<p><a href="nasmdoc8.html">Chapter 8: Writing 32-bit Code (Unix, Win32, DJGPP)</a><br>
|
||||
<a href="nasmdoc8.html#section-8.1">Section 8.1: Interfacing to 32-bit C Programs</a><br>
|
||||
<a href="nasmdoc8.html#section-8.1.1">Section 8.1.1: External Symbol Names</a><br>
|
||||
<a href="nasmdoc8.html#section-8.1.2">Section 8.1.2: Function Definitions and Function Calls</a><br>
|
||||
<a href="nasmdoc8.html#section-8.1.3">Section 8.1.3: Accessing Data Items</a><br>
|
||||
<a href="nasmdoc8.html#section-8.1.4">Section 8.1.4: <code><nobr>c32.mac</nobr></code>: Helper Macros for the 32-bit C Interface</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2">Section 8.2: Writing NetBSD/FreeBSD/OpenBSD and Linux/ELF Shared Libraries</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2.1">Section 8.2.1: Obtaining the Address of the GOT</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2.2">Section 8.2.2: Finding Your Local Data Items</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2.3">Section 8.2.3: Finding External and Common Data Items</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2.4">Section 8.2.4: Exporting Symbols to the Library User</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2.5">Section 8.2.5: Calling Procedures Outside the Library</a><br>
|
||||
<a href="nasmdoc8.html#section-8.2.6">Section 8.2.6: Generating the Library File</a><br>
|
||||
<p><a href="nasmdoc9.html">Chapter 9: Mixing 16 and 32 Bit Code</a><br>
|
||||
<a href="nasmdoc9.html#section-9.1">Section 9.1: Mixed-Size Jumps</a><br>
|
||||
<a href="nasmdoc9.html#section-9.2">Section 9.2: Addressing Between Different-Size Segments</a><br>
|
||||
<a href="nasmdoc9.html#section-9.3">Section 9.3: Other Mixed-Size Instructions</a><br>
|
||||
<p><a href="nasmdo10.html">Chapter 10: Troubleshooting</a><br>
|
||||
<a href="nasmdo10.html#section-10.1">Section 10.1: Common Problems</a><br>
|
||||
<a href="nasmdo10.html#section-10.1.1">Section 10.1.1: NASM Generates Inefficient Code</a><br>
|
||||
<a href="nasmdo10.html#section-10.1.2">Section 10.1.2: My Jumps are Out of Range</a><br>
|
||||
<a href="nasmdo10.html#section-10.1.3">Section 10.1.3: <code><nobr>ORG</nobr></code> Doesn't Work</a><br>
|
||||
<a href="nasmdo10.html#section-10.1.4">Section 10.1.4: <code><nobr>TIMES</nobr></code> Doesn't Work</a><br>
|
||||
<a href="nasmdo10.html#section-10.2">Section 10.2: Bugs</a><br>
|
||||
<p><a href="nasmdoca.html">Appendix A: Ndisasm</a><br>
|
||||
<a href="nasmdoca.html#section-A.1">Section A.1: Introduction</a><br>
|
||||
<a href="nasmdoca.html#section-A.2">Section A.2: Getting Started: Installation</a><br>
|
||||
<a href="nasmdoca.html#section-A.3">Section A.3: Running NDISASM</a><br>
|
||||
<a href="nasmdoca.html#section-A.3.1">Section A.3.1: COM Files: Specifying an Origin</a><br>
|
||||
<a href="nasmdoca.html#section-A.3.2">Section A.3.2: Code Following Data: Synchronisation</a><br>
|
||||
<a href="nasmdoca.html#section-A.3.3">Section A.3.3: Mixed Code and Data: Automatic (Intelligent) Synchronisation </a><br>
|
||||
<a href="nasmdoca.html#section-A.3.4">Section A.3.4: Other Options</a><br>
|
||||
<a href="nasmdoca.html#section-A.4">Section A.4: Bugs and Improvements</a><br>
|
||||
<p><a href="nasmdocb.html">Appendix B: x86 Instruction Reference</a><br>
|
||||
<a href="nasmdocb.html#section-B.1">Section B.1: Key to Operand Specifications</a><br>
|
||||
<a href="nasmdocb.html#section-B.2">Section B.2: Key to Opcode Descriptions</a><br>
|
||||
<a href="nasmdocb.html#section-B.2.1">Section B.2.1: Register Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.2.2">Section B.2.2: Condition Codes</a><br>
|
||||
<a href="nasmdocb.html#section-B.2.3">Section B.2.3: SSE Condition Predicates</a><br>
|
||||
<a href="nasmdocb.html#section-B.2.4">Section B.2.4: Status Flags</a><br>
|
||||
<a href="nasmdocb.html#section-B.2.5">Section B.2.5: Effective Address Encoding: ModR/M and SIB</a><br>
|
||||
<a href="nasmdocb.html#section-B.3">Section B.3: Key to Instruction Flags</a><br>
|
||||
<a href="nasmdocb.html#section-B.4">Section B.4: x86 Instruction Set</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.1">Section B.4.1: <code><nobr>AAA</nobr></code>, <code><nobr>AAS</nobr></code>, <code><nobr>AAM</nobr></code>, <code><nobr>AAD</nobr></code>: ASCII Adjustments</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.2">Section B.4.2: <code><nobr>ADC</nobr></code>: Add with Carry</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.3">Section B.4.3: <code><nobr>ADD</nobr></code>: Add Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.4">Section B.4.4: <code><nobr>ADDPD</nobr></code>: ADD Packed Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.5">Section B.4.5: <code><nobr>ADDPS</nobr></code>: ADD Packed Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.6">Section B.4.6: <code><nobr>ADDSD</nobr></code>: ADD Scalar Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.7">Section B.4.7: <code><nobr>ADDSS</nobr></code>: ADD Scalar Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.8">Section B.4.8: <code><nobr>AND</nobr></code>: Bitwise AND</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.9">Section B.4.9: <code><nobr>ANDNPD</nobr></code>: Bitwise Logical AND NOT of Packed Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.10">Section B.4.10: <code><nobr>ANDNPS</nobr></code>: Bitwise Logical AND NOT of Packed Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.11">Section B.4.11: <code><nobr>ANDPD</nobr></code>: Bitwise Logical AND For Single FP</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.12">Section B.4.12: <code><nobr>ANDPS</nobr></code>: Bitwise Logical AND For Single FP</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.13">Section B.4.13: <code><nobr>ARPL</nobr></code>: Adjust RPL Field of Selector</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.14">Section B.4.14: <code><nobr>BOUND</nobr></code>: Check Array Index against Bounds</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.15">Section B.4.15: <code><nobr>BSF</nobr></code>, <code><nobr>BSR</nobr></code>: Bit Scan</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.16">Section B.4.16: <code><nobr>BSWAP</nobr></code>: Byte Swap</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.17">Section B.4.17: <code><nobr>BT</nobr></code>, <code><nobr>BTC</nobr></code>, <code><nobr>BTR</nobr></code>, <code><nobr>BTS</nobr></code>: Bit Test</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.18">Section B.4.18: <code><nobr>CALL</nobr></code>: Call Subroutine</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.19">Section B.4.19: <code><nobr>CBW</nobr></code>, <code><nobr>CWD</nobr></code>, <code><nobr>CDQ</nobr></code>, <code><nobr>CWDE</nobr></code>: Sign Extensions</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.20">Section B.4.20: <code><nobr>CLC</nobr></code>, <code><nobr>CLD</nobr></code>, <code><nobr>CLI</nobr></code>, <code><nobr>CLTS</nobr></code>: Clear Flags</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.21">Section B.4.21: <code><nobr>CLFLUSH</nobr></code>: Flush Cache Line</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.22">Section B.4.22: <code><nobr>CMC</nobr></code>: Complement Carry Flag</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.23">Section B.4.23: <code><nobr>CMOVcc</nobr></code>: Conditional Move</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.24">Section B.4.24: <code><nobr>CMP</nobr></code>: Compare Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.25">Section B.4.25: <code><nobr>CMPccPD</nobr></code>: Packed Double-Precision FP Compare </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.26">Section B.4.26: <code><nobr>CMPccPS</nobr></code>: Packed Single-Precision FP Compare </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.27">Section B.4.27: <code><nobr>CMPSB</nobr></code>, <code><nobr>CMPSW</nobr></code>, <code><nobr>CMPSD</nobr></code>: Compare Strings</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.28">Section B.4.28: <code><nobr>CMPccSD</nobr></code>: Scalar Double-Precision FP Compare </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.29">Section B.4.29: <code><nobr>CMPccSS</nobr></code>: Scalar Single-Precision FP Compare </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.30">Section B.4.30: <code><nobr>CMPXCHG</nobr></code>, <code><nobr>CMPXCHG486</nobr></code>: Compare and Exchange</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.31">Section B.4.31: <code><nobr>CMPXCHG8B</nobr></code>: Compare and Exchange Eight Bytes</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.32">Section B.4.32: <code><nobr>COMISD</nobr></code>: Scalar Ordered Double-Precision FP Compare and Set EFLAGS</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.33">Section B.4.33: <code><nobr>COMISS</nobr></code>: Scalar Ordered Single-Precision FP Compare and Set EFLAGS</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.34">Section B.4.34: <code><nobr>CPUID</nobr></code>: Get CPU Identification Code</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.35">Section B.4.35: <code><nobr>CVTDQ2PD</nobr></code>: Packed Signed INT32 to Packed Double-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.36">Section B.4.36: <code><nobr>CVTDQ2PS</nobr></code>: Packed Signed INT32 to Packed Single-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.37">Section B.4.37: <code><nobr>CVTPD2DQ</nobr></code>: Packed Double-Precision FP to Packed Signed INT32 Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.38">Section B.4.38: <code><nobr>CVTPD2PI</nobr></code>: Packed Double-Precision FP to Packed Signed INT32 Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.39">Section B.4.39: <code><nobr>CVTPD2PS</nobr></code>: Packed Double-Precision FP to Packed Single-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.40">Section B.4.40: <code><nobr>CVTPI2PD</nobr></code>: Packed Signed INT32 to Packed Double-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.41">Section B.4.41: <code><nobr>CVTPI2PS</nobr></code>: Packed Signed INT32 to Packed Single-FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.42">Section B.4.42: <code><nobr>CVTPS2DQ</nobr></code>: Packed Single-Precision FP to Packed Signed INT32 Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.43">Section B.4.43: <code><nobr>CVTPS2PD</nobr></code>: Packed Single-Precision FP to Packed Double-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.44">Section B.4.44: <code><nobr>CVTPS2PI</nobr></code>: Packed Single-Precision FP to Packed Signed INT32 Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.45">Section B.4.45: <code><nobr>CVTSD2SI</nobr></code>: Scalar Double-Precision FP to Signed INT32 Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.46">Section B.4.46: <code><nobr>CVTSD2SS</nobr></code>: Scalar Double-Precision FP to Scalar Single-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.47">Section B.4.47: <code><nobr>CVTSI2SD</nobr></code>: Signed INT32 to Scalar Double-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.48">Section B.4.48: <code><nobr>CVTSI2SS</nobr></code>: Signed INT32 to Scalar Single-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.49">Section B.4.49: <code><nobr>CVTSS2SD</nobr></code>: Scalar Single-Precision FP to Scalar Double-Precision FP Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.50">Section B.4.50: <code><nobr>CVTSS2SI</nobr></code>: Scalar Single-Precision FP to Signed INT32 Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.51">Section B.4.51: <code><nobr>CVTTPD2DQ</nobr></code>: Packed Double-Precision FP to Packed Signed INT32 Conversion with Truncation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.52">Section B.4.52: <code><nobr>CVTTPD2PI</nobr></code>: Packed Double-Precision FP to Packed Signed INT32 Conversion with Truncation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.53">Section B.4.53: <code><nobr>CVTTPS2DQ</nobr></code>: Packed Single-Precision FP to Packed Signed INT32 Conversion with Truncation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.54">Section B.4.54: <code><nobr>CVTTPS2PI</nobr></code>: Packed Single-Precision FP to Packed Signed INT32 Conversion with Truncation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.55">Section B.4.55: <code><nobr>CVTTSD2SI</nobr></code>: Scalar Double-Precision FP to Signed INT32 Conversion with Truncation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.56">Section B.4.56: <code><nobr>CVTTSS2SI</nobr></code>: Scalar Single-Precision FP to Signed INT32 Conversion with Truncation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.57">Section B.4.57: <code><nobr>DAA</nobr></code>, <code><nobr>DAS</nobr></code>: Decimal Adjustments</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.58">Section B.4.58: <code><nobr>DEC</nobr></code>: Decrement Integer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.59">Section B.4.59: <code><nobr>DIV</nobr></code>: Unsigned Integer Divide</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.60">Section B.4.60: <code><nobr>DIVPD</nobr></code>: Packed Double-Precision FP Divide</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.61">Section B.4.61: <code><nobr>DIVPS</nobr></code>: Packed Single-Precision FP Divide</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.62">Section B.4.62: <code><nobr>DIVSD</nobr></code>: Scalar Double-Precision FP Divide</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.63">Section B.4.63: <code><nobr>DIVSS</nobr></code>: Scalar Single-Precision FP Divide</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.64">Section B.4.64: <code><nobr>EMMS</nobr></code>: Empty MMX State</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.65">Section B.4.65: <code><nobr>ENTER</nobr></code>: Create Stack Frame</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.66">Section B.4.66: <code><nobr>F2XM1</nobr></code>: Calculate 2**X-1</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.67">Section B.4.67: <code><nobr>FABS</nobr></code>: Floating-Point Absolute Value</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.68">Section B.4.68: <code><nobr>FADD</nobr></code>, <code><nobr>FADDP</nobr></code>: Floating-Point Addition</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.69">Section B.4.69: <code><nobr>FBLD</nobr></code>, <code><nobr>FBSTP</nobr></code>: BCD Floating-Point Load and Store</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.70">Section B.4.70: <code><nobr>FCHS</nobr></code>: Floating-Point Change Sign</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.71">Section B.4.71: <code><nobr>FCLEX</nobr></code>, <code><nobr>FNCLEX</nobr></code>: Clear Floating-Point Exceptions</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.72">Section B.4.72: <code><nobr>FCMOVcc</nobr></code>: Floating-Point Conditional Move</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.73">Section B.4.73: <code><nobr>FCOM</nobr></code>, <code><nobr>FCOMP</nobr></code>, <code><nobr>FCOMPP</nobr></code>, <code><nobr>FCOMI</nobr></code>, <code><nobr>FCOMIP</nobr></code>: Floating-Point Compare</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.74">Section B.4.74: <code><nobr>FCOS</nobr></code>: Cosine</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.75">Section B.4.75: <code><nobr>FDECSTP</nobr></code>: Decrement Floating-Point Stack Pointer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.76">Section B.4.76: <code><nobr>FxDISI</nobr></code>, <code><nobr>FxENI</nobr></code>: Disable and Enable Floating-Point Interrupts</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.77">Section B.4.77: <code><nobr>FDIV</nobr></code>, <code><nobr>FDIVP</nobr></code>, <code><nobr>FDIVR</nobr></code>, <code><nobr>FDIVRP</nobr></code>: Floating-Point Division</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.78">Section B.4.78: <code><nobr>FEMMS</nobr></code>: Faster Enter/Exit of the MMX or floating-point state</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.79">Section B.4.79: <code><nobr>FFREE</nobr></code>: Flag Floating-Point Register as Unused</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.80">Section B.4.80: <code><nobr>FIADD</nobr></code>: Floating-Point/Integer Addition</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.81">Section B.4.81: <code><nobr>FICOM</nobr></code>, <code><nobr>FICOMP</nobr></code>: Floating-Point/Integer Compare</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.82">Section B.4.82: <code><nobr>FIDIV</nobr></code>, <code><nobr>FIDIVR</nobr></code>: Floating-Point/Integer Division</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.83">Section B.4.83: <code><nobr>FILD</nobr></code>, <code><nobr>FIST</nobr></code>, <code><nobr>FISTP</nobr></code>: Floating-Point/Integer Conversion</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.84">Section B.4.84: <code><nobr>FIMUL</nobr></code>: Floating-Point/Integer Multiplication</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.85">Section B.4.85: <code><nobr>FINCSTP</nobr></code>: Increment Floating-Point Stack Pointer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.86">Section B.4.86: <code><nobr>FINIT</nobr></code>, <code><nobr>FNINIT</nobr></code>: Initialise Floating-Point Unit</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.87">Section B.4.87: <code><nobr>FISUB</nobr></code>: Floating-Point/Integer Subtraction</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.88">Section B.4.88: <code><nobr>FLD</nobr></code>: Floating-Point Load</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.89">Section B.4.89: <code><nobr>FLDxx</nobr></code>: Floating-Point Load Constants</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.90">Section B.4.90: <code><nobr>FLDCW</nobr></code>: Load Floating-Point Control Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.91">Section B.4.91: <code><nobr>FLDENV</nobr></code>: Load Floating-Point Environment</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.92">Section B.4.92: <code><nobr>FMUL</nobr></code>, <code><nobr>FMULP</nobr></code>: Floating-Point Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.93">Section B.4.93: <code><nobr>FNOP</nobr></code>: Floating-Point No Operation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.94">Section B.4.94: <code><nobr>FPATAN</nobr></code>, <code><nobr>FPTAN</nobr></code>: Arctangent and Tangent</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.95">Section B.4.95: <code><nobr>FPREM</nobr></code>, <code><nobr>FPREM1</nobr></code>: Floating-Point Partial Remainder</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.96">Section B.4.96: <code><nobr>FRNDINT</nobr></code>: Floating-Point Round to Integer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.97">Section B.4.97: <code><nobr>FSAVE</nobr></code>, <code><nobr>FRSTOR</nobr></code>: Save/Restore Floating-Point State</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.98">Section B.4.98: <code><nobr>FSCALE</nobr></code>: Scale Floating-Point Value by Power of Two</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.99">Section B.4.99: <code><nobr>FSETPM</nobr></code>: Set Protected Mode</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.100">Section B.4.100: <code><nobr>FSIN</nobr></code>, <code><nobr>FSINCOS</nobr></code>: Sine and Cosine</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.101">Section B.4.101: <code><nobr>FSQRT</nobr></code>: Floating-Point Square Root</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.102">Section B.4.102: <code><nobr>FST</nobr></code>, <code><nobr>FSTP</nobr></code>: Floating-Point Store</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.103">Section B.4.103: <code><nobr>FSTCW</nobr></code>: Store Floating-Point Control Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.104">Section B.4.104: <code><nobr>FSTENV</nobr></code>: Store Floating-Point Environment</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.105">Section B.4.105: <code><nobr>FSTSW</nobr></code>: Store Floating-Point Status Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.106">Section B.4.106: <code><nobr>FSUB</nobr></code>, <code><nobr>FSUBP</nobr></code>, <code><nobr>FSUBR</nobr></code>, <code><nobr>FSUBRP</nobr></code>: Floating-Point Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.107">Section B.4.107: <code><nobr>FTST</nobr></code>: Test <code><nobr>ST0</nobr></code> Against Zero</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.108">Section B.4.108: <code><nobr>FUCOMxx</nobr></code>: Floating-Point Unordered Compare</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.109">Section B.4.109: <code><nobr>FXAM</nobr></code>: Examine Class of Value in <code><nobr>ST0</nobr></code></a><br>
|
||||
<a href="nasmdocb.html#section-B.4.110">Section B.4.110: <code><nobr>FXCH</nobr></code>: Floating-Point Exchange</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.111">Section B.4.111: <code><nobr>FXRSTOR</nobr></code>: Restore <code><nobr>FP</nobr></code>, <code><nobr>MMX</nobr></code> and <code><nobr>SSE</nobr></code> State</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.112">Section B.4.112: <code><nobr>FXSAVE</nobr></code>: Store <code><nobr>FP</nobr></code>, <code><nobr>MMX</nobr></code> and <code><nobr>SSE</nobr></code> State</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.113">Section B.4.113: <code><nobr>FXTRACT</nobr></code>: Extract Exponent and Significand</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.114">Section B.4.114: <code><nobr>FYL2X</nobr></code>, <code><nobr>FYL2XP1</nobr></code>: Compute Y times Log2(X) or Log2(X+1)</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.115">Section B.4.115: <code><nobr>HLT</nobr></code>: Halt Processor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.116">Section B.4.116: <code><nobr>IBTS</nobr></code>: Insert Bit String</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.117">Section B.4.117: <code><nobr>IDIV</nobr></code>: Signed Integer Divide</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.118">Section B.4.118: <code><nobr>IMUL</nobr></code>: Signed Integer Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.119">Section B.4.119: <code><nobr>IN</nobr></code>: Input from I/O Port</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.120">Section B.4.120: <code><nobr>INC</nobr></code>: Increment Integer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.121">Section B.4.121: <code><nobr>INSB</nobr></code>, <code><nobr>INSW</nobr></code>, <code><nobr>INSD</nobr></code>: Input String from I/O Port</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.122">Section B.4.122: <code><nobr>INT</nobr></code>: Software Interrupt</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.123">Section B.4.123: <code><nobr>INT3</nobr></code>, <code><nobr>INT1</nobr></code>, <code><nobr>ICEBP</nobr></code>, <code><nobr>INT01</nobr></code>: Breakpoints</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.124">Section B.4.124: <code><nobr>INTO</nobr></code>: Interrupt if Overflow</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.125">Section B.4.125: <code><nobr>INVD</nobr></code>: Invalidate Internal Caches</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.126">Section B.4.126: <code><nobr>INVLPG</nobr></code>: Invalidate TLB Entry</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.127">Section B.4.127: <code><nobr>IRET</nobr></code>, <code><nobr>IRETW</nobr></code>, <code><nobr>IRETD</nobr></code>: Return from Interrupt</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.128">Section B.4.128: <code><nobr>Jcc</nobr></code>: Conditional Branch</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.129">Section B.4.129: <code><nobr>JCXZ</nobr></code>, <code><nobr>JECXZ</nobr></code>: Jump if CX/ECX Zero</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.130">Section B.4.130: <code><nobr>JMP</nobr></code>: Jump</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.131">Section B.4.131: <code><nobr>LAHF</nobr></code>: Load AH from Flags</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.132">Section B.4.132: <code><nobr>LAR</nobr></code>: Load Access Rights</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.133">Section B.4.133: <code><nobr>LDMXCSR</nobr></code>: Load Streaming SIMD Extension Control/Status</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.134">Section B.4.134: <code><nobr>LDS</nobr></code>, <code><nobr>LES</nobr></code>, <code><nobr>LFS</nobr></code>, <code><nobr>LGS</nobr></code>, <code><nobr>LSS</nobr></code>: Load Far Pointer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.135">Section B.4.135: <code><nobr>LEA</nobr></code>: Load Effective Address</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.136">Section B.4.136: <code><nobr>LEAVE</nobr></code>: Destroy Stack Frame</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.137">Section B.4.137: <code><nobr>LFENCE</nobr></code>: Load Fence</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.138">Section B.4.138: <code><nobr>LGDT</nobr></code>, <code><nobr>LIDT</nobr></code>, <code><nobr>LLDT</nobr></code>: Load Descriptor Tables</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.139">Section B.4.139: <code><nobr>LMSW</nobr></code>: Load/Store Machine Status Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.140">Section B.4.140: <code><nobr>LOADALL</nobr></code>, <code><nobr>LOADALL286</nobr></code>: Load Processor State</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.141">Section B.4.141: <code><nobr>LODSB</nobr></code>, <code><nobr>LODSW</nobr></code>, <code><nobr>LODSD</nobr></code>: Load from String</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.142">Section B.4.142: <code><nobr>LOOP</nobr></code>, <code><nobr>LOOPE</nobr></code>, <code><nobr>LOOPZ</nobr></code>, <code><nobr>LOOPNE</nobr></code>, <code><nobr>LOOPNZ</nobr></code>: Loop with Counter</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.143">Section B.4.143: <code><nobr>LSL</nobr></code>: Load Segment Limit</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.144">Section B.4.144: <code><nobr>LTR</nobr></code>: Load Task Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.145">Section B.4.145: <code><nobr>MASKMOVDQU</nobr></code>: Byte Mask Write</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.146">Section B.4.146: <code><nobr>MASKMOVQ</nobr></code>: Byte Mask Write</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.147">Section B.4.147: <code><nobr>MAXPD</nobr></code>: Return Packed Double-Precision FP Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.148">Section B.4.148: <code><nobr>MAXPS</nobr></code>: Return Packed Single-Precision FP Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.149">Section B.4.149: <code><nobr>MAXSD</nobr></code>: Return Scalar Double-Precision FP Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.150">Section B.4.150: <code><nobr>MAXSS</nobr></code>: Return Scalar Single-Precision FP Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.151">Section B.4.151: <code><nobr>MFENCE</nobr></code>: Memory Fence</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.152">Section B.4.152: <code><nobr>MINPD</nobr></code>: Return Packed Double-Precision FP Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.153">Section B.4.153: <code><nobr>MINPS</nobr></code>: Return Packed Single-Precision FP Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.154">Section B.4.154: <code><nobr>MINSD</nobr></code>: Return Scalar Double-Precision FP Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.155">Section B.4.155: <code><nobr>MINSS</nobr></code>: Return Scalar Single-Precision FP Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.156">Section B.4.156: <code><nobr>MOV</nobr></code>: Move Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.157">Section B.4.157: <code><nobr>MOVAPD</nobr></code>: Move Aligned Packed Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.158">Section B.4.158: <code><nobr>MOVAPS</nobr></code>: Move Aligned Packed Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.159">Section B.4.159: <code><nobr>MOVD</nobr></code>: Move Doubleword to/from MMX Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.160">Section B.4.160: <code><nobr>MOVDQ2Q</nobr></code>: Move Quadword from XMM to MMX register.</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.161">Section B.4.161: <code><nobr>MOVDQA</nobr></code>: Move Aligned Double Quadword</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.162">Section B.4.162: <code><nobr>MOVDQU</nobr></code>: Move Unaligned Double Quadword</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.163">Section B.4.163: <code><nobr>MOVHLPS</nobr></code>: Move Packed Single-Precision FP High to Low</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.164">Section B.4.164: <code><nobr>MOVHPD</nobr></code>: Move High Packed Double-Precision FP</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.165">Section B.4.165: <code><nobr>MOVHPS</nobr></code>: Move High Packed Single-Precision FP</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.166">Section B.4.166: <code><nobr>MOVLHPS</nobr></code>: Move Packed Single-Precision FP Low to High</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.167">Section B.4.167: <code><nobr>MOVLPD</nobr></code>: Move Low Packed Double-Precision FP</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.168">Section B.4.168: <code><nobr>MOVLPS</nobr></code>: Move Low Packed Single-Precision FP</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.169">Section B.4.169: <code><nobr>MOVMSKPD</nobr></code>: Extract Packed Double-Precision FP Sign Mask</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.170">Section B.4.170: <code><nobr>MOVMSKPS</nobr></code>: Extract Packed Single-Precision FP Sign Mask</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.171">Section B.4.171: <code><nobr>MOVNTDQ</nobr></code>: Move Double Quadword Non Temporal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.172">Section B.4.172: <code><nobr>MOVNTI</nobr></code>: Move Doubleword Non Temporal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.173">Section B.4.173: <code><nobr>MOVNTPD</nobr></code>: Move Aligned Four Packed Single-Precision FP Values Non Temporal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.174">Section B.4.174: <code><nobr>MOVNTPS</nobr></code>: Move Aligned Four Packed Single-Precision FP Values Non Temporal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.175">Section B.4.175: <code><nobr>MOVNTQ</nobr></code>: Move Quadword Non Temporal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.176">Section B.4.176: <code><nobr>MOVQ</nobr></code>: Move Quadword to/from MMX Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.177">Section B.4.177: <code><nobr>MOVQ2DQ</nobr></code>: Move Quadword from MMX to XMM register.</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.178">Section B.4.178: <code><nobr>MOVSB</nobr></code>, <code><nobr>MOVSW</nobr></code>, <code><nobr>MOVSD</nobr></code>: Move String</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.179">Section B.4.179: <code><nobr>MOVSD</nobr></code>: Move Scalar Double-Precision FP Value</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.180">Section B.4.180: <code><nobr>MOVSS</nobr></code>: Move Scalar Single-Precision FP Value</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.181">Section B.4.181: <code><nobr>MOVSX</nobr></code>, <code><nobr>MOVZX</nobr></code>: Move Data with Sign or Zero Extend</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.182">Section B.4.182: <code><nobr>MOVUPD</nobr></code>: Move Unaligned Packed Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.183">Section B.4.183: <code><nobr>MOVUPS</nobr></code>: Move Unaligned Packed Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.184">Section B.4.184: <code><nobr>MUL</nobr></code>: Unsigned Integer Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.185">Section B.4.185: <code><nobr>MULPD</nobr></code>: Packed Single-FP Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.186">Section B.4.186: <code><nobr>MULPS</nobr></code>: Packed Single-FP Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.187">Section B.4.187: <code><nobr>MULSD</nobr></code>: Scalar Single-FP Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.188">Section B.4.188: <code><nobr>MULSS</nobr></code>: Scalar Single-FP Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.189">Section B.4.189: <code><nobr>NEG</nobr></code>, <code><nobr>NOT</nobr></code>: Two's and One's Complement</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.190">Section B.4.190: <code><nobr>NOP</nobr></code>: No Operation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.191">Section B.4.191: <code><nobr>OR</nobr></code>: Bitwise OR</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.192">Section B.4.192: <code><nobr>ORPD</nobr></code>: Bit-wise Logical OR of Double-Precision FP Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.193">Section B.4.193: <code><nobr>ORPS</nobr></code>: Bit-wise Logical OR of Single-Precision FP Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.194">Section B.4.194: <code><nobr>OUT</nobr></code>: Output Data to I/O Port</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.195">Section B.4.195: <code><nobr>OUTSB</nobr></code>, <code><nobr>OUTSW</nobr></code>, <code><nobr>OUTSD</nobr></code>: Output String to I/O Port</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.196">Section B.4.196: <code><nobr>PACKSSDW</nobr></code>, <code><nobr>PACKSSWB</nobr></code>, <code><nobr>PACKUSWB</nobr></code>: Pack Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.197">Section B.4.197: <code><nobr>PADDB</nobr></code>, <code><nobr>PADDW</nobr></code>, <code><nobr>PADDD</nobr></code>: Add Packed Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.198">Section B.4.198: <code><nobr>PADDQ</nobr></code>: Add Packed Quadword Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.199">Section B.4.199: <code><nobr>PADDSB</nobr></code>, <code><nobr>PADDSW</nobr></code>: Add Packed Signed Integers With Saturation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.200">Section B.4.200: <code><nobr>PADDSIW</nobr></code>: MMX Packed Addition to Implicit Destination</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.201">Section B.4.201: <code><nobr>PADDUSB</nobr></code>, <code><nobr>PADDUSW</nobr></code>: Add Packed Unsigned Integers With Saturation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.202">Section B.4.202: <code><nobr>PAND</nobr></code>, <code><nobr>PANDN</nobr></code>: MMX Bitwise AND and AND-NOT</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.203">Section B.4.203: <code><nobr>PAUSE</nobr></code>: Spin Loop Hint</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.204">Section B.4.204: <code><nobr>PAVEB</nobr></code>: MMX Packed Average</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.205">Section B.4.205: <code><nobr>PAVGB</nobr></code> <code><nobr>PAVGW</nobr></code>: Average Packed Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.206">Section B.4.206: <code><nobr>PAVGUSB</nobr></code>: Average of unsigned packed 8-bit values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.207">Section B.4.207: <code><nobr>PCMPxx</nobr></code>: Compare Packed Integers.</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.208">Section B.4.208: <code><nobr>PDISTIB</nobr></code>: MMX Packed Distance and Accumulate with Implied Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.209">Section B.4.209: <code><nobr>PEXTRW</nobr></code>: Extract Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.210">Section B.4.210: <code><nobr>PF2ID</nobr></code>: Packed Single-Precision FP to Integer Convert</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.211">Section B.4.211: <code><nobr>PF2IW</nobr></code>: Packed Single-Precision FP to Integer Word Convert</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.212">Section B.4.212: <code><nobr>PFACC</nobr></code>: Packed Single-Precision FP Accumulate</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.213">Section B.4.213: <code><nobr>PFADD</nobr></code>: Packed Single-Precision FP Addition</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.214">Section B.4.214: <code><nobr>PFCMPxx</nobr></code>: Packed Single-Precision FP Compare </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.215">Section B.4.215: <code><nobr>PFMAX</nobr></code>: Packed Single-Precision FP Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.216">Section B.4.216: <code><nobr>PFMIN</nobr></code>: Packed Single-Precision FP Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.217">Section B.4.217: <code><nobr>PFMUL</nobr></code>: Packed Single-Precision FP Multiply</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.218">Section B.4.218: <code><nobr>PFNACC</nobr></code>: Packed Single-Precision FP Negative Accumulate</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.219">Section B.4.219: <code><nobr>PFPNACC</nobr></code>: Packed Single-Precision FP Mixed Accumulate</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.220">Section B.4.220: <code><nobr>PFRCP</nobr></code>: Packed Single-Precision FP Reciprocal Approximation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.221">Section B.4.221: <code><nobr>PFRCPIT1</nobr></code>: Packed Single-Precision FP Reciprocal, First Iteration Step</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.222">Section B.4.222: <code><nobr>PFRCPIT2</nobr></code>: Packed Single-Precision FP Reciprocal/ Reciprocal Square Root, Second Iteration Step</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.223">Section B.4.223: <code><nobr>PFRSQIT1</nobr></code>: Packed Single-Precision FP Reciprocal Square Root, First Iteration Step</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.224">Section B.4.224: <code><nobr>PFRSQRT</nobr></code>: Packed Single-Precision FP Reciprocal Square Root Approximation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.225">Section B.4.225: <code><nobr>PFSUB</nobr></code>: Packed Single-Precision FP Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.226">Section B.4.226: <code><nobr>PFSUBR</nobr></code>: Packed Single-Precision FP Reverse Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.227">Section B.4.227: <code><nobr>PI2FD</nobr></code>: Packed Doubleword Integer to Single-Precision FP Convert</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.228">Section B.4.228: <code><nobr>PF2IW</nobr></code>: Packed Word Integer to Single-Precision FP Convert</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.229">Section B.4.229: <code><nobr>PINSRW</nobr></code>: Insert Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.230">Section B.4.230: <code><nobr>PMACHRIW</nobr></code>: Packed Multiply and Accumulate with Rounding</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.231">Section B.4.231: <code><nobr>PMADDWD</nobr></code>: MMX Packed Multiply and Add</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.232">Section B.4.232: <code><nobr>PMAGW</nobr></code>: MMX Packed Magnitude</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.233">Section B.4.233: <code><nobr>PMAXSW</nobr></code>: Packed Signed Integer Word Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.234">Section B.4.234: <code><nobr>PMAXUB</nobr></code>: Packed Unsigned Integer Byte Maximum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.235">Section B.4.235: <code><nobr>PMINSW</nobr></code>: Packed Signed Integer Word Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.236">Section B.4.236: <code><nobr>PMINUB</nobr></code>: Packed Unsigned Integer Byte Minimum</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.237">Section B.4.237: <code><nobr>PMOVMSKB</nobr></code>: Move Byte Mask To Integer</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.238">Section B.4.238: <code><nobr>PMULHRWC</nobr></code>, <code><nobr>PMULHRIW</nobr></code>: Multiply Packed 16-bit Integers With Rounding, and Store High Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.239">Section B.4.239: <code><nobr>PMULHRWA</nobr></code>: Multiply Packed 16-bit Integers With Rounding, and Store High Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.240">Section B.4.240: <code><nobr>PMULHUW</nobr></code>: Multiply Packed 16-bit Integers, and Store High Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.241">Section B.4.241: <code><nobr>PMULHW</nobr></code>, <code><nobr>PMULLW</nobr></code>: Multiply Packed 16-bit Integers, and Store</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.242">Section B.4.242: <code><nobr>PMULUDQ</nobr></code>: Multiply Packed Unsigned 32-bit Integers, and Store.</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.243">Section B.4.243: <code><nobr>PMVccZB</nobr></code>: MMX Packed Conditional Move</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.244">Section B.4.244: <code><nobr>POP</nobr></code>: Pop Data from Stack</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.245">Section B.4.245: <code><nobr>POPAx</nobr></code>: Pop All General-Purpose Registers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.246">Section B.4.246: <code><nobr>POPFx</nobr></code>: Pop Flags Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.247">Section B.4.247: <code><nobr>POR</nobr></code>: MMX Bitwise OR</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.248">Section B.4.248: <code><nobr>PREFETCH</nobr></code>: Prefetch Data Into Caches</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.249">Section B.4.249: <code><nobr>PREFETCHh</nobr></code>: Prefetch Data Into Caches </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.250">Section B.4.250: <code><nobr>PSADBW</nobr></code>: Packed Sum of Absolute Differences</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.251">Section B.4.251: <code><nobr>PSHUFD</nobr></code>: Shuffle Packed Doublewords</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.252">Section B.4.252: <code><nobr>PSHUFHW</nobr></code>: Shuffle Packed High Words</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.253">Section B.4.253: <code><nobr>PSHUFLW</nobr></code>: Shuffle Packed Low Words</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.254">Section B.4.254: <code><nobr>PSHUFW</nobr></code>: Shuffle Packed Words</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.255">Section B.4.255: <code><nobr>PSLLx</nobr></code>: Packed Data Bit Shift Left Logical</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.256">Section B.4.256: <code><nobr>PSRAx</nobr></code>: Packed Data Bit Shift Right Arithmetic</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.257">Section B.4.257: <code><nobr>PSRLx</nobr></code>: Packed Data Bit Shift Right Logical</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.258">Section B.4.258: <code><nobr>PSUBx</nobr></code>: Subtract Packed Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.259">Section B.4.259: <code><nobr>PSUBSxx</nobr></code>, <code><nobr>PSUBUSx</nobr></code>: Subtract Packed Integers With Saturation</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.260">Section B.4.260: <code><nobr>PSUBSIW</nobr></code>: MMX Packed Subtract with Saturation to Implied Destination</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.261">Section B.4.261: <code><nobr>PSWAPD</nobr></code>: Swap Packed Data </a><br>
|
||||
<a href="nasmdocb.html#section-B.4.262">Section B.4.262: <code><nobr>PUNPCKxxx</nobr></code>: Unpack and Interleave Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.263">Section B.4.263: <code><nobr>PUSH</nobr></code>: Push Data on Stack</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.264">Section B.4.264: <code><nobr>PUSHAx</nobr></code>: Push All General-Purpose Registers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.265">Section B.4.265: <code><nobr>PUSHFx</nobr></code>: Push Flags Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.266">Section B.4.266: <code><nobr>PXOR</nobr></code>: MMX Bitwise XOR</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.267">Section B.4.267: <code><nobr>RCL</nobr></code>, <code><nobr>RCR</nobr></code>: Bitwise Rotate through Carry Bit</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.268">Section B.4.268: <code><nobr>RCPPS</nobr></code>: Packed Single-Precision FP Reciprocal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.269">Section B.4.269: <code><nobr>RCPSS</nobr></code>: Scalar Single-Precision FP Reciprocal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.270">Section B.4.270: <code><nobr>RDMSR</nobr></code>: Read Model-Specific Registers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.271">Section B.4.271: <code><nobr>RDPMC</nobr></code>: Read Performance-Monitoring Counters</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.272">Section B.4.272: <code><nobr>RDSHR</nobr></code>: Read SMM Header Pointer Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.273">Section B.4.273: <code><nobr>RDTSC</nobr></code>: Read Time-Stamp Counter</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.274">Section B.4.274: <code><nobr>RET</nobr></code>, <code><nobr>RETF</nobr></code>, <code><nobr>RETN</nobr></code>: Return from Procedure Call</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.275">Section B.4.275: <code><nobr>ROL</nobr></code>, <code><nobr>ROR</nobr></code>: Bitwise Rotate</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.276">Section B.4.276: <code><nobr>RSDC</nobr></code>: Restore Segment Register and Descriptor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.277">Section B.4.277: <code><nobr>RSLDT</nobr></code>: Restore Segment Register and Descriptor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.278">Section B.4.278: <code><nobr>RSM</nobr></code>: Resume from System-Management Mode</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.279">Section B.4.279: <code><nobr>RSQRTPS</nobr></code>: Packed Single-Precision FP Square Root Reciprocal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.280">Section B.4.280: <code><nobr>RSQRTSS</nobr></code>: Scalar Single-Precision FP Square Root Reciprocal</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.281">Section B.4.281: <code><nobr>RSTS</nobr></code>: Restore TSR and Descriptor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.282">Section B.4.282: <code><nobr>SAHF</nobr></code>: Store AH to Flags</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.283">Section B.4.283: <code><nobr>SAL</nobr></code>, <code><nobr>SAR</nobr></code>: Bitwise Arithmetic Shifts</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.284">Section B.4.284: <code><nobr>SALC</nobr></code>: Set AL from Carry Flag</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.285">Section B.4.285: <code><nobr>SBB</nobr></code>: Subtract with Borrow</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.286">Section B.4.286: <code><nobr>SCASB</nobr></code>, <code><nobr>SCASW</nobr></code>, <code><nobr>SCASD</nobr></code>: Scan String</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.287">Section B.4.287: <code><nobr>SETcc</nobr></code>: Set Register from Condition</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.288">Section B.4.288: <code><nobr>SFENCE</nobr></code>: Store Fence</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.289">Section B.4.289: <code><nobr>SGDT</nobr></code>, <code><nobr>SIDT</nobr></code>, <code><nobr>SLDT</nobr></code>: Store Descriptor Table Pointers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.290">Section B.4.290: <code><nobr>SHL</nobr></code>, <code><nobr>SHR</nobr></code>: Bitwise Logical Shifts</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.291">Section B.4.291: <code><nobr>SHLD</nobr></code>, <code><nobr>SHRD</nobr></code>: Bitwise Double-Precision Shifts</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.292">Section B.4.292: <code><nobr>SHUFPD</nobr></code>: Shuffle Packed Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.293">Section B.4.293: <code><nobr>SHUFPS</nobr></code>: Shuffle Packed Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.294">Section B.4.294: <code><nobr>SMI</nobr></code>: System Management Interrupt</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.295">Section B.4.295: <code><nobr>SMINT</nobr></code>, <code><nobr>SMINTOLD</nobr></code>: Software SMM Entry (CYRIX)</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.296">Section B.4.296: <code><nobr>SMSW</nobr></code>: Store Machine Status Word</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.297">Section B.4.297: <code><nobr>SQRTPD</nobr></code>: Packed Double-Precision FP Square Root</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.298">Section B.4.298: <code><nobr>SQRTPS</nobr></code>: Packed Single-Precision FP Square Root</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.299">Section B.4.299: <code><nobr>SQRTSD</nobr></code>: Scalar Double-Precision FP Square Root</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.300">Section B.4.300: <code><nobr>SQRTSS</nobr></code>: Scalar Single-Precision FP Square Root</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.301">Section B.4.301: <code><nobr>STC</nobr></code>, <code><nobr>STD</nobr></code>, <code><nobr>STI</nobr></code>: Set Flags</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.302">Section B.4.302: <code><nobr>STMXCSR</nobr></code>: Store Streaming SIMD Extension Control/Status</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.303">Section B.4.303: <code><nobr>STOSB</nobr></code>, <code><nobr>STOSW</nobr></code>, <code><nobr>STOSD</nobr></code>: Store Byte to String</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.304">Section B.4.304: <code><nobr>STR</nobr></code>: Store Task Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.305">Section B.4.305: <code><nobr>SUB</nobr></code>: Subtract Integers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.306">Section B.4.306: <code><nobr>SUBPD</nobr></code>: Packed Double-Precision FP Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.307">Section B.4.307: <code><nobr>SUBPS</nobr></code>: Packed Single-Precision FP Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.308">Section B.4.308: <code><nobr>SUBSD</nobr></code>: Scalar Single-FP Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.309">Section B.4.309: <code><nobr>SUBSS</nobr></code>: Scalar Single-FP Subtract</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.310">Section B.4.310: <code><nobr>SVDC</nobr></code>: Save Segment Register and Descriptor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.311">Section B.4.311: <code><nobr>SVLDT</nobr></code>: Save LDTR and Descriptor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.312">Section B.4.312: <code><nobr>SVTS</nobr></code>: Save TSR and Descriptor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.313">Section B.4.313: <code><nobr>SYSCALL</nobr></code>: Call Operating System</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.314">Section B.4.314: <code><nobr>SYSENTER</nobr></code>: Fast System Call</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.315">Section B.4.315: <code><nobr>SYSEXIT</nobr></code>: Fast Return From System Call</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.316">Section B.4.316: <code><nobr>SYSRET</nobr></code>: Return From Operating System</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.317">Section B.4.317: <code><nobr>TEST</nobr></code>: Test Bits (notional bitwise AND)</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.318">Section B.4.318: <code><nobr>UCOMISD</nobr></code>: Unordered Scalar Double-Precision FP compare and set EFLAGS</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.319">Section B.4.319: <code><nobr>UCOMISS</nobr></code>: Unordered Scalar Single-Precision FP compare and set EFLAGS</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.320">Section B.4.320: <code><nobr>UD0</nobr></code>, <code><nobr>UD1</nobr></code>, <code><nobr>UD2</nobr></code>: Undefined Instruction</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.321">Section B.4.321: <code><nobr>UMOV</nobr></code>: User Move Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.322">Section B.4.322: <code><nobr>UNPCKHPD</nobr></code>: Unpack and Interleave High Packed Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.323">Section B.4.323: <code><nobr>UNPCKHPS</nobr></code>: Unpack and Interleave High Packed Single-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.324">Section B.4.324: <code><nobr>UNPCKLPD</nobr></code>: Unpack and Interleave Low Packed Double-Precision FP Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.325">Section B.4.325: <code><nobr>UNPCKLPS</nobr></code>: Unpack and Interleave Low Packed Single-Precision FP Data</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.326">Section B.4.326: <code><nobr>VERR</nobr></code>, <code><nobr>VERW</nobr></code>: Verify Segment Readability/Writability</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.327">Section B.4.327: <code><nobr>WAIT</nobr></code>: Wait for Floating-Point Processor</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.328">Section B.4.328: <code><nobr>WBINVD</nobr></code>: Write Back and Invalidate Cache</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.329">Section B.4.329: <code><nobr>WRMSR</nobr></code>: Write Model-Specific Registers</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.330">Section B.4.330: <code><nobr>WRSHR</nobr></code>: Write SMM Header Pointer Register</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.331">Section B.4.331: <code><nobr>XADD</nobr></code>: Exchange and Add</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.332">Section B.4.332: <code><nobr>XBTS</nobr></code>: Extract Bit String</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.333">Section B.4.333: <code><nobr>XCHG</nobr></code>: Exchange</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.334">Section B.4.334: <code><nobr>XLATB</nobr></code>: Translate Byte in Lookup Table</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.335">Section B.4.335: <code><nobr>XOR</nobr></code>: Bitwise Exclusive OR</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.336">Section B.4.336: <code><nobr>XORPD</nobr></code>: Bitwise Logical XOR of Double-Precision FP Values</a><br>
|
||||
<a href="nasmdocb.html#section-B.4.337">Section B.4.337: <code><nobr>XORPS</nobr></code>: Bitwise Logical XOR of Single-Precision FP Values</a><br>
|
||||
<p><a href="nasmdoci.html">Index</a>
|
||||
</body></html>
|
||||
164
Ref-docs/nasmdoc/html/nasmdoc1.html
Normal file
164
Ref-docs/nasmdoc/html/nasmdoc1.html
Normal file
@@ -0,0 +1,164 @@
|
||||
<html><head><title>NASM Manual</title></head>
|
||||
<body><h1 align=center>The Netwide Assembler: NASM</h1>
|
||||
|
||||
<p align=center><a href="nasmdoc2.html">Next Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
<h2><a name="chapter-1">Chapter 1: Introduction</a></h2>
|
||||
<h3><a name="section-1.1">1.1 What Is NASM?</a></h3>
|
||||
<p>The Netwide Assembler, NASM, is an 80x86 assembler designed for
|
||||
portability and modularity. It supports a range of object file formats,
|
||||
including Linux and <code><nobr>NetBSD/FreeBSD</nobr></code>
|
||||
<code><nobr>a.out</nobr></code>, <code><nobr>ELF</nobr></code>,
|
||||
<code><nobr>COFF</nobr></code>, Microsoft 16-bit
|
||||
<code><nobr>OBJ</nobr></code> and <code><nobr>Win32</nobr></code>. It will
|
||||
also output plain binary files. Its syntax is designed to be simple and
|
||||
easy to understand, similar to Intel's but less complex. It supports
|
||||
<code><nobr>Pentium</nobr></code>, <code><nobr>P6</nobr></code>,
|
||||
<code><nobr>MMX</nobr></code>, <code><nobr>3DNow!</nobr></code>,
|
||||
<code><nobr>SSE</nobr></code> and <code><nobr>SSE2</nobr></code> opcodes,
|
||||
and has macro capability.
|
||||
<h4><a name="section-1.1.1">1.1.1 Why Yet Another Assembler?</a></h4>
|
||||
<p>The Netwide Assembler grew out of an idea on
|
||||
<code><nobr>comp.lang.asm.x86</nobr></code> (or possibly
|
||||
<code><nobr>alt.lang.asm</nobr></code> - I forget which), which was
|
||||
essentially that there didn't seem to be a good <em>free</em> x86-series
|
||||
assembler around, and that maybe someone ought to write one.
|
||||
<ul>
|
||||
<li><code><nobr>a86</nobr></code> is good, but not free, and in particular
|
||||
you don't get any 32-bit capability until you pay. It's DOS only, too.
|
||||
<li><code><nobr>gas</nobr></code> is free, and ports over DOS and Unix, but
|
||||
it's not very good, since it's designed to be a back end to
|
||||
<code><nobr>gcc</nobr></code>, which always feeds it correct code. So its
|
||||
error checking is minimal. Also, its syntax is horrible, from the point of
|
||||
view of anyone trying to actually <em>write</em> anything in it. Plus you
|
||||
can't write 16-bit code in it (properly).
|
||||
<li><code><nobr>as86</nobr></code> is Minix- and Linux-specific, and (my
|
||||
version at least) doesn't seem to have much (or any) documentation.
|
||||
<li><code><nobr>MASM</nobr></code> isn't very good, and it's (was)
|
||||
expensive, and it runs only under DOS.
|
||||
<li><code><nobr>TASM</nobr></code> is better, but still strives for MASM
|
||||
compatibility, which means millions of directives and tons of red tape. And
|
||||
its syntax is essentially MASM's, with the contradictions and quirks that
|
||||
entails (although it sorts out some of those by means of Ideal mode). It's
|
||||
expensive too. And it's DOS-only.
|
||||
</ul>
|
||||
<p>So here, for your coding pleasure, is NASM. At present it's still in
|
||||
prototype stage - we don't promise that it can outperform any of these
|
||||
assemblers. But please, <em>please</em> send us bug reports, fixes, helpful
|
||||
information, and anything else you can get your hands on (and thanks to the
|
||||
many people who've done this already! You all know who you are), and we'll
|
||||
improve it out of all recognition. Again.
|
||||
<h4><a name="section-1.1.2">1.1.2 Licence Conditions</a></h4>
|
||||
<p>Please see the file <code><nobr>COPYING</nobr></code>, supplied as part
|
||||
of any NASM distribution archive, for the licence conditions under which
|
||||
you may use NASM. NASM is now under the so-called GNU Lesser General Public
|
||||
License, LGPL.
|
||||
<h3><a name="section-1.2">1.2 Contact Information</a></h3>
|
||||
<p>The current version of NASM (since about 0.98.08) are maintained by a
|
||||
team of developers, accessible through the
|
||||
<code><nobr>nasm-devel</nobr></code> mailing list (see below for the link).
|
||||
If you want to report a bug, please read
|
||||
<a href="nasmdo10.html#section-10.2">section 10.2</a> first.
|
||||
<p>NASM has a WWW page at
|
||||
<a href="http://nasm.sourceforge.net"><code><nobr>http://nasm.sourceforge.net</nobr></code></a>.
|
||||
If it's not there, google for us!
|
||||
<p>The original authors are e-mailable as
|
||||
<a href="mailto:jules@dsf.org.uk"><code><nobr>jules@dsf.org.uk</nobr></code></a>
|
||||
and
|
||||
<a href="mailto:anakin@pobox.com"><code><nobr>anakin@pobox.com</nobr></code></a>.
|
||||
The latter is no longer involved in the development team.
|
||||
<p>New releases of NASM are uploaded to the official sites
|
||||
<a href="http://nasm.sourceforge.net"><code><nobr>http://nasm.sourceforge.net</nobr></code></a>
|
||||
and to
|
||||
<a href="ftp://ftp.kernel.org/pub/software/devel/nasm/"><code><nobr>ftp.kernel.org</nobr></code></a>
|
||||
and
|
||||
<a href="ftp://ibiblio.org/pub/Linux/devel/lang/assemblers/"><code><nobr>ibiblio.org</nobr></code></a>.
|
||||
<p>Announcements are posted to
|
||||
<a href="news:comp.lang.asm.x86"><code><nobr>comp.lang.asm.x86</nobr></code></a>,
|
||||
<a href="news:alt.lang.asm"><code><nobr>alt.lang.asm</nobr></code></a> and
|
||||
<a href="news:comp.os.linux.announce"><code><nobr>comp.os.linux.announce</nobr></code></a>
|
||||
<p>If you want information about NASM beta releases, and the current
|
||||
development status, please subscribe to the
|
||||
<code><nobr>nasm-devel</nobr></code> email list by registering at
|
||||
<a href="http://sourceforge.net/projects/nasm"><code><nobr>http://sourceforge.net/projects/nasm</nobr></code></a>.
|
||||
<h3><a name="section-1.3">1.3 Installation</a></h3>
|
||||
<h4><a name="section-1.3.1">1.3.1 Installing NASM under MS-DOS or Windows</a></h4>
|
||||
<p>Once you've obtained the DOS archive for NASM,
|
||||
<code><nobr>nasmXXX.zip</nobr></code> (where <code><nobr>XXX</nobr></code>
|
||||
denotes the version number of NASM contained in the archive), unpack it
|
||||
into its own directory (for example <code><nobr>c:\nasm</nobr></code>).
|
||||
<p>The archive will contain four executable files: the NASM executable
|
||||
files <code><nobr>nasm.exe</nobr></code> and
|
||||
<code><nobr>nasmw.exe</nobr></code>, and the NDISASM executable files
|
||||
<code><nobr>ndisasm.exe</nobr></code> and
|
||||
<code><nobr>ndisasmw.exe</nobr></code>. In each case, the file whose name
|
||||
ends in <code><nobr>w</nobr></code> is a <code><nobr>Win32</nobr></code>
|
||||
executable, designed to run under <code><nobr>Windows 95</nobr></code> or
|
||||
<code><nobr>Windows NT</nobr></code> Intel, and the other one is a 16-bit
|
||||
<code><nobr>DOS</nobr></code> executable.
|
||||
<p>The only file NASM needs to run is its own executable, so copy (at
|
||||
least) one of <code><nobr>nasm.exe</nobr></code> and
|
||||
<code><nobr>nasmw.exe</nobr></code> to a directory on your PATH, or
|
||||
alternatively edit <code><nobr>autoexec.bat</nobr></code> to add the
|
||||
<code><nobr>nasm</nobr></code> directory to your
|
||||
<code><nobr>PATH</nobr></code>. (If you're only installing the
|
||||
<code><nobr>Win32</nobr></code> version, you may wish to rename it to
|
||||
<code><nobr>nasm.exe</nobr></code>.)
|
||||
<p>That's it - NASM is installed. You don't need the nasm directory to be
|
||||
present to run NASM (unless you've added it to your
|
||||
<code><nobr>PATH</nobr></code>), so you can delete it if you need to save
|
||||
space; however, you may want to keep the documentation or test programs.
|
||||
<p>If you've downloaded the DOS source archive,
|
||||
<code><nobr>nasmXXXs.zip</nobr></code>, the <code><nobr>nasm</nobr></code>
|
||||
directory will also contain the full NASM source code, and a selection of
|
||||
Makefiles you can (hopefully) use to rebuild your copy of NASM from
|
||||
scratch.
|
||||
<p>Note that the source files <code><nobr>insnsa.c</nobr></code>,
|
||||
<code><nobr>insnsd.c</nobr></code>, <code><nobr>insnsi.h</nobr></code> and
|
||||
<code><nobr>insnsn.c</nobr></code> are automatically generated from the
|
||||
master instruction table <code><nobr>insns.dat</nobr></code> by a Perl
|
||||
script; the file <code><nobr>macros.c</nobr></code> is generated from
|
||||
<code><nobr>standard.mac</nobr></code> by another Perl script. Although the
|
||||
NASM source distribution includes these generated files, you will need to
|
||||
rebuild them (and hence, will need a Perl interpreter) if you change
|
||||
insns.dat, standard.mac or the documentation. It is possible future source
|
||||
distributions may not include these files at all. Ports of Perl for a
|
||||
variety of platforms, including DOS and Windows, are available from
|
||||
<a href="http://www.cpan.org/ports/">www.cpan.org</a>.
|
||||
<h4><a name="section-1.3.2">1.3.2 Installing NASM under Unix</a></h4>
|
||||
<p>Once you've obtained the Unix source archive for NASM,
|
||||
<code><nobr>nasm-X.XX.tar.gz</nobr></code> (where
|
||||
<code><nobr>X.XX</nobr></code> denotes the version number of NASM contained
|
||||
in the archive), unpack it into a directory such as
|
||||
<code><nobr>/usr/local/src</nobr></code>. The archive, when unpacked, will
|
||||
create its own subdirectory <code><nobr>nasm-X.XX</nobr></code>.
|
||||
<p>NASM is an auto-configuring package: once you've unpacked it,
|
||||
<code><nobr>cd</nobr></code> to the directory it's been unpacked into and
|
||||
type <code><nobr>./configure</nobr></code>. This shell script will find the
|
||||
best C compiler to use for building NASM and set up Makefiles accordingly.
|
||||
<p>Once NASM has auto-configured, you can type
|
||||
<code><nobr>make</nobr></code> to build the <code><nobr>nasm</nobr></code>
|
||||
and <code><nobr>ndisasm</nobr></code> binaries, and then
|
||||
<code><nobr>make install</nobr></code> to install them in
|
||||
<code><nobr>/usr/local/bin</nobr></code> and install the man pages
|
||||
<code><nobr>nasm.1</nobr></code> and <code><nobr>ndisasm.1</nobr></code> in
|
||||
<code><nobr>/usr/local/man/man1</nobr></code>. Alternatively, you can give
|
||||
options such as <code><nobr>--prefix</nobr></code> to the configure script
|
||||
(see the file <code><nobr>INSTALL</nobr></code> for more details), or
|
||||
install the programs yourself.
|
||||
<p>NASM also comes with a set of utilities for handling the
|
||||
<code><nobr>RDOFF</nobr></code> custom object-file format, which are in the
|
||||
<code><nobr>rdoff</nobr></code> subdirectory of the NASM archive. You can
|
||||
build these with <code><nobr>make rdf</nobr></code> and install them with
|
||||
<code><nobr>make rdf_install</nobr></code>, if you want them.
|
||||
<p>If NASM fails to auto-configure, you may still be able to make it
|
||||
compile by using the fall-back Unix makefile
|
||||
<code><nobr>Makefile.unx</nobr></code>. Copy or rename that file to
|
||||
<code><nobr>Makefile</nobr></code> and try typing
|
||||
<code><nobr>make</nobr></code>. There is also a Makefile.unx file in the
|
||||
<code><nobr>rdoff</nobr></code> subdirectory.
|
||||
<p align=center><a href="nasmdoc2.html">Next Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
</body></html>
|
||||
572
Ref-docs/nasmdoc/html/nasmdoc2.html
Normal file
572
Ref-docs/nasmdoc/html/nasmdoc2.html
Normal file
@@ -0,0 +1,572 @@
|
||||
<html><head><title>NASM Manual</title></head>
|
||||
<body><h1 align=center>The Netwide Assembler: NASM</h1>
|
||||
|
||||
<p align=center><a href="nasmdoc3.html">Next Chapter</a> |
|
||||
<a href="nasmdoc1.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
<h2><a name="chapter-2">Chapter 2: Running NASM</a></h2>
|
||||
<h3><a name="section-2.1">2.1 NASM Command-Line Syntax</a></h3>
|
||||
<p>To assemble a file, you issue a command of the form
|
||||
<p><pre>
|
||||
nasm -f <format> <filename> [-o <output>]
|
||||
</pre>
|
||||
<p>For example,
|
||||
<p><pre>
|
||||
nasm -f elf myfile.asm
|
||||
</pre>
|
||||
<p>will assemble <code><nobr>myfile.asm</nobr></code> into an
|
||||
<code><nobr>ELF</nobr></code> object file
|
||||
<code><nobr>myfile.o</nobr></code>. And
|
||||
<p><pre>
|
||||
nasm -f bin myfile.asm -o myfile.com
|
||||
</pre>
|
||||
<p>will assemble <code><nobr>myfile.asm</nobr></code> into a raw binary
|
||||
file <code><nobr>myfile.com</nobr></code>.
|
||||
<p>To produce a listing file, with the hex codes output from NASM displayed
|
||||
on the left of the original sources, use the <code><nobr>-l</nobr></code>
|
||||
option to give a listing file name, for example:
|
||||
<p><pre>
|
||||
nasm -f coff myfile.asm -l myfile.lst
|
||||
</pre>
|
||||
<p>To get further usage instructions from NASM, try typing
|
||||
<p><pre>
|
||||
nasm -h
|
||||
</pre>
|
||||
<p>As <code><nobr>-hf</nobr></code>, this will also list the available
|
||||
output file formats, and what they are.
|
||||
<p>If you use Linux but aren't sure whether your system is
|
||||
<code><nobr>a.out</nobr></code> or <code><nobr>ELF</nobr></code>, type
|
||||
<p><pre>
|
||||
file nasm
|
||||
</pre>
|
||||
<p>(in the directory in which you put the NASM binary when you installed
|
||||
it). If it says something like
|
||||
<p><pre>
|
||||
nasm: ELF 32-bit LSB executable i386 (386 and up) Version 1
|
||||
</pre>
|
||||
<p>then your system is <code><nobr>ELF</nobr></code>, and you should use
|
||||
the option <code><nobr>-f elf</nobr></code> when you want NASM to produce
|
||||
Linux object files. If it says
|
||||
<p><pre>
|
||||
nasm: Linux/i386 demand-paged executable (QMAGIC)
|
||||
</pre>
|
||||
<p>or something similar, your system is <code><nobr>a.out</nobr></code>,
|
||||
and you should use <code><nobr>-f aout</nobr></code> instead (Linux
|
||||
<code><nobr>a.out</nobr></code> systems have long been obsolete, and are
|
||||
rare these days.)
|
||||
<p>Like Unix compilers and assemblers, NASM is silent unless it goes wrong:
|
||||
you won't see any output at all, unless it gives error messages.
|
||||
<h4><a name="section-2.1.1">2.1.1 The <code><nobr>-o</nobr></code> Option: Specifying the Output File Name</a></h4>
|
||||
<p>NASM will normally choose the name of your output file for you;
|
||||
precisely how it does this is dependent on the object file format. For
|
||||
Microsoft object file formats (<code><nobr>obj</nobr></code> and
|
||||
<code><nobr>win32</nobr></code>), it will remove the
|
||||
<code><nobr>.asm</nobr></code> extension (or whatever extension you like to
|
||||
use - NASM doesn't care) from your source file name and substitute
|
||||
<code><nobr>.obj</nobr></code>. For Unix object file formats
|
||||
(<code><nobr>aout</nobr></code>, <code><nobr>coff</nobr></code>,
|
||||
<code><nobr>elf</nobr></code> and <code><nobr>as86</nobr></code>) it will
|
||||
substitute <code><nobr>.o</nobr></code>. For <code><nobr>rdf</nobr></code>,
|
||||
it will use <code><nobr>.rdf</nobr></code>, and for the
|
||||
<code><nobr>bin</nobr></code> format it will simply remove the extension,
|
||||
so that <code><nobr>myfile.asm</nobr></code> produces the output file
|
||||
<code><nobr>myfile</nobr></code>.
|
||||
<p>If the output file already exists, NASM will overwrite it, unless it has
|
||||
the same name as the input file, in which case it will give a warning and
|
||||
use <code><nobr>nasm.out</nobr></code> as the output file name instead.
|
||||
<p>For situations in which this behaviour is unacceptable, NASM provides
|
||||
the <code><nobr>-o</nobr></code> command-line option, which allows you to
|
||||
specify your desired output file name. You invoke
|
||||
<code><nobr>-o</nobr></code> by following it with the name you wish for the
|
||||
output file, either with or without an intervening space. For example:
|
||||
<p><pre>
|
||||
nasm -f bin program.asm -o program.com
|
||||
nasm -f bin driver.asm -odriver.sys
|
||||
</pre>
|
||||
<p>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
|
||||
<a href="#section-2.1.16">section 2.1.16</a>.
|
||||
<h4><a name="section-2.1.2">2.1.2 The <code><nobr>-f</nobr></code> Option: Specifying the Output File Format</a></h4>
|
||||
<p>If you do not supply the <code><nobr>-f</nobr></code> option to NASM, it
|
||||
will choose an output file format for you itself. In the distribution
|
||||
versions of NASM, the default is always <code><nobr>bin</nobr></code>; if
|
||||
you've compiled your own copy of NASM, you can redefine
|
||||
<code><nobr>OF_DEFAULT</nobr></code> at compile time and choose what you
|
||||
want the default to be.
|
||||
<p>Like <code><nobr>-o</nobr></code>, the intervening space between
|
||||
<code><nobr>-f</nobr></code> and the output file format is optional; so
|
||||
<code><nobr>-f elf</nobr></code> and <code><nobr>-felf</nobr></code> are
|
||||
both valid.
|
||||
<p>A complete list of the available output file formats can be given by
|
||||
issuing the command <code><nobr>nasm -hf</nobr></code>.
|
||||
<h4><a name="section-2.1.3">2.1.3 The <code><nobr>-l</nobr></code> Option: Generating a Listing File</a></h4>
|
||||
<p>If you supply the <code><nobr>-l</nobr></code> option to NASM, followed
|
||||
(with the usual optional space) by a file name, NASM will generate a
|
||||
source-listing file for you, in which addresses and generated code are
|
||||
listed on the left, and the actual source code, with expansions of
|
||||
multi-line macros (except those which specifically request no expansion in
|
||||
source listings: see <a href="nasmdoc4.html#section-4.3.9">section
|
||||
4.3.9</a>) on the right. For example:
|
||||
<p><pre>
|
||||
nasm -f elf myfile.asm -l myfile.lst
|
||||
</pre>
|
||||
<p>If a list file is selected, you may turn off listing for a section of
|
||||
your source with <code><nobr>[list -]</nobr></code>, and turn it back on
|
||||
with <code><nobr>[list +]</nobr></code>, (the default, obviously). There is
|
||||
no "user form" (without the brackets). This can be used to list only
|
||||
sections of interest, avoiding excessively long listings.
|
||||
<h4><a name="section-2.1.4">2.1.4 The <code><nobr>-M</nobr></code> Option: Generate Makefile Dependencies.</a></h4>
|
||||
<p>This option can be used to generate makefile dependencies on stdout.
|
||||
This can be redirected to a file for further processing. For example:
|
||||
<p><pre>
|
||||
NASM -M myfile.asm > myfile.dep
|
||||
</pre>
|
||||
<h4><a name="section-2.1.5">2.1.5 The <code><nobr>-F</nobr></code> Option: Selecting a Debug Information Format</a></h4>
|
||||
<p>This option is used to select the format of the debug information
|
||||
emitted into the output file, to be used by a debugger (or <em>will</em>
|
||||
be). Use of this switch does <em>not</em> enable output of the selected
|
||||
debug info format. Use <code><nobr>-g</nobr></code>, see
|
||||
<a href="#section-2.1.6">section 2.1.6</a>, to enable output.
|
||||
<p>A complete list of the available debug file formats for an output format
|
||||
can be seen by issuing the command
|
||||
<code><nobr>nasm -f <format> -y</nobr></code>. (only "borland" in "-f
|
||||
obj", as of 0.98.35, but "watch this space") See:
|
||||
<a href="#section-2.1.20">section 2.1.20</a>.
|
||||
<p>This should not be confused with the "-f dbg" output format option which
|
||||
is not built into NASM by default. For information on how to enable it when
|
||||
building from the sources, see <a href="nasmdoc6.html#section-6.10">section
|
||||
6.10</a>
|
||||
<h4><a name="section-2.1.6">2.1.6 The <code><nobr>-g</nobr></code> Option: Enabling Debug Information.</a></h4>
|
||||
<p>This option can be used to generate debugging information in the
|
||||
specified format. See: <a href="#section-2.1.5">section 2.1.5</a>. Using
|
||||
<code><nobr>-g</nobr></code> without <code><nobr>-F</nobr></code> results
|
||||
in emitting debug info in the default format, if any, for the selected
|
||||
output format. If no debug information is currently implemented in the
|
||||
selected output format, <code><nobr>-g</nobr></code> is <em>silently
|
||||
ignored</em>.
|
||||
<h4><a name="section-2.1.7">2.1.7 The <code><nobr>-X</nobr></code> Option: Selecting an Error Reporting Format</a></h4>
|
||||
<p>This option can be used to select an error reporting format for any
|
||||
error messages that might be produced by NASM.
|
||||
<p>Currently, two error reporting formats may be selected. They are the
|
||||
<code><nobr>-Xvc</nobr></code> option and the
|
||||
<code><nobr>-Xgnu</nobr></code> option. The GNU format is the default and
|
||||
looks like this:
|
||||
<p><pre>
|
||||
filename.asm:65: error: specific error message
|
||||
</pre>
|
||||
<p>where <code><nobr>filename.asm</nobr></code> is the name of the source
|
||||
file in which the error was detected, <code><nobr>65</nobr></code> is the
|
||||
source file line number on which the error was detected,
|
||||
<code><nobr>error</nobr></code> is the severity of the error (this could be
|
||||
<code><nobr>warning</nobr></code>), and
|
||||
<code><nobr>specific error message</nobr></code> is a more detailed text
|
||||
message which should help pinpoint the exact problem.
|
||||
<p>The other format, specified by <code><nobr>-Xvc</nobr></code> is the
|
||||
style used by Microsoft Visual C++ and some other programs. It looks like
|
||||
this:
|
||||
<p><pre>
|
||||
filename.asm(65) : error: specific error message
|
||||
</pre>
|
||||
<p>where the only difference is that the line number is in parentheses
|
||||
instead of being delimited by colons.
|
||||
<p>See also the <code><nobr>Visual C++</nobr></code> output format,
|
||||
<a href="nasmdoc6.html#section-6.3">section 6.3</a>.
|
||||
<h4><a name="section-2.1.8">2.1.8 The <code><nobr>-E</nobr></code> Option: Send Errors to a File</a></h4>
|
||||
<p>Under <code><nobr>MS-DOS</nobr></code> it can be difficult (though there
|
||||
are ways) to redirect the standard-error output of a program to a file.
|
||||
Since NASM usually produces its warning and error messages on
|
||||
<code><nobr>stderr</nobr></code>, this can make it hard to capture the
|
||||
errors if (for example) you want to load them into an editor.
|
||||
<p>NASM therefore provides the <code><nobr>-E</nobr></code> option, taking
|
||||
a filename argument which causes errors to be sent to the specified files
|
||||
rather than standard error. Therefore you can redirect the errors into a
|
||||
file by typing
|
||||
<p><pre>
|
||||
nasm -E myfile.err -f obj myfile.asm
|
||||
</pre>
|
||||
<h4><a name="section-2.1.9">2.1.9 The <code><nobr>-s</nobr></code> Option: Send Errors to <code><nobr>stdout</nobr></code></a></h4>
|
||||
<p>The <code><nobr>-s</nobr></code> option redirects error messages to
|
||||
<code><nobr>stdout</nobr></code> rather than
|
||||
<code><nobr>stderr</nobr></code>, so it can be redirected under
|
||||
<code><nobr>MS-DOS</nobr></code>. To assemble the file
|
||||
<code><nobr>myfile.asm</nobr></code> and pipe its output to the
|
||||
<code><nobr>more</nobr></code> program, you can type:
|
||||
<p><pre>
|
||||
nasm -s -f obj myfile.asm | more
|
||||
</pre>
|
||||
<p>See also the <code><nobr>-E</nobr></code> option,
|
||||
<a href="#section-2.1.8">section 2.1.8</a>.
|
||||
<h4><a name="section-2.1.10">2.1.10 The <code><nobr>-i</nobr></code> Option: Include File Search Directories</a></h4>
|
||||
<p>When NASM sees the <code><nobr>%include</nobr></code> or
|
||||
<code><nobr>incbin</nobr></code> directive in a source file (see
|
||||
<a href="nasmdoc4.html#section-4.6">section 4.6</a> or
|
||||
<a href="nasmdoc3.html#section-3.2.3">section 3.2.3</a>), it will search
|
||||
for the given file not only in the current directory, but also in any
|
||||
directories specified on the command line by the use of the
|
||||
<code><nobr>-i</nobr></code> option. Therefore you can include files from a
|
||||
macro library, for example, by typing
|
||||
<p><pre>
|
||||
nasm -ic:\macrolib\ -f obj myfile.asm
|
||||
</pre>
|
||||
<p>(As usual, a space between <code><nobr>-i</nobr></code> and the path
|
||||
name is allowed, and optional).
|
||||
<p>NASM, in the interests of complete source-code portability, does not
|
||||
understand the file naming conventions of the OS it is running on; the
|
||||
string you provide as an argument to the <code><nobr>-i</nobr></code>
|
||||
option will be prepended exactly as written to the name of the include
|
||||
file. Therefore the trailing backslash in the above example is necessary.
|
||||
Under Unix, a trailing forward slash is similarly necessary.
|
||||
<p>(You can use this to your advantage, if you're really perverse, by
|
||||
noting that the option <code><nobr>-ifoo</nobr></code> will cause
|
||||
<code><nobr>%include "bar.i"</nobr></code> to search for the file
|
||||
<code><nobr>foobar.i</nobr></code>...)
|
||||
<p>If you want to define a <em>standard</em> include search path, similar
|
||||
to <code><nobr>/usr/include</nobr></code> on Unix systems, you should place
|
||||
one or more <code><nobr>-i</nobr></code> directives in the
|
||||
<code><nobr>NASMENV</nobr></code> environment variable (see
|
||||
<a href="#section-2.1.22">section 2.1.22</a>).
|
||||
<p>For Makefile compatibility with many C compilers, this option can also
|
||||
be specified as <code><nobr>-I</nobr></code>.
|
||||
<h4><a name="section-2.1.11">2.1.11 The <code><nobr>-p</nobr></code> Option: Pre-Include a File</a></h4>
|
||||
<p>NASM allows you to specify files to be <em>pre-included</em> into your
|
||||
source file, by the use of the <code><nobr>-p</nobr></code> option. So
|
||||
running
|
||||
<p><pre>
|
||||
nasm myfile.asm -p myinc.inc
|
||||
</pre>
|
||||
<p>is equivalent to running <code><nobr>nasm myfile.asm</nobr></code> and
|
||||
placing the directive <code><nobr>%include "myinc.inc"</nobr></code> at the
|
||||
start of the file.
|
||||
<p>For consistency with the <code><nobr>-I</nobr></code>,
|
||||
<code><nobr>-D</nobr></code> and <code><nobr>-U</nobr></code> options, this
|
||||
option can also be specified as <code><nobr>-P</nobr></code>.
|
||||
<h4><a name="section-2.1.12">2.1.12 The <code><nobr>-d</nobr></code> Option: Pre-Define a Macro</a></h4>
|
||||
<p>Just as the <code><nobr>-p</nobr></code> option gives an alternative to
|
||||
placing <code><nobr>%include</nobr></code> directives at the start of a
|
||||
source file, the <code><nobr>-d</nobr></code> option gives an alternative
|
||||
to placing a <code><nobr>%define</nobr></code> directive. You could code
|
||||
<p><pre>
|
||||
nasm myfile.asm -dFOO=100
|
||||
</pre>
|
||||
<p>as an alternative to placing the directive
|
||||
<p><pre>
|
||||
%define FOO 100
|
||||
</pre>
|
||||
<p>at the start of the file. You can miss off the macro value, as well: the
|
||||
option <code><nobr>-dFOO</nobr></code> is equivalent to coding
|
||||
<code><nobr>%define FOO</nobr></code>. This form of the directive may be
|
||||
useful for selecting assembly-time options which are then tested using
|
||||
<code><nobr>%ifdef</nobr></code>, for example
|
||||
<code><nobr>-dDEBUG</nobr></code>.
|
||||
<p>For Makefile compatibility with many C compilers, this option can also
|
||||
be specified as <code><nobr>-D</nobr></code>.
|
||||
<h4><a name="section-2.1.13">2.1.13 The <code><nobr>-u</nobr></code> Option: Undefine a Macro</a></h4>
|
||||
<p>The <code><nobr>-u</nobr></code> option undefines a macro that would
|
||||
otherwise have been pre-defined, either automatically or by a
|
||||
<code><nobr>-p</nobr></code> or <code><nobr>-d</nobr></code> option
|
||||
specified earlier on the command lines.
|
||||
<p>For example, the following command line:
|
||||
<p><pre>
|
||||
nasm myfile.asm -dFOO=100 -uFOO
|
||||
</pre>
|
||||
<p>would result in <code><nobr>FOO</nobr></code> <em>not</em> being a
|
||||
predefined macro in the program. This is useful to override options
|
||||
specified at a different point in a Makefile.
|
||||
<p>For Makefile compatibility with many C compilers, this option can also
|
||||
be specified as <code><nobr>-U</nobr></code>.
|
||||
<h4><a name="section-2.1.14">2.1.14 The <code><nobr>-e</nobr></code> Option: Preprocess Only</a></h4>
|
||||
<p>NASM allows the preprocessor to be run on its own, up to a point. Using
|
||||
the <code><nobr>-e</nobr></code> option (which requires no arguments) will
|
||||
cause NASM to preprocess its input file, expand all the macro references,
|
||||
remove all the comments and preprocessor directives, and print the
|
||||
resulting file on standard output (or save it to a file, if the
|
||||
<code><nobr>-o</nobr></code> option is also used).
|
||||
<p>This option cannot be applied to programs which require the preprocessor
|
||||
to evaluate expressions which depend on the values of symbols: so code such
|
||||
as
|
||||
<p><pre>
|
||||
%assign tablesize ($-tablestart)
|
||||
</pre>
|
||||
<p>will cause an error in preprocess-only mode.
|
||||
<h4><a name="section-2.1.15">2.1.15 The <code><nobr>-a</nobr></code> Option: Don't Preprocess At All</a></h4>
|
||||
<p>If NASM is being used as the back end to a compiler, it might be
|
||||
desirable to suppress preprocessing completely and assume the compiler has
|
||||
already done it, to save time and increase compilation speeds. The
|
||||
<code><nobr>-a</nobr></code> option, requiring no argument, instructs NASM
|
||||
to replace its powerful preprocessor with a stub preprocessor which does
|
||||
nothing.
|
||||
<h4><a name="section-2.1.16">2.1.16 The <code><nobr>-On</nobr></code> Option: Specifying Multipass Optimization.</a></h4>
|
||||
<p>NASM defaults to being a two pass assembler. This means that if you have
|
||||
a complex source file which needs more than 2 passes to assemble optimally,
|
||||
you have to enable extra passes.
|
||||
<p>Using the <code><nobr>-O</nobr></code> option, you can tell NASM to
|
||||
carry out multiple passes. The syntax is:
|
||||
<ul>
|
||||
<li><code><nobr>-O0</nobr></code> strict two-pass assembly, JMP and Jcc are
|
||||
handled more like v0.98, except that backward JMPs are short, if possible.
|
||||
Immediate operands take their long forms if a short form is not specified.
|
||||
<li><code><nobr>-O1</nobr></code> strict two-pass assembly, but forward
|
||||
branches are assembled with code guaranteed to reach; may produce larger
|
||||
code than -O0, but will produce successful assembly more often if branch
|
||||
offset sizes are not specified. Additionally, immediate operands which will
|
||||
fit in a signed byte are optimised, unless the long form is specified.
|
||||
<li><code><nobr>-On</nobr></code> multi-pass optimization, minimize branch
|
||||
offsets; also will minimize signed immediate bytes, overriding size
|
||||
specification unless the <code><nobr>strict</nobr></code> keyword has been
|
||||
used (see <a href="nasmdoc3.html#section-3.7">section 3.7</a>). The number
|
||||
specifies the maximum number of passes. The more passes, the better the
|
||||
code, but the slower is the assembly.
|
||||
</ul>
|
||||
<p>Note that this is a capital O, and is different from a small o, which is
|
||||
used to specify the output format. See <a href="#section-2.1.1">section
|
||||
2.1.1</a>.
|
||||
<h4><a name="section-2.1.17">2.1.17 The <code><nobr>-t</nobr></code> option: Enable TASM Compatibility Mode</a></h4>
|
||||
<p>NASM includes a limited form of compatibility with Borland's
|
||||
<code><nobr>TASM</nobr></code>. When NASM's <code><nobr>-t</nobr></code>
|
||||
option is used, the following changes are made:
|
||||
<ul>
|
||||
<li>local labels may be prefixed with <code><nobr>@@</nobr></code> instead
|
||||
of <code><nobr>.</nobr></code>
|
||||
<li>TASM-style response files beginning with <code><nobr>@</nobr></code>
|
||||
may be specified on the command line. This is different from the
|
||||
<code><nobr>-@resp</nobr></code> style that NASM natively supports.
|
||||
<li>size override is supported within brackets. In TASM compatible mode, a
|
||||
size override inside square brackets changes the size of the operand, and
|
||||
not the address type of the operand as it does in NASM syntax. E.g.
|
||||
<code><nobr>mov eax,[DWORD val]</nobr></code> is valid syntax in TASM
|
||||
compatibility mode. Note that you lose the ability to override the default
|
||||
address type for the instruction.
|
||||
<li><code><nobr>%arg</nobr></code> preprocessor directive is supported
|
||||
which is similar to TASM's <code><nobr>ARG</nobr></code> directive.
|
||||
<li><code><nobr>%local</nobr></code> preprocessor directive
|
||||
<li><code><nobr>%stacksize</nobr></code> preprocessor directive
|
||||
<li>unprefixed forms of some directives supported
|
||||
(<code><nobr>arg</nobr></code>, <code><nobr>elif</nobr></code>,
|
||||
<code><nobr>else</nobr></code>, <code><nobr>endif</nobr></code>,
|
||||
<code><nobr>if</nobr></code>, <code><nobr>ifdef</nobr></code>,
|
||||
<code><nobr>ifdifi</nobr></code>, <code><nobr>ifndef</nobr></code>,
|
||||
<code><nobr>include</nobr></code>, <code><nobr>local</nobr></code>)
|
||||
<li>more...
|
||||
</ul>
|
||||
<p>For more information on the directives, see the section on TASM
|
||||
Compatiblity preprocessor directives in
|
||||
<a href="nasmdoc4.html#section-4.9">section 4.9</a>.
|
||||
<h4><a name="section-2.1.18">2.1.18 The <code><nobr>-w</nobr></code> Option: Enable or Disable Assembly Warnings</a></h4>
|
||||
<p>NASM can observe many conditions during the course of assembly which are
|
||||
worth mentioning to the user, but not a sufficiently severe error to
|
||||
justify NASM refusing to generate an output file. These conditions are
|
||||
reported like errors, but come up with the word `warning' before the
|
||||
message. Warnings do not prevent NASM from generating an output file and
|
||||
returning a success status to the operating system.
|
||||
<p>Some conditions are even less severe than that: they are only sometimes
|
||||
worth mentioning to the user. Therefore NASM supports the
|
||||
<code><nobr>-w</nobr></code> command-line option, which enables or disables
|
||||
certain classes of assembly warning. Such warning classes are described by
|
||||
a name, for example <code><nobr>orphan-labels</nobr></code>; you can enable
|
||||
warnings of this class by the command-line option
|
||||
<code><nobr>-w+orphan-labels</nobr></code> and disable it by
|
||||
<code><nobr>-w-orphan-labels</nobr></code>.
|
||||
<p>The suppressible warning classes are:
|
||||
<ul>
|
||||
<li><code><nobr>macro-params</nobr></code> covers warnings about multi-line
|
||||
macros being invoked with the wrong number of parameters. This warning
|
||||
class is enabled by default; see
|
||||
<a href="nasmdoc4.html#section-4.3.1">section 4.3.1</a> for an example of
|
||||
why you might want to disable it.
|
||||
<li><code><nobr>macro-selfref</nobr></code> warns if a macro references
|
||||
itself. This warning class is enabled by default.
|
||||
<li><code><nobr>orphan-labels</nobr></code> covers warnings about source
|
||||
lines which contain no instruction but define a label without a trailing
|
||||
colon. NASM does not warn about this somewhat obscure condition by default;
|
||||
see <a href="nasmdoc3.html#section-3.1">section 3.1</a> for an example of
|
||||
why you might want it to.
|
||||
<li><code><nobr>number-overflow</nobr></code> covers warnings about numeric
|
||||
constants which don't fit in 32 bits (for example, it's easy to type one
|
||||
too many Fs and produce <code><nobr>0x7ffffffff</nobr></code> by mistake).
|
||||
This warning class is enabled by default.
|
||||
<li><code><nobr>gnu-elf-extensions</nobr></code> warns if 8-bit or 16-bit
|
||||
relocations are used in <code><nobr>-f elf</nobr></code> format. The GNU
|
||||
extensions allow this. This warning class is enabled by default.
|
||||
<li>In addition, warning classes may be enabled or disabled across sections
|
||||
of source code with <code><nobr>[warning +warning-name]</nobr></code> or
|
||||
<code><nobr>[warning -warning-name]</nobr></code>. No "user form" (without
|
||||
the brackets) exists.
|
||||
</ul>
|
||||
<h4><a name="section-2.1.19">2.1.19 The <code><nobr>-v</nobr></code> Option: Display Version Info</a></h4>
|
||||
<p>Typing <code><nobr>NASM -v</nobr></code> will display the version of
|
||||
NASM which you are using, and the date on which it was compiled. This
|
||||
replaces the deprecated <code><nobr>-r</nobr></code>.
|
||||
<p>You will need the version number if you report a bug.
|
||||
<h4><a name="section-2.1.20">2.1.20 The <code><nobr>-y</nobr></code> Option: Display Available Debug Info Formats</a></h4>
|
||||
<p>Typing <code><nobr>nasm -f <option> -y</nobr></code> will display
|
||||
a list of the available debug info formats for the given output format. The
|
||||
default format is indicated by an asterisk. E.g.
|
||||
<code><nobr>nasm -f obj -y</nobr></code> yields
|
||||
<code><nobr>* borland</nobr></code>. (as of 0.98.35, the <em>only</em>
|
||||
debug info format implemented).
|
||||
<h4><a name="section-2.1.21">2.1.21 The <code><nobr>--prefix</nobr></code> and <code><nobr>--postfix</nobr></code> Options.</a></h4>
|
||||
<p>The <code><nobr>--prefix</nobr></code> and
|
||||
<code><nobr>--postfix</nobr></code> options prepend or append
|
||||
(respectively) the given argument to all <code><nobr>global</nobr></code>
|
||||
or <code><nobr>extern</nobr></code> variables. E.g.
|
||||
<code><nobr>--prefix_</nobr></code> will prepend the underscore to all
|
||||
global and external variables, as C sometimes (but not always) likes it.
|
||||
<h4><a name="section-2.1.22">2.1.22 The <code><nobr>NASMENV</nobr></code> Environment Variable</a></h4>
|
||||
<p>If you define an environment variable called
|
||||
<code><nobr>NASMENV</nobr></code>, the program will interpret it as a list
|
||||
of extra command-line options, which are processed before the real command
|
||||
line. You can use this to define standard search directories for include
|
||||
files, by putting <code><nobr>-i</nobr></code> options in the
|
||||
<code><nobr>NASMENV</nobr></code> variable.
|
||||
<p>The value of the variable is split up at white space, so that the value
|
||||
<code><nobr>-s -ic:\nasmlib</nobr></code> will be treated as two separate
|
||||
options. However, that means that the value
|
||||
<code><nobr>-dNAME="my name"</nobr></code> won't do what you might want,
|
||||
because it will be split at the space and the NASM command-line processing
|
||||
will get confused by the two nonsensical words
|
||||
<code><nobr>-dNAME="my</nobr></code> and <code><nobr>name"</nobr></code>.
|
||||
<p>To get round this, NASM provides a feature whereby, if you begin the
|
||||
<code><nobr>NASMENV</nobr></code> environment variable with some character
|
||||
that isn't a minus sign, then NASM will treat this character as the
|
||||
separator character for options. So setting the
|
||||
<code><nobr>NASMENV</nobr></code> variable to the value
|
||||
<code><nobr>!-s!-ic:\nasmlib</nobr></code> is equivalent to setting it to
|
||||
<code><nobr>-s -ic:\nasmlib</nobr></code>, but
|
||||
<code><nobr>!-dNAME="my name"</nobr></code> will work.
|
||||
<p>This environment variable was previously called
|
||||
<code><nobr>NASM</nobr></code>. This was changed with version 0.98.31.
|
||||
<h3><a name="section-2.2">2.2 Quick Start for MASM Users</a></h3>
|
||||
<p>If you're used to writing programs with MASM, or with TASM in
|
||||
MASM-compatible (non-Ideal) mode, or with <code><nobr>a86</nobr></code>,
|
||||
this section attempts to outline the major differences between MASM's
|
||||
syntax and NASM's. If you're not already used to MASM, it's probably worth
|
||||
skipping this section.
|
||||
<h4><a name="section-2.2.1">2.2.1 NASM Is Case-Sensitive</a></h4>
|
||||
<p>One simple difference is that NASM is case-sensitive. It makes a
|
||||
difference whether you call your label <code><nobr>foo</nobr></code>,
|
||||
<code><nobr>Foo</nobr></code> or <code><nobr>FOO</nobr></code>. If you're
|
||||
assembling to <code><nobr>DOS</nobr></code> or
|
||||
<code><nobr>OS/2</nobr></code> <code><nobr>.OBJ</nobr></code> files, you
|
||||
can invoke the <code><nobr>UPPERCASE</nobr></code> directive (documented in
|
||||
<a href="nasmdoc6.html#section-6.2">section 6.2</a>) to ensure that all
|
||||
symbols exported to other code modules are forced to be upper case; but
|
||||
even then, <em>within</em> a single module, NASM will distinguish between
|
||||
labels differing only in case.
|
||||
<h4><a name="section-2.2.2">2.2.2 NASM Requires Square Brackets For Memory References</a></h4>
|
||||
<p>NASM was designed with simplicity of syntax in mind. One of the design
|
||||
goals of NASM is that it should be possible, as far as is practical, for
|
||||
the user to look at a single line of NASM code and tell what opcode is
|
||||
generated by it. You can't do this in MASM: if you declare, for example,
|
||||
<p><pre>
|
||||
foo equ 1
|
||||
bar dw 2
|
||||
</pre>
|
||||
<p>then the two lines of code
|
||||
<p><pre>
|
||||
mov ax,foo
|
||||
mov ax,bar
|
||||
</pre>
|
||||
<p>generate completely different opcodes, despite having identical-looking
|
||||
syntaxes.
|
||||
<p>NASM avoids this undesirable situation by having a much simpler syntax
|
||||
for memory references. The rule is simply that any access to the
|
||||
<em>contents</em> of a memory location requires square brackets around the
|
||||
address, and any access to the <em>address</em> of a variable doesn't. So
|
||||
an instruction of the form <code><nobr>mov ax,foo</nobr></code> will
|
||||
<em>always</em> refer to a compile-time constant, whether it's an
|
||||
<code><nobr>EQU</nobr></code> or the address of a variable; and to access
|
||||
the <em>contents</em> of the variable <code><nobr>bar</nobr></code>, you
|
||||
must code <code><nobr>mov ax,[bar]</nobr></code>.
|
||||
<p>This also means that NASM has no need for MASM's
|
||||
<code><nobr>OFFSET</nobr></code> keyword, since the MASM code
|
||||
<code><nobr>mov ax,offset bar</nobr></code> means exactly the same thing as
|
||||
NASM's <code><nobr>mov ax,bar</nobr></code>. If you're trying to get large
|
||||
amounts of MASM code to assemble sensibly under NASM, you can always code
|
||||
<code><nobr>%idefine offset</nobr></code> to make the preprocessor treat
|
||||
the <code><nobr>OFFSET</nobr></code> keyword as a no-op.
|
||||
<p>This issue is even more confusing in <code><nobr>a86</nobr></code>,
|
||||
where declaring a label with a trailing colon defines it to be a `label' as
|
||||
opposed to a `variable' and causes <code><nobr>a86</nobr></code> to adopt
|
||||
NASM-style semantics; so in <code><nobr>a86</nobr></code>,
|
||||
<code><nobr>mov ax,var</nobr></code> has different behaviour depending on
|
||||
whether <code><nobr>var</nobr></code> was declared as
|
||||
<code><nobr>var: dw 0</nobr></code> (a label) or
|
||||
<code><nobr>var dw 0</nobr></code> (a word-size variable). NASM is very
|
||||
simple by comparison: <em>everything</em> is a label.
|
||||
<p>NASM, in the interests of simplicity, also does not support the hybrid
|
||||
syntaxes supported by MASM and its clones, such as
|
||||
<code><nobr>mov ax,table[bx]</nobr></code>, where a memory reference is
|
||||
denoted by one portion outside square brackets and another portion inside.
|
||||
The correct syntax for the above is
|
||||
<code><nobr>mov ax,[table+bx]</nobr></code>. Likewise,
|
||||
<code><nobr>mov ax,es:[di]</nobr></code> is wrong and
|
||||
<code><nobr>mov ax,[es:di]</nobr></code> is right.
|
||||
<h4><a name="section-2.2.3">2.2.3 NASM Doesn't Store Variable Types</a></h4>
|
||||
<p>NASM, by design, chooses not to remember the types of variables you
|
||||
declare. Whereas MASM will remember, on seeing
|
||||
<code><nobr>var dw 0</nobr></code>, that you declared
|
||||
<code><nobr>var</nobr></code> as a word-size variable, and will then be
|
||||
able to fill in the ambiguity in the size of the instruction
|
||||
<code><nobr>mov var,2</nobr></code>, NASM will deliberately remember
|
||||
nothing about the symbol <code><nobr>var</nobr></code> except where it
|
||||
begins, and so you must explicitly code
|
||||
<code><nobr>mov word [var],2</nobr></code>.
|
||||
<p>For this reason, NASM doesn't support the
|
||||
<code><nobr>LODS</nobr></code>, <code><nobr>MOVS</nobr></code>,
|
||||
<code><nobr>STOS</nobr></code>, <code><nobr>SCAS</nobr></code>,
|
||||
<code><nobr>CMPS</nobr></code>, <code><nobr>INS</nobr></code>, or
|
||||
<code><nobr>OUTS</nobr></code> instructions, but only supports the forms
|
||||
such as <code><nobr>LODSB</nobr></code>, <code><nobr>MOVSW</nobr></code>,
|
||||
and <code><nobr>SCASD</nobr></code>, which explicitly specify the size of
|
||||
the components of the strings being manipulated.
|
||||
<h4><a name="section-2.2.4">2.2.4 NASM Doesn't <code><nobr>ASSUME</nobr></code></a></h4>
|
||||
<p>As part of NASM's drive for simplicity, it also does not support the
|
||||
<code><nobr>ASSUME</nobr></code> directive. NASM will not keep track of
|
||||
what values you choose to put in your segment registers, and will never
|
||||
<em>automatically</em> generate a segment override prefix.
|
||||
<h4><a name="section-2.2.5">2.2.5 NASM Doesn't Support Memory Models</a></h4>
|
||||
<p>NASM also does not have any directives to support different 16-bit
|
||||
memory models. The programmer has to keep track of which functions are
|
||||
supposed to be called with a far call and which with a near call, and is
|
||||
responsible for putting the correct form of <code><nobr>RET</nobr></code>
|
||||
instruction (<code><nobr>RETN</nobr></code> or
|
||||
<code><nobr>RETF</nobr></code>; NASM accepts <code><nobr>RET</nobr></code>
|
||||
itself as an alternate form for <code><nobr>RETN</nobr></code>); in
|
||||
addition, the programmer is responsible for coding CALL FAR instructions
|
||||
where necessary when calling <em>external</em> functions, and must also
|
||||
keep track of which external variable definitions are far and which are
|
||||
near.
|
||||
<h4><a name="section-2.2.6">2.2.6 Floating-Point Differences</a></h4>
|
||||
<p>NASM uses different names to refer to floating-point registers from
|
||||
MASM: where MASM would call them <code><nobr>ST(0)</nobr></code>,
|
||||
<code><nobr>ST(1)</nobr></code> and so on, and
|
||||
<code><nobr>a86</nobr></code> would call them simply
|
||||
<code><nobr>0</nobr></code>, <code><nobr>1</nobr></code> and so on, NASM
|
||||
chooses to call them <code><nobr>st0</nobr></code>,
|
||||
<code><nobr>st1</nobr></code> etc.
|
||||
<p>As of version 0.96, NASM now treats the instructions with `nowait' forms
|
||||
in the same way as MASM-compatible assemblers. The idiosyncratic treatment
|
||||
employed by 0.95 and earlier was based on a misunderstanding by the
|
||||
authors.
|
||||
<h4><a name="section-2.2.7">2.2.7 Other Differences</a></h4>
|
||||
<p>For historical reasons, NASM uses the keyword
|
||||
<code><nobr>TWORD</nobr></code> where MASM and compatible assemblers use
|
||||
<code><nobr>TBYTE</nobr></code>.
|
||||
<p>NASM does not declare uninitialised storage in the same way as MASM:
|
||||
where a MASM programmer might use
|
||||
<code><nobr>stack db 64 dup (?)</nobr></code>, NASM requires
|
||||
<code><nobr>stack resb 64</nobr></code>, intended to be read as `reserve 64
|
||||
bytes'. For a limited amount of compatibility, since NASM treats
|
||||
<code><nobr>?</nobr></code> as a valid character in symbol names, you can
|
||||
code <code><nobr>? equ 0</nobr></code> and then writing
|
||||
<code><nobr>dw ?</nobr></code> will at least do something vaguely useful.
|
||||
<code><nobr>DUP</nobr></code> is still not a supported syntax, however.
|
||||
<p>In addition to all of this, macros and directives work completely
|
||||
differently to MASM. See <a href="nasmdoc4.html">chapter 4</a> and
|
||||
<a href="nasmdoc5.html">chapter 5</a> for further details.
|
||||
<p align=center><a href="nasmdoc3.html">Next Chapter</a> |
|
||||
<a href="nasmdoc1.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
</body></html>
|
||||
648
Ref-docs/nasmdoc/html/nasmdoc3.html
Normal file
648
Ref-docs/nasmdoc/html/nasmdoc3.html
Normal file
@@ -0,0 +1,648 @@
|
||||
<html><head><title>NASM Manual</title></head>
|
||||
<body><h1 align=center>The Netwide Assembler: NASM</h1>
|
||||
|
||||
<p align=center><a href="nasmdoc4.html">Next Chapter</a> |
|
||||
<a href="nasmdoc2.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
<h2><a name="chapter-3">Chapter 3: The NASM Language</a></h2>
|
||||
<h3><a name="section-3.1">3.1 Layout of a NASM Source Line</a></h3>
|
||||
<p>Like most assemblers, each NASM source line contains (unless it is a
|
||||
macro, a preprocessor directive or an assembler directive: see
|
||||
<a href="nasmdoc4.html">chapter 4</a> and <a href="nasmdoc5.html">chapter
|
||||
5</a>) some combination of the four fields
|
||||
<p><pre>
|
||||
label: instruction operands ; comment
|
||||
</pre>
|
||||
<p>As usual, most of these fields are optional; the presence or absence of
|
||||
any combination of a label, an instruction and a comment is allowed. Of
|
||||
course, the operand field is either required or forbidden by the presence
|
||||
and nature of the instruction field.
|
||||
<p>NASM uses backslash (\) as the line continuation character; if a line
|
||||
ends with backslash, the next line is considered to be a part of the
|
||||
backslash-ended line.
|
||||
<p>NASM places no restrictions on white space within a line: labels may
|
||||
have white space before them, or instructions may have no space before
|
||||
them, or anything. The colon after a label is also optional. (Note that
|
||||
this means that if you intend to code <code><nobr>lodsb</nobr></code> alone
|
||||
on a line, and type <code><nobr>lodab</nobr></code> by accident, then
|
||||
that's still a valid source line which does nothing but define a label.
|
||||
Running NASM with the command-line option
|
||||
<code><nobr>-w+orphan-labels</nobr></code> will cause it to warn you if you
|
||||
define a label alone on a line without a trailing colon.)
|
||||
<p>Valid characters in labels are letters, numbers,
|
||||
<code><nobr>_</nobr></code>, <code><nobr>$</nobr></code>,
|
||||
<code><nobr>#</nobr></code>, <code><nobr>@</nobr></code>,
|
||||
<code><nobr>~</nobr></code>, <code><nobr>.</nobr></code>, and
|
||||
<code><nobr>?</nobr></code>. The only characters which may be used as the
|
||||
<em>first</em> character of an identifier are letters,
|
||||
<code><nobr>.</nobr></code> (with special meaning: see
|
||||
<a href="#section-3.9">section 3.9</a>), <code><nobr>_</nobr></code> and
|
||||
<code><nobr>?</nobr></code>. An identifier may also be prefixed with a
|
||||
<code><nobr>$</nobr></code> to indicate that it is intended to be read as
|
||||
an identifier and not a reserved word; thus, if some other module you are
|
||||
linking with defines a symbol called <code><nobr>eax</nobr></code>, you can
|
||||
refer to <code><nobr>$eax</nobr></code> in NASM code to distinguish the
|
||||
symbol from the register.
|
||||
<p>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
|
||||
<code><nobr>LOCK</nobr></code>, <code><nobr>REP</nobr></code>,
|
||||
<code><nobr>REPE</nobr></code>/<code><nobr>REPZ</nobr></code> or
|
||||
<code><nobr>REPNE</nobr></code>/<code><nobr>REPNZ</nobr></code>, in the
|
||||
usual way. Explicit address-size and operand-size prefixes
|
||||
<code><nobr>A16</nobr></code>, <code><nobr>A32</nobr></code>,
|
||||
<code><nobr>O16</nobr></code> and <code><nobr>O32</nobr></code> are
|
||||
provided - one example of their use is given in
|
||||
<a href="nasmdoc9.html">chapter 9</a>. You can also use the name of a
|
||||
segment register as an instruction prefix: coding
|
||||
<code><nobr>es mov [bx],ax</nobr></code> is equivalent to coding
|
||||
<code><nobr>mov [es:bx],ax</nobr></code>. We recommend the latter syntax,
|
||||
since it is consistent with other syntactic features of the language, but
|
||||
for instructions such as <code><nobr>LODSB</nobr></code>, which has no
|
||||
operands and yet can require a segment override, there is no clean
|
||||
syntactic way to proceed apart from <code><nobr>es lodsb</nobr></code>.
|
||||
<p>An instruction is not required to use a prefix: prefixes such as
|
||||
<code><nobr>CS</nobr></code>, <code><nobr>A32</nobr></code>,
|
||||
<code><nobr>LOCK</nobr></code> or <code><nobr>REPE</nobr></code> can appear
|
||||
on a line by themselves, and NASM will just generate the prefix bytes.
|
||||
<p>In addition to actual machine instructions, NASM also supports a number
|
||||
of pseudo-instructions, described in <a href="#section-3.2">section
|
||||
3.2</a>.
|
||||
<p>Instruction operands may take a number of forms: they can be registers,
|
||||
described simply by the register name (e.g. <code><nobr>ax</nobr></code>,
|
||||
<code><nobr>bp</nobr></code>, <code><nobr>ebx</nobr></code>,
|
||||
<code><nobr>cr0</nobr></code>: NASM does not use the
|
||||
<code><nobr>gas</nobr></code>-style syntax in which register names must be
|
||||
prefixed by a <code><nobr>%</nobr></code> sign), or they can be effective
|
||||
addresses (see <a href="#section-3.3">section 3.3</a>), constants
|
||||
(<a href="#section-3.4">section 3.4</a>) or expressions
|
||||
(<a href="#section-3.5">section 3.5</a>).
|
||||
<p>For floating-point instructions, NASM accepts a wide range of syntaxes:
|
||||
you can use two-operand forms like MASM supports, or you can use NASM's
|
||||
native single-operand forms in most cases. Details of all forms of each
|
||||
supported instruction are given in <a href="nasmdocb.html">appendix B</a>.
|
||||
For example, you can code:
|
||||
<p><pre>
|
||||
fadd st1 ; this sets st0 := st0 + st1
|
||||
fadd st0,st1 ; so does this
|
||||
|
||||
fadd st1,st0 ; this sets st1 := st1 + st0
|
||||
fadd to st1 ; so does this
|
||||
</pre>
|
||||
<p>Almost any floating-point instruction that references memory must use
|
||||
one of the prefixes <code><nobr>DWORD</nobr></code>,
|
||||
<code><nobr>QWORD</nobr></code> or <code><nobr>TWORD</nobr></code> to
|
||||
indicate what size of memory operand it refers to.
|
||||
<h3><a name="section-3.2">3.2 Pseudo-Instructions</a></h3>
|
||||
<p>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
|
||||
<code><nobr>DB</nobr></code>, <code><nobr>DW</nobr></code>,
|
||||
<code><nobr>DD</nobr></code>, <code><nobr>DQ</nobr></code> and
|
||||
<code><nobr>DT</nobr></code>, their uninitialised counterparts
|
||||
<code><nobr>RESB</nobr></code>, <code><nobr>RESW</nobr></code>,
|
||||
<code><nobr>RESD</nobr></code>, <code><nobr>RESQ</nobr></code> and
|
||||
<code><nobr>REST</nobr></code>, the <code><nobr>INCBIN</nobr></code>
|
||||
command, the <code><nobr>EQU</nobr></code> command, and the
|
||||
<code><nobr>TIMES</nobr></code> prefix.
|
||||
<h4><a name="section-3.2.1">3.2.1 <code><nobr>DB</nobr></code> and friends: Declaring Initialised Data</a></h4>
|
||||
<p><code><nobr>DB</nobr></code>, <code><nobr>DW</nobr></code>,
|
||||
<code><nobr>DD</nobr></code>, <code><nobr>DQ</nobr></code> and
|
||||
<code><nobr>DT</nobr></code> are used, much as in MASM, to declare
|
||||
initialised data in the output file. They can be invoked in a wide range of
|
||||
ways:
|
||||
<p><pre>
|
||||
db 0x55 ; just the byte 0x55
|
||||
db 0x55,0x56,0x57 ; three bytes in succession
|
||||
db 'a',0x55 ; character constants are OK
|
||||
db 'hello',13,10,'$' ; so are string constants
|
||||
dw 0x1234 ; 0x34 0x12
|
||||
dw 'a' ; 0x61 0x00 (it's just a number)
|
||||
dw 'ab' ; 0x61 0x62 (character constant)
|
||||
dw 'abc' ; 0x61 0x62 0x63 0x00 (string)
|
||||
dd 0x12345678 ; 0x78 0x56 0x34 0x12
|
||||
dd 1.234567e20 ; floating-point constant
|
||||
dq 1.234567e20 ; double-precision float
|
||||
dt 1.234567e20 ; extended-precision float
|
||||
</pre>
|
||||
<p><code><nobr>DQ</nobr></code> and <code><nobr>DT</nobr></code> do not
|
||||
accept numeric constants or string constants as operands.
|
||||
<h4><a name="section-3.2.2">3.2.2 <code><nobr>RESB</nobr></code> and friends: Declaring Uninitialised Data</a></h4>
|
||||
<p><code><nobr>RESB</nobr></code>, <code><nobr>RESW</nobr></code>,
|
||||
<code><nobr>RESD</nobr></code>, <code><nobr>RESQ</nobr></code> and
|
||||
<code><nobr>REST</nobr></code> are designed to be used in the BSS section
|
||||
of a module: they declare <em>uninitialised</em> storage space. Each takes
|
||||
a single operand, which is the number of bytes, words, doublewords or
|
||||
whatever to reserve. As stated in
|
||||
<a href="nasmdoc2.html#section-2.2.7">section 2.2.7</a>, NASM does not
|
||||
support the MASM/TASM syntax of reserving uninitialised space by writing
|
||||
<code><nobr>DW ?</nobr></code> or similar things: this is what it does
|
||||
instead. The operand to a <code><nobr>RESB</nobr></code>-type
|
||||
pseudo-instruction is a <em>critical expression</em>: see
|
||||
<a href="#section-3.8">section 3.8</a>.
|
||||
<p>For example:
|
||||
<p><pre>
|
||||
buffer: resb 64 ; reserve 64 bytes
|
||||
wordvar: resw 1 ; reserve a word
|
||||
realarray resq 10 ; array of ten reals
|
||||
</pre>
|
||||
<h4><a name="section-3.2.3">3.2.3 <code><nobr>INCBIN</nobr></code>: Including External Binary Files</a></h4>
|
||||
<p><code><nobr>INCBIN</nobr></code> is borrowed from the old Amiga
|
||||
assembler DevPac: it includes a binary file verbatim into the output file.
|
||||
This can be handy for (for example) including graphics and sound data
|
||||
directly into a game executable file. It can be called in one of these
|
||||
three ways:
|
||||
<p><pre>
|
||||
incbin "file.dat" ; include the whole file
|
||||
incbin "file.dat",1024 ; skip the first 1024 bytes
|
||||
incbin "file.dat",1024,512 ; skip the first 1024, and
|
||||
; actually include at most 512
|
||||
</pre>
|
||||
<h4><a name="section-3.2.4">3.2.4 <code><nobr>EQU</nobr></code>: Defining Constants</a></h4>
|
||||
<p><code><nobr>EQU</nobr></code> defines a symbol to a given constant
|
||||
value: when <code><nobr>EQU</nobr></code> is used, the source line must
|
||||
contain a label. The action of <code><nobr>EQU</nobr></code> is to define
|
||||
the given label name to the value of its (only) operand. This definition is
|
||||
absolute, and cannot change later. So, for example,
|
||||
<p><pre>
|
||||
message db 'hello, world'
|
||||
msglen equ $-message
|
||||
</pre>
|
||||
<p>defines <code><nobr>msglen</nobr></code> to be the constant 12.
|
||||
<code><nobr>msglen</nobr></code> may not then be redefined later. This is
|
||||
not a preprocessor definition either: the value of
|
||||
<code><nobr>msglen</nobr></code> is evaluated <em>once</em>, using the
|
||||
value of <code><nobr>$</nobr></code> (see <a href="#section-3.5">section
|
||||
3.5</a> for an explanation of <code><nobr>$</nobr></code>) at the point of
|
||||
definition, rather than being evaluated wherever it is referenced and using
|
||||
the value of <code><nobr>$</nobr></code> at the point of reference. Note
|
||||
that the operand to an <code><nobr>EQU</nobr></code> is also a critical
|
||||
expression (<a href="#section-3.8">section 3.8</a>).
|
||||
<h4><a name="section-3.2.5">3.2.5 <code><nobr>TIMES</nobr></code>: Repeating Instructions or Data</a></h4>
|
||||
<p>The <code><nobr>TIMES</nobr></code> prefix causes the instruction to be
|
||||
assembled multiple times. This is partly present as NASM's equivalent of
|
||||
the <code><nobr>DUP</nobr></code> syntax supported by MASM-compatible
|
||||
assemblers, in that you can code
|
||||
<p><pre>
|
||||
zerobuf: times 64 db 0
|
||||
</pre>
|
||||
<p>or similar things; but <code><nobr>TIMES</nobr></code> is more versatile
|
||||
than that. The argument to <code><nobr>TIMES</nobr></code> is not just a
|
||||
numeric constant, but a numeric <em>expression</em>, so you can do things
|
||||
like
|
||||
<p><pre>
|
||||
buffer: db 'hello, world'
|
||||
times 64-$+buffer db ' '
|
||||
</pre>
|
||||
<p>which will store exactly enough spaces to make the total length of
|
||||
<code><nobr>buffer</nobr></code> up to 64. Finally,
|
||||
<code><nobr>TIMES</nobr></code> can be applied to ordinary instructions, so
|
||||
you can code trivial unrolled loops in it:
|
||||
<p><pre>
|
||||
times 100 movsb
|
||||
</pre>
|
||||
<p>Note that there is no effective difference between
|
||||
<code><nobr>times 100 resb 1</nobr></code> and
|
||||
<code><nobr>resb 100</nobr></code>, except that the latter will be
|
||||
assembled about 100 times faster due to the internal structure of the
|
||||
assembler.
|
||||
<p>The operand to <code><nobr>TIMES</nobr></code>, like that of
|
||||
<code><nobr>EQU</nobr></code> and those of <code><nobr>RESB</nobr></code>
|
||||
and friends, is a critical expression (<a href="#section-3.8">section
|
||||
3.8</a>).
|
||||
<p>Note also that <code><nobr>TIMES</nobr></code> can't be applied to
|
||||
macros: the reason for this is that <code><nobr>TIMES</nobr></code> is
|
||||
processed after the macro phase, which allows the argument to
|
||||
<code><nobr>TIMES</nobr></code> to contain expressions such as
|
||||
<code><nobr>64-$+buffer</nobr></code> as above. To repeat more than one
|
||||
line of code, or a complex macro, use the preprocessor
|
||||
<code><nobr>%rep</nobr></code> directive.
|
||||
<h3><a name="section-3.3">3.3 Effective Addresses</a></h3>
|
||||
<p>An effective address is any operand to an instruction which references
|
||||
memory. Effective addresses, in NASM, have a very simple syntax: they
|
||||
consist of an expression evaluating to the desired address, enclosed in
|
||||
square brackets. For example:
|
||||
<p><pre>
|
||||
wordvar dw 123
|
||||
mov ax,[wordvar]
|
||||
mov ax,[wordvar+1]
|
||||
mov ax,[es:wordvar+bx]
|
||||
</pre>
|
||||
<p>Anything not conforming to this simple system is not a valid memory
|
||||
reference in NASM, for example <code><nobr>es:wordvar[bx]</nobr></code>.
|
||||
<p>More complicated effective addresses, such as those involving more than
|
||||
one register, work in exactly the same way:
|
||||
<p><pre>
|
||||
mov eax,[ebx*2+ecx+offset]
|
||||
mov ax,[bp+di+8]
|
||||
</pre>
|
||||
<p>NASM is capable of doing algebra on these effective addresses, so that
|
||||
things which don't necessarily <em>look</em> legal are perfectly all right:
|
||||
<p><pre>
|
||||
mov eax,[ebx*5] ; assembles as [ebx*4+ebx]
|
||||
mov eax,[label1*2-label2] ; ie [label1+(label1-label2)]
|
||||
</pre>
|
||||
<p>Some forms of effective address have more than one assembled form; in
|
||||
most such cases NASM will generate the smallest form it can. For example,
|
||||
there are distinct assembled forms for the 32-bit effective addresses
|
||||
<code><nobr>[eax*2+0]</nobr></code> and
|
||||
<code><nobr>[eax+eax]</nobr></code>, and NASM will generally generate the
|
||||
latter on the grounds that the former requires four bytes to store a zero
|
||||
offset.
|
||||
<p>NASM has a hinting mechanism which will cause
|
||||
<code><nobr>[eax+ebx]</nobr></code> and <code><nobr>[ebx+eax]</nobr></code>
|
||||
to generate different opcodes; this is occasionally useful because
|
||||
<code><nobr>[esi+ebp]</nobr></code> and <code><nobr>[ebp+esi]</nobr></code>
|
||||
have different default segment registers.
|
||||
<p>However, you can force NASM to generate an effective address in a
|
||||
particular form by the use of the keywords <code><nobr>BYTE</nobr></code>,
|
||||
<code><nobr>WORD</nobr></code>, <code><nobr>DWORD</nobr></code> and
|
||||
<code><nobr>NOSPLIT</nobr></code>. If you need
|
||||
<code><nobr>[eax+3]</nobr></code> to be assembled using a double-word
|
||||
offset field instead of the one byte NASM will normally generate, you can
|
||||
code <code><nobr>[dword eax+3]</nobr></code>. Similarly, you can force NASM
|
||||
to use a byte offset for a small value which it hasn't seen on the first
|
||||
pass (see <a href="#section-3.8">section 3.8</a> for an example of such a
|
||||
code fragment) by using <code><nobr>[byte eax+offset]</nobr></code>. As
|
||||
special cases, <code><nobr>[byte eax]</nobr></code> will code
|
||||
<code><nobr>[eax+0]</nobr></code> with a byte offset of zero, and
|
||||
<code><nobr>[dword eax]</nobr></code> will code it with a double-word
|
||||
offset of zero. The normal form, <code><nobr>[eax]</nobr></code>, will be
|
||||
coded with no offset field.
|
||||
<p>The form described in the previous paragraph is also useful if you are
|
||||
trying to access data in a 32-bit segment from within 16 bit code. For more
|
||||
information on this see the section on mixed-size addressing
|
||||
(<a href="nasmdoc9.html#section-9.2">section 9.2</a>). In particular, if
|
||||
you need to access data with a known offset that is larger than will fit in
|
||||
a 16-bit value, if you don't specify that it is a dword offset, nasm will
|
||||
cause the high word of the offset to be lost.
|
||||
<p>Similarly, NASM will split <code><nobr>[eax*2]</nobr></code> into
|
||||
<code><nobr>[eax+eax]</nobr></code> because that allows the offset field to
|
||||
be absent and space to be saved; in fact, it will also split
|
||||
<code><nobr>[eax*2+offset]</nobr></code> into
|
||||
<code><nobr>[eax+eax+offset]</nobr></code>. You can combat this behaviour
|
||||
by the use of the <code><nobr>NOSPLIT</nobr></code> keyword:
|
||||
<code><nobr>[nosplit eax*2]</nobr></code> will force
|
||||
<code><nobr>[eax*2+0]</nobr></code> to be generated literally.
|
||||
<h3><a name="section-3.4">3.4 Constants</a></h3>
|
||||
<p>NASM understands four different types of constant: numeric, character,
|
||||
string and floating-point.
|
||||
<h4><a name="section-3.4.1">3.4.1 Numeric Constants</a></h4>
|
||||
<p>A numeric constant is simply a number. NASM allows you to specify
|
||||
numbers in a variety of number bases, in a variety of ways: you can suffix
|
||||
<code><nobr>H</nobr></code>, <code><nobr>Q</nobr></code> or
|
||||
<code><nobr>O</nobr></code>, and <code><nobr>B</nobr></code> for hex, octal
|
||||
and binary, or you can prefix <code><nobr>0x</nobr></code> for hex in the
|
||||
style of C, or you can prefix <code><nobr>$</nobr></code> for hex in the
|
||||
style of Borland Pascal. Note, though, that the <code><nobr>$</nobr></code>
|
||||
prefix does double duty as a prefix on identifiers (see
|
||||
<a href="#section-3.1">section 3.1</a>), so a hex number prefixed with a
|
||||
<code><nobr>$</nobr></code> sign must have a digit after the
|
||||
<code><nobr>$</nobr></code> rather than a letter.
|
||||
<p>Some examples:
|
||||
<p><pre>
|
||||
mov ax,100 ; decimal
|
||||
mov ax,0a2h ; hex
|
||||
mov ax,$0a2 ; hex again: the 0 is required
|
||||
mov ax,0xa2 ; hex yet again
|
||||
mov ax,777q ; octal
|
||||
mov ax,777o ; octal again
|
||||
mov ax,10010011b ; binary
|
||||
</pre>
|
||||
<h4><a name="section-3.4.2">3.4.2 Character Constants</a></h4>
|
||||
<p>A character constant consists of up to four characters enclosed in
|
||||
either single or double quotes. The type of quote makes no difference to
|
||||
NASM, except of course that surrounding the constant with single quotes
|
||||
allows double quotes to appear within it and vice versa.
|
||||
<p>A character constant with more than one character will be arranged with
|
||||
little-endian order in mind: if you code
|
||||
<p><pre>
|
||||
mov eax,'abcd'
|
||||
</pre>
|
||||
<p>then the constant generated is not <code><nobr>0x61626364</nobr></code>,
|
||||
but <code><nobr>0x64636261</nobr></code>, so that if you were then to store
|
||||
the value into memory, it would read <code><nobr>abcd</nobr></code> rather
|
||||
than <code><nobr>dcba</nobr></code>. This is also the sense of character
|
||||
constants understood by the Pentium's <code><nobr>CPUID</nobr></code>
|
||||
instruction (see <a href="nasmdocb.html#section-B.4.34">section
|
||||
B.4.34</a>).
|
||||
<h4><a name="section-3.4.3">3.4.3 String Constants</a></h4>
|
||||
<p>String constants are only acceptable to some pseudo-instructions, namely
|
||||
the <code><nobr>DB</nobr></code> family and
|
||||
<code><nobr>INCBIN</nobr></code>.
|
||||
<p>A string constant looks like a character constant, only longer. It is
|
||||
treated as a concatenation of maximum-size character constants for the
|
||||
conditions. So the following are equivalent:
|
||||
<p><pre>
|
||||
db 'hello' ; string constant
|
||||
db 'h','e','l','l','o' ; equivalent character constants
|
||||
</pre>
|
||||
<p>And the following are also equivalent:
|
||||
<p><pre>
|
||||
dd 'ninechars' ; doubleword string constant
|
||||
dd 'nine','char','s' ; becomes three doublewords
|
||||
db 'ninechars',0,0,0 ; and really looks like this
|
||||
</pre>
|
||||
<p>Note that when used as an operand to <code><nobr>db</nobr></code>, a
|
||||
constant like <code><nobr>'ab'</nobr></code> is treated as a string
|
||||
constant despite being short enough to be a character constant, because
|
||||
otherwise <code><nobr>db 'ab'</nobr></code> would have the same effect as
|
||||
<code><nobr>db 'a'</nobr></code>, which would be silly. Similarly,
|
||||
three-character or four-character constants are treated as strings when
|
||||
they are operands to <code><nobr>dw</nobr></code>.
|
||||
<h4><a name="section-3.4.4">3.4.4 Floating-Point Constants</a></h4>
|
||||
<p>Floating-point constants are acceptable only as arguments to
|
||||
<code><nobr>DD</nobr></code>, <code><nobr>DQ</nobr></code> and
|
||||
<code><nobr>DT</nobr></code>. They are expressed in the traditional form:
|
||||
digits, then a period, then optionally more digits, then optionally an
|
||||
<code><nobr>E</nobr></code> followed by an exponent. The period is
|
||||
mandatory, so that NASM can distinguish between
|
||||
<code><nobr>dd 1</nobr></code>, which declares an integer constant, and
|
||||
<code><nobr>dd 1.0</nobr></code> which declares a floating-point constant.
|
||||
<p>Some examples:
|
||||
<p><pre>
|
||||
dd 1.2 ; an easy one
|
||||
dq 1.e10 ; 10,000,000,000
|
||||
dq 1.e+10 ; synonymous with 1.e10
|
||||
dq 1.e-10 ; 0.000 000 000 1
|
||||
dt 3.141592653589793238462 ; pi
|
||||
</pre>
|
||||
<p>NASM cannot do compile-time arithmetic on floating-point constants. This
|
||||
is because NASM is designed to be portable - although it always generates
|
||||
code to run on x86 processors, the assembler itself can run on any system
|
||||
with an ANSI C compiler. Therefore, the assembler cannot guarantee the
|
||||
presence of a floating-point unit capable of handling the Intel number
|
||||
formats, and so for NASM to be able to do floating arithmetic it would have
|
||||
to include its own complete set of floating-point routines, which would
|
||||
significantly increase the size of the assembler for very little benefit.
|
||||
<h3><a name="section-3.5">3.5 Expressions</a></h3>
|
||||
<p>Expressions in NASM are similar in syntax to those in C.
|
||||
<p>NASM does not guarantee the size of the integers used to evaluate
|
||||
expressions at compile time: since NASM can compile and run on 64-bit
|
||||
systems quite happily, don't assume that expressions are evaluated in
|
||||
32-bit registers and so try to make deliberate use of integer overflow. It
|
||||
might not always work. The only thing NASM will guarantee is what's
|
||||
guaranteed by ANSI C: you always have <em>at least</em> 32 bits to work in.
|
||||
<p>NASM supports two special tokens in expressions, allowing calculations
|
||||
to involve the current assembly position: the <code><nobr>$</nobr></code>
|
||||
and <code><nobr>$$</nobr></code> tokens. <code><nobr>$</nobr></code>
|
||||
evaluates to the assembly position at the beginning of the line containing
|
||||
the expression; so you can code an infinite loop using
|
||||
<code><nobr>JMP $</nobr></code>. <code><nobr>$$</nobr></code> evaluates to
|
||||
the beginning of the current section; so you can tell how far into the
|
||||
section you are by using <code><nobr>($-$$)</nobr></code>.
|
||||
<p>The arithmetic operators provided by NASM are listed here, in increasing
|
||||
order of precedence.
|
||||
<h4><a name="section-3.5.1">3.5.1 <code><nobr>|</nobr></code>: Bitwise OR Operator</a></h4>
|
||||
<p>The <code><nobr>|</nobr></code> operator gives a bitwise OR, exactly as
|
||||
performed by the <code><nobr>OR</nobr></code> machine instruction. Bitwise
|
||||
OR is the lowest-priority arithmetic operator supported by NASM.
|
||||
<h4><a name="section-3.5.2">3.5.2 <code><nobr>^</nobr></code>: Bitwise XOR Operator</a></h4>
|
||||
<p><code><nobr>^</nobr></code> provides the bitwise XOR operation.
|
||||
<h4><a name="section-3.5.3">3.5.3 <code><nobr>&</nobr></code>: Bitwise AND Operator</a></h4>
|
||||
<p><code><nobr>&</nobr></code> provides the bitwise AND operation.
|
||||
<h4><a name="section-3.5.4">3.5.4 <code><nobr><<</nobr></code> and <code><nobr>>></nobr></code>: Bit Shift Operators</a></h4>
|
||||
<p><code><nobr><<</nobr></code> gives a bit-shift to the left, just
|
||||
as it does in C. So <code><nobr>5<<3</nobr></code> evaluates to 5
|
||||
times 8, or 40. <code><nobr>>></nobr></code> gives a bit-shift to the
|
||||
right; in NASM, such a shift is <em>always</em> unsigned, so that the bits
|
||||
shifted in from the left-hand end are filled with zero rather than a
|
||||
sign-extension of the previous highest bit.
|
||||
<h4><a name="section-3.5.5">3.5.5 <code><nobr>+</nobr></code> and <code><nobr>-</nobr></code>: Addition and Subtraction Operators</a></h4>
|
||||
<p>The <code><nobr>+</nobr></code> and <code><nobr>-</nobr></code>
|
||||
operators do perfectly ordinary addition and subtraction.
|
||||
<h4><a name="section-3.5.6">3.5.6 <code><nobr>*</nobr></code>, <code><nobr>/</nobr></code>, <code><nobr>//</nobr></code>, <code><nobr>%</nobr></code> and <code><nobr>%%</nobr></code>: Multiplication and Division</a></h4>
|
||||
<p><code><nobr>*</nobr></code> is the multiplication operator.
|
||||
<code><nobr>/</nobr></code> and <code><nobr>//</nobr></code> are both
|
||||
division operators: <code><nobr>/</nobr></code> is unsigned division and
|
||||
<code><nobr>//</nobr></code> is signed division. Similarly,
|
||||
<code><nobr>%</nobr></code> and <code><nobr>%%</nobr></code> provide
|
||||
unsigned and signed modulo operators respectively.
|
||||
<p>NASM, like ANSI C, provides no guarantees about the sensible operation
|
||||
of the signed modulo operator.
|
||||
<p>Since the <code><nobr>%</nobr></code> character is used extensively by
|
||||
the macro preprocessor, you should ensure that both the signed and unsigned
|
||||
modulo operators are followed by white space wherever they appear.
|
||||
<h4><a name="section-3.5.7">3.5.7 Unary Operators: <code><nobr>+</nobr></code>, <code><nobr>-</nobr></code>, <code><nobr>~</nobr></code> and <code><nobr>SEG</nobr></code></a></h4>
|
||||
<p>The highest-priority operators in NASM's expression grammar are those
|
||||
which only apply to one argument. <code><nobr>-</nobr></code> negates its
|
||||
operand, <code><nobr>+</nobr></code> does nothing (it's provided for
|
||||
symmetry with <code><nobr>-</nobr></code>), <code><nobr>~</nobr></code>
|
||||
computes the one's complement of its operand, and
|
||||
<code><nobr>SEG</nobr></code> provides the segment address of its operand
|
||||
(explained in more detail in <a href="#section-3.6">section 3.6</a>).
|
||||
<h3><a name="section-3.6">3.6 <code><nobr>SEG</nobr></code> and <code><nobr>WRT</nobr></code></a></h3>
|
||||
<p>When writing large 16-bit programs, which must be split into multiple
|
||||
segments, it is often necessary to be able to refer to the segment part of
|
||||
the address of a symbol. NASM supports the <code><nobr>SEG</nobr></code>
|
||||
operator to perform this function.
|
||||
<p>The <code><nobr>SEG</nobr></code> operator returns the
|
||||
<em>preferred</em> segment base of a symbol, defined as the segment base
|
||||
relative to which the offset of the symbol makes sense. So the code
|
||||
<p><pre>
|
||||
mov ax,seg symbol
|
||||
mov es,ax
|
||||
mov bx,symbol
|
||||
</pre>
|
||||
<p>will load <code><nobr>ES:BX</nobr></code> with a valid pointer to the
|
||||
symbol <code><nobr>symbol</nobr></code>.
|
||||
<p>Things can be more complex than this: since 16-bit segments and groups
|
||||
may overlap, you might occasionally want to refer to some symbol using a
|
||||
different segment base from the preferred one. NASM lets you do this, by
|
||||
the use of the <code><nobr>WRT</nobr></code> (With Reference To) keyword.
|
||||
So you can do things like
|
||||
<p><pre>
|
||||
mov ax,weird_seg ; weird_seg is a segment base
|
||||
mov es,ax
|
||||
mov bx,symbol wrt weird_seg
|
||||
</pre>
|
||||
<p>to load <code><nobr>ES:BX</nobr></code> with a different, but
|
||||
functionally equivalent, pointer to the symbol
|
||||
<code><nobr>symbol</nobr></code>.
|
||||
<p>NASM supports far (inter-segment) calls and jumps by means of the syntax
|
||||
<code><nobr>call segment:offset</nobr></code>, where
|
||||
<code><nobr>segment</nobr></code> and <code><nobr>offset</nobr></code> both
|
||||
represent immediate values. So to call a far procedure, you could code
|
||||
either of
|
||||
<p><pre>
|
||||
call (seg procedure):procedure
|
||||
call weird_seg:(procedure wrt weird_seg)
|
||||
</pre>
|
||||
<p>(The parentheses are included for clarity, to show the intended parsing
|
||||
of the above instructions. They are not necessary in practice.)
|
||||
<p>NASM supports the syntax <code><nobr>call far procedure</nobr></code> as
|
||||
a synonym for the first of the above usages. <code><nobr>JMP</nobr></code>
|
||||
works identically to <code><nobr>CALL</nobr></code> in these examples.
|
||||
<p>To declare a far pointer to a data item in a data segment, you must code
|
||||
<p><pre>
|
||||
dw symbol, seg symbol
|
||||
</pre>
|
||||
<p>NASM supports no convenient synonym for this, though you can always
|
||||
invent one using the macro processor.
|
||||
<h3><a name="section-3.7">3.7 <code><nobr>STRICT</nobr></code>: Inhibiting Optimization</a></h3>
|
||||
<p>When assembling with the optimizer set to level 2 or higher (see
|
||||
<a href="nasmdoc2.html#section-2.1.16">section 2.1.16</a>), NASM will use
|
||||
size specifiers (<code><nobr>BYTE</nobr></code>,
|
||||
<code><nobr>WORD</nobr></code>, <code><nobr>DWORD</nobr></code>,
|
||||
<code><nobr>QWORD</nobr></code>, or <code><nobr>TWORD</nobr></code>), but
|
||||
will give them the smallest possible size. The keyword
|
||||
<code><nobr>STRICT</nobr></code> can be used to inhibit optimization and
|
||||
force a particular operand to be emitted in the specified size. For
|
||||
example, with the optimizer on, and in <code><nobr>BITS 16</nobr></code>
|
||||
mode,
|
||||
<p><pre>
|
||||
push dword 33
|
||||
</pre>
|
||||
<p>is encoded in three bytes <code><nobr>66 6A 21</nobr></code>, whereas
|
||||
<p><pre>
|
||||
push strict dword 33
|
||||
</pre>
|
||||
<p>is encoded in six bytes, with a full dword immediate operand
|
||||
<code><nobr>66 68 21 00 00 00</nobr></code>.
|
||||
<p>With the optimizer off, the same code (six bytes) is generated whether
|
||||
the <code><nobr>STRICT</nobr></code> keyword was used or not.
|
||||
<h3><a name="section-3.8">3.8 Critical Expressions</a></h3>
|
||||
<p>A limitation of NASM is that it is a two-pass assembler; unlike TASM and
|
||||
others, it will always do exactly two assembly passes. Therefore it is
|
||||
unable to cope with source files that are complex enough to require three
|
||||
or more passes.
|
||||
<p>The first pass is used to determine the size of all the assembled code
|
||||
and data, so that the second pass, when generating all the code, knows all
|
||||
the symbol addresses the code refers to. So one thing NASM can't handle is
|
||||
code whose size depends on the value of a symbol declared after the code in
|
||||
question. For example,
|
||||
<p><pre>
|
||||
times (label-$) db 0
|
||||
label: db 'Where am I?'
|
||||
</pre>
|
||||
<p>The argument to <code><nobr>TIMES</nobr></code> in this case could
|
||||
equally legally evaluate to anything at all; NASM will reject this example
|
||||
because it cannot tell the size of the <code><nobr>TIMES</nobr></code> line
|
||||
when it first sees it. It will just as firmly reject the slightly
|
||||
paradoxical code
|
||||
<p><pre>
|
||||
times (label-$+1) db 0
|
||||
label: db 'NOW where am I?'
|
||||
</pre>
|
||||
<p>in which <em>any</em> value for the <code><nobr>TIMES</nobr></code>
|
||||
argument is by definition wrong!
|
||||
<p>NASM rejects these examples by means of a concept called a <em>critical
|
||||
expression</em>, which is defined to be an expression whose value is
|
||||
required to be computable in the first pass, and which must therefore
|
||||
depend only on symbols defined before it. The argument to the
|
||||
<code><nobr>TIMES</nobr></code> prefix is a critical expression; for the
|
||||
same reason, the arguments to the <code><nobr>RESB</nobr></code> family of
|
||||
pseudo-instructions are also critical expressions.
|
||||
<p>Critical expressions can crop up in other contexts as well: consider the
|
||||
following code.
|
||||
<p><pre>
|
||||
mov ax,symbol1
|
||||
symbol1 equ symbol2
|
||||
symbol2:
|
||||
</pre>
|
||||
<p>On the first pass, NASM cannot determine the value of
|
||||
<code><nobr>symbol1</nobr></code>, because
|
||||
<code><nobr>symbol1</nobr></code> is defined to be equal to
|
||||
<code><nobr>symbol2</nobr></code> which NASM hasn't seen yet. On the second
|
||||
pass, therefore, when it encounters the line
|
||||
<code><nobr>mov ax,symbol1</nobr></code>, it is unable to generate the code
|
||||
for it because it still doesn't know the value of
|
||||
<code><nobr>symbol1</nobr></code>. On the next line, it would see the
|
||||
<code><nobr>EQU</nobr></code> again and be able to determine the value of
|
||||
<code><nobr>symbol1</nobr></code>, but by then it would be too late.
|
||||
<p>NASM avoids this problem by defining the right-hand side of an
|
||||
<code><nobr>EQU</nobr></code> statement to be a critical expression, so the
|
||||
definition of <code><nobr>symbol1</nobr></code> would be rejected in the
|
||||
first pass.
|
||||
<p>There is a related issue involving forward references: consider this
|
||||
code fragment.
|
||||
<p><pre>
|
||||
mov eax,[ebx+offset]
|
||||
offset equ 10
|
||||
</pre>
|
||||
<p>NASM, on pass one, must calculate the size of the instruction
|
||||
<code><nobr>mov eax,[ebx+offset]</nobr></code> without knowing the value of
|
||||
<code><nobr>offset</nobr></code>. It has no way of knowing that
|
||||
<code><nobr>offset</nobr></code> is small enough to fit into a one-byte
|
||||
offset field and that it could therefore get away with generating a shorter
|
||||
form of the effective-address encoding; for all it knows, in pass one,
|
||||
<code><nobr>offset</nobr></code> could be a symbol in the code segment, and
|
||||
it might need the full four-byte form. So it is forced to compute the size
|
||||
of the instruction to accommodate a four-byte address part. In pass two,
|
||||
having made this decision, it is now forced to honour it and keep the
|
||||
instruction large, so the code generated in this case is not as small as it
|
||||
could have been. This problem can be solved by defining
|
||||
<code><nobr>offset</nobr></code> before using it, or by forcing byte size
|
||||
in the effective address by coding
|
||||
<code><nobr>[byte ebx+offset]</nobr></code>.
|
||||
<p>Note that use of the <code><nobr>-On</nobr></code> switch (with n>=2)
|
||||
makes some of the above no longer true (see
|
||||
<a href="nasmdoc2.html#section-2.1.16">section 2.1.16</a>).
|
||||
<h3><a name="section-3.9">3.9 Local Labels</a></h3>
|
||||
<p>NASM gives special treatment to symbols beginning with a period. A label
|
||||
beginning with a single period is treated as a <em>local</em> label, which
|
||||
means that it is associated with the previous non-local label. So, for
|
||||
example:
|
||||
<p><pre>
|
||||
label1 ; some code
|
||||
|
||||
.loop
|
||||
; some more code
|
||||
|
||||
jne .loop
|
||||
ret
|
||||
|
||||
label2 ; some code
|
||||
|
||||
.loop
|
||||
; some more code
|
||||
|
||||
jne .loop
|
||||
ret
|
||||
</pre>
|
||||
<p>In the above code fragment, each <code><nobr>JNE</nobr></code>
|
||||
instruction jumps to the line immediately before it, because the two
|
||||
definitions of <code><nobr>.loop</nobr></code> are kept separate by virtue
|
||||
of each being associated with the previous non-local label.
|
||||
<p>This form of local label handling is borrowed from the old Amiga
|
||||
assembler DevPac; however, NASM goes one step further, in allowing access
|
||||
to local labels from other parts of the code. This is achieved by means of
|
||||
<em>defining</em> a local label in terms of the previous non-local label:
|
||||
the first definition of <code><nobr>.loop</nobr></code> above is really
|
||||
defining a symbol called <code><nobr>label1.loop</nobr></code>, and the
|
||||
second defines a symbol called <code><nobr>label2.loop</nobr></code>. So,
|
||||
if you really needed to, you could write
|
||||
<p><pre>
|
||||
label3 ; some more code
|
||||
; and some more
|
||||
|
||||
jmp label1.loop
|
||||
</pre>
|
||||
<p>Sometimes it is useful - in a macro, for instance - to be able to define
|
||||
a label which can be referenced from anywhere but which doesn't interfere
|
||||
with the normal local-label mechanism. Such a label can't be non-local
|
||||
because it would interfere with subsequent definitions of, and references
|
||||
to, local labels; and it can't be local because the macro that defined it
|
||||
wouldn't know the label's full name. NASM therefore introduces a third type
|
||||
of label, which is probably only useful in macro definitions: if a label
|
||||
begins with the special prefix <code><nobr>..@</nobr></code>, then it does
|
||||
nothing to the local label mechanism. So you could code
|
||||
<p><pre>
|
||||
label1: ; a non-local label
|
||||
.local: ; this is really label1.local
|
||||
..@foo: ; this is a special symbol
|
||||
label2: ; another non-local label
|
||||
.local: ; this is really label2.local
|
||||
|
||||
jmp ..@foo ; this will jump three lines up
|
||||
</pre>
|
||||
<p>NASM has the capacity to define other special symbols beginning with a
|
||||
double period: for example, <code><nobr>..start</nobr></code> is used to
|
||||
specify the entry point in the <code><nobr>obj</nobr></code> output format
|
||||
(see <a href="nasmdoc6.html#section-6.2.6">section 6.2.6</a>).
|
||||
<p align=center><a href="nasmdoc4.html">Next Chapter</a> |
|
||||
<a href="nasmdoc2.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
</body></html>
|
||||
1558
Ref-docs/nasmdoc/html/nasmdoc4.html
Normal file
1558
Ref-docs/nasmdoc/html/nasmdoc4.html
Normal file
File diff suppressed because it is too large
Load Diff
309
Ref-docs/nasmdoc/html/nasmdoc5.html
Normal file
309
Ref-docs/nasmdoc/html/nasmdoc5.html
Normal file
@@ -0,0 +1,309 @@
|
||||
<html><head><title>NASM Manual</title></head>
|
||||
<body><h1 align=center>The Netwide Assembler: NASM</h1>
|
||||
|
||||
<p align=center><a href="nasmdoc6.html">Next Chapter</a> |
|
||||
<a href="nasmdoc4.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
<h2><a name="chapter-5">Chapter 5: Assembler Directives</a></h2>
|
||||
<p>NASM, though it attempts to avoid the bureaucracy of assemblers like
|
||||
MASM and TASM, is nevertheless forced to support a <em>few</em> directives.
|
||||
These are described in this chapter.
|
||||
<p>NASM's directives come in two types: <em>user-level</em> directives and
|
||||
<em>primitive</em> directives. Typically, each directive has a user-level
|
||||
form and a primitive form. In almost all cases, we recommend that users use
|
||||
the user-level forms of the directives, which are implemented as macros
|
||||
which call the primitive forms.
|
||||
<p>Primitive directives are enclosed in square brackets; user-level
|
||||
directives are not.
|
||||
<p>In addition to the universal directives described in this chapter, each
|
||||
object file format can optionally supply extra directives in order to
|
||||
control particular features of that file format. These
|
||||
<em>format-specific</em> directives are documented along with the formats
|
||||
that implement them, in <a href="nasmdoc6.html">chapter 6</a>.
|
||||
<h3><a name="section-5.1">5.1 <code><nobr>BITS</nobr></code>: Specifying Target Processor Mode</a></h3>
|
||||
<p>The <code><nobr>BITS</nobr></code> directive specifies whether NASM
|
||||
should generate code designed to run on a processor operating in 16-bit
|
||||
mode, or code designed to run on a processor operating in 32-bit mode. The
|
||||
syntax is <code><nobr>BITS 16</nobr></code> or
|
||||
<code><nobr>BITS 32</nobr></code>.
|
||||
<p>In most cases, you should not need to use <code><nobr>BITS</nobr></code>
|
||||
explicitly. The <code><nobr>aout</nobr></code>,
|
||||
<code><nobr>coff</nobr></code>, <code><nobr>elf</nobr></code> and
|
||||
<code><nobr>win32</nobr></code> object formats, which are designed for use
|
||||
in 32-bit operating systems, all cause NASM to select 32-bit mode by
|
||||
default. The <code><nobr>obj</nobr></code> object format allows you to
|
||||
specify each segment you define as either <code><nobr>USE16</nobr></code>
|
||||
or <code><nobr>USE32</nobr></code>, and NASM will set its operating mode
|
||||
accordingly, so the use of the <code><nobr>BITS</nobr></code> directive is
|
||||
once again unnecessary.
|
||||
<p>The most likely reason for using the <code><nobr>BITS</nobr></code>
|
||||
directive is to write 32-bit code in a flat binary file; this is because
|
||||
the <code><nobr>bin</nobr></code> output format defaults to 16-bit mode in
|
||||
anticipation of it being used most frequently to write DOS
|
||||
<code><nobr>.COM</nobr></code> programs, DOS <code><nobr>.SYS</nobr></code>
|
||||
device drivers and boot loader software.
|
||||
<p>You do <em>not</em> need to specify <code><nobr>BITS 32</nobr></code>
|
||||
merely in order to use 32-bit instructions in a 16-bit DOS program; if you
|
||||
do, the assembler will generate incorrect code because it will be writing
|
||||
code targeted at a 32-bit platform, to be run on a 16-bit one.
|
||||
<p>When NASM is in <code><nobr>BITS 16</nobr></code> state, instructions
|
||||
which use 32-bit data are prefixed with an 0x66 byte, and those referring
|
||||
to 32-bit addresses have an 0x67 prefix. In
|
||||
<code><nobr>BITS 32</nobr></code> state, the reverse is true: 32-bit
|
||||
instructions require no prefixes, whereas instructions using 16-bit data
|
||||
need an 0x66 and those working on 16-bit addresses need an 0x67.
|
||||
<p>The <code><nobr>BITS</nobr></code> directive has an exactly equivalent
|
||||
primitive form, <code><nobr>[BITS 16]</nobr></code> and
|
||||
<code><nobr>[BITS 32]</nobr></code>. The user-level form is a macro which
|
||||
has no function other than to call the primitive form.
|
||||
<p>Note that the space is neccessary, <code><nobr>BITS32</nobr></code> will
|
||||
<em>not</em> work!
|
||||
<h4><a name="section-5.1.1">5.1.1 <code><nobr>USE16</nobr></code> & <code><nobr>USE32</nobr></code>: Aliases for BITS</a></h4>
|
||||
<p>The `<code><nobr>USE16</nobr></code>' and
|
||||
`<code><nobr>USE32</nobr></code>' directives can be used in place of
|
||||
`<code><nobr>BITS 16</nobr></code>' and
|
||||
`<code><nobr>BITS 32</nobr></code>', for compatibility with other
|
||||
assemblers.
|
||||
<h3><a name="section-5.2">5.2 <code><nobr>SECTION</nobr></code> or <code><nobr>SEGMENT</nobr></code>: Changing and Defining Sections</a></h3>
|
||||
<p>The <code><nobr>SECTION</nobr></code> directive
|
||||
(<code><nobr>SEGMENT</nobr></code> is an exactly equivalent synonym)
|
||||
changes which section of the output file the code you write will be
|
||||
assembled into. In some object file formats, the number and names of
|
||||
sections are fixed; in others, the user may make up as many as they wish.
|
||||
Hence <code><nobr>SECTION</nobr></code> may sometimes give an error
|
||||
message, or may define a new section, if you try to switch to a section
|
||||
that does not (yet) exist.
|
||||
<p>The Unix object formats, and the <code><nobr>bin</nobr></code> object
|
||||
format (but see <a href="nasmdoc6.html#section-6.1.3">section 6.1.3</a>,
|
||||
all support the standardised section names <code><nobr>.text</nobr></code>,
|
||||
<code><nobr>.data</nobr></code> and <code><nobr>.bss</nobr></code> for the
|
||||
code, data and uninitialised-data sections. The
|
||||
<code><nobr>obj</nobr></code> format, by contrast, does not recognise these
|
||||
section names as being special, and indeed will strip off the leading
|
||||
period of any section name that has one.
|
||||
<h4><a name="section-5.2.1">5.2.1 The <code><nobr>__SECT__</nobr></code> Macro</a></h4>
|
||||
<p>The <code><nobr>SECTION</nobr></code> directive is unusual in that its
|
||||
user-level form functions differently from its primitive form. The
|
||||
primitive form, <code><nobr>[SECTION xyz]</nobr></code>, simply switches
|
||||
the current target section to the one given. The user-level form,
|
||||
<code><nobr>SECTION xyz</nobr></code>, however, first defines the
|
||||
single-line macro <code><nobr>__SECT__</nobr></code> to be the primitive
|
||||
<code><nobr>[SECTION]</nobr></code> directive which it is about to issue,
|
||||
and then issues it. So the user-level directive
|
||||
<p><pre>
|
||||
SECTION .text
|
||||
</pre>
|
||||
<p>expands to the two lines
|
||||
<p><pre>
|
||||
%define __SECT__ [SECTION .text]
|
||||
[SECTION .text]
|
||||
</pre>
|
||||
<p>Users may find it useful to make use of this in their own macros. For
|
||||
example, the <code><nobr>writefile</nobr></code> macro defined in
|
||||
<a href="nasmdoc4.html#section-4.3.3">section 4.3.3</a> can be usefully
|
||||
rewritten in the following more sophisticated form:
|
||||
<p><pre>
|
||||
%macro writefile 2+
|
||||
|
||||
[section .data]
|
||||
|
||||
%%str: db %2
|
||||
%%endstr:
|
||||
|
||||
__SECT__
|
||||
|
||||
mov dx,%%str
|
||||
mov cx,%%endstr-%%str
|
||||
mov bx,%1
|
||||
mov ah,0x40
|
||||
int 0x21
|
||||
|
||||
%endmacro
|
||||
</pre>
|
||||
<p>This form of the macro, once passed a string to output, first switches
|
||||
temporarily to the data section of the file, using the primitive form of
|
||||
the <code><nobr>SECTION</nobr></code> directive so as not to modify
|
||||
<code><nobr>__SECT__</nobr></code>. It then declares its string in the data
|
||||
section, and then invokes <code><nobr>__SECT__</nobr></code> to switch back
|
||||
to <em>whichever</em> section the user was previously working in. It thus
|
||||
avoids the need, in the previous version of the macro, to include a
|
||||
<code><nobr>JMP</nobr></code> instruction to jump over the data, and also
|
||||
does not fail if, in a complicated <code><nobr>OBJ</nobr></code> format
|
||||
module, the user could potentially be assembling the code in any of several
|
||||
separate code sections.
|
||||
<h3><a name="section-5.3">5.3 <code><nobr>ABSOLUTE</nobr></code>: Defining Absolute Labels</a></h3>
|
||||
<p>The <code><nobr>ABSOLUTE</nobr></code> directive can be thought of as an
|
||||
alternative form of <code><nobr>SECTION</nobr></code>: it causes the
|
||||
subsequent code to be directed at no physical section, but at the
|
||||
hypothetical section starting at the given absolute address. The only
|
||||
instructions you can use in this mode are the
|
||||
<code><nobr>RESB</nobr></code> family.
|
||||
<p><code><nobr>ABSOLUTE</nobr></code> is used as follows:
|
||||
<p><pre>
|
||||
absolute 0x1A
|
||||
|
||||
kbuf_chr resw 1
|
||||
kbuf_free resw 1
|
||||
kbuf resw 16
|
||||
</pre>
|
||||
<p>This example describes a section of the PC BIOS data area, at segment
|
||||
address 0x40: the above code defines <code><nobr>kbuf_chr</nobr></code> to
|
||||
be 0x1A, <code><nobr>kbuf_free</nobr></code> to be 0x1C, and
|
||||
<code><nobr>kbuf</nobr></code> to be 0x1E.
|
||||
<p>The user-level form of <code><nobr>ABSOLUTE</nobr></code>, like that of
|
||||
<code><nobr>SECTION</nobr></code>, redefines the
|
||||
<code><nobr>__SECT__</nobr></code> macro when it is invoked.
|
||||
<p><code><nobr>STRUC</nobr></code> and <code><nobr>ENDSTRUC</nobr></code>
|
||||
are defined as macros which use <code><nobr>ABSOLUTE</nobr></code> (and
|
||||
also <code><nobr>__SECT__</nobr></code>).
|
||||
<p><code><nobr>ABSOLUTE</nobr></code> doesn't have to take an absolute
|
||||
constant as an argument: it can take an expression (actually, a critical
|
||||
expression: see <a href="nasmdoc3.html#section-3.8">section 3.8</a>) and it
|
||||
can be a value in a segment. For example, a TSR can re-use its setup code
|
||||
as run-time BSS like this:
|
||||
<p><pre>
|
||||
org 100h ; it's a .COM program
|
||||
|
||||
jmp setup ; setup code comes last
|
||||
|
||||
; the resident part of the TSR goes here
|
||||
setup:
|
||||
; now write the code that installs the TSR here
|
||||
|
||||
absolute setup
|
||||
|
||||
runtimevar1 resw 1
|
||||
runtimevar2 resd 20
|
||||
|
||||
tsr_end:
|
||||
</pre>
|
||||
<p>This defines some variables `on top of' the setup code, so that after
|
||||
the setup has finished running, the space it took up can be re-used as data
|
||||
storage for the running TSR. The symbol `tsr_end' can be used to calculate
|
||||
the total size of the part of the TSR that needs to be made resident.
|
||||
<h3><a name="section-5.4">5.4 <code><nobr>EXTERN</nobr></code>: Importing Symbols from Other Modules</a></h3>
|
||||
<p><code><nobr>EXTERN</nobr></code> is similar to the MASM directive
|
||||
<code><nobr>EXTRN</nobr></code> and the C keyword
|
||||
<code><nobr>extern</nobr></code>: it is used to declare a symbol which is
|
||||
not defined anywhere in the module being assembled, but is assumed to be
|
||||
defined in some other module and needs to be referred to by this one. Not
|
||||
every object-file format can support external variables: the
|
||||
<code><nobr>bin</nobr></code> format cannot.
|
||||
<p>The <code><nobr>EXTERN</nobr></code> directive takes as many arguments
|
||||
as you like. Each argument is the name of a symbol:
|
||||
<p><pre>
|
||||
extern _printf
|
||||
extern _sscanf,_fscanf
|
||||
</pre>
|
||||
<p>Some object-file formats provide extra features to the
|
||||
<code><nobr>EXTERN</nobr></code> directive. In all cases, the extra
|
||||
features are used by suffixing a colon to the symbol name followed by
|
||||
object-format specific text. For example, the <code><nobr>obj</nobr></code>
|
||||
format allows you to declare that the default segment base of an external
|
||||
should be the group <code><nobr>dgroup</nobr></code> by means of the
|
||||
directive
|
||||
<p><pre>
|
||||
extern _variable:wrt dgroup
|
||||
</pre>
|
||||
<p>The primitive form of <code><nobr>EXTERN</nobr></code> differs from the
|
||||
user-level form only in that it can take only one argument at a time: the
|
||||
support for multiple arguments is implemented at the preprocessor level.
|
||||
<p>You can declare the same variable as <code><nobr>EXTERN</nobr></code>
|
||||
more than once: NASM will quietly ignore the second and later
|
||||
redeclarations. You can't declare a variable as
|
||||
<code><nobr>EXTERN</nobr></code> as well as something else, though.
|
||||
<h3><a name="section-5.5">5.5 <code><nobr>GLOBAL</nobr></code>: Exporting Symbols to Other Modules</a></h3>
|
||||
<p><code><nobr>GLOBAL</nobr></code> is the other end of
|
||||
<code><nobr>EXTERN</nobr></code>: if one module declares a symbol as
|
||||
<code><nobr>EXTERN</nobr></code> and refers to it, then in order to prevent
|
||||
linker errors, some other module must actually <em>define</em> the symbol
|
||||
and declare it as <code><nobr>GLOBAL</nobr></code>. Some assemblers use the
|
||||
name <code><nobr>PUBLIC</nobr></code> for this purpose.
|
||||
<p>The <code><nobr>GLOBAL</nobr></code> directive applying to a symbol must
|
||||
appear <em>before</em> the definition of the symbol.
|
||||
<p><code><nobr>GLOBAL</nobr></code> uses the same syntax as
|
||||
<code><nobr>EXTERN</nobr></code>, except that it must refer to symbols
|
||||
which <em>are</em> defined in the same module as the
|
||||
<code><nobr>GLOBAL</nobr></code> directive. For example:
|
||||
<p><pre>
|
||||
global _main
|
||||
_main:
|
||||
; some code
|
||||
</pre>
|
||||
<p><code><nobr>GLOBAL</nobr></code>, like <code><nobr>EXTERN</nobr></code>,
|
||||
allows object formats to define private extensions by means of a colon. The
|
||||
<code><nobr>elf</nobr></code> object format, for example, lets you specify
|
||||
whether global data items are functions or data:
|
||||
<p><pre>
|
||||
global hashlookup:function, hashtable:data
|
||||
</pre>
|
||||
<p>Like <code><nobr>EXTERN</nobr></code>, the primitive form of
|
||||
<code><nobr>GLOBAL</nobr></code> differs from the user-level form only in
|
||||
that it can take only one argument at a time.
|
||||
<h3><a name="section-5.6">5.6 <code><nobr>COMMON</nobr></code>: Defining Common Data Areas</a></h3>
|
||||
<p>The <code><nobr>COMMON</nobr></code> directive is used to declare
|
||||
<em>common variables</em>. A common variable is much like a global variable
|
||||
declared in the uninitialised data section, so that
|
||||
<p><pre>
|
||||
common intvar 4
|
||||
</pre>
|
||||
<p>is similar in function to
|
||||
<p><pre>
|
||||
global intvar
|
||||
section .bss
|
||||
|
||||
intvar resd 1
|
||||
</pre>
|
||||
<p>The difference is that if more than one module defines the same common
|
||||
variable, then at link time those variables will be <em>merged</em>, and
|
||||
references to <code><nobr>intvar</nobr></code> in all modules will point at
|
||||
the same piece of memory.
|
||||
<p>Like <code><nobr>GLOBAL</nobr></code> and
|
||||
<code><nobr>EXTERN</nobr></code>, <code><nobr>COMMON</nobr></code> supports
|
||||
object-format specific extensions. For example, the
|
||||
<code><nobr>obj</nobr></code> format allows common variables to be NEAR or
|
||||
FAR, and the <code><nobr>elf</nobr></code> format allows you to specify the
|
||||
alignment requirements of a common variable:
|
||||
<p><pre>
|
||||
common commvar 4:near ; works in OBJ
|
||||
common intarray 100:4 ; works in ELF: 4 byte aligned
|
||||
</pre>
|
||||
<p>Once again, like <code><nobr>EXTERN</nobr></code> and
|
||||
<code><nobr>GLOBAL</nobr></code>, the primitive form of
|
||||
<code><nobr>COMMON</nobr></code> differs from the user-level form only in
|
||||
that it can take only one argument at a time.
|
||||
<h3><a name="section-5.7">5.7 <code><nobr>CPU</nobr></code>: Defining CPU Dependencies</a></h3>
|
||||
<p>The <code><nobr>CPU</nobr></code> directive restricts assembly to those
|
||||
instructions which are available on the specified CPU.
|
||||
<p>Options are:
|
||||
<ul>
|
||||
<li><code><nobr>CPU 8086</nobr></code> Assemble only 8086 instruction set
|
||||
<li><code><nobr>CPU 186</nobr></code> Assemble instructions up to the 80186
|
||||
instruction set
|
||||
<li><code><nobr>CPU 286</nobr></code> Assemble instructions up to the 286
|
||||
instruction set
|
||||
<li><code><nobr>CPU 386</nobr></code> Assemble instructions up to the 386
|
||||
instruction set
|
||||
<li><code><nobr>CPU 486</nobr></code> 486 instruction set
|
||||
<li><code><nobr>CPU 586</nobr></code> Pentium instruction set
|
||||
<li><code><nobr>CPU PENTIUM</nobr></code> Same as 586
|
||||
<li><code><nobr>CPU 686</nobr></code> P6 instruction set
|
||||
<li><code><nobr>CPU PPRO</nobr></code> Same as 686
|
||||
<li><code><nobr>CPU P2</nobr></code> Same as 686
|
||||
<li><code><nobr>CPU P3</nobr></code> Pentium III (Katmai) instruction sets
|
||||
<li><code><nobr>CPU KATMAI</nobr></code> Same as P3
|
||||
<li><code><nobr>CPU P4</nobr></code> Pentium 4 (Willamette) instruction set
|
||||
<li><code><nobr>CPU WILLAMETTE</nobr></code> Same as P4
|
||||
<li><code><nobr>CPU PRESCOTT</nobr></code> Prescott instruction set
|
||||
<li><code><nobr>CPU IA64</nobr></code> IA64 CPU (in x86 mode) instruction
|
||||
set
|
||||
</ul>
|
||||
<p>All options are case insensitive. All instructions will be selected only
|
||||
if they apply to the selected CPU or lower. By default, all instructions
|
||||
are available.
|
||||
<p align=center><a href="nasmdoc6.html">Next Chapter</a> |
|
||||
<a href="nasmdoc4.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
</body></html>
|
||||
837
Ref-docs/nasmdoc/html/nasmdoc6.html
Normal file
837
Ref-docs/nasmdoc/html/nasmdoc6.html
Normal file
@@ -0,0 +1,837 @@
|
||||
<html><head><title>NASM Manual</title></head>
|
||||
<body><h1 align=center>The Netwide Assembler: NASM</h1>
|
||||
|
||||
<p align=center><a href="nasmdoc7.html">Next Chapter</a> |
|
||||
<a href="nasmdoc5.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
<h2><a name="chapter-6">Chapter 6: Output Formats</a></h2>
|
||||
<p>NASM is a portable assembler, designed to be able to compile on any ANSI
|
||||
C-supporting platform and produce output to run on a variety of Intel x86
|
||||
operating systems. For this reason, it has a large number of available
|
||||
output formats, selected using the <code><nobr>-f</nobr></code> option on
|
||||
the NASM command line. Each of these formats, along with its extensions to
|
||||
the base NASM syntax, is detailed in this chapter.
|
||||
<p>As stated in <a href="nasmdoc2.html#section-2.1.1">section 2.1.1</a>,
|
||||
NASM chooses a default name for your output file based on the input file
|
||||
name and the chosen output format. This will be generated by removing the
|
||||
extension (<code><nobr>.asm</nobr></code>, <code><nobr>.s</nobr></code>, or
|
||||
whatever you like to use) from the input file name, and substituting an
|
||||
extension defined by the output format. The extensions are given with each
|
||||
format below.
|
||||
<h3><a name="section-6.1">6.1 <code><nobr>bin</nobr></code>: Flat-Form Binary Output</a></h3>
|
||||
<p>The <code><nobr>bin</nobr></code> format does not produce object files:
|
||||
it generates nothing in the output file except the code you wrote. Such
|
||||
`pure binary' files are used by MS-DOS: <code><nobr>.COM</nobr></code>
|
||||
executables and <code><nobr>.SYS</nobr></code> device drivers are pure
|
||||
binary files. Pure binary output is also useful for operating system and
|
||||
boot loader development.
|
||||
<p>The <code><nobr>bin</nobr></code> format supports multiple section
|
||||
names. For details of how nasm handles sections in the
|
||||
<code><nobr>bin</nobr></code> format, see <a href="#section-6.1.3">section
|
||||
6.1.3</a>.
|
||||
<p>Using the <code><nobr>bin</nobr></code> format puts NASM by default into
|
||||
16-bit mode (see <a href="nasmdoc5.html#section-5.1">section 5.1</a>). In
|
||||
order to use <code><nobr>bin</nobr></code> to write 32-bit code such as an
|
||||
OS kernel, you need to explicitly issue the
|
||||
<code><nobr>BITS 32</nobr></code> directive.
|
||||
<p><code><nobr>bin</nobr></code> has no default output file name extension:
|
||||
instead, it leaves your file name as it is once the original extension has
|
||||
been removed. Thus, the default is for NASM to assemble
|
||||
<code><nobr>binprog.asm</nobr></code> into a binary file called
|
||||
<code><nobr>binprog</nobr></code>.
|
||||
<h4><a name="section-6.1.1">6.1.1 <code><nobr>ORG</nobr></code>: Binary File Program Origin</a></h4>
|
||||
<p>The <code><nobr>bin</nobr></code> format provides an additional
|
||||
directive to the list given in <a href="nasmdoc5.html">chapter 5</a>:
|
||||
<code><nobr>ORG</nobr></code>. The function of the
|
||||
<code><nobr>ORG</nobr></code> directive is to specify the origin address
|
||||
which NASM will assume the program begins at when it is loaded into memory.
|
||||
<p>For example, the following code will generate the longword
|
||||
<code><nobr>0x00000104</nobr></code>:
|
||||
<p><pre>
|
||||
org 0x100
|
||||
dd label
|
||||
label:
|
||||
</pre>
|
||||
<p>Unlike the <code><nobr>ORG</nobr></code> directive provided by
|
||||
MASM-compatible assemblers, which allows you to jump around in the object
|
||||
file and overwrite code you have already generated, NASM's
|
||||
<code><nobr>ORG</nobr></code> does exactly what the directive says:
|
||||
<em>origin</em>. Its sole function is to specify one offset which is added
|
||||
to all internal address references within the section; it does not permit
|
||||
any of the trickery that MASM's version does. See
|
||||
<a href="nasmdo10.html#section-10.1.3">section 10.1.3</a> for further
|
||||
comments.
|
||||
<h4><a name="section-6.1.2">6.1.2 <code><nobr>bin</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a></h4>
|
||||
<p>The <code><nobr>bin</nobr></code> output format extends the
|
||||
<code><nobr>SECTION</nobr></code> (or <code><nobr>SEGMENT</nobr></code>)
|
||||
directive to allow you to specify the alignment requirements of segments.
|
||||
This is done by appending the <code><nobr>ALIGN</nobr></code> qualifier to
|
||||
the end of the section-definition line. For example,
|
||||
<p><pre>
|
||||
section .data align=16
|
||||
</pre>
|
||||
<p>switches to the section <code><nobr>.data</nobr></code> and also
|
||||
specifies that it must be aligned on a 16-byte boundary.
|
||||
<p>The parameter to <code><nobr>ALIGN</nobr></code> specifies how many low
|
||||
bits of the section start address must be forced to zero. The alignment
|
||||
value given may be any power of two.
|
||||
<h4><a name="section-6.1.3">6.1.3 <code><nobr>Multisection</nobr></code> support for the BIN format.</a></h4>
|
||||
<p>The <code><nobr>bin</nobr></code> format allows the use of multiple
|
||||
sections, of arbitrary names, besides the "known"
|
||||
<code><nobr>.text</nobr></code>, <code><nobr>.data</nobr></code>, and
|
||||
<code><nobr>.bss</nobr></code> names.
|
||||
<ul>
|
||||
<li>Sections may be designated <code><nobr>progbits</nobr></code> or
|
||||
<code><nobr>nobits</nobr></code>. Default is
|
||||
<code><nobr>progbits</nobr></code> (except <code><nobr>.bss</nobr></code>,
|
||||
which defaults to <code><nobr>nobits</nobr></code>, of course).
|
||||
<li>Sections can be aligned at a specified boundary following the previous
|
||||
section with <code><nobr>align=</nobr></code>, or at an arbitrary
|
||||
byte-granular position with <code><nobr>start=</nobr></code>.
|
||||
<li>Sections can be given a virtual start address, which will be used for
|
||||
the calculation of all memory references within that section with
|
||||
<code><nobr>vstart=</nobr></code>.
|
||||
<li>Sections can be ordered using
|
||||
<code><nobr>follows=</nobr></code><code><nobr><section></nobr></code>
|
||||
or
|
||||
<code><nobr>vfollows=</nobr></code><code><nobr><section></nobr></code>
|
||||
as an alternative to specifying an explicit start address.
|
||||
<li>Arguments to <code><nobr>org</nobr></code>,
|
||||
<code><nobr>start</nobr></code>, <code><nobr>vstart</nobr></code>, and
|
||||
<code><nobr>align=</nobr></code> are critical expressions. See
|
||||
<a href="nasmdoc3.html#section-3.8">section 3.8</a>. E.g.
|
||||
<code><nobr>align=(1 << ALIGN_SHIFT)</nobr></code> -
|
||||
<code><nobr>ALIGN_SHIFT</nobr></code> must be defined before it is used
|
||||
here.
|
||||
<li>Any code which comes before an explicit
|
||||
<code><nobr>SECTION</nobr></code> directive is directed by default into the
|
||||
<code><nobr>.text</nobr></code> section.
|
||||
<li>If an <code><nobr>ORG</nobr></code> statement is not given,
|
||||
<code><nobr>ORG 0</nobr></code> is used by default.
|
||||
<li>The <code><nobr>.bss</nobr></code> section will be placed after the
|
||||
last <code><nobr>progbits</nobr></code> section, unless
|
||||
<code><nobr>start=</nobr></code>, <code><nobr>vstart=</nobr></code>,
|
||||
<code><nobr>follows=</nobr></code>, or <code><nobr>vfollows=</nobr></code>
|
||||
has been specified.
|
||||
<li>All sections are aligned on dword boundaries, unless a different
|
||||
alignment has been specified.
|
||||
<li>Sections may not overlap.
|
||||
<li>Nasm creates the
|
||||
<code><nobr>section.<secname>.start</nobr></code> for each section,
|
||||
which may be used in your code.
|
||||
</ul>
|
||||
<h4><a name="section-6.1.4">6.1.4 Map files</a></h4>
|
||||
<p>Map files can be generated in <code><nobr>-f bin</nobr></code> format by
|
||||
means of the <code><nobr>[map]</nobr></code> option. Map types of
|
||||
<code><nobr>all</nobr></code> (default), <code><nobr>brief</nobr></code>,
|
||||
<code><nobr>sections</nobr></code>, <code><nobr>segments</nobr></code>, or
|
||||
<code><nobr>symbols</nobr></code> may be specified. Output may be directed
|
||||
to <code><nobr>stdout</nobr></code> (default),
|
||||
<code><nobr>stderr</nobr></code>, or a specified file. E.g.
|
||||
<code><nobr>[map symbols myfile.map]</nobr></code>. No "user form" exists,
|
||||
the square brackets must be used.
|
||||
<h3><a name="section-6.2">6.2 <code><nobr>obj</nobr></code>: Microsoft OMF Object Files</a></h3>
|
||||
<p>The <code><nobr>obj</nobr></code> file format (NASM calls it
|
||||
<code><nobr>obj</nobr></code> rather than <code><nobr>omf</nobr></code> for
|
||||
historical reasons) is the one produced by MASM and TASM, which is
|
||||
typically fed to 16-bit DOS linkers to produce
|
||||
<code><nobr>.EXE</nobr></code> files. It is also the format used by OS/2.
|
||||
<p><code><nobr>obj</nobr></code> provides a default output file-name
|
||||
extension of <code><nobr>.obj</nobr></code>.
|
||||
<p><code><nobr>obj</nobr></code> is not exclusively a 16-bit format,
|
||||
though: NASM has full support for the 32-bit extensions to the format. In
|
||||
particular, 32-bit <code><nobr>obj</nobr></code> format files are used by
|
||||
Borland's Win32 compilers, instead of using Microsoft's newer
|
||||
<code><nobr>win32</nobr></code> object file format.
|
||||
<p>The <code><nobr>obj</nobr></code> format does not define any special
|
||||
segment names: you can call your segments anything you like. Typical names
|
||||
for segments in <code><nobr>obj</nobr></code> format files are
|
||||
<code><nobr>CODE</nobr></code>, <code><nobr>DATA</nobr></code> and
|
||||
<code><nobr>BSS</nobr></code>.
|
||||
<p>If your source file contains code before specifying an explicit
|
||||
<code><nobr>SEGMENT</nobr></code> directive, then NASM will invent its own
|
||||
segment called <code><nobr>__NASMDEFSEG</nobr></code> for you.
|
||||
<p>When you define a segment in an <code><nobr>obj</nobr></code> file, NASM
|
||||
defines the segment name as a symbol as well, so that you can access the
|
||||
segment address of the segment. So, for example:
|
||||
<p><pre>
|
||||
segment data
|
||||
|
||||
dvar: dw 1234
|
||||
|
||||
segment code
|
||||
|
||||
function:
|
||||
mov ax,data ; get segment address of data
|
||||
mov ds,ax ; and move it into DS
|
||||
inc word [dvar] ; now this reference will work
|
||||
ret
|
||||
</pre>
|
||||
<p>The <code><nobr>obj</nobr></code> format also enables the use of the
|
||||
<code><nobr>SEG</nobr></code> and <code><nobr>WRT</nobr></code> operators,
|
||||
so that you can write code which does things like
|
||||
<p><pre>
|
||||
extern foo
|
||||
|
||||
mov ax,seg foo ; get preferred segment of foo
|
||||
mov ds,ax
|
||||
mov ax,data ; a different segment
|
||||
mov es,ax
|
||||
mov ax,[ds:foo] ; this accesses `foo'
|
||||
mov [es:foo wrt data],bx ; so does this
|
||||
</pre>
|
||||
<h4><a name="section-6.2.1">6.2.1 <code><nobr>obj</nobr></code> Extensions to the <code><nobr>SEGMENT</nobr></code> Directive</a></h4>
|
||||
<p>The <code><nobr>obj</nobr></code> output format extends the
|
||||
<code><nobr>SEGMENT</nobr></code> (or <code><nobr>SECTION</nobr></code>)
|
||||
directive to allow you to specify various properties of the segment you are
|
||||
defining. This is done by appending extra qualifiers to the end of the
|
||||
segment-definition line. For example,
|
||||
<p><pre>
|
||||
segment code private align=16
|
||||
</pre>
|
||||
<p>defines the segment <code><nobr>code</nobr></code>, but also declares it
|
||||
to be a private segment, and requires that the portion of it described in
|
||||
this code module must be aligned on a 16-byte boundary.
|
||||
<p>The available qualifiers are:
|
||||
<ul>
|
||||
<li><code><nobr>PRIVATE</nobr></code>, <code><nobr>PUBLIC</nobr></code>,
|
||||
<code><nobr>COMMON</nobr></code> and <code><nobr>STACK</nobr></code>
|
||||
specify the combination characteristics of the segment.
|
||||
<code><nobr>PRIVATE</nobr></code> segments do not get combined with any
|
||||
others by the linker; <code><nobr>PUBLIC</nobr></code> and
|
||||
<code><nobr>STACK</nobr></code> segments get concatenated together at link
|
||||
time; and <code><nobr>COMMON</nobr></code> segments all get overlaid on top
|
||||
of each other rather than stuck end-to-end.
|
||||
<li><code><nobr>ALIGN</nobr></code> is used, as shown above, to specify how
|
||||
many low bits of the segment start address must be forced to zero. The
|
||||
alignment value given may be any power of two from 1 to 4096; in reality,
|
||||
the only values supported are 1, 2, 4, 16, 256 and 4096, so if 8 is
|
||||
specified it will be rounded up to 16, and 32, 64 and 128 will all be
|
||||
rounded up to 256, and so on. Note that alignment to 4096-byte boundaries
|
||||
is a PharLap extension to the format and may not be supported by all
|
||||
linkers.
|
||||
<li><code><nobr>CLASS</nobr></code> can be used to specify the segment
|
||||
class; this feature indicates to the linker that segments of the same class
|
||||
should be placed near each other in the output file. The class name can be
|
||||
any word, e.g. <code><nobr>CLASS=CODE</nobr></code>.
|
||||
<li><code><nobr>OVERLAY</nobr></code>, like
|
||||
<code><nobr>CLASS</nobr></code>, is specified with an arbitrary word as an
|
||||
argument, and provides overlay information to an overlay-capable linker.
|
||||
<li>Segments can be declared as <code><nobr>USE16</nobr></code> or
|
||||
<code><nobr>USE32</nobr></code>, which has the effect of recording the
|
||||
choice in the object file and also ensuring that NASM's default assembly
|
||||
mode when assembling in that segment is 16-bit or 32-bit respectively.
|
||||
<li>When writing OS/2 object files, you should declare 32-bit segments as
|
||||
<code><nobr>FLAT</nobr></code>, which causes the default segment base for
|
||||
anything in the segment to be the special group
|
||||
<code><nobr>FLAT</nobr></code>, and also defines the group if it is not
|
||||
already defined.
|
||||
<li>The <code><nobr>obj</nobr></code> file format also allows segments to
|
||||
be declared as having a pre-defined absolute segment address, although no
|
||||
linkers are currently known to make sensible use of this feature;
|
||||
nevertheless, NASM allows you to declare a segment such as
|
||||
<code><nobr>SEGMENT SCREEN ABSOLUTE=0xB800</nobr></code> if you need to.
|
||||
The <code><nobr>ABSOLUTE</nobr></code> and <code><nobr>ALIGN</nobr></code>
|
||||
keywords are mutually exclusive.
|
||||
</ul>
|
||||
<p>NASM's default segment attributes are <code><nobr>PUBLIC</nobr></code>,
|
||||
<code><nobr>ALIGN=1</nobr></code>, no class, no overlay, and
|
||||
<code><nobr>USE16</nobr></code>.
|
||||
<h4><a name="section-6.2.2">6.2.2 <code><nobr>GROUP</nobr></code>: Defining Groups of Segments</a></h4>
|
||||
<p>The <code><nobr>obj</nobr></code> format also allows segments to be
|
||||
grouped, so that a single segment register can be used to refer to all the
|
||||
segments in a group. NASM therefore supplies the
|
||||
<code><nobr>GROUP</nobr></code> directive, whereby you can code
|
||||
<p><pre>
|
||||
segment data
|
||||
|
||||
; some data
|
||||
|
||||
segment bss
|
||||
|
||||
; some uninitialised data
|
||||
|
||||
group dgroup data bss
|
||||
</pre>
|
||||
<p>which will define a group called <code><nobr>dgroup</nobr></code> to
|
||||
contain the segments <code><nobr>data</nobr></code> and
|
||||
<code><nobr>bss</nobr></code>. Like <code><nobr>SEGMENT</nobr></code>,
|
||||
<code><nobr>GROUP</nobr></code> causes the group name to be defined as a
|
||||
symbol, so that you can refer to a variable <code><nobr>var</nobr></code>
|
||||
in the <code><nobr>data</nobr></code> segment as
|
||||
<code><nobr>var wrt data</nobr></code> or as
|
||||
<code><nobr>var wrt dgroup</nobr></code>, depending on which segment value
|
||||
is currently in your segment register.
|
||||
<p>If you just refer to <code><nobr>var</nobr></code>, however, and
|
||||
<code><nobr>var</nobr></code> is declared in a segment which is part of a
|
||||
group, then NASM will default to giving you the offset of
|
||||
<code><nobr>var</nobr></code> from the beginning of the <em>group</em>, not
|
||||
the <em>segment</em>. Therefore <code><nobr>SEG var</nobr></code>, also,
|
||||
will return the group base rather than the segment base.
|
||||
<p>NASM will allow a segment to be part of more than one group, but will
|
||||
generate a warning if you do this. Variables declared in a segment which is
|
||||
part of more than one group will default to being relative to the first
|
||||
group that was defined to contain the segment.
|
||||
<p>A group does not have to contain any segments; you can still make
|
||||
<code><nobr>WRT</nobr></code> references to a group which does not contain
|
||||
the variable you are referring to. OS/2, for example, defines the special
|
||||
group <code><nobr>FLAT</nobr></code> with no segments in it.
|
||||
<h4><a name="section-6.2.3">6.2.3 <code><nobr>UPPERCASE</nobr></code>: Disabling Case Sensitivity in Output</a></h4>
|
||||
<p>Although NASM itself is case sensitive, some OMF linkers are not;
|
||||
therefore it can be useful for NASM to output single-case object files. The
|
||||
<code><nobr>UPPERCASE</nobr></code> format-specific directive causes all
|
||||
segment, group and symbol names that are written to the object file to be
|
||||
forced to upper case just before being written. Within a source file, NASM
|
||||
is still case-sensitive; but the object file can be written entirely in
|
||||
upper case if desired.
|
||||
<p><code><nobr>UPPERCASE</nobr></code> is used alone on a line; it requires
|
||||
no parameters.
|
||||
<h4><a name="section-6.2.4">6.2.4 <code><nobr>IMPORT</nobr></code>: Importing DLL Symbols</a></h4>
|
||||
<p>The <code><nobr>IMPORT</nobr></code> format-specific directive defines a
|
||||
symbol to be imported from a DLL, for use if you are writing a DLL's import
|
||||
library in NASM. You still need to declare the symbol as
|
||||
<code><nobr>EXTERN</nobr></code> as well as using the
|
||||
<code><nobr>IMPORT</nobr></code> directive.
|
||||
<p>The <code><nobr>IMPORT</nobr></code> directive takes two required
|
||||
parameters, separated by white space, which are (respectively) the name of
|
||||
the symbol you wish to import and the name of the library you wish to
|
||||
import it from. For example:
|
||||
<p><pre>
|
||||
import WSAStartup wsock32.dll
|
||||
</pre>
|
||||
<p>A third optional parameter gives the name by which the symbol is known
|
||||
in the library you are importing it from, in case this is not the same as
|
||||
the name you wish the symbol to be known by to your code once you have
|
||||
imported it. For example:
|
||||
<p><pre>
|
||||
import asyncsel wsock32.dll WSAAsyncSelect
|
||||
</pre>
|
||||
<h4><a name="section-6.2.5">6.2.5 <code><nobr>EXPORT</nobr></code>: Exporting DLL Symbols</a></h4>
|
||||
<p>The <code><nobr>EXPORT</nobr></code> format-specific directive defines a
|
||||
global symbol to be exported as a DLL symbol, for use if you are writing a
|
||||
DLL in NASM. You still need to declare the symbol as
|
||||
<code><nobr>GLOBAL</nobr></code> as well as using the
|
||||
<code><nobr>EXPORT</nobr></code> directive.
|
||||
<p><code><nobr>EXPORT</nobr></code> takes one required parameter, which is
|
||||
the name of the symbol you wish to export, as it was defined in your source
|
||||
file. An optional second parameter (separated by white space from the
|
||||
first) gives the <em>external</em> name of the symbol: the name by which
|
||||
you wish the symbol to be known to programs using the DLL. If this name is
|
||||
the same as the internal name, you may leave the second parameter off.
|
||||
<p>Further parameters can be given to define attributes of the exported
|
||||
symbol. These parameters, like the second, are separated by white space. If
|
||||
further parameters are given, the external name must also be specified,
|
||||
even if it is the same as the internal name. The available attributes are:
|
||||
<ul>
|
||||
<li><code><nobr>resident</nobr></code> indicates that the exported name is
|
||||
to be kept resident by the system loader. This is an optimisation for
|
||||
frequently used symbols imported by name.
|
||||
<li><code><nobr>nodata</nobr></code> indicates that the exported symbol is
|
||||
a function which does not make use of any initialised data.
|
||||
<li><code><nobr>parm=NNN</nobr></code>, where <code><nobr>NNN</nobr></code>
|
||||
is an integer, sets the number of parameter words for the case in which the
|
||||
symbol is a call gate between 32-bit and 16-bit segments.
|
||||
<li>An attribute which is just a number indicates that the symbol should be
|
||||
exported with an identifying number (ordinal), and gives the desired
|
||||
number.
|
||||
</ul>
|
||||
<p>For example:
|
||||
<p><pre>
|
||||
export myfunc
|
||||
export myfunc TheRealMoreFormalLookingFunctionName
|
||||
export myfunc myfunc 1234 ; export by ordinal
|
||||
export myfunc myfunc resident parm=23 nodata
|
||||
</pre>
|
||||
<h4><a name="section-6.2.6">6.2.6 <code><nobr>..start</nobr></code>: Defining the Program Entry Point</a></h4>
|
||||
<p><code><nobr>OMF</nobr></code> linkers require exactly one of the object
|
||||
files being linked to define the program entry point, where execution will
|
||||
begin when the program is run. If the object file that defines the entry
|
||||
point is assembled using NASM, you specify the entry point by declaring the
|
||||
special symbol <code><nobr>..start</nobr></code> at the point where you
|
||||
wish execution to begin.
|
||||
<h4><a name="section-6.2.7">6.2.7 <code><nobr>obj</nobr></code> Extensions to the <code><nobr>EXTERN</nobr></code> Directive</a></h4>
|
||||
<p>If you declare an external symbol with the directive
|
||||
<p><pre>
|
||||
extern foo
|
||||
</pre>
|
||||
<p>then references such as <code><nobr>mov ax,foo</nobr></code> will give
|
||||
you the offset of <code><nobr>foo</nobr></code> from its preferred segment
|
||||
base (as specified in whichever module <code><nobr>foo</nobr></code> is
|
||||
actually defined in). So to access the contents of
|
||||
<code><nobr>foo</nobr></code> you will usually need to do something like
|
||||
<p><pre>
|
||||
mov ax,seg foo ; get preferred segment base
|
||||
mov es,ax ; move it into ES
|
||||
mov ax,[es:foo] ; and use offset `foo' from it
|
||||
</pre>
|
||||
<p>This is a little unwieldy, particularly if you know that an external is
|
||||
going to be accessible from a given segment or group, say
|
||||
<code><nobr>dgroup</nobr></code>. So if <code><nobr>DS</nobr></code>
|
||||
already contained <code><nobr>dgroup</nobr></code>, you could simply code
|
||||
<p><pre>
|
||||
mov ax,[foo wrt dgroup]
|
||||
</pre>
|
||||
<p>However, having to type this every time you want to access
|
||||
<code><nobr>foo</nobr></code> can be a pain; so NASM allows you to declare
|
||||
<code><nobr>foo</nobr></code> in the alternative form
|
||||
<p><pre>
|
||||
extern foo:wrt dgroup
|
||||
</pre>
|
||||
<p>This form causes NASM to pretend that the preferred segment base of
|
||||
<code><nobr>foo</nobr></code> is in fact <code><nobr>dgroup</nobr></code>;
|
||||
so the expression <code><nobr>seg foo</nobr></code> will now return
|
||||
<code><nobr>dgroup</nobr></code>, and the expression
|
||||
<code><nobr>foo</nobr></code> is equivalent to
|
||||
<code><nobr>foo wrt dgroup</nobr></code>.
|
||||
<p>This default-<code><nobr>WRT</nobr></code> mechanism can be used to make
|
||||
externals appear to be relative to any group or segment in your program. It
|
||||
can also be applied to common variables: see
|
||||
<a href="#section-6.2.8">section 6.2.8</a>.
|
||||
<h4><a name="section-6.2.8">6.2.8 <code><nobr>obj</nobr></code> Extensions to the <code><nobr>COMMON</nobr></code> Directive</a></h4>
|
||||
<p>The <code><nobr>obj</nobr></code> format allows common variables to be
|
||||
either near or far; NASM allows you to specify which your variables should
|
||||
be by the use of the syntax
|
||||
<p><pre>
|
||||
common nearvar 2:near ; `nearvar' is a near common
|
||||
common farvar 10:far ; and `farvar' is far
|
||||
</pre>
|
||||
<p>Far common variables may be greater in size than 64Kb, and so the OMF
|
||||
specification says that they are declared as a number of <em>elements</em>
|
||||
of a given size. So a 10-byte far common variable could be declared as ten
|
||||
one-byte elements, five two-byte elements, two five-byte elements or one
|
||||
ten-byte element.
|
||||
<p>Some <code><nobr>OMF</nobr></code> linkers require the element size, as
|
||||
well as the variable size, to match when resolving common variables
|
||||
declared in more than one module. Therefore NASM must allow you to specify
|
||||
the element size on your far common variables. This is done by the
|
||||
following syntax:
|
||||
<p><pre>
|
||||
common c_5by2 10:far 5 ; two five-byte elements
|
||||
common c_2by5 10:far 2 ; five two-byte elements
|
||||
</pre>
|
||||
<p>If no element size is specified, the default is 1. Also, the
|
||||
<code><nobr>FAR</nobr></code> keyword is not required when an element size
|
||||
is specified, since only far commons may have element sizes at all. So the
|
||||
above declarations could equivalently be
|
||||
<p><pre>
|
||||
common c_5by2 10:5 ; two five-byte elements
|
||||
common c_2by5 10:2 ; five two-byte elements
|
||||
</pre>
|
||||
<p>In addition to these extensions, the <code><nobr>COMMON</nobr></code>
|
||||
directive in <code><nobr>obj</nobr></code> also supports
|
||||
default-<code><nobr>WRT</nobr></code> specification like
|
||||
<code><nobr>EXTERN</nobr></code> does (explained in
|
||||
<a href="#section-6.2.7">section 6.2.7</a>). So you can also declare things
|
||||
like
|
||||
<p><pre>
|
||||
common foo 10:wrt dgroup
|
||||
common bar 16:far 2:wrt data
|
||||
common baz 24:wrt data:6
|
||||
</pre>
|
||||
<h3><a name="section-6.3">6.3 <code><nobr>win32</nobr></code>: Microsoft Win32 Object Files</a></h3>
|
||||
<p>The <code><nobr>win32</nobr></code> output format generates Microsoft
|
||||
Win32 object files, suitable for passing to Microsoft linkers such as
|
||||
Visual C++. Note that Borland Win32 compilers do not use this format, but
|
||||
use <code><nobr>obj</nobr></code> instead (see
|
||||
<a href="#section-6.2">section 6.2</a>).
|
||||
<p><code><nobr>win32</nobr></code> provides a default output file-name
|
||||
extension of <code><nobr>.obj</nobr></code>.
|
||||
<p>Note that although Microsoft say that Win32 object files follow the
|
||||
<code><nobr>COFF</nobr></code> (Common Object File Format) standard, the
|
||||
object files produced by Microsoft Win32 compilers are not compatible with
|
||||
COFF linkers such as DJGPP's, and vice versa. This is due to a difference
|
||||
of opinion over the precise semantics of PC-relative relocations. To
|
||||
produce COFF files suitable for DJGPP, use NASM's
|
||||
<code><nobr>coff</nobr></code> output format; conversely, the
|
||||
<code><nobr>coff</nobr></code> format does not produce object files that
|
||||
Win32 linkers can generate correct output from.
|
||||
<h4><a name="section-6.3.1">6.3.1 <code><nobr>win32</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a></h4>
|
||||
<p>Like the <code><nobr>obj</nobr></code> format,
|
||||
<code><nobr>win32</nobr></code> allows you to specify additional
|
||||
information on the <code><nobr>SECTION</nobr></code> directive line, to
|
||||
control the type and properties of sections you declare. Section types and
|
||||
properties are generated automatically by NASM for the standard section
|
||||
names <code><nobr>.text</nobr></code>, <code><nobr>.data</nobr></code> and
|
||||
<code><nobr>.bss</nobr></code>, but may still be overridden by these
|
||||
qualifiers.
|
||||
<p>The available qualifiers are:
|
||||
<ul>
|
||||
<li><code><nobr>code</nobr></code>, or equivalently
|
||||
<code><nobr>text</nobr></code>, defines the section to be a code section.
|
||||
This marks the section as readable and executable, but not writable, and
|
||||
also indicates to the linker that the type of the section is code.
|
||||
<li><code><nobr>data</nobr></code> and <code><nobr>bss</nobr></code> define
|
||||
the section to be a data section, analogously to
|
||||
<code><nobr>code</nobr></code>. Data sections are marked as readable and
|
||||
writable, but not executable. <code><nobr>data</nobr></code> declares an
|
||||
initialised data section, whereas <code><nobr>bss</nobr></code> declares an
|
||||
uninitialised data section.
|
||||
<li><code><nobr>rdata</nobr></code> declares an initialised data section
|
||||
that is readable but not writable. Microsoft compilers use this section to
|
||||
place constants in it.
|
||||
<li><code><nobr>info</nobr></code> defines the section to be an
|
||||
informational section, which is not included in the executable file by the
|
||||
linker, but may (for example) pass information <em>to</em> the linker. For
|
||||
example, declaring an <code><nobr>info</nobr></code>-type section called
|
||||
<code><nobr>.drectve</nobr></code> causes the linker to interpret the
|
||||
contents of the section as command-line options.
|
||||
<li><code><nobr>align=</nobr></code>, used with a trailing number as in
|
||||
<code><nobr>obj</nobr></code>, gives the alignment requirements of the
|
||||
section. The maximum you may specify is 64: the Win32 object file format
|
||||
contains no means to request a greater section alignment than this. If
|
||||
alignment is not explicitly specified, the defaults are 16-byte alignment
|
||||
for code sections, 8-byte alignment for rdata sections and 4-byte alignment
|
||||
for data (and BSS) sections. Informational sections get a default alignment
|
||||
of 1 byte (no alignment), though the value does not matter.
|
||||
</ul>
|
||||
<p>The defaults assumed by NASM if you do not specify the above qualifiers
|
||||
are:
|
||||
<p><pre>
|
||||
section .text code align=16
|
||||
section .data data align=4
|
||||
section .rdata rdata align=8
|
||||
section .bss bss align=4
|
||||
</pre>
|
||||
<p>Any other section name is treated by default like
|
||||
<code><nobr>.text</nobr></code>.
|
||||
<h3><a name="section-6.4">6.4 <code><nobr>coff</nobr></code>: Common Object File Format</a></h3>
|
||||
<p>The <code><nobr>coff</nobr></code> output type produces
|
||||
<code><nobr>COFF</nobr></code> object files suitable for linking with the
|
||||
DJGPP linker.
|
||||
<p><code><nobr>coff</nobr></code> provides a default output file-name
|
||||
extension of <code><nobr>.o</nobr></code>.
|
||||
<p>The <code><nobr>coff</nobr></code> format supports the same extensions
|
||||
to the <code><nobr>SECTION</nobr></code> directive as
|
||||
<code><nobr>win32</nobr></code> does, except that the
|
||||
<code><nobr>align</nobr></code> qualifier and the
|
||||
<code><nobr>info</nobr></code> section type are not supported.
|
||||
<h3><a name="section-6.5">6.5 <code><nobr>elf</nobr></code>: Executable and Linkable Format Object Files</a></h3>
|
||||
<p>The <code><nobr>elf</nobr></code> output format generates
|
||||
<code><nobr>ELF32</nobr></code> (Executable and Linkable Format) object
|
||||
files, as used by Linux as well as Unix System V, including Solaris x86,
|
||||
UnixWare and SCO Unix. <code><nobr>elf</nobr></code> provides a default
|
||||
output file-name extension of <code><nobr>.o</nobr></code>.
|
||||
<h4><a name="section-6.5.1">6.5.1 <code><nobr>elf</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a></h4>
|
||||
<p>Like the <code><nobr>obj</nobr></code> format,
|
||||
<code><nobr>elf</nobr></code> allows you to specify additional information
|
||||
on the <code><nobr>SECTION</nobr></code> directive line, to control the
|
||||
type and properties of sections you declare. Section types and properties
|
||||
are generated automatically by NASM for the standard section names
|
||||
<code><nobr>.text</nobr></code>, <code><nobr>.data</nobr></code> and
|
||||
<code><nobr>.bss</nobr></code>, but may still be overridden by these
|
||||
qualifiers.
|
||||
<p>The available qualifiers are:
|
||||
<ul>
|
||||
<li><code><nobr>alloc</nobr></code> defines the section to be one which is
|
||||
loaded into memory when the program is run.
|
||||
<code><nobr>noalloc</nobr></code> defines it to be one which is not, such
|
||||
as an informational or comment section.
|
||||
<li><code><nobr>exec</nobr></code> defines the section to be one which
|
||||
should have execute permission when the program is run.
|
||||
<code><nobr>noexec</nobr></code> defines it as one which should not.
|
||||
<li><code><nobr>write</nobr></code> defines the section to be one which
|
||||
should be writable when the program is run.
|
||||
<code><nobr>nowrite</nobr></code> defines it as one which should not.
|
||||
<li><code><nobr>progbits</nobr></code> defines the section to be one with
|
||||
explicit contents stored in the object file: an ordinary code or data
|
||||
section, for example, <code><nobr>nobits</nobr></code> defines the section
|
||||
to be one with no explicit contents given, such as a BSS section.
|
||||
<li><code><nobr>align=</nobr></code>, used with a trailing number as in
|
||||
<code><nobr>obj</nobr></code>, gives the alignment requirements of the
|
||||
section.
|
||||
</ul>
|
||||
<p>The defaults assumed by NASM if you do not specify the above qualifiers
|
||||
are:
|
||||
<p><pre>
|
||||
section .text progbits alloc exec nowrite align=16
|
||||
section .rodata progbits alloc noexec nowrite align=4
|
||||
section .data progbits alloc noexec write align=4
|
||||
section .bss nobits alloc noexec write align=4
|
||||
section other progbits alloc noexec nowrite align=1
|
||||
</pre>
|
||||
<p>(Any section name other than <code><nobr>.text</nobr></code>,
|
||||
<code><nobr>.rodata</nobr></code>, <code><nobr>.data</nobr></code> and
|
||||
<code><nobr>.bss</nobr></code> is treated by default like
|
||||
<code><nobr>other</nobr></code> in the above code.)
|
||||
<h4><a name="section-6.5.2">6.5.2 Position-Independent Code: <code><nobr>elf</nobr></code> Special Symbols and <code><nobr>WRT</nobr></code></a></h4>
|
||||
<p>The <code><nobr>ELF</nobr></code> specification contains enough features
|
||||
to allow position-independent code (PIC) to be written, which makes ELF
|
||||
shared libraries very flexible. However, it also means NASM has to be able
|
||||
to generate a variety of strange relocation types in ELF object files, if
|
||||
it is to be an assembler which can write PIC.
|
||||
<p>Since <code><nobr>ELF</nobr></code> does not support segment-base
|
||||
references, the <code><nobr>WRT</nobr></code> operator is not used for its
|
||||
normal purpose; therefore NASM's <code><nobr>elf</nobr></code> output
|
||||
format makes use of <code><nobr>WRT</nobr></code> for a different purpose,
|
||||
namely the PIC-specific relocation types.
|
||||
<p><code><nobr>elf</nobr></code> defines five special symbols which you can
|
||||
use as the right-hand side of the <code><nobr>WRT</nobr></code> operator to
|
||||
obtain PIC relocation types. They are <code><nobr>..gotpc</nobr></code>,
|
||||
<code><nobr>..gotoff</nobr></code>, <code><nobr>..got</nobr></code>,
|
||||
<code><nobr>..plt</nobr></code> and <code><nobr>..sym</nobr></code>. Their
|
||||
functions are summarised here:
|
||||
<ul>
|
||||
<li>Referring to the symbol marking the global offset table base using
|
||||
<code><nobr>wrt ..gotpc</nobr></code> will end up giving the distance from
|
||||
the beginning of the current section to the global offset table.
|
||||
(<code><nobr>_GLOBAL_OFFSET_TABLE_</nobr></code> is the standard symbol
|
||||
name used to refer to the GOT.) So you would then need to add
|
||||
<code><nobr>$$</nobr></code> to the result to get the real address of the
|
||||
GOT.
|
||||
<li>Referring to a location in one of your own sections using
|
||||
<code><nobr>wrt ..gotoff</nobr></code> will give the distance from the
|
||||
beginning of the GOT to the specified location, so that adding on the
|
||||
address of the GOT would give the real address of the location you wanted.
|
||||
<li>Referring to an external or global symbol using
|
||||
<code><nobr>wrt ..got</nobr></code> causes the linker to build an entry
|
||||
<em>in</em> the GOT containing the address of the symbol, and the reference
|
||||
gives the distance from the beginning of the GOT to the entry; so you can
|
||||
add on the address of the GOT, load from the resulting address, and end up
|
||||
with the address of the symbol.
|
||||
<li>Referring to a procedure name using <code><nobr>wrt ..plt</nobr></code>
|
||||
causes the linker to build a procedure linkage table entry for the symbol,
|
||||
and the reference gives the address of the PLT entry. You can only use this
|
||||
in contexts which would generate a PC-relative relocation normally (i.e. as
|
||||
the destination for <code><nobr>CALL</nobr></code> or
|
||||
<code><nobr>JMP</nobr></code>), since ELF contains no relocation type to
|
||||
refer to PLT entries absolutely.
|
||||
<li>Referring to a symbol name using <code><nobr>wrt ..sym</nobr></code>
|
||||
causes NASM to write an ordinary relocation, but instead of making the
|
||||
relocation relative to the start of the section and then adding on the
|
||||
offset to the symbol, it will write a relocation record aimed directly at
|
||||
the symbol in question. The distinction is a necessary one due to a
|
||||
peculiarity of the dynamic linker.
|
||||
</ul>
|
||||
<p>A fuller explanation of how to use these relocation types to write
|
||||
shared libraries entirely in NASM is given in
|
||||
<a href="nasmdoc8.html#section-8.2">section 8.2</a>.
|
||||
<h4><a name="section-6.5.3">6.5.3 <code><nobr>elf</nobr></code> Extensions to the <code><nobr>GLOBAL</nobr></code> Directive</a></h4>
|
||||
<p><code><nobr>ELF</nobr></code> object files can contain more information
|
||||
about a global symbol than just its address: they can contain the size of
|
||||
the symbol and its type as well. These are not merely debugger
|
||||
conveniences, but are actually necessary when the program being written is
|
||||
a shared library. NASM therefore supports some extensions to the
|
||||
<code><nobr>GLOBAL</nobr></code> directive, allowing you to specify these
|
||||
features.
|
||||
<p>You can specify whether a global variable is a function or a data object
|
||||
by suffixing the name with a colon and the word
|
||||
<code><nobr>function</nobr></code> or <code><nobr>data</nobr></code>.
|
||||
(<code><nobr>object</nobr></code> is a synonym for
|
||||
<code><nobr>data</nobr></code>.) For example:
|
||||
<p><pre>
|
||||
global hashlookup:function, hashtable:data
|
||||
</pre>
|
||||
<p>exports the global symbol <code><nobr>hashlookup</nobr></code> as a
|
||||
function and <code><nobr>hashtable</nobr></code> as a data object.
|
||||
<p>You can also specify the size of the data associated with the symbol, as
|
||||
a numeric expression (which may involve labels, and even forward
|
||||
references) after the type specifier. Like this:
|
||||
<p><pre>
|
||||
global hashtable:data (hashtable.end - hashtable)
|
||||
|
||||
hashtable:
|
||||
db this,that,theother ; some data here
|
||||
.end:
|
||||
</pre>
|
||||
<p>This makes NASM automatically calculate the length of the table and
|
||||
place that information into the <code><nobr>ELF</nobr></code> symbol table.
|
||||
<p>Declaring the type and size of global symbols is necessary when writing
|
||||
shared library code. For more information, see
|
||||
<a href="nasmdoc8.html#section-8.2.4">section 8.2.4</a>.
|
||||
<h4><a name="section-6.5.4">6.5.4 <code><nobr>elf</nobr></code> Extensions to the <code><nobr>COMMON</nobr></code> Directive </a></h4>
|
||||
<p><code><nobr>ELF</nobr></code> also allows you to specify alignment
|
||||
requirements on common variables. This is done by putting a number (which
|
||||
must be a power of two) after the name and size of the common variable,
|
||||
separated (as usual) by a colon. For example, an array of doublewords would
|
||||
benefit from 4-byte alignment:
|
||||
<p><pre>
|
||||
common dwordarray 128:4
|
||||
</pre>
|
||||
<p>This declares the total size of the array to be 128 bytes, and requires
|
||||
that it be aligned on a 4-byte boundary.
|
||||
<h4><a name="section-6.5.5">6.5.5 16-bit code and ELF </a></h4>
|
||||
<p>The <code><nobr>ELF32</nobr></code> specification doesn't provide
|
||||
relocations for 8- and 16-bit values, but the GNU
|
||||
<code><nobr>ld</nobr></code> linker adds these as an extension. NASM can
|
||||
generate GNU-compatible relocations, to allow 16-bit code to be linked as
|
||||
ELF using GNU <code><nobr>ld</nobr></code>. If NASM is used with the
|
||||
<code><nobr>-w+gnu-elf-extensions</nobr></code> option, a warning is issued
|
||||
when one of these relocations is generated.
|
||||
<h3><a name="section-6.6">6.6 <code><nobr>aout</nobr></code>: Linux <code><nobr>a.out</nobr></code> Object Files</a></h3>
|
||||
<p>The <code><nobr>aout</nobr></code> format generates
|
||||
<code><nobr>a.out</nobr></code> object files, in the form used by early
|
||||
Linux systems (current Linux systems use ELF, see
|
||||
<a href="#section-6.5">section 6.5</a>.) These differ from other
|
||||
<code><nobr>a.out</nobr></code> object files in that the magic number in
|
||||
the first four bytes of the file is different; also, some implementations
|
||||
of <code><nobr>a.out</nobr></code>, for example NetBSD's, support
|
||||
position-independent code, which Linux's implementation does not.
|
||||
<p><code><nobr>a.out</nobr></code> provides a default output file-name
|
||||
extension of <code><nobr>.o</nobr></code>.
|
||||
<p><code><nobr>a.out</nobr></code> is a very simple object format. It
|
||||
supports no special directives, no special symbols, no use of
|
||||
<code><nobr>SEG</nobr></code> or <code><nobr>WRT</nobr></code>, and no
|
||||
extensions to any standard directives. It supports only the three standard
|
||||
section names <code><nobr>.text</nobr></code>,
|
||||
<code><nobr>.data</nobr></code> and <code><nobr>.bss</nobr></code>.
|
||||
<h3><a name="section-6.7">6.7 <code><nobr>aoutb</nobr></code>: NetBSD/FreeBSD/OpenBSD <code><nobr>a.out</nobr></code> Object Files</a></h3>
|
||||
<p>The <code><nobr>aoutb</nobr></code> format generates
|
||||
<code><nobr>a.out</nobr></code> object files, in the form used by the
|
||||
various free <code><nobr>BSD Unix</nobr></code> clones,
|
||||
<code><nobr>NetBSD</nobr></code>, <code><nobr>FreeBSD</nobr></code> and
|
||||
<code><nobr>OpenBSD</nobr></code>. For simple object files, this object
|
||||
format is exactly the same as <code><nobr>aout</nobr></code> except for the
|
||||
magic number in the first four bytes of the file. However, the
|
||||
<code><nobr>aoutb</nobr></code> format supports position-independent code
|
||||
in the same way as the <code><nobr>elf</nobr></code> format, so you can use
|
||||
it to write <code><nobr>BSD</nobr></code> shared libraries.
|
||||
<p><code><nobr>aoutb</nobr></code> provides a default output file-name
|
||||
extension of <code><nobr>.o</nobr></code>.
|
||||
<p><code><nobr>aoutb</nobr></code> supports no special directives, no
|
||||
special symbols, and only the three standard section names
|
||||
<code><nobr>.text</nobr></code>, <code><nobr>.data</nobr></code> and
|
||||
<code><nobr>.bss</nobr></code>. However, it also supports the same use of
|
||||
<code><nobr>WRT</nobr></code> as <code><nobr>elf</nobr></code> does, to
|
||||
provide position-independent code relocation types. See
|
||||
<a href="#section-6.5.2">section 6.5.2</a> for full documentation of this
|
||||
feature.
|
||||
<p><code><nobr>aoutb</nobr></code> also supports the same extensions to the
|
||||
<code><nobr>GLOBAL</nobr></code> directive as <code><nobr>elf</nobr></code>
|
||||
does: see <a href="#section-6.5.3">section 6.5.3</a> for documentation of
|
||||
this.
|
||||
<h3><a name="section-6.8">6.8 <code><nobr>as86</nobr></code>: Minix/Linux <code><nobr>as86</nobr></code> Object Files</a></h3>
|
||||
<p>The Minix/Linux 16-bit assembler <code><nobr>as86</nobr></code> has its
|
||||
own non-standard object file format. Although its companion linker
|
||||
<code><nobr>ld86</nobr></code> produces something close to ordinary
|
||||
<code><nobr>a.out</nobr></code> binaries as output, the object file format
|
||||
used to communicate between <code><nobr>as86</nobr></code> and
|
||||
<code><nobr>ld86</nobr></code> is not itself
|
||||
<code><nobr>a.out</nobr></code>.
|
||||
<p>NASM supports this format, just in case it is useful, as
|
||||
<code><nobr>as86</nobr></code>. <code><nobr>as86</nobr></code> provides a
|
||||
default output file-name extension of <code><nobr>.o</nobr></code>.
|
||||
<p><code><nobr>as86</nobr></code> is a very simple object format (from the
|
||||
NASM user's point of view). It supports no special directives, no special
|
||||
symbols, no use of <code><nobr>SEG</nobr></code> or
|
||||
<code><nobr>WRT</nobr></code>, and no extensions to any standard
|
||||
directives. It supports only the three standard section names
|
||||
<code><nobr>.text</nobr></code>, <code><nobr>.data</nobr></code> and
|
||||
<code><nobr>.bss</nobr></code>.
|
||||
<h3><a name="section-6.9">6.9 <code><nobr>rdf</nobr></code>: Relocatable Dynamic Object File Format</a></h3>
|
||||
<p>The <code><nobr>rdf</nobr></code> output format produces
|
||||
<code><nobr>RDOFF</nobr></code> object files.
|
||||
<code><nobr>RDOFF</nobr></code> (Relocatable Dynamic Object File Format) is
|
||||
a home-grown object-file format, designed alongside NASM itself and
|
||||
reflecting in its file format the internal structure of the assembler.
|
||||
<p><code><nobr>RDOFF</nobr></code> is not used by any well-known operating
|
||||
systems. Those writing their own systems, however, may well wish to use
|
||||
<code><nobr>RDOFF</nobr></code> as their object format, on the grounds that
|
||||
it is designed primarily for simplicity and contains very little
|
||||
file-header bureaucracy.
|
||||
<p>The Unix NASM archive, and the DOS archive which includes sources, both
|
||||
contain an <code><nobr>rdoff</nobr></code> subdirectory holding a set of
|
||||
RDOFF utilities: an RDF linker, an <code><nobr>RDF</nobr></code>
|
||||
static-library manager, an RDF file dump utility, and a program which will
|
||||
load and execute an RDF executable under Linux.
|
||||
<p><code><nobr>rdf</nobr></code> supports only the standard section names
|
||||
<code><nobr>.text</nobr></code>, <code><nobr>.data</nobr></code> and
|
||||
<code><nobr>.bss</nobr></code>.
|
||||
<h4><a name="section-6.9.1">6.9.1 Requiring a Library: The <code><nobr>LIBRARY</nobr></code> Directive</a></h4>
|
||||
<p><code><nobr>RDOFF</nobr></code> contains a mechanism for an object file
|
||||
to demand a given library to be linked to the module, either at load time
|
||||
or run time. This is done by the <code><nobr>LIBRARY</nobr></code>
|
||||
directive, which takes one argument which is the name of the module:
|
||||
<p><pre>
|
||||
library mylib.rdl
|
||||
</pre>
|
||||
<h4><a name="section-6.9.2">6.9.2 Specifying a Module Name: The <code><nobr>MODULE</nobr></code> Directive</a></h4>
|
||||
<p>Special <code><nobr>RDOFF</nobr></code> header record is used to store
|
||||
the name of the module. It can be used, for example, by run-time loader to
|
||||
perform dynamic linking. <code><nobr>MODULE</nobr></code> directive takes
|
||||
one argument which is the name of current module:
|
||||
<p><pre>
|
||||
module mymodname
|
||||
</pre>
|
||||
<p>Note that when you statically link modules and tell linker to strip the
|
||||
symbols from output file, all module names will be stripped too. To avoid
|
||||
it, you should start module names with <code><nobr>$</nobr></code>, like:
|
||||
<p><pre>
|
||||
module $kernel.core
|
||||
</pre>
|
||||
<h4><a name="section-6.9.3">6.9.3 <code><nobr>rdf</nobr></code> Extensions to the <code><nobr>GLOBAL</nobr></code> directive</a></h4>
|
||||
<p><code><nobr>RDOFF</nobr></code> global symbols can contain additional
|
||||
information needed by the static linker. You can mark a global symbol as
|
||||
exported, thus telling the linker do not strip it from target executable or
|
||||
library file. Like in <code><nobr>ELF</nobr></code>, you can also specify
|
||||
whether an exported symbol is a procedure (function) or data object.
|
||||
<p>Suffixing the name with a colon and the word
|
||||
<code><nobr>export</nobr></code> you make the symbol exported:
|
||||
<p><pre>
|
||||
global sys_open:export
|
||||
</pre>
|
||||
<p>To specify that exported symbol is a procedure (function), you add the
|
||||
word <code><nobr>proc</nobr></code> or <code><nobr>function</nobr></code>
|
||||
after declaration:
|
||||
<p><pre>
|
||||
global sys_open:export proc
|
||||
</pre>
|
||||
<p>Similarly, to specify exported data object, add the word
|
||||
<code><nobr>data</nobr></code> or <code><nobr>object</nobr></code> to the
|
||||
directive:
|
||||
<p><pre>
|
||||
global kernel_ticks:export data
|
||||
</pre>
|
||||
<h3><a name="section-6.10">6.10 <code><nobr>dbg</nobr></code>: Debugging Format</a></h3>
|
||||
<p>The <code><nobr>dbg</nobr></code> output format is not built into NASM
|
||||
in the default configuration. If you are building your own NASM executable
|
||||
from the sources, you can define <code><nobr>OF_DBG</nobr></code> in
|
||||
<code><nobr>outform.h</nobr></code> or on the compiler command line, and
|
||||
obtain the <code><nobr>dbg</nobr></code> output format.
|
||||
<p>The <code><nobr>dbg</nobr></code> format does not output an object file
|
||||
as such; instead, it outputs a text file which contains a complete list of
|
||||
all the transactions between the main body of NASM and the output-format
|
||||
back end module. It is primarily intended to aid people who want to write
|
||||
their own output drivers, so that they can get a clearer idea of the
|
||||
various requests the main program makes of the output driver, and in what
|
||||
order they happen.
|
||||
<p>For simple files, one can easily use the <code><nobr>dbg</nobr></code>
|
||||
format like this:
|
||||
<p><pre>
|
||||
nasm -f dbg filename.asm
|
||||
</pre>
|
||||
<p>which will generate a diagnostic file called
|
||||
<code><nobr>filename.dbg</nobr></code>. However, this will not work well on
|
||||
files which were designed for a different object format, because each
|
||||
object format defines its own macros (usually user-level forms of
|
||||
directives), and those macros will not be defined in the
|
||||
<code><nobr>dbg</nobr></code> format. Therefore it can be useful to run
|
||||
NASM twice, in order to do the preprocessing with the native object format
|
||||
selected:
|
||||
<p><pre>
|
||||
nasm -e -f rdf -o rdfprog.i rdfprog.asm
|
||||
nasm -a -f dbg rdfprog.i
|
||||
</pre>
|
||||
<p>This preprocesses <code><nobr>rdfprog.asm</nobr></code> into
|
||||
<code><nobr>rdfprog.i</nobr></code>, keeping the
|
||||
<code><nobr>rdf</nobr></code> object format selected in order to make sure
|
||||
RDF special directives are converted into primitive form correctly. Then
|
||||
the preprocessed source is fed through the <code><nobr>dbg</nobr></code>
|
||||
format to generate the final diagnostic output.
|
||||
<p>This workaround will still typically not work for programs intended for
|
||||
<code><nobr>obj</nobr></code> format, because the
|
||||
<code><nobr>obj</nobr></code> <code><nobr>SEGMENT</nobr></code> and
|
||||
<code><nobr>GROUP</nobr></code> directives have side effects of defining
|
||||
the segment and group names as symbols; <code><nobr>dbg</nobr></code> will
|
||||
not do this, so the program will not assemble. You will have to work around
|
||||
that by defining the symbols yourself (using
|
||||
<code><nobr>EXTERN</nobr></code>, for example) if you really need to get a
|
||||
<code><nobr>dbg</nobr></code> trace of an
|
||||
<code><nobr>obj</nobr></code>-specific source file.
|
||||
<p><code><nobr>dbg</nobr></code> accepts any section name and any
|
||||
directives at all, and logs them all to its output file.
|
||||
<p align=center><a href="nasmdoc7.html">Next Chapter</a> |
|
||||
<a href="nasmdoc5.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
</body></html>
|
||||
808
Ref-docs/nasmdoc/html/nasmdoc7.html
Normal file
808
Ref-docs/nasmdoc/html/nasmdoc7.html
Normal file
@@ -0,0 +1,808 @@
|
||||
<html><head><title>NASM Manual</title></head>
|
||||
<body><h1 align=center>The Netwide Assembler: NASM</h1>
|
||||
|
||||
<p align=center><a href="nasmdoc8.html">Next Chapter</a> |
|
||||
<a href="nasmdoc6.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
<h2><a name="chapter-7">Chapter 7: Writing 16-bit Code (DOS, Windows 3/3.1)</a></h2>
|
||||
<p>This chapter attempts to cover some of the common issues encountered
|
||||
when writing 16-bit code to run under <code><nobr>MS-DOS</nobr></code> or
|
||||
<code><nobr>Windows 3.x</nobr></code>. It covers how to link programs to
|
||||
produce <code><nobr>.EXE</nobr></code> or <code><nobr>.COM</nobr></code>
|
||||
files, how to write <code><nobr>.SYS</nobr></code> device drivers, and how
|
||||
to interface assembly language code with 16-bit C compilers and with
|
||||
Borland Pascal.
|
||||
<h3><a name="section-7.1">7.1 Producing <code><nobr>.EXE</nobr></code> Files</a></h3>
|
||||
<p>Any large program written under DOS needs to be built as a
|
||||
<code><nobr>.EXE</nobr></code> file: only <code><nobr>.EXE</nobr></code>
|
||||
files have the necessary internal structure required to span more than one
|
||||
64K segment. Windows programs, also, have to be built as
|
||||
<code><nobr>.EXE</nobr></code> files, since Windows does not support the
|
||||
<code><nobr>.COM</nobr></code> format.
|
||||
<p>In general, you generate <code><nobr>.EXE</nobr></code> files by using
|
||||
the <code><nobr>obj</nobr></code> output format to produce one or more
|
||||
<code><nobr>.OBJ</nobr></code> files, and then linking them together using
|
||||
a linker. However, NASM also supports the direct generation of simple DOS
|
||||
<code><nobr>.EXE</nobr></code> files using the
|
||||
<code><nobr>bin</nobr></code> output format (by using
|
||||
<code><nobr>DB</nobr></code> and <code><nobr>DW</nobr></code> to construct
|
||||
the <code><nobr>.EXE</nobr></code> file header), and a macro package is
|
||||
supplied to do this. Thanks to Yann Guidon for contributing the code for
|
||||
this.
|
||||
<p>NASM may also support <code><nobr>.EXE</nobr></code> natively as another
|
||||
output format in future releases.
|
||||
<h4><a name="section-7.1.1">7.1.1 Using the <code><nobr>obj</nobr></code> Format To Generate <code><nobr>.EXE</nobr></code> Files</a></h4>
|
||||
<p>This section describes the usual method of generating
|
||||
<code><nobr>.EXE</nobr></code> files by linking
|
||||
<code><nobr>.OBJ</nobr></code> files together.
|
||||
<p>Most 16-bit programming language packages come with a suitable linker;
|
||||
if you have none of these, there is a free linker called VAL, available in
|
||||
<code><nobr>LZH</nobr></code> archive format from
|
||||
<a href="ftp://x2ftp.oulu.fi/pub/msdos/programming/lang/"><code><nobr>x2ftp.oulu.fi</nobr></code></a>.
|
||||
An LZH archiver can be found at
|
||||
<a href="ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers"><code><nobr>ftp.simtel.net</nobr></code></a>.
|
||||
There is another `free' linker (though this one doesn't come with sources)
|
||||
called FREELINK, available from
|
||||
<a href="http://www.pcorner.com/tpc/old/3-101.html"><code><nobr>www.pcorner.com</nobr></code></a>.
|
||||
A third, <code><nobr>djlink</nobr></code>, written by DJ Delorie, is
|
||||
available at
|
||||
<a href="http://www.delorie.com/djgpp/16bit/djlink/"><code><nobr>www.delorie.com</nobr></code></a>.
|
||||
A fourth linker, <code><nobr>ALINK</nobr></code>, written by Anthony A.J.
|
||||
Williams, is available at
|
||||
<a href="http://alink.sourceforge.net"><code><nobr>alink.sourceforge.net</nobr></code></a>.
|
||||
<p>When linking several <code><nobr>.OBJ</nobr></code> files into a
|
||||
<code><nobr>.EXE</nobr></code> file, you should ensure that exactly one of
|
||||
them has a start point defined (using the <code><nobr>..start</nobr></code>
|
||||
special symbol defined by the <code><nobr>obj</nobr></code> format: see
|
||||
<a href="nasmdoc6.html#section-6.2.6">section 6.2.6</a>). If no module
|
||||
defines a start point, the linker will not know what value to give the
|
||||
entry-point field in the output file header; if more than one defines a
|
||||
start point, the linker will not know <em>which</em> value to use.
|
||||
<p>An example of a NASM source file which can be assembled to a
|
||||
<code><nobr>.OBJ</nobr></code> file and linked on its own to a
|
||||
<code><nobr>.EXE</nobr></code> is given here. It demonstrates the basic
|
||||
principles of defining a stack, initialising the segment registers, and
|
||||
declaring a start point. This file is also provided in the
|
||||
<code><nobr>test</nobr></code> subdirectory of the NASM archives, under the
|
||||
name <code><nobr>objexe.asm</nobr></code>.
|
||||
<p><pre>
|
||||
segment code
|
||||
|
||||
..start:
|
||||
mov ax,data
|
||||
mov ds,ax
|
||||
mov ax,stack
|
||||
mov ss,ax
|
||||
mov sp,stacktop
|
||||
</pre>
|
||||
<p>This initial piece of code sets up <code><nobr>DS</nobr></code> to point
|
||||
to the data segment, and initialises <code><nobr>SS</nobr></code> and
|
||||
<code><nobr>SP</nobr></code> to point to the top of the provided stack.
|
||||
Notice that interrupts are implicitly disabled for one instruction after a
|
||||
move into <code><nobr>SS</nobr></code>, precisely for this situation, so
|
||||
that there's no chance of an interrupt occurring between the loads of
|
||||
<code><nobr>SS</nobr></code> and <code><nobr>SP</nobr></code> and not
|
||||
having a stack to execute on.
|
||||
<p>Note also that the special symbol <code><nobr>..start</nobr></code> is
|
||||
defined at the beginning of this code, which means that will be the entry
|
||||
point into the resulting executable file.
|
||||
<p><pre>
|
||||
mov dx,hello
|
||||
mov ah,9
|
||||
int 0x21
|
||||
</pre>
|
||||
<p>The above is the main program: load <code><nobr>DS:DX</nobr></code> with
|
||||
a pointer to the greeting message (<code><nobr>hello</nobr></code> is
|
||||
implicitly relative to the segment <code><nobr>data</nobr></code>, which
|
||||
was loaded into <code><nobr>DS</nobr></code> in the setup code, so the full
|
||||
pointer is valid), and call the DOS print-string function.
|
||||
<p><pre>
|
||||
mov ax,0x4c00
|
||||
int 0x21
|
||||
</pre>
|
||||
<p>This terminates the program using another DOS system call.
|
||||
<p><pre>
|
||||
segment data
|
||||
|
||||
hello: db 'hello, world', 13, 10, '$'
|
||||
</pre>
|
||||
<p>The data segment contains the string we want to display.
|
||||
<p><pre>
|
||||
segment stack stack
|
||||
resb 64
|
||||
stacktop:
|
||||
</pre>
|
||||
<p>The above code declares a stack segment containing 64 bytes of
|
||||
uninitialised stack space, and points <code><nobr>stacktop</nobr></code> at
|
||||
the top of it. The directive <code><nobr>segment stack stack</nobr></code>
|
||||
defines a segment <em>called</em> <code><nobr>stack</nobr></code>, and also
|
||||
of <em>type</em> <code><nobr>STACK</nobr></code>. The latter is not
|
||||
necessary to the correct running of the program, but linkers are likely to
|
||||
issue warnings or errors if your program has no segment of type
|
||||
<code><nobr>STACK</nobr></code>.
|
||||
<p>The above file, when assembled into a <code><nobr>.OBJ</nobr></code>
|
||||
file, will link on its own to a valid <code><nobr>.EXE</nobr></code> file,
|
||||
which when run will print `hello, world' and then exit.
|
||||
<h4><a name="section-7.1.2">7.1.2 Using the <code><nobr>bin</nobr></code> Format To Generate <code><nobr>.EXE</nobr></code> Files</a></h4>
|
||||
<p>The <code><nobr>.EXE</nobr></code> file format is simple enough that
|
||||
it's possible to build a <code><nobr>.EXE</nobr></code> file by writing a
|
||||
pure-binary program and sticking a 32-byte header on the front. This header
|
||||
is simple enough that it can be generated using
|
||||
<code><nobr>DB</nobr></code> and <code><nobr>DW</nobr></code> commands by
|
||||
NASM itself, so that you can use the <code><nobr>bin</nobr></code> output
|
||||
format to directly generate <code><nobr>.EXE</nobr></code> files.
|
||||
<p>Included in the NASM archives, in the <code><nobr>misc</nobr></code>
|
||||
subdirectory, is a file <code><nobr>exebin.mac</nobr></code> of macros. It
|
||||
defines three macros: <code><nobr>EXE_begin</nobr></code>,
|
||||
<code><nobr>EXE_stack</nobr></code> and <code><nobr>EXE_end</nobr></code>.
|
||||
<p>To produce a <code><nobr>.EXE</nobr></code> file using this method, you
|
||||
should start by using <code><nobr>%include</nobr></code> to load the
|
||||
<code><nobr>exebin.mac</nobr></code> macro package into your source file.
|
||||
You should then issue the <code><nobr>EXE_begin</nobr></code> macro call
|
||||
(which takes no arguments) to generate the file header data. Then write
|
||||
code as normal for the <code><nobr>bin</nobr></code> format - you can use
|
||||
all three standard sections <code><nobr>.text</nobr></code>,
|
||||
<code><nobr>.data</nobr></code> and <code><nobr>.bss</nobr></code>. At the
|
||||
end of the file you should call the <code><nobr>EXE_end</nobr></code> macro
|
||||
(again, no arguments), which defines some symbols to mark section sizes,
|
||||
and these symbols are referred to in the header code generated by
|
||||
<code><nobr>EXE_begin</nobr></code>.
|
||||
<p>In this model, the code you end up writing starts at
|
||||
<code><nobr>0x100</nobr></code>, just like a <code><nobr>.COM</nobr></code>
|
||||
file - in fact, if you strip off the 32-byte header from the resulting
|
||||
<code><nobr>.EXE</nobr></code> file, you will have a valid
|
||||
<code><nobr>.COM</nobr></code> program. All the segment bases are the same,
|
||||
so you are limited to a 64K program, again just like a
|
||||
<code><nobr>.COM</nobr></code> file. Note that an
|
||||
<code><nobr>ORG</nobr></code> directive is issued by the
|
||||
<code><nobr>EXE_begin</nobr></code> macro, so you should not explicitly
|
||||
issue one of your own.
|
||||
<p>You can't directly refer to your segment base value, unfortunately,
|
||||
since this would require a relocation in the header, and things would get a
|
||||
lot more complicated. So you should get your segment base by copying it out
|
||||
of <code><nobr>CS</nobr></code> instead.
|
||||
<p>On entry to your <code><nobr>.EXE</nobr></code> file,
|
||||
<code><nobr>SS:SP</nobr></code> are already set up to point to the top of a
|
||||
2Kb stack. You can adjust the default stack size of 2Kb by calling the
|
||||
<code><nobr>EXE_stack</nobr></code> macro. For example, to change the stack
|
||||
size of your program to 64 bytes, you would call
|
||||
<code><nobr>EXE_stack 64</nobr></code>.
|
||||
<p>A sample program which generates a <code><nobr>.EXE</nobr></code> file
|
||||
in this way is given in the <code><nobr>test</nobr></code> subdirectory of
|
||||
the NASM archive, as <code><nobr>binexe.asm</nobr></code>.
|
||||
<h3><a name="section-7.2">7.2 Producing <code><nobr>.COM</nobr></code> Files</a></h3>
|
||||
<p>While large DOS programs must be written as
|
||||
<code><nobr>.EXE</nobr></code> files, small ones are often better written
|
||||
as <code><nobr>.COM</nobr></code> files. <code><nobr>.COM</nobr></code>
|
||||
files are pure binary, and therefore most easily produced using the
|
||||
<code><nobr>bin</nobr></code> output format.
|
||||
<h4><a name="section-7.2.1">7.2.1 Using the <code><nobr>bin</nobr></code> Format To Generate <code><nobr>.COM</nobr></code> Files</a></h4>
|
||||
<p><code><nobr>.COM</nobr></code> files expect to be loaded at offset
|
||||
<code><nobr>100h</nobr></code> into their segment (though the segment may
|
||||
change). Execution then begins at <code><nobr>100h</nobr></code>, i.e.
|
||||
right at the start of the program. So to write a
|
||||
<code><nobr>.COM</nobr></code> program, you would create a source file
|
||||
looking like
|
||||
<p><pre>
|
||||
org 100h
|
||||
|
||||
section .text
|
||||
|
||||
start:
|
||||
; put your code here
|
||||
|
||||
section .data
|
||||
|
||||
; put data items here
|
||||
|
||||
section .bss
|
||||
|
||||
; put uninitialised data here
|
||||
</pre>
|
||||
<p>The <code><nobr>bin</nobr></code> format puts the
|
||||
<code><nobr>.text</nobr></code> section first in the file, so you can
|
||||
declare data or BSS items before beginning to write code if you want to and
|
||||
the code will still end up at the front of the file where it belongs.
|
||||
<p>The BSS (uninitialised data) section does not take up space in the
|
||||
<code><nobr>.COM</nobr></code> file itself: instead, addresses of BSS items
|
||||
are resolved to point at space beyond the end of the file, on the grounds
|
||||
that this will be free memory when the program is run. Therefore you should
|
||||
not rely on your BSS being initialised to all zeros when you run.
|
||||
<p>To assemble the above program, you should use a command line like
|
||||
<p><pre>
|
||||
nasm myprog.asm -fbin -o myprog.com
|
||||
</pre>
|
||||
<p>The <code><nobr>bin</nobr></code> format would produce a file called
|
||||
<code><nobr>myprog</nobr></code> if no explicit output file name were
|
||||
specified, so you have to override it and give the desired file name.
|
||||
<h4><a name="section-7.2.2">7.2.2 Using the <code><nobr>obj</nobr></code> Format To Generate <code><nobr>.COM</nobr></code> Files</a></h4>
|
||||
<p>If you are writing a <code><nobr>.COM</nobr></code> program as more than
|
||||
one module, you may wish to assemble several <code><nobr>.OBJ</nobr></code>
|
||||
files and link them together into a <code><nobr>.COM</nobr></code> program.
|
||||
You can do this, provided you have a linker capable of outputting
|
||||
<code><nobr>.COM</nobr></code> files directly (TLINK does this), or
|
||||
alternatively a converter program such as <code><nobr>EXE2BIN</nobr></code>
|
||||
to transform the <code><nobr>.EXE</nobr></code> file output from the linker
|
||||
into a <code><nobr>.COM</nobr></code> file.
|
||||
<p>If you do this, you need to take care of several things:
|
||||
<ul>
|
||||
<li>The first object file containing code should start its code segment
|
||||
with a line like <code><nobr>RESB 100h</nobr></code>. This is to ensure
|
||||
that the code begins at offset <code><nobr>100h</nobr></code> relative to
|
||||
the beginning of the code segment, so that the linker or converter program
|
||||
does not have to adjust address references within the file when generating
|
||||
the <code><nobr>.COM</nobr></code> file. Other assemblers use an
|
||||
<code><nobr>ORG</nobr></code> directive for this purpose, but
|
||||
<code><nobr>ORG</nobr></code> in NASM is a format-specific directive to the
|
||||
<code><nobr>bin</nobr></code> output format, and does not mean the same
|
||||
thing as it does in MASM-compatible assemblers.
|
||||
<li>You don't need to define a stack segment.
|
||||
<li>All your segments should be in the same group, so that every time your
|
||||
code or data references a symbol offset, all offsets are relative to the
|
||||
same segment base. This is because, when a <code><nobr>.COM</nobr></code>
|
||||
file is loaded, all the segment registers contain the same value.
|
||||
</ul>
|
||||
<h3><a name="section-7.3">7.3 Producing <code><nobr>.SYS</nobr></code> Files</a></h3>
|
||||
<p>MS-DOS device drivers - <code><nobr>.SYS</nobr></code> files - are pure
|
||||
binary files, similar to <code><nobr>.COM</nobr></code> files, except that
|
||||
they start at origin zero rather than <code><nobr>100h</nobr></code>.
|
||||
Therefore, if you are writing a device driver using the
|
||||
<code><nobr>bin</nobr></code> format, you do not need the
|
||||
<code><nobr>ORG</nobr></code> directive, since the default origin for
|
||||
<code><nobr>bin</nobr></code> is zero. Similarly, if you are using
|
||||
<code><nobr>obj</nobr></code>, you do not need the
|
||||
<code><nobr>RESB 100h</nobr></code> at the start of your code segment.
|
||||
<p><code><nobr>.SYS</nobr></code> files start with a header structure,
|
||||
containing pointers to the various routines inside the driver which do the
|
||||
work. This structure should be defined at the start of the code segment,
|
||||
even though it is not actually code.
|
||||
<p>For more information on the format of <code><nobr>.SYS</nobr></code>
|
||||
files, and the data which has to go in the header structure, a list of
|
||||
books is given in the Frequently Asked Questions list for the newsgroup
|
||||
<a href="news:comp.os.msdos.programmer"><code><nobr>comp.os.msdos.programmer</nobr></code></a>.
|
||||
<h3><a name="section-7.4">7.4 Interfacing to 16-bit C Programs</a></h3>
|
||||
<p>This section covers the basics of writing assembly routines that call,
|
||||
or are called from, C programs. To do this, you would typically write an
|
||||
assembly module as a <code><nobr>.OBJ</nobr></code> file, and link it with
|
||||
your C modules to produce a mixed-language program.
|
||||
<h4><a name="section-7.4.1">7.4.1 External Symbol Names</a></h4>
|
||||
<p>C compilers have the convention that the names of all global symbols
|
||||
(functions or data) they define are formed by prefixing an underscore to
|
||||
the name as it appears in the C program. So, for example, the function a C
|
||||
programmer thinks of as <code><nobr>printf</nobr></code> appears to an
|
||||
assembly language programmer as <code><nobr>_printf</nobr></code>. This
|
||||
means that in your assembly programs, you can define symbols without a
|
||||
leading underscore, and not have to worry about name clashes with C
|
||||
symbols.
|
||||
<p>If you find the underscores inconvenient, you can define macros to
|
||||
replace the <code><nobr>GLOBAL</nobr></code> and
|
||||
<code><nobr>EXTERN</nobr></code> directives as follows:
|
||||
<p><pre>
|
||||
%macro cglobal 1
|
||||
|
||||
global _%1
|
||||
%define %1 _%1
|
||||
|
||||
%endmacro
|
||||
|
||||
%macro cextern 1
|
||||
|
||||
extern _%1
|
||||
%define %1 _%1
|
||||
|
||||
%endmacro
|
||||
</pre>
|
||||
<p>(These forms of the macros only take one argument at a time; a
|
||||
<code><nobr>%rep</nobr></code> construct could solve this.)
|
||||
<p>If you then declare an external like this:
|
||||
<p><pre>
|
||||
cextern printf
|
||||
</pre>
|
||||
<p>then the macro will expand it as
|
||||
<p><pre>
|
||||
extern _printf
|
||||
%define printf _printf
|
||||
</pre>
|
||||
<p>Thereafter, you can reference <code><nobr>printf</nobr></code> as if it
|
||||
was a symbol, and the preprocessor will put the leading underscore on where
|
||||
necessary.
|
||||
<p>The <code><nobr>cglobal</nobr></code> macro works similarly. You must
|
||||
use <code><nobr>cglobal</nobr></code> before defining the symbol in
|
||||
question, but you would have had to do that anyway if you used
|
||||
<code><nobr>GLOBAL</nobr></code>.
|
||||
<p>Also see <a href="nasmdoc2.html#section-2.1.21">section 2.1.21</a>.
|
||||
<h4><a name="section-7.4.2">7.4.2 Memory Models</a></h4>
|
||||
<p>NASM contains no mechanism to support the various C memory models
|
||||
directly; you have to keep track yourself of which one you are writing for.
|
||||
This means you have to keep track of the following things:
|
||||
<ul>
|
||||
<li>In models using a single code segment (tiny, small and compact),
|
||||
functions are near. This means that function pointers, when stored in data
|
||||
segments or pushed on the stack as function arguments, are 16 bits long and
|
||||
contain only an offset field (the <code><nobr>CS</nobr></code> register
|
||||
never changes its value, and always gives the segment part of the full
|
||||
function address), and that functions are called using ordinary near
|
||||
<code><nobr>CALL</nobr></code> instructions and return using
|
||||
<code><nobr>RETN</nobr></code> (which, in NASM, is synonymous with
|
||||
<code><nobr>RET</nobr></code> anyway). This means both that you should
|
||||
write your own routines to return with <code><nobr>RETN</nobr></code>, and
|
||||
that you should call external C routines with near
|
||||
<code><nobr>CALL</nobr></code> instructions.
|
||||
<li>In models using more than one code segment (medium, large and huge),
|
||||
functions are far. This means that function pointers are 32 bits long
|
||||
(consisting of a 16-bit offset followed by a 16-bit segment), and that
|
||||
functions are called using <code><nobr>CALL FAR</nobr></code> (or
|
||||
<code><nobr>CALL seg:offset</nobr></code>) and return using
|
||||
<code><nobr>RETF</nobr></code>. Again, you should therefore write your own
|
||||
routines to return with <code><nobr>RETF</nobr></code> and use
|
||||
<code><nobr>CALL FAR</nobr></code> to call external routines.
|
||||
<li>In models using a single data segment (tiny, small and medium), data
|
||||
pointers are 16 bits long, containing only an offset field (the
|
||||
<code><nobr>DS</nobr></code> register doesn't change its value, and always
|
||||
gives the segment part of the full data item address).
|
||||
<li>In models using more than one data segment (compact, large and huge),
|
||||
data pointers are 32 bits long, consisting of a 16-bit offset followed by a
|
||||
16-bit segment. You should still be careful not to modify
|
||||
<code><nobr>DS</nobr></code> in your routines without restoring it
|
||||
afterwards, but <code><nobr>ES</nobr></code> is free for you to use to
|
||||
access the contents of 32-bit data pointers you are passed.
|
||||
<li>The huge memory model allows single data items to exceed 64K in size.
|
||||
In all other memory models, you can access the whole of a data item just by
|
||||
doing arithmetic on the offset field of the pointer you are given, whether
|
||||
a segment field is present or not; in huge model, you have to be more
|
||||
careful of your pointer arithmetic.
|
||||
<li>In most memory models, there is a <em>default</em> data segment, whose
|
||||
segment address is kept in <code><nobr>DS</nobr></code> throughout the
|
||||
program. This data segment is typically the same segment as the stack, kept
|
||||
in <code><nobr>SS</nobr></code>, so that functions' local variables (which
|
||||
are stored on the stack) and global data items can both be accessed easily
|
||||
without changing <code><nobr>DS</nobr></code>. Particularly large data
|
||||
items are typically stored in other segments. However, some memory models
|
||||
(though not the standard ones, usually) allow the assumption that
|
||||
<code><nobr>SS</nobr></code> and <code><nobr>DS</nobr></code> hold the same
|
||||
value to be removed. Be careful about functions' local variables in this
|
||||
latter case.
|
||||
</ul>
|
||||
<p>In models with a single code segment, the segment is called
|
||||
<code><nobr>_TEXT</nobr></code>, so your code segment must also go by this
|
||||
name in order to be linked into the same place as the main code segment. In
|
||||
models with a single data segment, or with a default data segment, it is
|
||||
called <code><nobr>_DATA</nobr></code>.
|
||||
<h4><a name="section-7.4.3">7.4.3 Function Definitions and Function Calls</a></h4>
|
||||
<p>The C calling convention in 16-bit programs is as follows. In the
|
||||
following description, the words <em>caller</em> and <em>callee</em> are
|
||||
used to denote the function doing the calling and the function which gets
|
||||
called.
|
||||
<ul>
|
||||
<li>The caller pushes the function's parameters on the stack, one after
|
||||
another, in reverse order (right to left, so that the first argument
|
||||
specified to the function is pushed last).
|
||||
<li>The caller then executes a <code><nobr>CALL</nobr></code> instruction
|
||||
to pass control to the callee. This <code><nobr>CALL</nobr></code> is
|
||||
either near or far depending on the memory model.
|
||||
<li>The callee receives control, and typically (although this is not
|
||||
actually necessary, in functions which do not need to access their
|
||||
parameters) starts by saving the value of <code><nobr>SP</nobr></code> in
|
||||
<code><nobr>BP</nobr></code> so as to be able to use
|
||||
<code><nobr>BP</nobr></code> as a base pointer to find its parameters on
|
||||
the stack. However, the caller was probably doing this too, so part of the
|
||||
calling convention states that <code><nobr>BP</nobr></code> must be
|
||||
preserved by any C function. Hence the callee, if it is going to set up
|
||||
<code><nobr>BP</nobr></code> as a <em>frame pointer</em>, must push the
|
||||
previous value first.
|
||||
<li>The callee may then access its parameters relative to
|
||||
<code><nobr>BP</nobr></code>. The word at <code><nobr>[BP]</nobr></code>
|
||||
holds the previous value of <code><nobr>BP</nobr></code> as it was pushed;
|
||||
the next word, at <code><nobr>[BP+2]</nobr></code>, holds the offset part
|
||||
of the return address, pushed implicitly by <code><nobr>CALL</nobr></code>.
|
||||
In a small-model (near) function, the parameters start after that, at
|
||||
<code><nobr>[BP+4]</nobr></code>; in a large-model (far) function, the
|
||||
segment part of the return address lives at
|
||||
<code><nobr>[BP+4]</nobr></code>, and the parameters begin at
|
||||
<code><nobr>[BP+6]</nobr></code>. The leftmost parameter of the function,
|
||||
since it was pushed last, is accessible at this offset from
|
||||
<code><nobr>BP</nobr></code>; the others follow, at successively greater
|
||||
offsets. Thus, in a function such as <code><nobr>printf</nobr></code> which
|
||||
takes a variable number of parameters, the pushing of the parameters in
|
||||
reverse order means that the function knows where to find its first
|
||||
parameter, which tells it the number and type of the remaining ones.
|
||||
<li>The callee may also wish to decrease <code><nobr>SP</nobr></code>
|
||||
further, so as to allocate space on the stack for local variables, which
|
||||
will then be accessible at negative offsets from
|
||||
<code><nobr>BP</nobr></code>.
|
||||
<li>The callee, if it wishes to return a value to the caller, should leave
|
||||
the value in <code><nobr>AL</nobr></code>, <code><nobr>AX</nobr></code> or
|
||||
<code><nobr>DX:AX</nobr></code> depending on the size of the value.
|
||||
Floating-point results are sometimes (depending on the compiler) returned
|
||||
in <code><nobr>ST0</nobr></code>.
|
||||
<li>Once the callee has finished processing, it restores
|
||||
<code><nobr>SP</nobr></code> from <code><nobr>BP</nobr></code> if it had
|
||||
allocated local stack space, then pops the previous value of
|
||||
<code><nobr>BP</nobr></code>, and returns via
|
||||
<code><nobr>RETN</nobr></code> or <code><nobr>RETF</nobr></code> depending
|
||||
on memory model.
|
||||
<li>When the caller regains control from the callee, the function
|
||||
parameters are still on the stack, so it typically adds an immediate
|
||||
constant to <code><nobr>SP</nobr></code> to remove them (instead of
|
||||
executing a number of slow <code><nobr>POP</nobr></code> instructions).
|
||||
Thus, if a function is accidentally called with the wrong number of
|
||||
parameters due to a prototype mismatch, the stack will still be returned to
|
||||
a sensible state since the caller, which <em>knows</em> how many parameters
|
||||
it pushed, does the removing.
|
||||
</ul>
|
||||
<p>It is instructive to compare this calling convention with that for
|
||||
Pascal programs (described in <a href="#section-7.5.1">section 7.5.1</a>).
|
||||
Pascal has a simpler convention, since no functions have variable numbers
|
||||
of parameters. Therefore the callee knows how many parameters it should
|
||||
have been passed, and is able to deallocate them from the stack itself by
|
||||
passing an immediate argument to the <code><nobr>RET</nobr></code> or
|
||||
<code><nobr>RETF</nobr></code> instruction, so the caller does not have to
|
||||
do it. Also, the parameters are pushed in left-to-right order, not
|
||||
right-to-left, which means that a compiler can give better guarantees about
|
||||
sequence points without performance suffering.
|
||||
<p>Thus, you would define a function in C style in the following way. The
|
||||
following example is for small model:
|
||||
<p><pre>
|
||||
global _myfunc
|
||||
|
||||
_myfunc:
|
||||
push bp
|
||||
mov bp,sp
|
||||
sub sp,0x40 ; 64 bytes of local stack space
|
||||
mov bx,[bp+4] ; first parameter to function
|
||||
|
||||
; some more code
|
||||
|
||||
mov sp,bp ; undo "sub sp,0x40" above
|
||||
pop bp
|
||||
ret
|
||||
</pre>
|
||||
<p>For a large-model function, you would replace
|
||||
<code><nobr>RET</nobr></code> by <code><nobr>RETF</nobr></code>, and look
|
||||
for the first parameter at <code><nobr>[BP+6]</nobr></code> instead of
|
||||
<code><nobr>[BP+4]</nobr></code>. Of course, if one of the parameters is a
|
||||
pointer, then the offsets of <em>subsequent</em> parameters will change
|
||||
depending on the memory model as well: far pointers take up four bytes on
|
||||
the stack when passed as a parameter, whereas near pointers take up two.
|
||||
<p>At the other end of the process, to call a C function from your assembly
|
||||
code, you would do something like this:
|
||||
<p><pre>
|
||||
extern _printf
|
||||
|
||||
; and then, further down...
|
||||
|
||||
push word [myint] ; one of my integer variables
|
||||
push word mystring ; pointer into my data segment
|
||||
call _printf
|
||||
add sp,byte 4 ; `byte' saves space
|
||||
|
||||
; then those data items...
|
||||
|
||||
segment _DATA
|
||||
|
||||
myint dw 1234
|
||||
mystring db 'This number -> %d <- should be 1234',10,0
|
||||
</pre>
|
||||
<p>This piece of code is the small-model assembly equivalent of the C code
|
||||
<p><pre>
|
||||
int myint = 1234;
|
||||
printf("This number -> %d <- should be 1234\n", myint);
|
||||
</pre>
|
||||
<p>In large model, the function-call code might look more like this. In
|
||||
this example, it is assumed that <code><nobr>DS</nobr></code> already holds
|
||||
the segment base of the segment <code><nobr>_DATA</nobr></code>. If not,
|
||||
you would have to initialise it first.
|
||||
<p><pre>
|
||||
push word [myint]
|
||||
push word seg mystring ; Now push the segment, and...
|
||||
push word mystring ; ... offset of "mystring"
|
||||
call far _printf
|
||||
add sp,byte 6
|
||||
</pre>
|
||||
<p>The integer value still takes up one word on the stack, since large
|
||||
model does not affect the size of the <code><nobr>int</nobr></code> data
|
||||
type. The first argument (pushed last) to <code><nobr>printf</nobr></code>,
|
||||
however, is a data pointer, and therefore has to contain a segment and
|
||||
offset part. The segment should be stored second in memory, and therefore
|
||||
must be pushed first. (Of course, <code><nobr>PUSH DS</nobr></code> would
|
||||
have been a shorter instruction than
|
||||
<code><nobr>PUSH WORD SEG mystring</nobr></code>, if
|
||||
<code><nobr>DS</nobr></code> was set up as the above example assumed.) Then
|
||||
the actual call becomes a far call, since functions expect far calls in
|
||||
large model; and <code><nobr>SP</nobr></code> has to be increased by 6
|
||||
rather than 4 afterwards to make up for the extra word of parameters.
|
||||
<h4><a name="section-7.4.4">7.4.4 Accessing Data Items</a></h4>
|
||||
<p>To get at the contents of C variables, or to declare variables which C
|
||||
can access, you need only declare the names as
|
||||
<code><nobr>GLOBAL</nobr></code> or <code><nobr>EXTERN</nobr></code>.
|
||||
(Again, the names require leading underscores, as stated in
|
||||
<a href="#section-7.4.1">section 7.4.1</a>.) Thus, a C variable declared as
|
||||
<code><nobr>int i</nobr></code> can be accessed from assembler as
|
||||
<p><pre>
|
||||
extern _i
|
||||
|
||||
mov ax,[_i]
|
||||
</pre>
|
||||
<p>And to declare your own integer variable which C programs can access as
|
||||
<code><nobr>extern int j</nobr></code>, you do this (making sure you are
|
||||
assembling in the <code><nobr>_DATA</nobr></code> segment, if necessary):
|
||||
<p><pre>
|
||||
global _j
|
||||
|
||||
_j dw 0
|
||||
</pre>
|
||||
<p>To access a C array, you need to know the size of the components of the
|
||||
array. For example, <code><nobr>int</nobr></code> variables are two bytes
|
||||
long, so if a C program declares an array as
|
||||
<code><nobr>int a[10]</nobr></code>, you can access
|
||||
<code><nobr>a[3]</nobr></code> by coding
|
||||
<code><nobr>mov ax,[_a+6]</nobr></code>. (The byte offset 6 is obtained by
|
||||
multiplying the desired array index, 3, by the size of the array element,
|
||||
2.) The sizes of the C base types in 16-bit compilers are: 1 for
|
||||
<code><nobr>char</nobr></code>, 2 for <code><nobr>short</nobr></code> and
|
||||
<code><nobr>int</nobr></code>, 4 for <code><nobr>long</nobr></code> and
|
||||
<code><nobr>float</nobr></code>, and 8 for
|
||||
<code><nobr>double</nobr></code>.
|
||||
<p>To access a C data structure, you need to know the offset from the base
|
||||
of the structure to the field you are interested in. You can either do this
|
||||
by converting the C structure definition into a NASM structure definition
|
||||
(using <code><nobr>STRUC</nobr></code>), or by calculating the one offset
|
||||
and using just that.
|
||||
<p>To do either of these, you should read your C compiler's manual to find
|
||||
out how it organises data structures. NASM gives no special alignment to
|
||||
structure members in its own <code><nobr>STRUC</nobr></code> macro, so you
|
||||
have to specify alignment yourself if the C compiler generates it.
|
||||
Typically, you might find that a structure like
|
||||
<p><pre>
|
||||
struct {
|
||||
char c;
|
||||
int i;
|
||||
} foo;
|
||||
</pre>
|
||||
<p>might be four bytes long rather than three, since the
|
||||
<code><nobr>int</nobr></code> field would be aligned to a two-byte
|
||||
boundary. However, this sort of feature tends to be a configurable option
|
||||
in the C compiler, either using command-line options or
|
||||
<code><nobr>#pragma</nobr></code> lines, so you have to find out how your
|
||||
own compiler does it.
|
||||
<h4><a name="section-7.4.5">7.4.5 <code><nobr>c16.mac</nobr></code>: Helper Macros for the 16-bit C Interface</a></h4>
|
||||
<p>Included in the NASM archives, in the <code><nobr>misc</nobr></code>
|
||||
directory, is a file <code><nobr>c16.mac</nobr></code> of macros. It
|
||||
defines three macros: <code><nobr>proc</nobr></code>,
|
||||
<code><nobr>arg</nobr></code> and <code><nobr>endproc</nobr></code>. These
|
||||
are intended to be used for C-style procedure definitions, and they
|
||||
automate a lot of the work involved in keeping track of the calling
|
||||
convention.
|
||||
<p>(An alternative, TASM compatible form of <code><nobr>arg</nobr></code>
|
||||
is also now built into NASM's preprocessor. See
|
||||
<a href="nasmdoc4.html#section-4.9">section 4.9</a> for details.)
|
||||
<p>An example of an assembly function using the macro set is given here:
|
||||
<p><pre>
|
||||
proc _nearproc
|
||||
|
||||
%$i arg
|
||||
%$j arg
|
||||
mov ax,[bp + %$i]
|
||||
mov bx,[bp + %$j]
|
||||
add ax,[bx]
|
||||
|
||||
endproc
|
||||
</pre>
|
||||
<p>This defines <code><nobr>_nearproc</nobr></code> to be a procedure
|
||||
taking two arguments, the first (<code><nobr>i</nobr></code>) an integer
|
||||
and the second (<code><nobr>j</nobr></code>) a pointer to an integer. It
|
||||
returns <code><nobr>i + *j</nobr></code>.
|
||||
<p>Note that the <code><nobr>arg</nobr></code> macro has an
|
||||
<code><nobr>EQU</nobr></code> as the first line of its expansion, and since
|
||||
the label before the macro call gets prepended to the first line of the
|
||||
expanded macro, the <code><nobr>EQU</nobr></code> works, defining
|
||||
<code><nobr>%$i</nobr></code> to be an offset from
|
||||
<code><nobr>BP</nobr></code>. A context-local variable is used, local to
|
||||
the context pushed by the <code><nobr>proc</nobr></code> macro and popped
|
||||
by the <code><nobr>endproc</nobr></code> macro, so that the same argument
|
||||
name can be used in later procedures. Of course, you don't <em>have</em> to
|
||||
do that.
|
||||
<p>The macro set produces code for near functions (tiny, small and
|
||||
compact-model code) by default. You can have it generate far functions
|
||||
(medium, large and huge-model code) by means of coding
|
||||
<code><nobr>%define FARCODE</nobr></code>. This changes the kind of return
|
||||
instruction generated by <code><nobr>endproc</nobr></code>, and also
|
||||
changes the starting point for the argument offsets. The macro set contains
|
||||
no intrinsic dependency on whether data pointers are far or not.
|
||||
<p><code><nobr>arg</nobr></code> can take an optional parameter, giving the
|
||||
size of the argument. If no size is given, 2 is assumed, since it is likely
|
||||
that many function parameters will be of type
|
||||
<code><nobr>int</nobr></code>.
|
||||
<p>The large-model equivalent of the above function would look like this:
|
||||
<p><pre>
|
||||
%define FARCODE
|
||||
|
||||
proc _farproc
|
||||
|
||||
%$i arg
|
||||
%$j arg 4
|
||||
mov ax,[bp + %$i]
|
||||
mov bx,[bp + %$j]
|
||||
mov es,[bp + %$j + 2]
|
||||
add ax,[bx]
|
||||
|
||||
endproc
|
||||
</pre>
|
||||
<p>This makes use of the argument to the <code><nobr>arg</nobr></code>
|
||||
macro to define a parameter of size 4, because <code><nobr>j</nobr></code>
|
||||
is now a far pointer. When we load from <code><nobr>j</nobr></code>, we
|
||||
must load a segment and an offset.
|
||||
<h3><a name="section-7.5">7.5 Interfacing to Borland Pascal Programs</a></h3>
|
||||
<p>Interfacing to Borland Pascal programs is similar in concept to
|
||||
interfacing to 16-bit C programs. The differences are:
|
||||
<ul>
|
||||
<li>The leading underscore required for interfacing to C programs is not
|
||||
required for Pascal.
|
||||
<li>The memory model is always large: functions are far, data pointers are
|
||||
far, and no data item can be more than 64K long. (Actually, some functions
|
||||
are near, but only those functions that are local to a Pascal unit and
|
||||
never called from outside it. All assembly functions that Pascal calls, and
|
||||
all Pascal functions that assembly routines are able to call, are far.)
|
||||
However, all static data declared in a Pascal program goes into the default
|
||||
data segment, which is the one whose segment address will be in
|
||||
<code><nobr>DS</nobr></code> when control is passed to your assembly code.
|
||||
The only things that do not live in the default data segment are local
|
||||
variables (they live in the stack segment) and dynamically allocated
|
||||
variables. All data <em>pointers</em>, however, are far.
|
||||
<li>The function calling convention is different - described below.
|
||||
<li>Some data types, such as strings, are stored differently.
|
||||
<li>There are restrictions on the segment names you are allowed to use -
|
||||
Borland Pascal will ignore code or data declared in a segment it doesn't
|
||||
like the name of. The restrictions are described below.
|
||||
</ul>
|
||||
<h4><a name="section-7.5.1">7.5.1 The Pascal Calling Convention</a></h4>
|
||||
<p>The 16-bit Pascal calling convention is as follows. In the following
|
||||
description, the words <em>caller</em> and <em>callee</em> are used to
|
||||
denote the function doing the calling and the function which gets called.
|
||||
<ul>
|
||||
<li>The caller pushes the function's parameters on the stack, one after
|
||||
another, in normal order (left to right, so that the first argument
|
||||
specified to the function is pushed first).
|
||||
<li>The caller then executes a far <code><nobr>CALL</nobr></code>
|
||||
instruction to pass control to the callee.
|
||||
<li>The callee receives control, and typically (although this is not
|
||||
actually necessary, in functions which do not need to access their
|
||||
parameters) starts by saving the value of <code><nobr>SP</nobr></code> in
|
||||
<code><nobr>BP</nobr></code> so as to be able to use
|
||||
<code><nobr>BP</nobr></code> as a base pointer to find its parameters on
|
||||
the stack. However, the caller was probably doing this too, so part of the
|
||||
calling convention states that <code><nobr>BP</nobr></code> must be
|
||||
preserved by any function. Hence the callee, if it is going to set up
|
||||
<code><nobr>BP</nobr></code> as a frame pointer, must push the previous
|
||||
value first.
|
||||
<li>The callee may then access its parameters relative to
|
||||
<code><nobr>BP</nobr></code>. The word at <code><nobr>[BP]</nobr></code>
|
||||
holds the previous value of <code><nobr>BP</nobr></code> as it was pushed.
|
||||
The next word, at <code><nobr>[BP+2]</nobr></code>, holds the offset part
|
||||
of the return address, and the next one at <code><nobr>[BP+4]</nobr></code>
|
||||
the segment part. The parameters begin at <code><nobr>[BP+6]</nobr></code>.
|
||||
The rightmost parameter of the function, since it was pushed last, is
|
||||
accessible at this offset from <code><nobr>BP</nobr></code>; the others
|
||||
follow, at successively greater offsets.
|
||||
<li>The callee may also wish to decrease <code><nobr>SP</nobr></code>
|
||||
further, so as to allocate space on the stack for local variables, which
|
||||
will then be accessible at negative offsets from
|
||||
<code><nobr>BP</nobr></code>.
|
||||
<li>The callee, if it wishes to return a value to the caller, should leave
|
||||
the value in <code><nobr>AL</nobr></code>, <code><nobr>AX</nobr></code> or
|
||||
<code><nobr>DX:AX</nobr></code> depending on the size of the value.
|
||||
Floating-point results are returned in <code><nobr>ST0</nobr></code>.
|
||||
Results of type <code><nobr>Real</nobr></code> (Borland's own custom
|
||||
floating-point data type, not handled directly by the FPU) are returned in
|
||||
<code><nobr>DX:BX:AX</nobr></code>. To return a result of type
|
||||
<code><nobr>String</nobr></code>, the caller pushes a pointer to a
|
||||
temporary string before pushing the parameters, and the callee places the
|
||||
returned string value at that location. The pointer is not a parameter, and
|
||||
should not be removed from the stack by the <code><nobr>RETF</nobr></code>
|
||||
instruction.
|
||||
<li>Once the callee has finished processing, it restores
|
||||
<code><nobr>SP</nobr></code> from <code><nobr>BP</nobr></code> if it had
|
||||
allocated local stack space, then pops the previous value of
|
||||
<code><nobr>BP</nobr></code>, and returns via
|
||||
<code><nobr>RETF</nobr></code>. It uses the form of
|
||||
<code><nobr>RETF</nobr></code> with an immediate parameter, giving the
|
||||
number of bytes taken up by the parameters on the stack. This causes the
|
||||
parameters to be removed from the stack as a side effect of the return
|
||||
instruction.
|
||||
<li>When the caller regains control from the callee, the function
|
||||
parameters have already been removed from the stack, so it needs to do
|
||||
nothing further.
|
||||
</ul>
|
||||
<p>Thus, you would define a function in Pascal style, taking two
|
||||
<code><nobr>Integer</nobr></code>-type parameters, in the following way:
|
||||
<p><pre>
|
||||
global myfunc
|
||||
|
||||
myfunc: push bp
|
||||
mov bp,sp
|
||||
sub sp,0x40 ; 64 bytes of local stack space
|
||||
mov bx,[bp+8] ; first parameter to function
|
||||
mov bx,[bp+6] ; second parameter to function
|
||||
|
||||
; some more code
|
||||
|
||||
mov sp,bp ; undo "sub sp,0x40" above
|
||||
pop bp
|
||||
retf 4 ; total size of params is 4
|
||||
</pre>
|
||||
<p>At the other end of the process, to call a Pascal function from your
|
||||
assembly code, you would do something like this:
|
||||
<p><pre>
|
||||
extern SomeFunc
|
||||
|
||||
; and then, further down...
|
||||
|
||||
push word seg mystring ; Now push the segment, and...
|
||||
push word mystring ; ... offset of "mystring"
|
||||
push word [myint] ; one of my variables
|
||||
call far SomeFunc
|
||||
</pre>
|
||||
<p>This is equivalent to the Pascal code
|
||||
<p><pre>
|
||||
procedure SomeFunc(String: PChar; Int: Integer);
|
||||
SomeFunc(@mystring, myint);
|
||||
</pre>
|
||||
<h4><a name="section-7.5.2">7.5.2 Borland Pascal Segment Name Restrictions</a></h4>
|
||||
<p>Since Borland Pascal's internal unit file format is completely different
|
||||
from <code><nobr>OBJ</nobr></code>, it only makes a very sketchy job of
|
||||
actually reading and understanding the various information contained in a
|
||||
real <code><nobr>OBJ</nobr></code> file when it links that in. Therefore an
|
||||
object file intended to be linked to a Pascal program must obey a number of
|
||||
restrictions:
|
||||
<ul>
|
||||
<li>Procedures and functions must be in a segment whose name is either
|
||||
<code><nobr>CODE</nobr></code>, <code><nobr>CSEG</nobr></code>, or
|
||||
something ending in <code><nobr>_TEXT</nobr></code>.
|
||||
<li>Initialised data must be in a segment whose name is either
|
||||
<code><nobr>CONST</nobr></code> or something ending in
|
||||
<code><nobr>_DATA</nobr></code>.
|
||||
<li>Uninitialised data must be in a segment whose name is either
|
||||
<code><nobr>DATA</nobr></code>, <code><nobr>DSEG</nobr></code>, or
|
||||
something ending in <code><nobr>_BSS</nobr></code>.
|
||||
<li>Any other segments in the object file are completely ignored.
|
||||
<code><nobr>GROUP</nobr></code> directives and segment attributes are also
|
||||
ignored.
|
||||
</ul>
|
||||
<h4><a name="section-7.5.3">7.5.3 Using <code><nobr>c16.mac</nobr></code> With Pascal Programs</a></h4>
|
||||
<p>The <code><nobr>c16.mac</nobr></code> macro package, described in
|
||||
<a href="#section-7.4.5">section 7.4.5</a>, can also be used to simplify
|
||||
writing functions to be called from Pascal programs, if you code
|
||||
<code><nobr>%define PASCAL</nobr></code>. This definition ensures that
|
||||
functions are far (it implies <code><nobr>FARCODE</nobr></code>), and also
|
||||
causes procedure return instructions to be generated with an operand.
|
||||
<p>Defining <code><nobr>PASCAL</nobr></code> does not change the code which
|
||||
calculates the argument offsets; you must declare your function's arguments
|
||||
in reverse order. For example:
|
||||
<p><pre>
|
||||
%define PASCAL
|
||||
|
||||
proc _pascalproc
|
||||
|
||||
%$j arg 4
|
||||
%$i arg
|
||||
mov ax,[bp + %$i]
|
||||
mov bx,[bp + %$j]
|
||||
mov es,[bp + %$j + 2]
|
||||
add ax,[bx]
|
||||
|
||||
endproc
|
||||
</pre>
|
||||
<p>This defines the same routine, conceptually, as the example in
|
||||
<a href="#section-7.4.5">section 7.4.5</a>: it defines a function taking
|
||||
two arguments, an integer and a pointer to an integer, which returns the
|
||||
sum of the integer and the contents of the pointer. The only difference
|
||||
between this code and the large-model C version is that
|
||||
<code><nobr>PASCAL</nobr></code> is defined instead of
|
||||
<code><nobr>FARCODE</nobr></code>, and that the arguments are declared in
|
||||
reverse order.
|
||||
<p align=center><a href="nasmdoc8.html">Next Chapter</a> |
|
||||
<a href="nasmdoc6.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
</body></html>
|
||||
482
Ref-docs/nasmdoc/html/nasmdoc8.html
Normal file
482
Ref-docs/nasmdoc/html/nasmdoc8.html
Normal file
@@ -0,0 +1,482 @@
|
||||
<html><head><title>NASM Manual</title></head>
|
||||
<body><h1 align=center>The Netwide Assembler: NASM</h1>
|
||||
|
||||
<p align=center><a href="nasmdoc9.html">Next Chapter</a> |
|
||||
<a href="nasmdoc7.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
<h2><a name="chapter-8">Chapter 8: Writing 32-bit Code (Unix, Win32, DJGPP)</a></h2>
|
||||
<p>This chapter attempts to cover some of the common issues involved when
|
||||
writing 32-bit code, to run under Win32 or Unix, or to be linked with C
|
||||
code generated by a Unix-style C compiler such as DJGPP. It covers how to
|
||||
write assembly code to interface with 32-bit C routines, and how to write
|
||||
position-independent code for shared libraries.
|
||||
<p>Almost all 32-bit code, and in particular all code running under
|
||||
<code><nobr>Win32</nobr></code>, <code><nobr>DJGPP</nobr></code> or any of
|
||||
the PC Unix variants, runs in <em>flat</em> memory model. This means that
|
||||
the segment registers and paging have already been set up to give you the
|
||||
same 32-bit 4Gb address space no matter what segment you work relative to,
|
||||
and that you should ignore all segment registers completely. When writing
|
||||
flat-model application code, you never need to use a segment override or
|
||||
modify any segment register, and the code-section addresses you pass to
|
||||
<code><nobr>CALL</nobr></code> and <code><nobr>JMP</nobr></code> live in
|
||||
the same address space as the data-section addresses you access your
|
||||
variables by and the stack-section addresses you access local variables and
|
||||
procedure parameters by. Every address is 32 bits long and contains only an
|
||||
offset part.
|
||||
<h3><a name="section-8.1">8.1 Interfacing to 32-bit C Programs</a></h3>
|
||||
<p>A lot of the discussion in <a href="nasmdoc7.html#section-7.4">section
|
||||
7.4</a>, about interfacing to 16-bit C programs, still applies when working
|
||||
in 32 bits. The absence of memory models or segmentation worries simplifies
|
||||
things a lot.
|
||||
<h4><a name="section-8.1.1">8.1.1 External Symbol Names</a></h4>
|
||||
<p>Most 32-bit C compilers share the convention used by 16-bit compilers,
|
||||
that the names of all global symbols (functions or data) they define are
|
||||
formed by prefixing an underscore to the name as it appears in the C
|
||||
program. However, not all of them do: the <code><nobr>ELF</nobr></code>
|
||||
specification states that C symbols do <em>not</em> have a leading
|
||||
underscore on their assembly-language names.
|
||||
<p>The older Linux <code><nobr>a.out</nobr></code> C compiler, all
|
||||
<code><nobr>Win32</nobr></code> compilers, <code><nobr>DJGPP</nobr></code>,
|
||||
and <code><nobr>NetBSD</nobr></code> and <code><nobr>FreeBSD</nobr></code>,
|
||||
all use the leading underscore; for these compilers, the macros
|
||||
<code><nobr>cextern</nobr></code> and <code><nobr>cglobal</nobr></code>, as
|
||||
given in <a href="nasmdoc7.html#section-7.4.1">section 7.4.1</a>, will
|
||||
still work. For <code><nobr>ELF</nobr></code>, though, the leading
|
||||
underscore should not be used.
|
||||
<p>See also <a href="nasmdoc2.html#section-2.1.21">section 2.1.21</a>.
|
||||
<h4><a name="section-8.1.2">8.1.2 Function Definitions and Function Calls</a></h4>
|
||||
<p>The C calling conventionThe C calling convention in 32-bit programs is
|
||||
as follows. In the following description, the words <em>caller</em> and
|
||||
<em>callee</em> are used to denote the function doing the calling and the
|
||||
function which gets called.
|
||||
<ul>
|
||||
<li>The caller pushes the function's parameters on the stack, one after
|
||||
another, in reverse order (right to left, so that the first argument
|
||||
specified to the function is pushed last).
|
||||
<li>The caller then executes a near <code><nobr>CALL</nobr></code>
|
||||
instruction to pass control to the callee.
|
||||
<li>The callee receives control, and typically (although this is not
|
||||
actually necessary, in functions which do not need to access their
|
||||
parameters) starts by saving the value of <code><nobr>ESP</nobr></code> in
|
||||
<code><nobr>EBP</nobr></code> so as to be able to use
|
||||
<code><nobr>EBP</nobr></code> as a base pointer to find its parameters on
|
||||
the stack. However, the caller was probably doing this too, so part of the
|
||||
calling convention states that <code><nobr>EBP</nobr></code> must be
|
||||
preserved by any C function. Hence the callee, if it is going to set up
|
||||
<code><nobr>EBP</nobr></code> as a frame pointer, must push the previous
|
||||
value first.
|
||||
<li>The callee may then access its parameters relative to
|
||||
<code><nobr>EBP</nobr></code>. The doubleword at
|
||||
<code><nobr>[EBP]</nobr></code> holds the previous value of
|
||||
<code><nobr>EBP</nobr></code> as it was pushed; the next doubleword, at
|
||||
<code><nobr>[EBP+4]</nobr></code>, holds the return address, pushed
|
||||
implicitly by <code><nobr>CALL</nobr></code>. The parameters start after
|
||||
that, at <code><nobr>[EBP+8]</nobr></code>. The leftmost parameter of the
|
||||
function, since it was pushed last, is accessible at this offset from
|
||||
<code><nobr>EBP</nobr></code>; the others follow, at successively greater
|
||||
offsets. Thus, in a function such as <code><nobr>printf</nobr></code> which
|
||||
takes a variable number of parameters, the pushing of the parameters in
|
||||
reverse order means that the function knows where to find its first
|
||||
parameter, which tells it the number and type of the remaining ones.
|
||||
<li>The callee may also wish to decrease <code><nobr>ESP</nobr></code>
|
||||
further, so as to allocate space on the stack for local variables, which
|
||||
will then be accessible at negative offsets from
|
||||
<code><nobr>EBP</nobr></code>.
|
||||
<li>The callee, if it wishes to return a value to the caller, should leave
|
||||
the value in <code><nobr>AL</nobr></code>, <code><nobr>AX</nobr></code> or
|
||||
<code><nobr>EAX</nobr></code> depending on the size of the value.
|
||||
Floating-point results are typically returned in
|
||||
<code><nobr>ST0</nobr></code>.
|
||||
<li>Once the callee has finished processing, it restores
|
||||
<code><nobr>ESP</nobr></code> from <code><nobr>EBP</nobr></code> if it had
|
||||
allocated local stack space, then pops the previous value of
|
||||
<code><nobr>EBP</nobr></code>, and returns via
|
||||
<code><nobr>RET</nobr></code> (equivalently,
|
||||
<code><nobr>RETN</nobr></code>).
|
||||
<li>When the caller regains control from the callee, the function
|
||||
parameters are still on the stack, so it typically adds an immediate
|
||||
constant to <code><nobr>ESP</nobr></code> to remove them (instead of
|
||||
executing a number of slow <code><nobr>POP</nobr></code> instructions).
|
||||
Thus, if a function is accidentally called with the wrong number of
|
||||
parameters due to a prototype mismatch, the stack will still be returned to
|
||||
a sensible state since the caller, which <em>knows</em> how many parameters
|
||||
it pushed, does the removing.
|
||||
</ul>
|
||||
<p>There is an alternative calling convention used by Win32 programs for
|
||||
Windows API calls, and also for functions called <em>by</em> the Windows
|
||||
API such as window procedures: they follow what Microsoft calls the
|
||||
<code><nobr>__stdcall</nobr></code> convention. This is slightly closer to
|
||||
the Pascal convention, in that the callee clears the stack by passing a
|
||||
parameter to the <code><nobr>RET</nobr></code> instruction. However, the
|
||||
parameters are still pushed in right-to-left order.
|
||||
<p>Thus, you would define a function in C style in the following way:
|
||||
<p><pre>
|
||||
global _myfunc
|
||||
|
||||
_myfunc:
|
||||
push ebp
|
||||
mov ebp,esp
|
||||
sub esp,0x40 ; 64 bytes of local stack space
|
||||
mov ebx,[ebp+8] ; first parameter to function
|
||||
|
||||
; some more code
|
||||
|
||||
leave ; mov esp,ebp / pop ebp
|
||||
ret
|
||||
</pre>
|
||||
<p>At the other end of the process, to call a C function from your assembly
|
||||
code, you would do something like this:
|
||||
<p><pre>
|
||||
extern _printf
|
||||
|
||||
; and then, further down...
|
||||
|
||||
push dword [myint] ; one of my integer variables
|
||||
push dword mystring ; pointer into my data segment
|
||||
call _printf
|
||||
add esp,byte 8 ; `byte' saves space
|
||||
|
||||
; then those data items...
|
||||
|
||||
segment _DATA
|
||||
|
||||
myint dd 1234
|
||||
mystring db 'This number -> %d <- should be 1234',10,0
|
||||
</pre>
|
||||
<p>This piece of code is the assembly equivalent of the C code
|
||||
<p><pre>
|
||||
int myint = 1234;
|
||||
printf("This number -> %d <- should be 1234\n", myint);
|
||||
</pre>
|
||||
<h4><a name="section-8.1.3">8.1.3 Accessing Data Items</a></h4>
|
||||
<p>To get at the contents of C variables, or to declare variables which C
|
||||
can access, you need only declare the names as
|
||||
<code><nobr>GLOBAL</nobr></code> or <code><nobr>EXTERN</nobr></code>.
|
||||
(Again, the names require leading underscores, as stated in
|
||||
<a href="#section-8.1.1">section 8.1.1</a>.) Thus, a C variable declared as
|
||||
<code><nobr>int i</nobr></code> can be accessed from assembler as
|
||||
<p><pre>
|
||||
extern _i
|
||||
mov eax,[_i]
|
||||
</pre>
|
||||
<p>And to declare your own integer variable which C programs can access as
|
||||
<code><nobr>extern int j</nobr></code>, you do this (making sure you are
|
||||
assembling in the <code><nobr>_DATA</nobr></code> segment, if necessary):
|
||||
<p><pre>
|
||||
global _j
|
||||
_j dd 0
|
||||
</pre>
|
||||
<p>To access a C array, you need to know the size of the components of the
|
||||
array. For example, <code><nobr>int</nobr></code> variables are four bytes
|
||||
long, so if a C program declares an array as
|
||||
<code><nobr>int a[10]</nobr></code>, you can access
|
||||
<code><nobr>a[3]</nobr></code> by coding
|
||||
<code><nobr>mov ax,[_a+12]</nobr></code>. (The byte offset 12 is obtained
|
||||
by multiplying the desired array index, 3, by the size of the array
|
||||
element, 4.) The sizes of the C base types in 32-bit compilers are: 1 for
|
||||
<code><nobr>char</nobr></code>, 2 for <code><nobr>short</nobr></code>, 4
|
||||
for <code><nobr>int</nobr></code>, <code><nobr>long</nobr></code> and
|
||||
<code><nobr>float</nobr></code>, and 8 for
|
||||
<code><nobr>double</nobr></code>. Pointers, being 32-bit addresses, are
|
||||
also 4 bytes long.
|
||||
<p>To access a C data structure, you need to know the offset from the base
|
||||
of the structure to the field you are interested in. You can either do this
|
||||
by converting the C structure definition into a NASM structure definition
|
||||
(using <code><nobr>STRUC</nobr></code>), or by calculating the one offset
|
||||
and using just that.
|
||||
<p>To do either of these, you should read your C compiler's manual to find
|
||||
out how it organises data structures. NASM gives no special alignment to
|
||||
structure members in its own <code><nobr>STRUC</nobr></code> macro, so you
|
||||
have to specify alignment yourself if the C compiler generates it.
|
||||
Typically, you might find that a structure like
|
||||
<p><pre>
|
||||
struct {
|
||||
char c;
|
||||
int i;
|
||||
} foo;
|
||||
</pre>
|
||||
<p>might be eight bytes long rather than five, since the
|
||||
<code><nobr>int</nobr></code> field would be aligned to a four-byte
|
||||
boundary. However, this sort of feature is sometimes a configurable option
|
||||
in the C compiler, either using command-line options or
|
||||
<code><nobr>#pragma</nobr></code> lines, so you have to find out how your
|
||||
own compiler does it.
|
||||
<h4><a name="section-8.1.4">8.1.4 <code><nobr>c32.mac</nobr></code>: Helper Macros for the 32-bit C Interface</a></h4>
|
||||
<p>Included in the NASM archives, in the <code><nobr>misc</nobr></code>
|
||||
directory, is a file <code><nobr>c32.mac</nobr></code> of macros. It
|
||||
defines three macros: <code><nobr>proc</nobr></code>,
|
||||
<code><nobr>arg</nobr></code> and <code><nobr>endproc</nobr></code>. These
|
||||
are intended to be used for C-style procedure definitions, and they
|
||||
automate a lot of the work involved in keeping track of the calling
|
||||
convention.
|
||||
<p>An example of an assembly function using the macro set is given here:
|
||||
<p><pre>
|
||||
proc _proc32
|
||||
|
||||
%$i arg
|
||||
%$j arg
|
||||
mov eax,[ebp + %$i]
|
||||
mov ebx,[ebp + %$j]
|
||||
add eax,[ebx]
|
||||
|
||||
endproc
|
||||
</pre>
|
||||
<p>This defines <code><nobr>_proc32</nobr></code> to be a procedure taking
|
||||
two arguments, the first (<code><nobr>i</nobr></code>) an integer and the
|
||||
second (<code><nobr>j</nobr></code>) a pointer to an integer. It returns
|
||||
<code><nobr>i + *j</nobr></code>.
|
||||
<p>Note that the <code><nobr>arg</nobr></code> macro has an
|
||||
<code><nobr>EQU</nobr></code> as the first line of its expansion, and since
|
||||
the label before the macro call gets prepended to the first line of the
|
||||
expanded macro, the <code><nobr>EQU</nobr></code> works, defining
|
||||
<code><nobr>%$i</nobr></code> to be an offset from
|
||||
<code><nobr>BP</nobr></code>. A context-local variable is used, local to
|
||||
the context pushed by the <code><nobr>proc</nobr></code> macro and popped
|
||||
by the <code><nobr>endproc</nobr></code> macro, so that the same argument
|
||||
name can be used in later procedures. Of course, you don't <em>have</em> to
|
||||
do that.
|
||||
<p><code><nobr>arg</nobr></code> can take an optional parameter, giving the
|
||||
size of the argument. If no size is given, 4 is assumed, since it is likely
|
||||
that many function parameters will be of type <code><nobr>int</nobr></code>
|
||||
or pointers.
|
||||
<h3><a name="section-8.2">8.2 Writing NetBSD/FreeBSD/OpenBSD and Linux/ELF Shared Libraries</a></h3>
|
||||
<p><code><nobr>ELF</nobr></code> replaced the older
|
||||
<code><nobr>a.out</nobr></code> object file format under Linux because it
|
||||
contains support for position-independent code (PIC), which makes writing
|
||||
shared libraries much easier. NASM supports the
|
||||
<code><nobr>ELF</nobr></code> position-independent code features, so you
|
||||
can write Linux <code><nobr>ELF</nobr></code> shared libraries in NASM.
|
||||
<p>NetBSD, and its close cousins FreeBSD and OpenBSD, take a different
|
||||
approach by hacking PIC support into the <code><nobr>a.out</nobr></code>
|
||||
format. NASM supports this as the <code><nobr>aoutb</nobr></code> output
|
||||
format, so you can write BSD shared libraries in NASM too.
|
||||
<p>The operating system loads a PIC shared library by memory-mapping the
|
||||
library file at an arbitrarily chosen point in the address space of the
|
||||
running process. The contents of the library's code section must therefore
|
||||
not depend on where it is loaded in memory.
|
||||
<p>Therefore, you cannot get at your variables by writing code like this:
|
||||
<p><pre>
|
||||
mov eax,[myvar] ; WRONG
|
||||
</pre>
|
||||
<p>Instead, the linker provides an area of memory called the <em>global
|
||||
offset table</em>, or GOT; the GOT is situated at a constant distance from
|
||||
your library's code, so if you can find out where your library is loaded
|
||||
(which is typically done using a <code><nobr>CALL</nobr></code> and
|
||||
<code><nobr>POP</nobr></code> combination), you can obtain the address of
|
||||
the GOT, and you can then load the addresses of your variables out of
|
||||
linker-generated entries in the GOT.
|
||||
<p>The <em>data</em> section of a PIC shared library does not have these
|
||||
restrictions: since the data section is writable, it has to be copied into
|
||||
memory anyway rather than just paged in from the library file, so as long
|
||||
as it's being copied it can be relocated too. So you can put ordinary types
|
||||
of relocation in the data section without too much worry (but see
|
||||
<a href="#section-8.2.4">section 8.2.4</a> for a caveat).
|
||||
<h4><a name="section-8.2.1">8.2.1 Obtaining the Address of the GOT</a></h4>
|
||||
<p>Each code module in your shared library should define the GOT as an
|
||||
external symbol:
|
||||
<p><pre>
|
||||
extern _GLOBAL_OFFSET_TABLE_ ; in ELF
|
||||
extern __GLOBAL_OFFSET_TABLE_ ; in BSD a.out
|
||||
</pre>
|
||||
<p>At the beginning of any function in your shared library which plans to
|
||||
access your data or BSS sections, you must first calculate the address of
|
||||
the GOT. This is typically done by writing the function in this form:
|
||||
<p><pre>
|
||||
func: push ebp
|
||||
mov ebp,esp
|
||||
push ebx
|
||||
call .get_GOT
|
||||
.get_GOT:
|
||||
pop ebx
|
||||
add ebx,_GLOBAL_OFFSET_TABLE_+$$-.get_GOT wrt ..gotpc
|
||||
|
||||
; the function body comes here
|
||||
|
||||
mov ebx,[ebp-4]
|
||||
mov esp,ebp
|
||||
pop ebp
|
||||
ret
|
||||
</pre>
|
||||
<p>(For BSD, again, the symbol
|
||||
<code><nobr>_GLOBAL_OFFSET_TABLE</nobr></code> requires a second leading
|
||||
underscore.)
|
||||
<p>The first two lines of this function are simply the standard C prologue
|
||||
to set up a stack frame, and the last three lines are standard C function
|
||||
epilogue. The third line, and the fourth to last line, save and restore the
|
||||
<code><nobr>EBX</nobr></code> register, because PIC shared libraries use
|
||||
this register to store the address of the GOT.
|
||||
<p>The interesting bit is the <code><nobr>CALL</nobr></code> instruction
|
||||
and the following two lines. The <code><nobr>CALL</nobr></code> and
|
||||
<code><nobr>POP</nobr></code> combination obtains the address of the label
|
||||
<code><nobr>.get_GOT</nobr></code>, without having to know in advance where
|
||||
the program was loaded (since the <code><nobr>CALL</nobr></code>
|
||||
instruction is encoded relative to the current position). The
|
||||
<code><nobr>ADD</nobr></code> instruction makes use of one of the special
|
||||
PIC relocation types: GOTPC relocation. With the
|
||||
<code><nobr>WRT ..gotpc</nobr></code> qualifier specified, the symbol
|
||||
referenced (here <code><nobr>_GLOBAL_OFFSET_TABLE_</nobr></code>, the
|
||||
special symbol assigned to the GOT) is given as an offset from the
|
||||
beginning of the section. (Actually, <code><nobr>ELF</nobr></code> encodes
|
||||
it as the offset from the operand field of the
|
||||
<code><nobr>ADD</nobr></code> instruction, but NASM simplifies this
|
||||
deliberately, so you do things the same way for both
|
||||
<code><nobr>ELF</nobr></code> and <code><nobr>BSD</nobr></code>.) So the
|
||||
instruction then <em>adds</em> the beginning of the section, to get the
|
||||
real address of the GOT, and subtracts the value of
|
||||
<code><nobr>.get_GOT</nobr></code> which it knows is in
|
||||
<code><nobr>EBX</nobr></code>. Therefore, by the time that instruction has
|
||||
finished, <code><nobr>EBX</nobr></code> contains the address of the GOT.
|
||||
<p>If you didn't follow that, don't worry: it's never necessary to obtain
|
||||
the address of the GOT by any other means, so you can put those three
|
||||
instructions into a macro and safely ignore them:
|
||||
<p><pre>
|
||||
%macro get_GOT 0
|
||||
|
||||
call %%getgot
|
||||
%%getgot:
|
||||
pop ebx
|
||||
add ebx,_GLOBAL_OFFSET_TABLE_+$$-%%getgot wrt ..gotpc
|
||||
|
||||
%endmacro
|
||||
</pre>
|
||||
<h4><a name="section-8.2.2">8.2.2 Finding Your Local Data Items</a></h4>
|
||||
<p>Having got the GOT, you can then use it to obtain the addresses of your
|
||||
data items. Most variables will reside in the sections you have declared;
|
||||
they can be accessed using the <code><nobr>..gotoff</nobr></code> special
|
||||
<code><nobr>WRT</nobr></code> type. The way this works is like this:
|
||||
<p><pre>
|
||||
lea eax,[ebx+myvar wrt ..gotoff]
|
||||
</pre>
|
||||
<p>The expression <code><nobr>myvar wrt ..gotoff</nobr></code> is
|
||||
calculated, when the shared library is linked, to be the offset to the
|
||||
local variable <code><nobr>myvar</nobr></code> from the beginning of the
|
||||
GOT. Therefore, adding it to <code><nobr>EBX</nobr></code> as above will
|
||||
place the real address of <code><nobr>myvar</nobr></code> in
|
||||
<code><nobr>EAX</nobr></code>.
|
||||
<p>If you declare variables as <code><nobr>GLOBAL</nobr></code> without
|
||||
specifying a size for them, they are shared between code modules in the
|
||||
library, but do not get exported from the library to the program that
|
||||
loaded it. They will still be in your ordinary data and BSS sections, so
|
||||
you can access them in the same way as local variables, using the above
|
||||
<code><nobr>..gotoff</nobr></code> mechanism.
|
||||
<p>Note that due to a peculiarity of the way BSD
|
||||
<code><nobr>a.out</nobr></code> format handles this relocation type, there
|
||||
must be at least one non-local symbol in the same section as the address
|
||||
you're trying to access.
|
||||
<h4><a name="section-8.2.3">8.2.3 Finding External and Common Data Items</a></h4>
|
||||
<p>If your library needs to get at an external variable (external to the
|
||||
<em>library</em>, not just to one of the modules within it), you must use
|
||||
the <code><nobr>..got</nobr></code> type to get at it. The
|
||||
<code><nobr>..got</nobr></code> type, instead of giving you the offset from
|
||||
the GOT base to the variable, gives you the offset from the GOT base to a
|
||||
GOT <em>entry</em> containing the address of the variable. The linker will
|
||||
set up this GOT entry when it builds the library, and the dynamic linker
|
||||
will place the correct address in it at load time. So to obtain the address
|
||||
of an external variable <code><nobr>extvar</nobr></code> in
|
||||
<code><nobr>EAX</nobr></code>, you would code
|
||||
<p><pre>
|
||||
mov eax,[ebx+extvar wrt ..got]
|
||||
</pre>
|
||||
<p>This loads the address of <code><nobr>extvar</nobr></code> out of an
|
||||
entry in the GOT. The linker, when it builds the shared library, collects
|
||||
together every relocation of type <code><nobr>..got</nobr></code>, and
|
||||
builds the GOT so as to ensure it has every necessary entry present.
|
||||
<p>Common variables must also be accessed in this way.
|
||||
<h4><a name="section-8.2.4">8.2.4 Exporting Symbols to the Library User</a></h4>
|
||||
<p>If you want to export symbols to the user of the library, you have to
|
||||
declare whether they are functions or data, and if they are data, you have
|
||||
to give the size of the data item. This is because the dynamic linker has
|
||||
to build procedure linkage table entries for any exported functions, and
|
||||
also moves exported data items away from the library's data section in
|
||||
which they were declared.
|
||||
<p>So to export a function to users of the library, you must use
|
||||
<p><pre>
|
||||
global func:function ; declare it as a function
|
||||
|
||||
func: push ebp
|
||||
|
||||
; etc.
|
||||
</pre>
|
||||
<p>And to export a data item such as an array, you would have to code
|
||||
<p><pre>
|
||||
global array:data array.end-array ; give the size too
|
||||
|
||||
array: resd 128
|
||||
.end:
|
||||
</pre>
|
||||
<p>Be careful: If you export a variable to the library user, by declaring
|
||||
it as <code><nobr>GLOBAL</nobr></code> and supplying a size, the variable
|
||||
will end up living in the data section of the main program, rather than in
|
||||
your library's data section, where you declared it. So you will have to
|
||||
access your own global variable with the <code><nobr>..got</nobr></code>
|
||||
mechanism rather than <code><nobr>..gotoff</nobr></code>, as if it were
|
||||
external (which, effectively, it has become).
|
||||
<p>Equally, if you need to store the address of an exported global in one
|
||||
of your data sections, you can't do it by means of the standard sort of
|
||||
code:
|
||||
<p><pre>
|
||||
dataptr: dd global_data_item ; WRONG
|
||||
</pre>
|
||||
<p>NASM will interpret this code as an ordinary relocation, in which
|
||||
<code><nobr>global_data_item</nobr></code> is merely an offset from the
|
||||
beginning of the <code><nobr>.data</nobr></code> section (or whatever); so
|
||||
this reference will end up pointing at your data section instead of at the
|
||||
exported global which resides elsewhere.
|
||||
<p>Instead of the above code, then, you must write
|
||||
<p><pre>
|
||||
dataptr: dd global_data_item wrt ..sym
|
||||
</pre>
|
||||
<p>which makes use of the special <code><nobr>WRT</nobr></code> type
|
||||
<code><nobr>..sym</nobr></code> to instruct NASM to search the symbol table
|
||||
for a particular symbol at that address, rather than just relocating by
|
||||
section base.
|
||||
<p>Either method will work for functions: referring to one of your
|
||||
functions by means of
|
||||
<p><pre>
|
||||
funcptr: dd my_function
|
||||
</pre>
|
||||
<p>will give the user the address of the code you wrote, whereas
|
||||
<p><pre>
|
||||
funcptr: dd my_function wrt .sym
|
||||
</pre>
|
||||
<p>will give the address of the procedure linkage table for the function,
|
||||
which is where the calling program will <em>believe</em> the function
|
||||
lives. Either address is a valid way to call the function.
|
||||
<h4><a name="section-8.2.5">8.2.5 Calling Procedures Outside the Library</a></h4>
|
||||
<p>Calling procedures outside your shared library has to be done by means
|
||||
of a <em>procedure linkage table</em>, or PLT. The PLT is placed at a known
|
||||
offset from where the library is loaded, so the library code can make calls
|
||||
to the PLT in a position-independent way. Within the PLT there is code to
|
||||
jump to offsets contained in the GOT, so function calls to other shared
|
||||
libraries or to routines in the main program can be transparently passed
|
||||
off to their real destinations.
|
||||
<p>To call an external routine, you must use another special PIC relocation
|
||||
type, <code><nobr>WRT ..plt</nobr></code>. This is much easier than the
|
||||
GOT-based ones: you simply replace calls such as
|
||||
<code><nobr>CALL printf</nobr></code> with the PLT-relative version
|
||||
<code><nobr>CALL printf WRT ..plt</nobr></code>.
|
||||
<h4><a name="section-8.2.6">8.2.6 Generating the Library File</a></h4>
|
||||
<p>Having written some code modules and assembled them to
|
||||
<code><nobr>.o</nobr></code> files, you then generate your shared library
|
||||
with a command such as
|
||||
<p><pre>
|
||||
ld -shared -o library.so module1.o module2.o # for ELF
|
||||
ld -Bshareable -o library.so module1.o module2.o # for BSD
|
||||
</pre>
|
||||
<p>For ELF, if your shared library is going to reside in system directories
|
||||
such as <code><nobr>/usr/lib</nobr></code> or
|
||||
<code><nobr>/lib</nobr></code>, it is usually worth using the
|
||||
<code><nobr>-soname</nobr></code> flag to the linker, to store the final
|
||||
library file name, with a version number, into the library:
|
||||
<p><pre>
|
||||
ld -shared -soname library.so.1 -o library.so.1.2 *.o
|
||||
</pre>
|
||||
<p>You would then copy <code><nobr>library.so.1.2</nobr></code> into the
|
||||
library directory, and create <code><nobr>library.so.1</nobr></code> as a
|
||||
symbolic link to it.
|
||||
<p align=center><a href="nasmdoc9.html">Next Chapter</a> |
|
||||
<a href="nasmdoc7.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
</body></html>
|
||||
175
Ref-docs/nasmdoc/html/nasmdoc9.html
Normal file
175
Ref-docs/nasmdoc/html/nasmdoc9.html
Normal file
@@ -0,0 +1,175 @@
|
||||
<html><head><title>NASM Manual</title></head>
|
||||
<body><h1 align=center>The Netwide Assembler: NASM</h1>
|
||||
|
||||
<p align=center><a href="nasmdo10.html">Next Chapter</a> |
|
||||
<a href="nasmdoc8.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
<h2><a name="chapter-9">Chapter 9: Mixing 16 and 32 Bit Code</a></h2>
|
||||
<p>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 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.
|
||||
<h3><a name="section-9.1">9.1 Mixed-Size Jumps</a></h3>
|
||||
<p>The most common form of mixed-size instruction is the one used when
|
||||
writing a 32-bit OS: having done your setup in 16-bit mode, such as loading
|
||||
the kernel, you then have to boot it by switching into protected mode and
|
||||
jumping to the 32-bit kernel start address. In a fully 32-bit OS, this
|
||||
tends to be the <em>only</em> mixed-size instruction you need, since
|
||||
everything before it can be done in pure 16-bit code, and everything after
|
||||
it can be pure 32-bit.
|
||||
<p>This jump must specify a 48-bit far address, since the target segment is
|
||||
a 32-bit one. However, it must be assembled in a 16-bit segment, so just
|
||||
coding, for example,
|
||||
<p><pre>
|
||||
jmp 0x1234:0x56789ABC ; wrong!
|
||||
</pre>
|
||||
<p>will not work, since the offset part of the address will be truncated to
|
||||
<code><nobr>0x9ABC</nobr></code> and the jump will be an ordinary 16-bit
|
||||
far one.
|
||||
<p>The Linux kernel setup code gets round the inability of
|
||||
<code><nobr>as86</nobr></code> to generate the required instruction by
|
||||
coding it manually, using <code><nobr>DB</nobr></code> instructions. NASM
|
||||
can go one better than that, by actually generating the right instruction
|
||||
itself. Here's how to do it right:
|
||||
<p><pre>
|
||||
jmp dword 0x1234:0x56789ABC ; right
|
||||
</pre>
|
||||
<p>The <code><nobr>DWORD</nobr></code> prefix (strictly speaking, it should
|
||||
come <em>after</em> the colon, since it is declaring the <em>offset</em>
|
||||
field to be a doubleword; but NASM will accept either form, since both are
|
||||
unambiguous) forces the offset part to be treated as far, in the assumption
|
||||
that you are deliberately writing a jump from a 16-bit segment to a 32-bit
|
||||
one.
|
||||
<p>You can do the reverse operation, jumping from a 32-bit segment to a
|
||||
16-bit one, by means of the <code><nobr>WORD</nobr></code> prefix:
|
||||
<p><pre>
|
||||
jmp word 0x8765:0x4321 ; 32 to 16 bit
|
||||
</pre>
|
||||
<p>If the <code><nobr>WORD</nobr></code> prefix is specified in 16-bit
|
||||
mode, or the <code><nobr>DWORD</nobr></code> prefix in 32-bit mode, they
|
||||
will be ignored, since each is explicitly forcing NASM into a mode it was
|
||||
in anyway.
|
||||
<h3><a name="section-9.2">9.2 Addressing Between Different-Size Segments</a></h3>
|
||||
<p>If your OS is mixed 16 and 32-bit, or if you are writing a DOS extender,
|
||||
you are likely to have to deal with some 16-bit segments and some 32-bit
|
||||
ones. At some point, you will probably end up writing code in a 16-bit
|
||||
segment which has to access data in a 32-bit segment, or vice versa.
|
||||
<p>If the data you are trying to access in a 32-bit segment lies within the
|
||||
first 64K of the segment, you may be able to get away with using an
|
||||
ordinary 16-bit addressing operation for the purpose; but sooner or later,
|
||||
you will want to do 32-bit addressing from 16-bit mode.
|
||||
<p>The easiest way to do this is to make sure you use a register for the
|
||||
address, since any effective address containing a 32-bit register is forced
|
||||
to be a 32-bit address. So you can do
|
||||
<p><pre>
|
||||
mov eax,offset_into_32_bit_segment_specified_by_fs
|
||||
mov dword [fs:eax],0x11223344
|
||||
</pre>
|
||||
<p>This is fine, but slightly cumbersome (since it wastes an instruction
|
||||
and a register) if you already know the precise offset you are aiming at.
|
||||
The x86 architecture does allow 32-bit effective addresses to specify
|
||||
nothing but a 4-byte offset, so why shouldn't NASM be able to generate the
|
||||
best instruction for the purpose?
|
||||
<p>It can. As in <a href="#section-9.1">section 9.1</a>, you need only
|
||||
prefix the address with the <code><nobr>DWORD</nobr></code> keyword, and it
|
||||
will be forced to be a 32-bit address:
|
||||
<p><pre>
|
||||
mov dword [fs:dword my_offset],0x11223344
|
||||
</pre>
|
||||
<p>Also as in <a href="#section-9.1">section 9.1</a>, NASM is not fussy
|
||||
about whether the <code><nobr>DWORD</nobr></code> prefix comes before or
|
||||
after the segment override, so arguably a nicer-looking way to code the
|
||||
above instruction is
|
||||
<p><pre>
|
||||
mov dword [dword fs:my_offset],0x11223344
|
||||
</pre>
|
||||
<p>Don't confuse the <code><nobr>DWORD</nobr></code> prefix
|
||||
<em>outside</em> the square brackets, which controls the size of the data
|
||||
stored at the address, with the one <code><nobr>inside</nobr></code> the
|
||||
square brackets which controls the length of the address itself. The two
|
||||
can quite easily be different:
|
||||
<p><pre>
|
||||
mov word [dword 0x12345678],0x9ABC
|
||||
</pre>
|
||||
<p>This moves 16 bits of data to an address specified by a 32-bit offset.
|
||||
<p>You can also specify <code><nobr>WORD</nobr></code> or
|
||||
<code><nobr>DWORD</nobr></code> prefixes along with the
|
||||
<code><nobr>FAR</nobr></code> prefix to indirect far jumps or calls. For
|
||||
example:
|
||||
<p><pre>
|
||||
call dword far [fs:word 0x4321]
|
||||
</pre>
|
||||
<p>This instruction contains an address specified by a 16-bit offset; it
|
||||
loads a 48-bit far pointer from that (16-bit segment and 32-bit offset),
|
||||
and calls that address.
|
||||
<h3><a name="section-9.3">9.3 Other Mixed-Size Instructions</a></h3>
|
||||
<p>The other way you might want to access data might be using the string
|
||||
instructions (<code><nobr>LODSx</nobr></code>,
|
||||
<code><nobr>STOSx</nobr></code> and so on) or the
|
||||
<code><nobr>XLATB</nobr></code> instruction. These instructions, since they
|
||||
take no parameters, might seem to have no easy way to make them perform
|
||||
32-bit addressing when assembled in a 16-bit segment.
|
||||
<p>This is the purpose of NASM's <code><nobr>a16</nobr></code> and
|
||||
<code><nobr>a32</nobr></code> prefixes. If you are coding
|
||||
<code><nobr>LODSB</nobr></code> in a 16-bit segment but it is supposed to
|
||||
be accessing a string in a 32-bit segment, you should load the desired
|
||||
address into <code><nobr>ESI</nobr></code> and then code
|
||||
<p><pre>
|
||||
a32 lodsb
|
||||
</pre>
|
||||
<p>The prefix forces the addressing size to 32 bits, meaning that
|
||||
<code><nobr>LODSB</nobr></code> loads from
|
||||
<code><nobr>[DS:ESI]</nobr></code> instead of
|
||||
<code><nobr>[DS:SI]</nobr></code>. To access a string in a 16-bit segment
|
||||
when coding in a 32-bit one, the corresponding
|
||||
<code><nobr>a16</nobr></code> prefix can be used.
|
||||
<p>The <code><nobr>a16</nobr></code> and <code><nobr>a32</nobr></code>
|
||||
prefixes can be applied to any instruction in NASM's instruction table, but
|
||||
most of them can generate all the useful forms without them. The prefixes
|
||||
are necessary only for instructions with implicit addressing:
|
||||
<code><nobr>CMPSx</nobr></code>
|
||||
(<a href="nasmdocb.html#section-B.4.27">section B.4.27</a>),
|
||||
<code><nobr>SCASx</nobr></code>
|
||||
(<a href="nasmdocb.html#section-B.4.286">section B.4.286</a>),
|
||||
<code><nobr>LODSx</nobr></code>
|
||||
(<a href="nasmdocb.html#section-B.4.141">section B.4.141</a>),
|
||||
<code><nobr>STOSx</nobr></code>
|
||||
(<a href="nasmdocb.html#section-B.4.303">section B.4.303</a>),
|
||||
<code><nobr>MOVSx</nobr></code>
|
||||
(<a href="nasmdocb.html#section-B.4.178">section B.4.178</a>),
|
||||
<code><nobr>INSx</nobr></code>
|
||||
(<a href="nasmdocb.html#section-B.4.121">section B.4.121</a>),
|
||||
<code><nobr>OUTSx</nobr></code>
|
||||
(<a href="nasmdocb.html#section-B.4.195">section B.4.195</a>), and
|
||||
<code><nobr>XLATB</nobr></code>
|
||||
(<a href="nasmdocb.html#section-B.4.334">section B.4.334</a>). Also, the
|
||||
various push and pop instructions (<code><nobr>PUSHA</nobr></code> and
|
||||
<code><nobr>POPF</nobr></code> as well as the more usual
|
||||
<code><nobr>PUSH</nobr></code> and <code><nobr>POP</nobr></code>) can
|
||||
accept <code><nobr>a16</nobr></code> or <code><nobr>a32</nobr></code>
|
||||
prefixes to force a particular one of <code><nobr>SP</nobr></code> or
|
||||
<code><nobr>ESP</nobr></code> to be used as a stack pointer, in case the
|
||||
stack segment in use is a different size from the code segment.
|
||||
<p><code><nobr>PUSH</nobr></code> and <code><nobr>POP</nobr></code>, when
|
||||
applied to segment registers in 32-bit mode, also have the slightly odd
|
||||
behaviour that they push and pop 4 bytes at a time, of which the top two
|
||||
are ignored and the bottom two give the value of the segment register being
|
||||
manipulated. To force the 16-bit behaviour of segment-register push and pop
|
||||
instructions, you can use the operand-size prefix
|
||||
<code><nobr>o16</nobr></code>:
|
||||
<p><pre>
|
||||
o16 push ss
|
||||
o16 push ds
|
||||
</pre>
|
||||
<p>This code saves a doubleword of stack space by fitting two segment
|
||||
registers into the space which would normally be consumed by pushing one.
|
||||
<p>(You can also use the <code><nobr>o32</nobr></code> prefix to force the
|
||||
32-bit behaviour when in 16-bit mode, but this seems less useful.)
|
||||
<p align=center><a href="nasmdo10.html">Next Chapter</a> |
|
||||
<a href="nasmdoc8.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
</body></html>
|
||||
177
Ref-docs/nasmdoc/html/nasmdoca.html
Normal file
177
Ref-docs/nasmdoc/html/nasmdoca.html
Normal file
@@ -0,0 +1,177 @@
|
||||
<html><head><title>NASM Manual</title></head>
|
||||
<body><h1 align=center>The Netwide Assembler: NASM</h1>
|
||||
|
||||
<p align=center><a href="nasmdocb.html">Next Chapter</a> |
|
||||
<a href="nasmdo10.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
<h2><a name="appendix-A">Appendix A: Ndisasm</a></h2>
|
||||
<p>The Netwide Disassembler, NDISASM
|
||||
<h3><a name="section-A.1">A.1 Introduction</a></h3>
|
||||
<p>The Netwide Disassembler is a small companion program to the Netwide
|
||||
Assembler, NASM. It seemed a shame to have an x86 assembler, complete with
|
||||
a full instruction table, and not make as much use of it as possible, so
|
||||
here's a disassembler which shares the instruction table (and some other
|
||||
bits of code) with NASM.
|
||||
<p>The Netwide Disassembler does nothing except to produce disassemblies of
|
||||
<em>binary</em> source files. NDISASM does not have any understanding of
|
||||
object file formats, like <code><nobr>objdump</nobr></code>, and it will
|
||||
not understand <code><nobr>DOS .EXE</nobr></code> files like
|
||||
<code><nobr>debug</nobr></code> will. It just disassembles.
|
||||
<h3><a name="section-A.2">A.2 Getting Started: Installation</a></h3>
|
||||
<p>See <a href="nasmdoc1.html#section-1.3">section 1.3</a> for installation
|
||||
instructions. NDISASM, like NASM, has a <code><nobr>man page</nobr></code>
|
||||
which you may want to put somewhere useful, if you are on a Unix system.
|
||||
<h3><a name="section-A.3">A.3 Running NDISASM</a></h3>
|
||||
<p>To disassemble a file, you will typically use a command of the form
|
||||
<p><pre>
|
||||
ndisasm [-b16 | -b32] filename
|
||||
</pre>
|
||||
<p>NDISASM can disassemble 16-bit code or 32-bit code equally easily,
|
||||
provided of course that you remember to specify which it is to work with.
|
||||
If no <code><nobr>-b</nobr></code> switch is present, NDISASM works in
|
||||
16-bit mode by default. The <code><nobr>-u</nobr></code> switch (for USE32)
|
||||
also invokes 32-bit mode.
|
||||
<p>Two more command line options are <code><nobr>-r</nobr></code> which
|
||||
reports the version number of NDISASM you are running, and
|
||||
<code><nobr>-h</nobr></code> which gives a short summary of command line
|
||||
options.
|
||||
<h4><a name="section-A.3.1">A.3.1 COM Files: Specifying an Origin</a></h4>
|
||||
<p>To disassemble a <code><nobr>DOS .COM</nobr></code> file correctly, a
|
||||
disassembler must assume that the first instruction in the file is loaded
|
||||
at address <code><nobr>0x100</nobr></code>, rather than at zero. NDISASM,
|
||||
which assumes by default that any file you give it is loaded at zero, will
|
||||
therefore need to be informed of this.
|
||||
<p>The <code><nobr>-o</nobr></code> option allows you to declare a
|
||||
different origin for the file you are disassembling. Its argument may be
|
||||
expressed in any of the NASM numeric formats: decimal by default, if it
|
||||
begins with `<code><nobr>$</nobr></code>' or `<code><nobr>0x</nobr></code>'
|
||||
or ends in `<code><nobr>H</nobr></code>' it's
|
||||
<code><nobr>hex</nobr></code>, if it ends in `<code><nobr>Q</nobr></code>'
|
||||
it's <code><nobr>octal</nobr></code>, and if it ends in
|
||||
`<code><nobr>B</nobr></code>' it's <code><nobr>binary</nobr></code>.
|
||||
<p>Hence, to disassemble a <code><nobr>.COM</nobr></code> file:
|
||||
<p><pre>
|
||||
ndisasm -o100h filename.com
|
||||
</pre>
|
||||
<p>will do the trick.
|
||||
<h4><a name="section-A.3.2">A.3.2 Code Following Data: Synchronisation</a></h4>
|
||||
<p>Suppose you are disassembling a file which contains some data which
|
||||
isn't machine code, and <em>then</em> contains some machine code. NDISASM
|
||||
will faithfully plough through the data section, producing machine
|
||||
instructions wherever it can (although most of them will look bizarre, and
|
||||
some may have unusual prefixes, e.g.
|
||||
`<code><nobr>FS OR AX,0x240A</nobr></code>'), and generating `DB'
|
||||
instructions ever so often if it's totally stumped. Then it will reach the
|
||||
code section.
|
||||
<p>Supposing NDISASM has just finished generating a strange machine
|
||||
instruction from part of the data section, and its file position is now one
|
||||
byte <em>before</em> the beginning of the code section. It's entirely
|
||||
possible that another spurious instruction will get generated, starting
|
||||
with the final byte of the data section, and 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.
|
||||
<p>To avoid this, you can specify a
|
||||
`<code><nobr>synchronisation</nobr></code>' point, or indeed as many
|
||||
synchronisation points as you like (although NDISASM can only handle 8192
|
||||
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 would cause it to jump over a sync
|
||||
point, it will discard that instruction and output a
|
||||
`<code><nobr>db</nobr></code>' instead. So it <em>will</em> start
|
||||
disassembly exactly from the sync point, and so you <em>will</em> see all
|
||||
the instructions in your code section.
|
||||
<p>Sync points are specified using the <code><nobr>-s</nobr></code> option:
|
||||
they are measured in terms of the program origin, not the file position. So
|
||||
if you want to synchronise after 32 bytes of a
|
||||
<code><nobr>.COM</nobr></code> file, you would have to do
|
||||
<p><pre>
|
||||
ndisasm -o100h -s120h file.com
|
||||
</pre>
|
||||
<p>rather than
|
||||
<p><pre>
|
||||
ndisasm -o100h -s20h file.com
|
||||
</pre>
|
||||
<p>As stated above, you can specify multiple sync markers if you need to,
|
||||
just by repeating the <code><nobr>-s</nobr></code> option.
|
||||
<h4><a name="section-A.3.3">A.3.3 Mixed Code and Data: Automatic (Intelligent) Synchronisation </a></h4>
|
||||
<p>Suppose you are disassembling the boot sector of a
|
||||
<code><nobr>DOS</nobr></code> floppy (maybe it has a virus, and you need to
|
||||
understand the virus so that you know what kinds of damage it might have
|
||||
done you). Typically, this will contain a <code><nobr>JMP</nobr></code>
|
||||
instruction, then some data, then the rest of the code. So there is a very
|
||||
good chance of NDISASM being <em>misaligned</em> when the data ends and the
|
||||
code begins. Hence a sync point is needed.
|
||||
<p>On the other hand, why should you have to specify the sync point
|
||||
manually? What you'd do in order to find where the sync point would be,
|
||||
surely, would be to read the <code><nobr>JMP</nobr></code> instruction, and
|
||||
then to use its target address as a sync point. So can NDISASM do that for
|
||||
you?
|
||||
<p>The answer, of course, is yes: using either of the synonymous switches
|
||||
<code><nobr>-a</nobr></code> (for automatic sync) or
|
||||
<code><nobr>-i</nobr></code> (for intelligent sync) will enable
|
||||
<code><nobr>auto-sync</nobr></code> mode. Auto-sync mode automatically
|
||||
generates a sync point for any forward-referring PC-relative jump or call
|
||||
instruction that NDISASM encounters. (Since NDISASM is one-pass, if it
|
||||
encounters a PC-relative jump whose target has already been processed,
|
||||
there isn't much it can do about it...)
|
||||
<p>Only PC-relative jumps are processed, since an absolute jump is either
|
||||
through a register (in which case NDISASM doesn't know what the register
|
||||
contains) or involves a segment address (in which case the target code
|
||||
isn't in the same segment that NDISASM is working in, and so the sync point
|
||||
can't be placed anywhere useful).
|
||||
<p>For some kinds of file, this mechanism will automatically put sync
|
||||
points in all the right places, and save you from having to place any sync
|
||||
points manually. However, it should be stressed that auto-sync mode is
|
||||
<em>not</em> guaranteed to catch all the sync points, and you may still
|
||||
have to place some manually.
|
||||
<p>Auto-sync mode doesn't prevent you from declaring manual sync points: it
|
||||
just adds automatically generated ones to the ones you provide. It's
|
||||
perfectly feasible to specify <code><nobr>-i</nobr></code> <em>and</em>
|
||||
some <code><nobr>-s</nobr></code> options.
|
||||
<p>Another caveat with auto-sync mode is that if, by some unpleasant fluke,
|
||||
something in your data section should disassemble to a PC-relative call or
|
||||
jump instruction, NDISASM may obediently place a sync point in a totally
|
||||
random place, for example in the middle of one of the instructions in your
|
||||
code section. So you may end up with a wrong disassembly even if you use
|
||||
auto-sync. Again, there isn't much I can do about this. If you have
|
||||
problems, you'll have to use manual sync points, or use the
|
||||
<code><nobr>-k</nobr></code> option (documented below) to suppress
|
||||
disassembly of the data area.
|
||||
<h4><a name="section-A.3.4">A.3.4 Other Options</a></h4>
|
||||
<p>The <code><nobr>-e</nobr></code> option skips a header on the file, by
|
||||
ignoring the first N bytes. This means that the header is <em>not</em>
|
||||
counted towards the disassembly offset: if you give
|
||||
<code><nobr>-e10 -o10</nobr></code>, disassembly will start at byte 10 in
|
||||
the file, and this will be given offset 10, not 20.
|
||||
<p>The <code><nobr>-k</nobr></code> option is provided with two
|
||||
comma-separated numeric arguments, the first of which is an assembly offset
|
||||
and the second is a number of bytes to skip. This <em>will</em> count the
|
||||
skipped bytes towards the assembly offset: its use is to suppress
|
||||
disassembly of a data section which wouldn't contain anything you wanted to
|
||||
see anyway.
|
||||
<h3><a name="section-A.4">A.4 Bugs and Improvements</a></h3>
|
||||
<p>There are no known bugs. However, any you find, with patches if
|
||||
possible, should be sent to
|
||||
<a href="mailto:jules@dsf.org.uk"><code><nobr>jules@dsf.org.uk</nobr></code></a>
|
||||
or
|
||||
<a href="mailto:anakin@pobox.com"><code><nobr>anakin@pobox.com</nobr></code></a>,
|
||||
or to the developer's site at
|
||||
<a href="https://sourceforge.net/projects/nasm/"><code><nobr>https://sourceforge.net/projects/nasm/</nobr></code></a>
|
||||
and we'll try to fix them. Feel free to send contributions and new features
|
||||
as well.
|
||||
<p>Future plans include awareness of which processors certain instructions
|
||||
will run on, and marking of instructions that are too advanced for some
|
||||
processor (or are <code><nobr>FPU</nobr></code> instructions, or are
|
||||
undocumented opcodes, or are privileged protected-mode instructions, or
|
||||
whatever).
|
||||
<p>That's All Folks!
|
||||
<p>I hope NDISASM is of some use to somebody. Including me. :-)
|
||||
<p>I don't recommend taking NDISASM apart to see how an efficient
|
||||
disassembler works, because as far as I know, it isn't an efficient one
|
||||
anyway. You have been warned.
|
||||
<p align=center><a href="nasmdocb.html">Next Chapter</a> |
|
||||
<a href="nasmdo10.html">Previous Chapter</a> |
|
||||
<a href="nasmdoc0.html">Contents</a> |
|
||||
<a href="nasmdoci.html">Index</a>
|
||||
</body></html>
|
||||
6303
Ref-docs/nasmdoc/html/nasmdocb.html
Normal file
6303
Ref-docs/nasmdoc/html/nasmdocb.html
Normal file
File diff suppressed because it is too large
Load Diff
3427
Ref-docs/nasmdoc/html/nasmdoci.html
Normal file
3427
Ref-docs/nasmdoc/html/nasmdoci.html
Normal file
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user