diff options
| author | HyungKyu Song <hk76.song@samsung.com> | 2013-02-16 00:52:20 +0900 |
|---|---|---|
| committer | HyungKyu Song <hk76.song@samsung.com> | 2013-02-16 00:52:20 +0900 |
| commit | e6c15f0e49b4ea41b5c5eb36457db0127ec901fc (patch) | |
| tree | 996be9095a97ff2aac0d98963b6044d47a0ec60c /doc/html | |
| parent | 65c26d26fb72cec0d43d199c72ed27513d17f4c9 (diff) | |
| download | nasm-tizen_2.0.tar.gz nasm-tizen_2.0.tar.bz2 nasm-tizen_2.0.zip | |
Diffstat (limited to 'doc/html')
| -rw-r--r-- | doc/html/nasmdo10.html | 165 | ||||
| -rw-r--r-- | doc/html/nasmdo11.html | 164 | ||||
| -rw-r--r-- | doc/html/nasmdo12.html | 178 | ||||
| -rw-r--r-- | doc/html/nasmdoc0.html | 378 | ||||
| -rw-r--r-- | doc/html/nasmdoc1.html | 159 | ||||
| -rw-r--r-- | doc/html/nasmdoc2.html | 650 | ||||
| -rw-r--r-- | doc/html/nasmdoc3.html | 753 | ||||
| -rw-r--r-- | doc/html/nasmdoc4.html | 1970 | ||||
| -rw-r--r-- | doc/html/nasmdoc5.html | 83 | ||||
| -rw-r--r-- | doc/html/nasmdoc6.html | 371 | ||||
| -rw-r--r-- | doc/html/nasmdoc7.html | 1267 | ||||
| -rw-r--r-- | doc/html/nasmdoc8.html | 808 | ||||
| -rw-r--r-- | doc/html/nasmdoc9.html | 482 | ||||
| -rw-r--r-- | doc/html/nasmdoca.html | 165 | ||||
| -rw-r--r-- | doc/html/nasmdocb.html | 3148 | ||||
| -rw-r--r-- | doc/html/nasmdocc.html | 1468 | ||||
| -rw-r--r-- | doc/html/nasmdoci.html | 2345 |
17 files changed, 14554 insertions, 0 deletions
diff --git a/doc/html/nasmdo10.html b/doc/html/nasmdo10.html new file mode 100644 index 0000000..151dee1 --- /dev/null +++ b/doc/html/nasmdo10.html @@ -0,0 +1,165 @@ +<html><head><title>NASM Manual</title></head> +<body><h1 align=center>The Netwide Assembler: NASM</h1> + +<p align=center><a href="nasmdo11.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: 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-10.1">10.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-10.2">10.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-10.1">section 10.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-10.1">section 10.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-10.3">10.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>, +<code><nobr>a32</nobr></code> and <code><nobr>a64</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>, <code><nobr>a32</nobr></code> and +<code><nobr>a64</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>, +<code><nobr>SCASx</nobr></code>, <code><nobr>LODSx</nobr></code>, +<code><nobr>STOSx</nobr></code>, <code><nobr>MOVSx</nobr></code>, +<code><nobr>INSx</nobr></code>, <code><nobr>OUTSx</nobr></code>, and +<code><nobr>XLATB</nobr></code>. 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>, <code><nobr>a32</nobr></code> or +<code><nobr>a64</nobr></code> prefixes to force a particular one of +<code><nobr>SP</nobr></code>, <code><nobr>ESP</nobr></code> or +<code><nobr>RSP</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="nasmdo11.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> diff --git a/doc/html/nasmdo11.html b/doc/html/nasmdo11.html new file mode 100644 index 0000000..c40eede --- /dev/null +++ b/doc/html/nasmdo11.html @@ -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="nasmdo12.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="chapter-11">Chapter 11: Writing 64-bit Code (Unix, Win64)</a></h2> +<p>This chapter attempts to cover some of the common issues involved when +writing 64-bit code, to run under Win64 or Unix. It covers how to write +assembly code to interface with 64-bit C routines, and how to write +position-independent code for shared libraries. +<p>All 64-bit code uses a flat memory model, since segmentation is not +available in 64-bit mode. The one exception is the +<code><nobr>FS</nobr></code> and <code><nobr>GS</nobr></code> registers, +which still add their bases. +<p>Position independence in 64-bit mode is significantly simpler, since the +processor supports <code><nobr>RIP</nobr></code>-relative addressing +directly; see the <code><nobr>REL</nobr></code> keyword +(<a href="nasmdoc3.html#section-3.3">section 3.3</a>). On most 64-bit +platforms, it is probably desirable to make that the default, using the +directive <code><nobr>DEFAULT REL</nobr></code> +(<a href="nasmdoc6.html#section-6.2">section 6.2</a>). +<p>64-bit programming is relatively similar to 32-bit programming, but of +course pointers are 64 bits long; additionally, all existing platforms pass +arguments in registers rather than on the stack. Furthermore, 64-bit +platforms use SSE2 by default for floating point. Please see the ABI +documentation for your platform. +<p>64-bit platforms differ in the sizes of the fundamental datatypes, not +just from 32-bit platforms but from each other. If a specific size data +type is desired, it is probably best to use the types defined in the +Standard C header <code><nobr><inttypes.h></nobr></code>. +<p>In 64-bit mode, the default instruction size is still 32 bits. When +loading a value into a 32-bit register (but not an 8- or 16-bit register), +the upper 32 bits of the corresponding 64-bit register are set to zero. +<h3><a name="section-11.1">11.1 Register Names in 64-bit Mode</a></h3> +<p>NASM uses the following names for general-purpose registers in 64-bit +mode, for 8-, 16-, 32- and 64-bit references, respecitively: +<p><pre> + AL/AH, CL/CH, DL/DH, BL/BH, SPL, BPL, SIL, DIL, R8B-R15B + AX, CX, DX, BX, SP, BP, SI, DI, R8W-R15W + EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI, R8D-R15D + RAX, RCX, RDX, RBX, RSP, RBP, RSI, RDI, R8-R15 +</pre> +<p>This is consistent with the AMD documentation and most other assemblers. +The Intel documentation, however, uses the names +<code><nobr>R8L-R15L</nobr></code> for 8-bit references to the higher +registers. It is possible to use those names by definiting them as macros; +similarly, if one wants to use numeric names for the low 8 registers, +define them as macros. The standard macro package +<code><nobr>altreg</nobr></code> (see +<a href="nasmdoc5.html#section-5.1">section 5.1</a>) can be used for this +purpose. +<h3><a name="section-11.2">11.2 Immediates and Displacements in 64-bit Mode</a></h3> +<p>In 64-bit mode, immediates and displacements are generally only 32 bits +wide. NASM will therefore truncate most displacements and immediates to 32 +bits. +<p>The only instruction which takes a full 64-bit immediate is: +<p><pre> + MOV reg64,imm64 +</pre> +<p>NASM will produce this instruction whenever the programmer uses +<code><nobr>MOV</nobr></code> with an immediate into a 64-bit register. If +this is not desirable, simply specify the equivalent 32-bit register, which +will be automatically zero-extended by the processor, or specify the +immediate as <code><nobr>DWORD</nobr></code>: +<p><pre> + mov rax,foo ; 64-bit immediate + mov rax,qword foo ; (identical) + mov eax,foo ; 32-bit immediate, zero-extended + mov rax,dword foo ; 32-bit immediate, sign-extended +</pre> +<p>The length of these instructions are 10, 5 and 7 bytes, respectively. +<p>The only instructions which take a full 64-bit <em>displacement</em> is +loading or storing, using <code><nobr>MOV</nobr></code>, +<code><nobr>AL</nobr></code>, <code><nobr>AX</nobr></code>, +<code><nobr>EAX</nobr></code> or <code><nobr>RAX</nobr></code> (but no +other registers) to an absolute 64-bit address. Since this is a relatively +rarely used instruction (64-bit code generally uses relative addressing), +the programmer has to explicitly declare the displacement size as +<code><nobr>QWORD</nobr></code>: +<p><pre> + default abs + + mov eax,[foo] ; 32-bit absolute disp, sign-extended + mov eax,[a32 foo] ; 32-bit absolute disp, zero-extended + mov eax,[qword foo] ; 64-bit absolute disp + + default rel + + mov eax,[foo] ; 32-bit relative disp + mov eax,[a32 foo] ; d:o, address truncated to 32 bits(!) + mov eax,[qword foo] ; error + mov eax,[abs qword foo] ; 64-bit absolute disp +</pre> +<p>A sign-extended absolute displacement can access from -2 GB to +2 GB; a +zero-extended absolute displacement can access from 0 to 4 GB. +<h3><a name="section-11.3">11.3 Interfacing to 64-bit C Programs (Unix)</a></h3> +<p>On Unix, the 64-bit ABI is defined by the document: +<p> +<a href="http://www.x86-64.org/documentation/abi.pdf"><code><nobr>http://www.x86-64.org/documentation/abi.pdf</nobr></code></a> +<p>Although written for AT&T-syntax assembly, the concepts apply +equally well for NASM-style assembly. What follows is a simplified summary. +<p>The first six integer arguments (from the left) are passed in +<code><nobr>RDI</nobr></code>, <code><nobr>RSI</nobr></code>, +<code><nobr>RDX</nobr></code>, <code><nobr>RCX</nobr></code>, +<code><nobr>R8</nobr></code>, and <code><nobr>R9</nobr></code>, in that +order. Additional integer arguments are passed on the stack. These +registers, plus <code><nobr>RAX</nobr></code>, +<code><nobr>R10</nobr></code> and <code><nobr>R11</nobr></code> are +destroyed by function calls, and thus are available for use by the function +without saving. +<p>Integer return values are passed in <code><nobr>RAX</nobr></code> and +<code><nobr>RDX</nobr></code>, in that order. +<p>Floating point is done using SSE registers, except for +<code><nobr>long double</nobr></code>. Floating-point arguments are passed +in <code><nobr>XMM0</nobr></code> to <code><nobr>XMM7</nobr></code>; return +is <code><nobr>XMM0</nobr></code> and <code><nobr>XMM1</nobr></code>. +<code><nobr>long double</nobr></code> are passed on the stack, and returned +in <code><nobr>ST0</nobr></code> and <code><nobr>ST1</nobr></code>. +<p>All SSE and x87 registers are destroyed by function calls. +<p>On 64-bit Unix, <code><nobr>long</nobr></code> is 64 bits. +<p>Integer and SSE register arguments are counted separately, so for the +case of +<p><pre> + void foo(long a, double b, int c) +</pre> +<p><code><nobr>a</nobr></code> is passed in <code><nobr>RDI</nobr></code>, +<code><nobr>b</nobr></code> in <code><nobr>XMM0</nobr></code>, and +<code><nobr>c</nobr></code> in <code><nobr>ESI</nobr></code>. +<h3><a name="section-11.4">11.4 Interfacing to 64-bit C Programs (Win64)</a></h3> +<p>The Win64 ABI is described at: +<p> +<a href="http://msdn2.microsoft.com/en-gb/library/ms794533.aspx"><code><nobr>http://msdn2.microsoft.com/en-gb/library/ms794533.aspx</nobr></code></a> +<p>What follows is a simplified summary. +<p>The first four integer arguments are passed in +<code><nobr>RCX</nobr></code>, <code><nobr>RDX</nobr></code>, +<code><nobr>R8</nobr></code> and <code><nobr>R9</nobr></code>, in that +order. Additional integer arguments are passed on the stack. These +registers, plus <code><nobr>RAX</nobr></code>, +<code><nobr>R10</nobr></code> and <code><nobr>R11</nobr></code> are +destroyed by function calls, and thus are available for use by the function +without saving. +<p>Integer return values are passed in <code><nobr>RAX</nobr></code> only. +<p>Floating point is done using SSE registers, except for +<code><nobr>long double</nobr></code>. Floating-point arguments are passed +in <code><nobr>XMM0</nobr></code> to <code><nobr>XMM3</nobr></code>; return +is <code><nobr>XMM0</nobr></code> only. +<p>On Win64, <code><nobr>long</nobr></code> is 32 bits; +<code><nobr>long long</nobr></code> or <code><nobr>_int64</nobr></code> is +64 bits. +<p>Integer and SSE register arguments are counted together, so for the case +of +<p><pre> + void foo(long long a, double b, int c) +</pre> +<p><code><nobr>a</nobr></code> is passed in <code><nobr>RCX</nobr></code>, +<code><nobr>b</nobr></code> in <code><nobr>XMM1</nobr></code>, and +<code><nobr>c</nobr></code> in <code><nobr>R8D</nobr></code>. +<p align=center><a href="nasmdo12.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> diff --git a/doc/html/nasmdo12.html b/doc/html/nasmdo12.html new file mode 100644 index 0000000..9c937f8 --- /dev/null +++ b/doc/html/nasmdo12.html @@ -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="nasmdo11.html">Previous Chapter</a> | +<a href="nasmdoc0.html">Contents</a> | +<a href="nasmdoci.html">Index</a> +<h2><a name="chapter-12">Chapter 12: 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-12.1">12.1 Common Problems</a></h3> +<h4><a name="section-12.1.1">12.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>-O</nobr></code> option (see +<a href="nasmdoc2.html#section-2.1.22">section 2.1.22</a>). +<h4><a name="section-12.1.2">12.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.22">section 2.1.22</a>. +<h4><a name="section-12.1.3">12.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-12.1.4">12.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-12.2">12.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-12.1">section 12.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="nasmdo11.html">Previous Chapter</a> | +<a href="nasmdoc0.html">Contents</a> | +<a href="nasmdoci.html">Index</a> +</body></html> diff --git a/doc/html/nasmdoc0.html b/doc/html/nasmdoc0.html new file mode 100644 index 0000000..2b51d51 --- /dev/null +++ b/doc/html/nasmdoc0.html @@ -0,0 +1,378 @@ +<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: License 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>-MG</nobr></code> Option: Generate Makefile Dependencies</a><br> +<a href="nasmdoc2.html#section-2.1.6">Section 2.1.6: The <code><nobr>-MF</nobr></code> Option: Set Makefile Dependency File</a><br> +<a href="nasmdoc2.html#section-2.1.7">Section 2.1.7: The <code><nobr>-MD</nobr></code> Option: Assemble and Generate Dependencies</a><br> +<a href="nasmdoc2.html#section-2.1.8">Section 2.1.8: The <code><nobr>-MT</nobr></code> Option: Dependency Target Name</a><br> +<a href="nasmdoc2.html#section-2.1.9">Section 2.1.9: The <code><nobr>-MQ</nobr></code> Option: Dependency Target Name (Quoted)</a><br> +<a href="nasmdoc2.html#section-2.1.10">Section 2.1.10: The <code><nobr>-MP</nobr></code> Option: Emit phony targets</a><br> +<a href="nasmdoc2.html#section-2.1.11">Section 2.1.11: The <code><nobr>-F</nobr></code> Option: Selecting a Debug Information Format</a><br> +<a href="nasmdoc2.html#section-2.1.12">Section 2.1.12: The <code><nobr>-g</nobr></code> Option: Enabling Debug Information.</a><br> +<a href="nasmdoc2.html#section-2.1.13">Section 2.1.13: The <code><nobr>-X</nobr></code> Option: Selecting an Error Reporting Format</a><br> +<a href="nasmdoc2.html#section-2.1.14">Section 2.1.14: The <code><nobr>-Z</nobr></code> Option: Send Errors to a File</a><br> +<a href="nasmdoc2.html#section-2.1.15">Section 2.1.15: The <code><nobr>-s</nobr></code> Option: Send Errors to <code><nobr>stdout</nobr></code></a><br> +<a href="nasmdoc2.html#section-2.1.16">Section 2.1.16: The <code><nobr>-i</nobr></code> Option: Include File Search Directories</a><br> +<a href="nasmdoc2.html#section-2.1.17">Section 2.1.17: The <code><nobr>-p</nobr></code> Option: Pre-Include a File</a><br> +<a href="nasmdoc2.html#section-2.1.18">Section 2.1.18: The <code><nobr>-d</nobr></code> Option: Pre-Define a Macro</a><br> +<a href="nasmdoc2.html#section-2.1.19">Section 2.1.19: The <code><nobr>-u</nobr></code> Option: Undefine a Macro</a><br> +<a href="nasmdoc2.html#section-2.1.20">Section 2.1.20: The <code><nobr>-E</nobr></code> Option: Preprocess Only</a><br> +<a href="nasmdoc2.html#section-2.1.21">Section 2.1.21: The <code><nobr>-a</nobr></code> Option: Don't Preprocess At All</a><br> +<a href="nasmdoc2.html#section-2.1.22">Section 2.1.22: The <code><nobr>-O</nobr></code> Option: Specifying Multipass Optimization</a><br> +<a href="nasmdoc2.html#section-2.1.23">Section 2.1.23: The <code><nobr>-t</nobr></code> Option: Enable TASM Compatibility Mode</a><br> +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24: The <code><nobr>-w</nobr></code> and <code><nobr>-W</nobr></code> Options: Enable or Disable Assembly Warnings</a><br> +<a href="nasmdoc2.html#section-2.1.25">Section 2.1.25: The <code><nobr>-v</nobr></code> Option: Display Version Info</a><br> +<a href="nasmdoc2.html#section-2.1.26">Section 2.1.26: The <code><nobr>-y</nobr></code> Option: Display Available Debug Info Formats</a><br> +<a href="nasmdoc2.html#section-2.1.27">Section 2.1.27: The <code><nobr>--prefix</nobr></code> and <code><nobr>--postfix</nobr></code> Options.</a><br> +<a href="nasmdoc2.html#section-2.1.28">Section 2.1.28: 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 Initialized Data</a><br> +<a href="nasmdoc3.html#section-3.2.2">Section 3.2.2: <code><nobr>RESB</nobr></code> and Friends: Declaring Uninitialized 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 Strings</a><br> +<a href="nasmdoc3.html#section-3.4.3">Section 3.4.3: Character Constants</a><br> +<a href="nasmdoc3.html#section-3.4.4">Section 3.4.4: String Constants</a><br> +<a href="nasmdoc3.html#section-3.4.5">Section 3.4.5: Unicode Strings</a><br> +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6: Floating-Point Constants</a><br> +<a href="nasmdoc3.html#section-3.4.7">Section 3.4.7: Packed BCD 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>, <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: Resolving <code><nobr>%define</nobr></code>: <code><nobr>%xdefine</nobr></code></a><br> +<a href="nasmdoc4.html#section-4.1.3">Section 4.1.3: Macro Indirection: <code><nobr>%[...]</nobr></code></a><br> +<a href="nasmdoc4.html#section-4.1.4">Section 4.1.4: Concatenating Single Line Macro Tokens: <code><nobr>%+</nobr></code></a><br> +<a href="nasmdoc4.html#section-4.1.5">Section 4.1.5: The Macro Name Itself: <code><nobr>%?</nobr></code> and <code><nobr>%??</nobr></code></a><br> +<a href="nasmdoc4.html#section-4.1.6">Section 4.1.6: Undefining Single-Line Macros: <code><nobr>%undef</nobr></code></a><br> +<a href="nasmdoc4.html#section-4.1.7">Section 4.1.7: Preprocessor Variables: <code><nobr>%assign</nobr></code></a><br> +<a href="nasmdoc4.html#section-4.1.8">Section 4.1.8: Defining Strings: <code><nobr>%defstr</nobr></code></a><br> +<a href="nasmdoc4.html#section-4.1.9">Section 4.1.9: Defining Tokens: <code><nobr>%deftok</nobr></code></a><br> +<a href="nasmdoc4.html#section-4.2">Section 4.2: String Manipulation in Macros</a><br> +<a href="nasmdoc4.html#section-4.2.1">Section 4.2.1: Concatenating Strings: <code><nobr>%strcat</nobr></code></a><br> +<a href="nasmdoc4.html#section-4.2.2">Section 4.2.2: String Length: <code><nobr>%strlen</nobr></code></a><br> +<a href="nasmdoc4.html#section-4.2.3">Section 4.2.3: Extracting Substrings: <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: Recursive Multi-Line Macros: <code><nobr>%rmacro</nobr></code></a><br> +<a href="nasmdoc4.html#section-4.3.2">Section 4.3.2: Overloading Multi-Line Macros</a><br> +<a href="nasmdoc4.html#section-4.3.3">Section 4.3.3: Macro-Local Labels</a><br> +<a href="nasmdoc4.html#section-4.3.4">Section 4.3.4: Greedy Macro Parameters</a><br> +<a href="nasmdoc4.html#section-4.3.5">Section 4.3.5: Default Macro Parameters</a><br> +<a href="nasmdoc4.html#section-4.3.6">Section 4.3.6: <code><nobr>%0</nobr></code>: Macro Parameter Counter</a><br> +<a href="nasmdoc4.html#section-4.3.7">Section 4.3.7: <code><nobr>%rotate</nobr></code>: Rotating Macro Parameters</a><br> +<a href="nasmdoc4.html#section-4.3.8">Section 4.3.8: Concatenating Macro Parameters</a><br> +<a href="nasmdoc4.html#section-4.3.9">Section 4.3.9: Condition Codes as Macro Parameters</a><br> +<a href="nasmdoc4.html#section-4.3.10">Section 4.3.10: Disabling Listing Expansion</a><br> +<a href="nasmdoc4.html#section-4.3.11">Section 4.3.11: Undefining Multi-Line Macros: <code><nobr>%unmacro</nobr></code></a><br> +<a href="nasmdoc4.html#section-4.3.12">Section 4.3.12: Exiting Multi-Line Macros: <code><nobr>%exitmacro</nobr></code></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>%iftoken</nobr></code>: Test for a Single Token</a><br> +<a href="nasmdoc4.html#section-4.4.8">Section 4.4.8: <code><nobr>%ifempty</nobr></code>: Test for Empty Expansion</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: Source Files and Dependencies</a><br> +<a href="nasmdoc4.html#section-4.6.1">Section 4.6.1: <code><nobr>%include</nobr></code>: Including Other Files</a><br> +<a href="nasmdoc4.html#section-4.6.2">Section 4.6.2: <code><nobr>%pathsearch</nobr></code>: Search the Include Path</a><br> +<a href="nasmdoc4.html#section-4.6.3">Section 4.6.3: <code><nobr>%depend</nobr></code>: Add Dependent Files</a><br> +<a href="nasmdoc4.html#section-4.6.4">Section 4.6.4: <code><nobr>%use</nobr></code>: Include Standard Macro Package</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: Stack Relative Preprocessor Directives</a><br> +<a href="nasmdoc4.html#section-4.8.1">Section 4.8.1: <code><nobr>%arg</nobr></code> Directive</a><br> +<a href="nasmdoc4.html#section-4.8.2">Section 4.8.2: <code><nobr>%stacksize</nobr></code> Directive</a><br> +<a href="nasmdoc4.html#section-4.8.3">Section 4.8.3: <code><nobr>%local</nobr></code> Directive</a><br> +<a href="nasmdoc4.html#section-4.9">Section 4.9: Reporting User-Defined Errors: <code><nobr>%error</nobr></code>, <code><nobr>%warning</nobr></code>, <code><nobr>%fatal</nobr></code></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> +<a href="nasmdoc4.html#section-4.11">Section 4.11: Standard Macros</a><br> +<a href="nasmdoc4.html#section-4.11.1">Section 4.11.1: NASM Version Macros</a><br> +<a href="nasmdoc4.html#section-4.11.2">Section 4.11.2: <code><nobr>__NASM_VERSION_ID__</nobr></code>: NASM Version ID</a><br> +<a href="nasmdoc4.html#section-4.11.3">Section 4.11.3: <code><nobr>__NASM_VER__</nobr></code>: NASM Version string</a><br> +<a href="nasmdoc4.html#section-4.11.4">Section 4.11.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.11.5">Section 4.11.5: <code><nobr>__BITS__</nobr></code>: Current BITS Mode</a><br> +<a href="nasmdoc4.html#section-4.11.6">Section 4.11.6: <code><nobr>__OUTPUT_FORMAT__</nobr></code>: Current Output Format</a><br> +<a href="nasmdoc4.html#section-4.11.7">Section 4.11.7: Assembly Date and Time Macros</a><br> +<a href="nasmdoc4.html#section-4.11.8">Section 4.11.8: <code><nobr>__USE_</nobr></code><em>package</em><code><nobr>__</nobr></code>: Package Include Test</a><br> +<a href="nasmdoc4.html#section-4.11.9">Section 4.11.9: <code><nobr>__PASS__</nobr></code>: Assembly Pass</a><br> +<a href="nasmdoc4.html#section-4.11.10">Section 4.11.10: <code><nobr>STRUC</nobr></code> and <code><nobr>ENDSTRUC</nobr></code>: Declaring Structure Data Types</a><br> +<a href="nasmdoc4.html#section-4.11.11">Section 4.11.11: <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.11.12">Section 4.11.12: <code><nobr>ALIGN</nobr></code> and <code><nobr>ALIGNB</nobr></code>: Data Alignment</a><br> +<p><a href="nasmdoc5.html">Chapter 5: Standard Macro Packages</a><br> +<a href="nasmdoc5.html#section-5.1">Section 5.1: <code><nobr>altreg</nobr></code>: Alternate Register Names</a><br> +<a href="nasmdoc5.html#section-5.2">Section 5.2: <code><nobr>smartalign</nobr></code>: Smart <code><nobr>ALIGN</nobr></code> Macro</a><br> +<p><a href="nasmdoc6.html">Chapter 6: Assembler Directives</a><br> +<a href="nasmdoc6.html#section-6.1">Section 6.1: <code><nobr>BITS</nobr></code>: Specifying Target Processor Mode</a><br> +<a href="nasmdoc6.html#section-6.1.1">Section 6.1.1: <code><nobr>USE16</nobr></code> & <code><nobr>USE32</nobr></code>: Aliases for BITS</a><br> +<a href="nasmdoc6.html#section-6.2">Section 6.2: <code><nobr>DEFAULT</nobr></code>: Change the assembler defaults</a><br> +<a href="nasmdoc6.html#section-6.3">Section 6.3: <code><nobr>SECTION</nobr></code> or <code><nobr>SEGMENT</nobr></code>: Changing and Defining Sections</a><br> +<a href="nasmdoc6.html#section-6.3.1">Section 6.3.1: The <code><nobr>__SECT__</nobr></code> Macro</a><br> +<a href="nasmdoc6.html#section-6.4">Section 6.4: <code><nobr>ABSOLUTE</nobr></code>: Defining Absolute Labels</a><br> +<a href="nasmdoc6.html#section-6.5">Section 6.5: <code><nobr>EXTERN</nobr></code>: Importing Symbols from Other Modules</a><br> +<a href="nasmdoc6.html#section-6.6">Section 6.6: <code><nobr>GLOBAL</nobr></code>: Exporting Symbols to Other Modules</a><br> +<a href="nasmdoc6.html#section-6.7">Section 6.7: <code><nobr>COMMON</nobr></code>: Defining Common Data Areas</a><br> +<a href="nasmdoc6.html#section-6.8">Section 6.8: <code><nobr>CPU</nobr></code>: Defining CPU Dependencies</a><br> +<a href="nasmdoc6.html#section-6.9">Section 6.9: <code><nobr>FLOAT</nobr></code>: Handling of floating-point constants</a><br> +<p><a href="nasmdoc7.html">Chapter 7: Output Formats</a><br> +<a href="nasmdoc7.html#section-7.1">Section 7.1: <code><nobr>bin</nobr></code>: Flat-Form Binary Output</a><br> +<a href="nasmdoc7.html#section-7.1.1">Section 7.1.1: <code><nobr>ORG</nobr></code>: Binary File Program Origin</a><br> +<a href="nasmdoc7.html#section-7.1.2">Section 7.1.2: <code><nobr>bin</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a><br> +<a href="nasmdoc7.html#section-7.1.3">Section 7.1.3: Multisection Support for the <code><nobr>bin</nobr></code> Format</a><br> +<a href="nasmdoc7.html#section-7.1.4">Section 7.1.4: Map Files</a><br> +<a href="nasmdoc7.html#section-7.2">Section 7.2: <code><nobr>ith</nobr></code>: Intel Hex Output</a><br> +<a href="nasmdoc7.html#section-7.3">Section 7.3: <code><nobr>srec</nobr></code>: Motorola S-Records Output</a><br> +<a href="nasmdoc7.html#section-7.4">Section 7.4: <code><nobr>obj</nobr></code>: Microsoft OMF Object Files</a><br> +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1: <code><nobr>obj</nobr></code> Extensions to the <code><nobr>SEGMENT</nobr></code> Directive</a><br> +<a href="nasmdoc7.html#section-7.4.2">Section 7.4.2: <code><nobr>GROUP</nobr></code>: Defining Groups of Segments</a><br> +<a href="nasmdoc7.html#section-7.4.3">Section 7.4.3: <code><nobr>UPPERCASE</nobr></code>: Disabling Case Sensitivity in Output</a><br> +<a href="nasmdoc7.html#section-7.4.4">Section 7.4.4: <code><nobr>IMPORT</nobr></code>: Importing DLL Symbols</a><br> +<a href="nasmdoc7.html#section-7.4.5">Section 7.4.5: <code><nobr>EXPORT</nobr></code>: Exporting DLL Symbols</a><br> +<a href="nasmdoc7.html#section-7.4.6">Section 7.4.6: <code><nobr>..start</nobr></code>: Defining the Program Entry Point</a><br> +<a href="nasmdoc7.html#section-7.4.7">Section 7.4.7: <code><nobr>obj</nobr></code> Extensions to the <code><nobr>EXTERN</nobr></code> Directive</a><br> +<a href="nasmdoc7.html#section-7.4.8">Section 7.4.8: <code><nobr>obj</nobr></code> Extensions to the <code><nobr>COMMON</nobr></code> Directive</a><br> +<a href="nasmdoc7.html#section-7.5">Section 7.5: <code><nobr>win32</nobr></code>: Microsoft Win32 Object Files</a><br> +<a href="nasmdoc7.html#section-7.5.1">Section 7.5.1: <code><nobr>win32</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a><br> +<a href="nasmdoc7.html#section-7.5.2">Section 7.5.2: <code><nobr>win32</nobr></code>: Safe Structured Exception Handling</a><br> +<a href="nasmdoc7.html#section-7.6">Section 7.6: <code><nobr>win64</nobr></code>: Microsoft Win64 Object Files</a><br> +<a href="nasmdoc7.html#section-7.6.1">Section 7.6.1: <code><nobr>win64</nobr></code>: Writing Position-Independent Code</a><br> +<a href="nasmdoc7.html#section-7.6.2">Section 7.6.2: <code><nobr>win64</nobr></code>: Structured Exception Handling</a><br> +<a href="nasmdoc7.html#section-7.7">Section 7.7: <code><nobr>coff</nobr></code>: Common Object File Format</a><br> +<a href="nasmdoc7.html#section-7.8">Section 7.8: <code><nobr>macho32</nobr></code> and <code><nobr>macho64</nobr></code>: Mach Object File Format</a><br> +<a href="nasmdoc7.html#section-7.9">Section 7.9: <code><nobr>elf32</nobr></code> and <code><nobr>elf64</nobr></code>: Executable and Linkable Format Object Files</a><br> +<a href="nasmdoc7.html#section-7.9.1">Section 7.9.1: ELF specific directive <code><nobr>osabi</nobr></code></a><br> +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2: <code><nobr>elf</nobr></code> Extensions to the <code><nobr>SECTION</nobr></code> Directive</a><br> +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3: Position-Independent Code: <code><nobr>elf</nobr></code> Special Symbols and <code><nobr>WRT</nobr></code></a><br> +<a href="nasmdoc7.html#section-7.9.4">Section 7.9.4: Thread Local Storage: <code><nobr>elf</nobr></code> Special Symbols and <code><nobr>WRT</nobr></code></a><br> +<a href="nasmdoc7.html#section-7.9.5">Section 7.9.5: <code><nobr>elf</nobr></code> Extensions to the <code><nobr>GLOBAL</nobr></code> Directive</a><br> +<a href="nasmdoc7.html#section-7.9.6">Section 7.9.6: <code><nobr>elf</nobr></code> Extensions to the <code><nobr>COMMON</nobr></code> Directive </a><br> +<a href="nasmdoc7.html#section-7.9.7">Section 7.9.7: 16-bit code and ELF </a><br> +<a href="nasmdoc7.html#section-7.9.8">Section 7.9.8: Debug formats and ELF </a><br> +<a href="nasmdoc7.html#section-7.10">Section 7.10: <code><nobr>aout</nobr></code>: Linux <code><nobr>a.out</nobr></code> Object Files</a><br> +<a href="nasmdoc7.html#section-7.11">Section 7.11: <code><nobr>aoutb</nobr></code>: NetBSD/FreeBSD/OpenBSD <code><nobr>a.out</nobr></code> Object Files</a><br> +<a href="nasmdoc7.html#section-7.12">Section 7.12: <code><nobr>as86</nobr></code>: Minix/Linux <code><nobr>as86</nobr></code> Object Files</a><br> +<a href="nasmdoc7.html#section-7.13">Section 7.13: <code><nobr>rdf</nobr></code>: Relocatable Dynamic Object File Format</a><br> +<a href="nasmdoc7.html#section-7.13.1">Section 7.13.1: Requiring a Library: The <code><nobr>LIBRARY</nobr></code> Directive</a><br> +<a href="nasmdoc7.html#section-7.13.2">Section 7.13.2: Specifying a Module Name: The <code><nobr>MODULE</nobr></code> Directive</a><br> +<a href="nasmdoc7.html#section-7.13.3">Section 7.13.3: <code><nobr>rdf</nobr></code> Extensions to the <code><nobr>GLOBAL</nobr></code> Directive</a><br> +<a href="nasmdoc7.html#section-7.13.4">Section 7.13.4: <code><nobr>rdf</nobr></code> Extensions to the <code><nobr>EXTERN</nobr></code> Directive</a><br> +<a href="nasmdoc7.html#section-7.14">Section 7.14: <code><nobr>dbg</nobr></code>: Debugging Format</a><br> +<p><a href="nasmdoc8.html">Chapter 8: Writing 16-bit Code (DOS, Windows 3/3.1)</a><br> +<a href="nasmdoc8.html#section-8.1">Section 8.1: Producing <code><nobr>.EXE</nobr></code> Files</a><br> +<a href="nasmdoc8.html#section-8.1.1">Section 8.1.1: Using the <code><nobr>obj</nobr></code> Format To Generate <code><nobr>.EXE</nobr></code> Files</a><br> +<a href="nasmdoc8.html#section-8.1.2">Section 8.1.2: Using the <code><nobr>bin</nobr></code> Format To Generate <code><nobr>.EXE</nobr></code> Files</a><br> +<a href="nasmdoc8.html#section-8.2">Section 8.2: Producing <code><nobr>.COM</nobr></code> Files</a><br> +<a href="nasmdoc8.html#section-8.2.1">Section 8.2.1: Using the <code><nobr>bin</nobr></code> Format To Generate <code><nobr>.COM</nobr></code> Files</a><br> +<a href="nasmdoc8.html#section-8.2.2">Section 8.2.2: Using the <code><nobr>obj</nobr></code> Format To Generate <code><nobr>.COM</nobr></code> Files</a><br> +<a href="nasmdoc8.html#section-8.3">Section 8.3: Producing <code><nobr>.SYS</nobr></code> Files</a><br> +<a href="nasmdoc8.html#section-8.4">Section 8.4: Interfacing to 16-bit C Programs</a><br> +<a href="nasmdoc8.html#section-8.4.1">Section 8.4.1: External Symbol Names</a><br> +<a href="nasmdoc8.html#section-8.4.2">Section 8.4.2: Memory Models</a><br> +<a href="nasmdoc8.html#section-8.4.3">Section 8.4.3: Function Definitions and Function Calls</a><br> +<a href="nasmdoc8.html#section-8.4.4">Section 8.4.4: Accessing Data Items</a><br> +<a href="nasmdoc8.html#section-8.4.5">Section 8.4.5: <code><nobr>c16.mac</nobr></code>: Helper Macros for the 16-bit C Interface</a><br> +<a href="nasmdoc8.html#section-8.5">Section 8.5: Interfacing to Borland Pascal Programs</a><br> +<a href="nasmdoc8.html#section-8.5.1">Section 8.5.1: The Pascal Calling Convention</a><br> +<a href="nasmdoc8.html#section-8.5.2">Section 8.5.2: Borland Pascal Segment Name Restrictions</a><br> +<a href="nasmdoc8.html#section-8.5.3">Section 8.5.3: Using <code><nobr>c16.mac</nobr></code> With Pascal Programs</a><br> +<p><a href="nasmdoc9.html">Chapter 9: Writing 32-bit Code (Unix, Win32, DJGPP)</a><br> +<a href="nasmdoc9.html#section-9.1">Section 9.1: Interfacing to 32-bit C Programs</a><br> +<a href="nasmdoc9.html#section-9.1.1">Section 9.1.1: External Symbol Names</a><br> +<a href="nasmdoc9.html#section-9.1.2">Section 9.1.2: Function Definitions and Function Calls</a><br> +<a href="nasmdoc9.html#section-9.1.3">Section 9.1.3: Accessing Data Items</a><br> +<a href="nasmdoc9.html#section-9.1.4">Section 9.1.4: <code><nobr>c32.mac</nobr></code>: Helper Macros for the 32-bit C Interface</a><br> +<a href="nasmdoc9.html#section-9.2">Section 9.2: Writing NetBSD/FreeBSD/OpenBSD and Linux/ELF Shared Libraries</a><br> +<a href="nasmdoc9.html#section-9.2.1">Section 9.2.1: Obtaining the Address of the GOT</a><br> +<a href="nasmdoc9.html#section-9.2.2">Section 9.2.2: Finding Your Local Data Items</a><br> +<a href="nasmdoc9.html#section-9.2.3">Section 9.2.3: Finding External and Common Data Items</a><br> +<a href="nasmdoc9.html#section-9.2.4">Section 9.2.4: Exporting Symbols to the Library User</a><br> +<a href="nasmdoc9.html#section-9.2.5">Section 9.2.5: Calling Procedures Outside the Library</a><br> +<a href="nasmdoc9.html#section-9.2.6">Section 9.2.6: Generating the Library File</a><br> +<p><a href="nasmdo10.html">Chapter 10: Mixing 16 and 32 Bit Code</a><br> +<a href="nasmdo10.html#section-10.1">Section 10.1: Mixed-Size Jumps</a><br> +<a href="nasmdo10.html#section-10.2">Section 10.2: Addressing Between Different-Size Segments</a><br> +<a href="nasmdo10.html#section-10.3">Section 10.3: Other Mixed-Size Instructions</a><br> +<p><a href="nasmdo11.html">Chapter 11: Writing 64-bit Code (Unix, Win64)</a><br> +<a href="nasmdo11.html#section-11.1">Section 11.1: Register Names in 64-bit Mode</a><br> +<a href="nasmdo11.html#section-11.2">Section 11.2: Immediates and Displacements in 64-bit Mode</a><br> +<a href="nasmdo11.html#section-11.3">Section 11.3: Interfacing to 64-bit C Programs (Unix)</a><br> +<a href="nasmdo11.html#section-11.4">Section 11.4: Interfacing to 64-bit C Programs (Win64)</a><br> +<p><a href="nasmdo12.html">Chapter 12: Troubleshooting</a><br> +<a href="nasmdo12.html#section-12.1">Section 12.1: Common Problems</a><br> +<a href="nasmdo12.html#section-12.1.1">Section 12.1.1: NASM Generates Inefficient Code</a><br> +<a href="nasmdo12.html#section-12.1.2">Section 12.1.2: My Jumps are Out of Range</a><br> +<a href="nasmdo12.html#section-12.1.3">Section 12.1.3: <code><nobr>ORG</nobr></code> Doesn't Work</a><br> +<a href="nasmdo12.html#section-12.1.4">Section 12.1.4: <code><nobr>TIMES</nobr></code> Doesn't Work</a><br> +<a href="nasmdo12.html#section-12.2">Section 12.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: Instruction List</a><br> +<a href="nasmdocb.html#section-B.1">Section B.1: Introduction</a><br> +<a href="nasmdocb.html#section-B.1.1">Section B.1.1: Special instructions...</a><br> +<a href="nasmdocb.html#section-B.1.2">Section B.1.2: Conventional instructions</a><br> +<a href="nasmdocb.html#section-B.1.3">Section B.1.3: Katmai Streaming SIMD instructions (SSE -- a.k.a. KNI, XMM, MMX2)</a><br> +<a href="nasmdocb.html#section-B.1.4">Section B.1.4: Introduced in Deschutes but necessary for SSE support</a><br> +<a href="nasmdocb.html#section-B.1.5">Section B.1.5: XSAVE group (AVX and extended state)</a><br> +<a href="nasmdocb.html#section-B.1.6">Section B.1.6: Generic memory operations</a><br> +<a href="nasmdocb.html#section-B.1.7">Section B.1.7: New MMX instructions introduced in Katmai</a><br> +<a href="nasmdocb.html#section-B.1.8">Section B.1.8: AMD Enhanced 3DNow! (Athlon) instructions</a><br> +<a href="nasmdocb.html#section-B.1.9">Section B.1.9: Willamette SSE2 Cacheability Instructions</a><br> +<a href="nasmdocb.html#section-B.1.10">Section B.1.10: Willamette MMX instructions (SSE2 SIMD Integer Instructions)</a><br> +<a href="nasmdocb.html#section-B.1.11">Section B.1.11: Willamette Streaming SIMD instructions (SSE2)</a><br> +<a href="nasmdocb.html#section-B.1.12">Section B.1.12: Prescott New Instructions (SSE3)</a><br> +<a href="nasmdocb.html#section-B.1.13">Section B.1.13: VMX Instructions</a><br> +<a href="nasmdocb.html#section-B.1.14">Section B.1.14: Extended Page Tables VMX instructions</a><br> +<a href="nasmdocb.html#section-B.1.15">Section B.1.15: Tejas New Instructions (SSSE3)</a><br> +<a href="nasmdocb.html#section-B.1.16">Section B.1.16: AMD SSE4A</a><br> +<a href="nasmdocb.html#section-B.1.17">Section B.1.17: New instructions in Barcelona</a><br> +<a href="nasmdocb.html#section-B.1.18">Section B.1.18: Penryn New Instructions (SSE4.1)</a><br> +<a href="nasmdocb.html#section-B.1.19">Section B.1.19: Nehalem New Instructions (SSE4.2)</a><br> +<a href="nasmdocb.html#section-B.1.20">Section B.1.20: Intel SMX</a><br> +<a href="nasmdocb.html#section-B.1.21">Section B.1.21: Geode (Cyrix) 3DNow! additions</a><br> +<a href="nasmdocb.html#section-B.1.22">Section B.1.22: Intel new instructions in ???</a><br> +<a href="nasmdocb.html#section-B.1.23">Section B.1.23: Intel AES instructions</a><br> +<a href="nasmdocb.html#section-B.1.24">Section B.1.24: Intel AVX AES instructions</a><br> +<a href="nasmdocb.html#section-B.1.25">Section B.1.25: Intel AVX instructions</a><br> +<a href="nasmdocb.html#section-B.1.26">Section B.1.26: Intel Carry-Less Multiplication instructions (CLMUL)</a><br> +<a href="nasmdocb.html#section-B.1.27">Section B.1.27: Intel AVX Carry-Less Multiplication instructions (CLMUL)</a><br> +<a href="nasmdocb.html#section-B.1.28">Section B.1.28: Intel Fused Multiply-Add instructions (FMA)</a><br> +<a href="nasmdocb.html#section-B.1.29">Section B.1.29: VIA (Centaur) security instructions</a><br> +<a href="nasmdocb.html#section-B.1.30">Section B.1.30: AMD Lightweight Profiling (LWP) instructions</a><br> +<a href="nasmdocb.html#section-B.1.31">Section B.1.31: AMD XOP, FMA4 and CVT16 instructions (SSE5)</a><br> +<a href="nasmdocb.html#section-B.1.32">Section B.1.32: Systematic names for the hinting nop instructions</a><br> +<p><a href="nasmdocc.html">Appendix C: NASM Version History</a><br> +<a href="nasmdocc.html#section-C.1">Section C.1: NASM 2 Series</a><br> +<a href="nasmdocc.html#section-C.1.1">Section C.1.1: Version 2.08</a><br> +<a href="nasmdocc.html#section-C.1.2">Section C.1.2: Version 2.07</a><br> +<a href="nasmdocc.html#section-C.1.3">Section C.1.3: Version 2.06</a><br> +<a href="nasmdocc.html#section-C.1.4">Section C.1.4: Version 2.05.01</a><br> +<a href="nasmdocc.html#section-C.1.5">Section C.1.5: Version 2.05</a><br> +<a href="nasmdocc.html#section-C.1.6">Section C.1.6: Version 2.04</a><br> +<a href="nasmdocc.html#section-C.1.7">Section C.1.7: Version 2.03.01</a><br> +<a href="nasmdocc.html#section-C.1.8">Section C.1.8: Version 2.03</a><br> +<a href="nasmdocc.html#section-C.1.9">Section C.1.9: Version 2.02</a><br> +<a href="nasmdocc.html#section-C.1.10">Section C.1.10: Version 2.01</a><br> +<a href="nasmdocc.html#section-C.1.11">Section C.1.11: Version 2.00</a><br> +<a href="nasmdocc.html#section-C.2">Section C.2: NASM 0.98 Series</a><br> +<a href="nasmdocc.html#section-C.2.1">Section C.2.1: Version 0.98.39</a><br> +<a href="nasmdocc.html#section-C.2.2">Section C.2.2: Version 0.98.38</a><br> +<a href="nasmdocc.html#section-C.2.3">Section C.2.3: Version 0.98.37</a><br> +<a href="nasmdocc.html#section-C.2.4">Section C.2.4: Version 0.98.36</a><br> +<a href="nasmdocc.html#section-C.2.5">Section C.2.5: Version 0.98.35</a><br> +<a href="nasmdocc.html#section-C.2.6">Section C.2.6: Version 0.98.34</a><br> +<a href="nasmdocc.html#section-C.2.7">Section C.2.7: Version 0.98.33</a><br> +<a href="nasmdocc.html#section-C.2.8">Section C.2.8: Version 0.98.32</a><br> +<a href="nasmdocc.html#section-C.2.9">Section C.2.9: Version 0.98.31</a><br> +<a href="nasmdocc.html#section-C.2.10">Section C.2.10: Version 0.98.30</a><br> +<a href="nasmdocc.html#section-C.2.11">Section C.2.11: Version 0.98.28</a><br> +<a href="nasmdocc.html#section-C.2.12">Section C.2.12: Version 0.98.26</a><br> +<a href="nasmdocc.html#section-C.2.13">Section C.2.13: Version 0.98.25alt</a><br> +<a href="nasmdocc.html#section-C.2.14">Section C.2.14: Version 0.98.25</a><br> +<a href="nasmdocc.html#section-C.2.15">Section C.2.15: Version 0.98.24p1</a><br> +<a href="nasmdocc.html#section-C.2.16">Section C.2.16: Version 0.98.24</a><br> +<a href="nasmdocc.html#section-C.2.17">Section C.2.17: Version 0.98.23</a><br> +<a href="nasmdocc.html#section-C.2.18">Section C.2.18: Version 0.98.22</a><br> +<a href="nasmdocc.html#section-C.2.19">Section C.2.19: Version 0.98.21</a><br> +<a href="nasmdocc.html#section-C.2.20">Section C.2.20: Version 0.98.20</a><br> +<a href="nasmdocc.html#section-C.2.21">Section C.2.21: Version 0.98.19</a><br> +<a href="nasmdocc.html#section-C.2.22">Section C.2.22: Version 0.98.18</a><br> +<a href="nasmdocc.html#section-C.2.23">Section C.2.23: Version 0.98.17</a><br> +<a href="nasmdocc.html#section-C.2.24">Section C.2.24: Version 0.98.16</a><br> +<a href="nasmdocc.html#section-C.2.25">Section C.2.25: Version 0.98.15</a><br> +<a href="nasmdocc.html#section-C.2.26">Section C.2.26: Version 0.98.14</a><br> +<a href="nasmdocc.html#section-C.2.27">Section C.2.27: Version 0.98.13</a><br> +<a href="nasmdocc.html#section-C.2.28">Section C.2.28: Version 0.98.12</a><br> +<a href="nasmdocc.html#section-C.2.29">Section C.2.29: Version 0.98.11</a><br> +<a href="nasmdocc.html#section-C.2.30">Section C.2.30: Version 0.98.10</a><br> +<a href="nasmdocc.html#section-C.2.31">Section C.2.31: Version 0.98.09</a><br> +<a href="nasmdocc.html#section-C.2.32">Section C.2.32: Version 0.98.08</a><br> +<a href="nasmdocc.html#section-C.2.33">Section C.2.33: Version 0.98.09b with John Coffman patches released 28-Oct-2001</a><br> +<a href="nasmdocc.html#section-C.2.34">Section C.2.34: Version 0.98.07 released 01/28/01</a><br> +<a href="nasmdocc.html#section-C.2.35">Section C.2.35: Version 0.98.06f released 01/18/01</a><br> +<a href="nasmdocc.html#section-C.2.36">Section C.2.36: Version 0.98.06e released 01/09/01</a><br> +<a href="nasmdocc.html#section-C.2.37">Section C.2.37: Version 0.98p1</a><br> +<a href="nasmdocc.html#section-C.2.38">Section C.2.38: Version 0.98bf (bug-fixed)</a><br> +<a href="nasmdocc.html#section-C.2.39">Section C.2.39: Version 0.98.03 with John Coffman's changes released 27-Jul-2000</a><br> +<a href="nasmdocc.html#section-C.2.40">Section C.2.40: Version 0.98.03</a><br> +<a href="nasmdocc.html#section-C.2.41">Section C.2.41: Version 0.98</a><br> +<a href="nasmdocc.html#section-C.2.42">Section C.2.42: Version 0.98p9</a><br> +<a href="nasmdocc.html#section-C.2.43">Section C.2.43: Version 0.98p8</a><br> +<a href="nasmdocc.html#section-C.2.44">Section C.2.44: Version 0.98p7</a><br> +<a href="nasmdocc.html#section-C.2.45">Section C.2.45: Version 0.98p6</a><br> +<a href="nasmdocc.html#section-C.2.46">Section C.2.46: Version 0.98p3.7</a><br> +<a href="nasmdocc.html#section-C.2.47">Section C.2.47: Version 0.98p3.6</a><br> +<a href="nasmdocc.html#section-C.2.48">Section C.2.48: Version 0.98p3.5</a><br> +<a href="nasmdocc.html#section-C.2.49">Section C.2.49: Version 0.98p3.4</a><br> +<a href="nasmdocc.html#section-C.2.50">Section C.2.50: Version 0.98p3.3</a><br> +<a href="nasmdocc.html#section-C.2.51">Section C.2.51: Version 0.98p3.2</a><br> +<a href="nasmdocc.html#section-C.2.52">Section C.2.52: Version 0.98p3-hpa</a><br> +<a href="nasmdocc.html#section-C.2.53">Section C.2.53: Version 0.98 pre-release 3</a><br> +<a href="nasmdocc.html#section-C.2.54">Section C.2.54: Version 0.98 pre-release 2</a><br> +<a href="nasmdocc.html#section-C.2.55">Section C.2.55: Version 0.98 pre-release 1</a><br> +<a href="nasmdocc.html#section-C.3">Section C.3: NASM 0.9 Series</a><br> +<a href="nasmdocc.html#section-C.3.1">Section C.3.1: Version 0.97 released December 1997</a><br> +<a href="nasmdocc.html#section-C.3.2">Section C.3.2: Version 0.96 released November 1997</a><br> +<a href="nasmdocc.html#section-C.3.3">Section C.3.3: Version 0.95 released July 1997</a><br> +<a href="nasmdocc.html#section-C.3.4">Section C.3.4: Version 0.94 released April 1997</a><br> +<a href="nasmdocc.html#section-C.3.5">Section C.3.5: Version 0.93 released January 1997</a><br> +<a href="nasmdocc.html#section-C.3.6">Section C.3.6: Version 0.92 released January 1997</a><br> +<a href="nasmdocc.html#section-C.3.7">Section C.3.7: Version 0.91 released November 1996</a><br> +<a href="nasmdocc.html#section-C.3.8">Section C.3.8: Version 0.90 released October 1996</a><br> +<p><a href="nasmdoci.html">Index</a> +</body></html> diff --git a/doc/html/nasmdoc1.html b/doc/html/nasmdoc1.html new file mode 100644 index 0000000..d370895 --- /dev/null +++ b/doc/html/nasmdoc1.html @@ -0,0 +1,159 @@ +<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 and x86-64 assembler designed +for portability and modularity. It supports a range of object file formats, +including Linux and <code><nobr>*BSD</nobr></code> +<code><nobr>a.out</nobr></code>, <code><nobr>ELF</nobr></code>, +<code><nobr>COFF</nobr></code>, <code><nobr>Mach-O</nobr></code>, Microsoft +16-bit <code><nobr>OBJ</nobr></code>, <code><nobr>Win32</nobr></code> and +<code><nobr>Win64</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 all currently known x86 architectural +extensions, and has strong support for macros. +<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 to 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 specific to Minix and Linux, 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 License Conditions</a></h4> +<p>Please see the file <code><nobr>LICENSE</nobr></code>, supplied as part +of any NASM distribution archive, for the license conditions under which +you may use NASM. NASM is now under the so-called 2-clause BSD license, +also known as the simplified BSD license. +<p>Copyright 1996-2009 the NASM Authors - All rights reserved. +<p>Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are met: +<ul> +<li>Redistributions of source code must retain the above copyright notice, +this list of conditions and the following disclaimer. +<li>Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. +</ul> +<p>THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS +IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, +THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR +CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, +EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, +PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; +OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, +WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR +OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF +ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +<h3><a name="section-1.2">1.2 Contact Information</a></h3> +<p>The current version of NASM (since about 0.98.08) is 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="nasmdo12.html#section-12.2">section 12.2</a> first. +<p>NASM has a website at +<a href="http://www.nasm.us/"><code><nobr>http://www.nasm.us/</nobr></code></a>. +If it's not there, google for us! +<p>New releases, release candidates, and daily development snapshots of +NASM are available from the official web site. +<p>Announcements are posted to +<a href="news:comp.lang.asm.x86"><code><nobr>comp.lang.asm.x86</nobr></code></a>, +and to the web site +<a href="http://www.freshmeat.net/"><code><nobr>http://www.freshmeat.net/</nobr></code></a>. +<p>If you want information about the current development status, please +subscribe to the <code><nobr>nasm-devel</nobr></code> email list; see link +from the website. +<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 appropriate archive for NASM, +<code><nobr>nasm-XXX-dos.zip</nobr></code> or +<code><nobr>nasm-XXX-win32.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 a set of executable files: the NASM executable +file <code><nobr>nasm.exe</nobr></code>, the NDISASM executable file +<code><nobr>ndisasm.exe</nobr></code>, and possibly additional utilities to +handle the RDOFF file format. +<p>The only file NASM needs to run is its own executable, so copy +<code><nobr>nasm.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> (to do that under Windows XP, go to Start +> Control Panel > System > Advanced > Environment Variables; +these instructions may work under other versions of Windows as well.) +<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>nasm-XXX.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. See the file <code><nobr>INSTALL</nobr></code> in the source +archive. +<p>Note that a number of files are generated from other files by Perl +scripts. 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-XXX.tar.gz</nobr></code> (where +<code><nobr>XXX</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-XXX</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 align=center><a href="nasmdoc2.html">Next Chapter</a> | +<a href="nasmdoc0.html">Contents</a> | +<a href="nasmdoci.html">Index</a> +</body></html> diff --git a/doc/html/nasmdoc2.html b/doc/html/nasmdoc2.html new file mode 100644 index 0000000..a639a4a --- /dev/null +++ b/doc/html/nasmdoc2.html @@ -0,0 +1,650 @@ +<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>, +<code><nobr>win32</nobr></code> and <code><nobr>win64</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>as86</nobr></code>, +<code><nobr>coff</nobr></code>, <code><nobr>elf32</nobr></code>, +<code><nobr>elf64</nobr></code>, <code><nobr>ieee</nobr></code>, +<code><nobr>macho32</nobr></code> and <code><nobr>macho64</nobr></code>) it +will substitute <code><nobr>.o</nobr></code>. For +<code><nobr>dbg</nobr></code>, <code><nobr>rdf</nobr></code>, +<code><nobr>ith</nobr></code> and <code><nobr>srec</nobr></code>, it will +use <code><nobr>.dbg</nobr></code>, <code><nobr>.rdf</nobr></code>, +<code><nobr>.ith</nobr></code> and <code><nobr>.srec</nobr></code>, +respectively, 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.22">section 2.1.22</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.10">section +4.3.10</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>-MG</nobr></code> Option: Generate Makefile Dependencies</a></h4> +<p>This option can be used to generate makefile dependencies on stdout. +This differs from the <code><nobr>-M</nobr></code> option in that if a +nonexisting file is encountered, it is assumed to be a generated file and +is added to the dependency list without a prefix. +<h4><a name="section-2.1.6">2.1.6 The <code><nobr>-MF</nobr></code> Option: Set Makefile Dependency File</a></h4> +<p>This option can be used with the <code><nobr>-M</nobr></code> or +<code><nobr>-MG</nobr></code> options to send the output to a file, rather +than to stdout. For example: +<p><pre> +nasm -M -MF myfile.dep myfile.asm +</pre> +<h4><a name="section-2.1.7">2.1.7 The <code><nobr>-MD</nobr></code> Option: Assemble and Generate Dependencies</a></h4> +<p>The <code><nobr>-MD</nobr></code> option acts as the combination of the +<code><nobr>-M</nobr></code> and <code><nobr>-MF</nobr></code> options +(i.e. a filename has to be specified.) However, unlike the +<code><nobr>-M</nobr></code> or <code><nobr>-MG</nobr></code> options, +<code><nobr>-MD</nobr></code> does <em>not</em> inhibit the normal +operation of the assembler. Use this to automatically generate updated +dependencies with every assembly session. For example: +<p><pre> +nasm -f elf -o myfile.o -MD myfile.dep myfile.asm +</pre> +<h4><a name="section-2.1.8">2.1.8 The <code><nobr>-MT</nobr></code> Option: Dependency Target Name</a></h4> +<p>The <code><nobr>-MT</nobr></code> option can be used to override the +default name of the dependency target. This is normally the same as the +output filename, specified by the <code><nobr>-o</nobr></code> option. +<h4><a name="section-2.1.9">2.1.9 The <code><nobr>-MQ</nobr></code> Option: Dependency Target Name (Quoted)</a></h4> +<p>The <code><nobr>-MQ</nobr></code> option acts as the +<code><nobr>-MT</nobr></code> option, except it tries to quote characters +that have special meaning in Makefile syntax. This is not foolproof, as not +all characters with special meaning are quotable in Make. +<h4><a name="section-2.1.10">2.1.10 The <code><nobr>-MP</nobr></code> Option: Emit phony targets</a></h4> +<p>When used with any of the dependency generation options, the +<code><nobr>-MP</nobr></code> option causes NASM to emit a phony target +without dependencies for each header file. This prevents Make from +complaining if a header file has been removed. +<h4><a name="section-2.1.11">2.1.11 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). Prior to version 2.03.01, the use of this switch did <em>not</em> +enable output of the selected debug info format. Use +<code><nobr>-g</nobr></code>, see <a href="#section-2.1.12">section +2.1.12</a>, to enable output. Versions 2.03.01 and later automatically +enable <code><nobr>-g</nobr></code> if <code><nobr>-F</nobr></code> is +specified. +<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>. Not all output formats +currently support debugging output. See <a href="#section-2.1.26">section +2.1.26</a>. +<p>This should not be confused with the <code><nobr>-f dbg</nobr></code> +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="nasmdoc7.html#section-7.14">section 7.14</a>. +<h4><a name="section-2.1.12">2.1.12 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.11">section 2.1.11</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.13">2.1.13 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="nasmdoc7.html#section-7.5">section 7.5</a>. +<h4><a name="section-2.1.14">2.1.14 The <code><nobr>-Z</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>-Z</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 -Z myfile.err -f obj myfile.asm +</pre> +<p>In earlier versions of NASM, this option was called +<code><nobr>-E</nobr></code>, but it was changed since +<code><nobr>-E</nobr></code> is an option conventionally used for +preprocessing only, with disastrous results. See +<a href="#section-2.1.20">section 2.1.20</a>. +<h4><a name="section-2.1.15">2.1.15 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>-Z</nobr></code> option, +<a href="#section-2.1.14">section 2.1.14</a>. +<h4><a name="section-2.1.16">2.1.16 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>%pathsearch</nobr></code> directive in a source file (see +<a href="nasmdoc4.html#section-4.6.1">section 4.6.1</a>, +<a href="nasmdoc4.html#section-4.6.2">section 4.6.2</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.28">section 2.1.28</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.17">2.1.17 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.18">2.1.18 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.19">2.1.19 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.20">2.1.20 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. +<p>For compatiblity with older version of NASM, this option can also be +written <code><nobr>-e</nobr></code>. <code><nobr>-E</nobr></code> in older +versions of NASM was the equivalent of the current +<code><nobr>-Z</nobr></code> option, <a href="#section-2.1.14">section +2.1.14</a>. +<h4><a name="section-2.1.21">2.1.21 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.22">2.1.22 The <code><nobr>-O</nobr></code> Option: Specifying Multipass Optimization</a></h4> +<p>NASM defaults to not optimizing operands which can fit into a signed +byte. This means that if you want the shortest possible object code, you +have to enable optimization. +<p>Using the <code><nobr>-O</nobr></code> option, you can tell NASM to +carry out different levels of optimization. The syntax is: +<ul> +<li><code><nobr>-O0</nobr></code>: No optimization. All operands take their +long forms, if a short form is not specified, except conditional jumps. +This is intended to match NASM 0.98 behavior. +<li><code><nobr>-O1</nobr></code>: Minimal optimization. As above, but +immediate operands which will fit in a signed byte are optimized, unless +the long form is specified. Conditional jumps default to the long form +unless otherwise specified. +<li><code><nobr>-Ox</nobr></code> (where <code><nobr>x</nobr></code> is the +actual letter <code><nobr>x</nobr></code>): Multipass optimization. +Minimize branch offsets and 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>). For +compatability with earlier releases, the letter <code><nobr>x</nobr></code> +may also be any number greater than one. This number has no effect on the +actual number of passes. +</ul> +<p>The <code><nobr>-Ox</nobr></code> mode is recommended for most uses. +<p>Note that this is a capital <code><nobr>O</nobr></code>, and is +different from a small <code><nobr>o</nobr></code>, which is used to +specify the output file name. See <a href="#section-2.1.1">section +2.1.1</a>. +<h4><a name="section-2.1.23">2.1.23 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>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>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>) +</ul> +<h4><a name="section-2.1.24">2.1.24 The <code><nobr>-w</nobr></code> and <code><nobr>-W</nobr></code> Options: 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.2">section 4.3.2</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 disabled by default. +<li><code><nobr>macro-defaults</nobr></code> warns when a macro has more +default parameters than optional parameters. This warning class is enabled +by default; see <a href="nasmdoc4.html#section-4.3.5">section 4.3.5</a> for +why you might want to disable it. +<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 warns about this somewhat obscure condition by default; see +<a href="nasmdoc3.html#section-3.1">section 3.1</a> for more information. +<li><code><nobr>number-overflow</nobr></code> covers warnings about numeric +constants which don't fit in 64 bits. 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 disabled by default. +<li><code><nobr>float-overflow</nobr></code> warns about floating point +overflow. Enabled by default. +<li><code><nobr>float-denorm</nobr></code> warns about floating point +denormals. Disabled by default. +<li><code><nobr>float-underflow</nobr></code> warns about floating point +underflow. Disabled by default. +<li><code><nobr>float-toolong</nobr></code> warns about too many digits in +floating-point numbers. Enabled by default. +<li><code><nobr>user</nobr></code> controls +<code><nobr>%warning</nobr></code> directives (see +<a href="nasmdoc4.html#section-4.9">section 4.9</a>). Enabled by default. +<li><code><nobr>error</nobr></code> causes warnings to be treated as +errors. Disabled by default. +<li><code><nobr>all</nobr></code> is an alias for <em>all</em> suppressible +warning classes (not including <code><nobr>error</nobr></code>). Thus, +<code><nobr>-w+all</nobr></code> enables all available warnings. +</ul> +<p>In addition, you can set warning classes across sections. Warning +classes may be enabled with +<code><nobr>[warning +warning-name]</nobr></code>, disabled with +<code><nobr>[warning -warning-name]</nobr></code> or reset to their +original value with <code><nobr>[warning *warning-name]</nobr></code>. No +"user form" (without the brackets) exists. +<p>Since version 2.00, NASM has also supported the gcc-like syntax +<code><nobr>-Wwarning</nobr></code> and +<code><nobr>-Wno-warning</nobr></code> instead of +<code><nobr>-w+warning</nobr></code> and +<code><nobr>-w-warning</nobr></code>, respectively. +<h4><a name="section-2.1.25">2.1.25 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. +<p>You will need the version number if you report a bug. +<h4><a name="section-2.1.26">2.1.26 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. For example: +<p><pre> +nasm -f elf -y +</pre> +<p><pre> +valid debug formats for 'elf32' output format are + ('*' denotes default): + * stabs ELF32 (i386) stabs debug format for Linux + dwarf elf32 (i386) dwarf debug format for Linux +</pre> +<h4><a name="section-2.1.27">2.1.27 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.28">2.1.28 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="nasmdoc7.html#section-7.4">section 7.4</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 uninitialized 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="nasmdoc6.html">chapter 6</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> diff --git a/doc/html/nasmdoc3.html b/doc/html/nasmdoc3.html new file mode 100644 index 0000000..b70e438 --- /dev/null +++ b/doc/html/nasmdoc3.html @@ -0,0 +1,753 @@ +<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="nasmdoc6.html">chapter +6</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. Maximum length of an identifier is 4095 +characters. +<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>A64</nobr></code>, <code><nobr>O16</nobr></code> and +<code><nobr>O32</nobr></code>, <code><nobr>O64</nobr></code> are provided - +one example of their use is given in <a href="nasmdo10.html">chapter +10</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 x87 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. 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 x87 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>, +<code><nobr>DT</nobr></code>, <code><nobr>DO</nobr></code> and +<code><nobr>DY</nobr></code>; their uninitialized counterparts +<code><nobr>RESB</nobr></code>, <code><nobr>RESW</nobr></code>, +<code><nobr>RESD</nobr></code>, <code><nobr>RESQ</nobr></code>, +<code><nobr>REST</nobr></code>, <code><nobr>RESO</nobr></code> and +<code><nobr>RESY</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 Initialized Data</a></h4> +<p><code><nobr>DB</nobr></code>, <code><nobr>DW</nobr></code>, +<code><nobr>DD</nobr></code>, <code><nobr>DQ</nobr></code>, +<code><nobr>DT</nobr></code>, <code><nobr>DO</nobr></code> and +<code><nobr>DY</nobr></code> are used, much as in MASM, to declare +initialized 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 0x123456789abcdef0 ; eight byte constant + dq 1.234567e20 ; double-precision float + dt 1.234567e20 ; extended-precision float +</pre> +<p><code><nobr>DT</nobr></code>, <code><nobr>DO</nobr></code> and +<code><nobr>DY</nobr></code> do not accept numeric constants as operands. +<h4><a name="section-3.2.2">3.2.2 <code><nobr>RESB</nobr></code> and Friends: Declaring Uninitialized Data</a></h4> +<p><code><nobr>RESB</nobr></code>, <code><nobr>RESW</nobr></code>, +<code><nobr>RESD</nobr></code>, <code><nobr>RESQ</nobr></code>, +<code><nobr>REST</nobr></code>, <code><nobr>RESO</nobr></code> and +<code><nobr>RESY</nobr></code> are designed to be used in the BSS section +of a module: they declare <em>uninitialized</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 uninitialized 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 +ymmval: resy 1 ; one YMM register +</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> +<p><code><nobr>INCBIN</nobr></code> is both a directive and a standard +macro; the standard macro version searches for the file in the include file +search path and adds the file to the dependency lists. This macro can be +overridden if desired. +<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. +<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> 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="nasmdo10.html#section-10.2">section 10.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. +<p>In 64-bit mode, NASM will by default generate absolute addresses. The +<code><nobr>REL</nobr></code> keyword makes it produce +<code><nobr>RIP</nobr></code>-relative addresses. Since this is frequently +the normally desired behaviour, see the <code><nobr>DEFAULT</nobr></code> +directive (<a href="nasmdoc6.html#section-6.2">section 6.2</a>). The +keyword <code><nobr>ABS</nobr></code> overrides +<code><nobr>REL</nobr></code>. +<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> or <code><nobr>X</nobr></code>, +<code><nobr>Q</nobr></code> or <code><nobr>O</nobr></code>, and +<code><nobr>B</nobr></code> for hexadecimal, octal and binary respectively, +or you can prefix <code><nobr>0x</nobr></code> for hexadecimal in the style +of C, or you can prefix <code><nobr>$</nobr></code> for hexadecimal 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. In addition, current +versions of NASM accept the prefix <code><nobr>0h</nobr></code> for +hexadecimal, <code><nobr>0o</nobr></code> or <code><nobr>0q</nobr></code> +for octal, and <code><nobr>0b</nobr></code> for binary. Please note that +unlike C, a <code><nobr>0</nobr></code> prefix by itself does <em>not</em> +imply an octal constant! +<p>Numeric constants can have underscores (<code><nobr>_</nobr></code>) +interspersed to break up long strings. +<p>Some examples (all producing exactly the same code): +<p><pre> + mov ax,200 ; decimal + mov ax,0200 ; still decimal + mov ax,0200d ; explicitly decimal + mov ax,0d200 ; also decimal + mov ax,0c8h ; hex + mov ax,$0c8 ; hex again: the 0 is required + mov ax,0xc8 ; hex yet again + mov ax,0hc8 ; still hex + mov ax,310q ; octal + mov ax,310o ; octal again + mov ax,0o310 ; octal yet again + mov ax,0q310 ; hex yet again + mov ax,11001000b ; binary + mov ax,1100_1000b ; same binary constant + mov ax,0b1100_1000 ; same binary constant yet again +</pre> +<h4><a name="section-3.4.2">3.4.2 Character Strings</a></h4> +<p>A character string consists of up to eight characters enclosed in either +single quotes (<code><nobr>'...'</nobr></code>), double quotes +(<code><nobr>"..."</nobr></code>) or backquotes +(<code><nobr>`...`</nobr></code>). Single or double quotes are equivalent +to NASM (except of course that surrounding the constant with single quotes +allows double quotes to appear within it and vice versa); the contents of +those are represented verbatim. Strings enclosed in backquotes support +C-style <code><nobr>\</nobr></code>-escapes for special characters. +<p>The following escape sequences are recognized by backquoted strings: +<p><pre> + \' single quote (') + \" double quote (") + \` backquote (`) + \\ backslash (\) + \? question mark (?) + \a BEL (ASCII 7) + \b BS (ASCII 8) + \t TAB (ASCII 9) + \n LF (ASCII 10) + \v VT (ASCII 11) + \f FF (ASCII 12) + \r CR (ASCII 13) + \e ESC (ASCII 27) + \377 Up to 3 octal digits - literal byte + \xFF Up to 2 hexadecimal digits - literal byte + \u1234 4 hexadecimal digits - Unicode character + \U12345678 8 hexadecimal digits - Unicode character +</pre> +<p>All other escape sequences are reserved. Note that +<code><nobr>\0</nobr></code>, meaning a <code><nobr>NUL</nobr></code> +character (ASCII 0), is a special case of the octal escape sequence. +<p>Unicode characters specified with <code><nobr>\u</nobr></code> or +<code><nobr>\U</nobr></code> are converted to UTF-8. For example, the +following lines are all equivalent: +<p><pre> + db `\u263a` ; UTF-8 smiley face + db `\xe2\x98\xba` ; UTF-8 smiley face + db 0E2h, 098h, 0BAh ; UTF-8 smiley face +</pre> +<h4><a name="section-3.4.3">3.4.3 Character Constants</a></h4> +<p>A character constant consists of a string up to eight bytes long, used +in an expression context. It is treated as if it was an integer. +<p>A character constant with more than one byte 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. +<h4><a name="section-3.4.4">3.4.4 String Constants</a></h4> +<p>String constants are character strings used in the context of some +pseudo-instructions, namely the <code><nobr>DB</nobr></code> family and +<code><nobr>INCBIN</nobr></code> (where it represents a filename.) They are +also used in certain preprocessor directives. +<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 in a string-supporting context, quoted strings are +treated as a string constants even if they are 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>, +and so forth. +<h4><a name="section-3.4.5">3.4.5 Unicode Strings</a></h4> +<p>The special operators <code><nobr>__utf16__</nobr></code> and +<code><nobr>__utf32__</nobr></code> allows definition of Unicode strings. +They take a string in UTF-8 format and converts it to (littleendian) UTF-16 +or UTF-32, respectively. +<p>For example: +<p><pre> +%define u(x) __utf16__(x) +%define w(x) __utf32__(x) + + dw u('C:\WINDOWS'), 0 ; Pathname in UTF-16 + dd w(`A + B = \u206a`), 0 ; String in UTF-32 +</pre> +<p><code><nobr>__utf16__</nobr></code> and +<code><nobr>__utf32__</nobr></code> can be applied either to strings passed +to the <code><nobr>DB</nobr></code> family instructions, or to character +constants in an expression context. +<h4><a name="section-3.4.6">3.4.6 Floating-Point Constants</a></h4> +<p>Floating-point constants are acceptable only as arguments to +<code><nobr>DB</nobr></code>, <code><nobr>DW</nobr></code>, +<code><nobr>DD</nobr></code>, <code><nobr>DQ</nobr></code>, +<code><nobr>DT</nobr></code>, and <code><nobr>DO</nobr></code>, or as +arguments to the special operators <code><nobr>__float8__</nobr></code>, +<code><nobr>__float16__</nobr></code>, +<code><nobr>__float32__</nobr></code>, +<code><nobr>__float64__</nobr></code>, +<code><nobr>__float80m__</nobr></code>, +<code><nobr>__float80e__</nobr></code>, +<code><nobr>__float128l__</nobr></code>, and +<code><nobr>__float128h__</nobr></code>. +<p>Floating-point constants 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. +NASM also support C99-style hexadecimal floating-point: +<code><nobr>0x</nobr></code>, hexadecimal digits, period, optionally more +hexadeximal digits, then optionally a <code><nobr>P</nobr></code> followed +by a <em>binary</em> (not hexadecimal) exponent in decimal notation. +<p>Underscores to break up groups of digits are permitted in floating-point +constants as well. +<p>Some examples: +<p><pre> + db -0.2 ; "Quarter precision" + dw -0.5 ; IEEE 754r/SSE5 half precision + dd 1.2 ; an easy one + dd 1.222_222_222 ; underscores are permitted + dd 0x1p+2 ; 1.0x2^2 = 4.0 + dq 0x1p+32 ; 1.0x2^32 = 4 294 967 296.0 + dq 1.e10 ; 10 000 000 000.0 + dq 1.e+10 ; synonymous with 1.e10 + dq 1.e-10 ; 0.000 000 000 1 + dt 3.141592653589793238462 ; pi + do 1.e+4000 ; IEEE 754r quad precision +</pre> +<p>The 8-bit "quarter-precision" floating-point format is +sign:exponent:mantissa = 1:4:3 with an exponent bias of 7. This appears to +be the most frequently used 8-bit floating-point format, although it is not +covered by any formal standard. This is sometimes called a "minifloat." +<p>The special operators are used to produce floating-point numbers in +other contexts. They produce the binary representation of a specific +floating-point number as an integer, and can use anywhere integer constants +are used in an expression. <code><nobr>__float80m__</nobr></code> and +<code><nobr>__float80e__</nobr></code> produce the 64-bit mantissa and +16-bit exponent of an 80-bit floating-point number, and +<code><nobr>__float128l__</nobr></code> and +<code><nobr>__float128h__</nobr></code> produce the lower and upper 64-bit +halves of a 128-bit floating-point number, respectively. +<p>For example: +<p><pre> + mov rax,__float64__(3.141592653589793238462) +</pre> +<p>... would assign the binary representation of pi as a 64-bit floating +point number into <code><nobr>RAX</nobr></code>. This is exactly equivalent +to: +<p><pre> + mov rax,0x400921fb54442d18 +</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. +<p>The special tokens <code><nobr>__Infinity__</nobr></code>, +<code><nobr>__QNaN__</nobr></code> (or <code><nobr>__NaN__</nobr></code>) +and <code><nobr>__SNaN__</nobr></code> can be used to generate infinities, +quiet NaNs, and signalling NaNs, respectively. These are normally used as +macros: +<p><pre> +%define Inf __Infinity__ +%define NaN __QNaN__ + + dq +1.5, -Inf, NaN ; Double-precision constants +</pre> +<h4><a name="section-3.4.7">3.4.7 Packed BCD Constants</a></h4> +<p>x87-style packed BCD constants can be used in the same contexts as +80-bit floating-point numbers. They are suffixed with +<code><nobr>p</nobr></code> or prefixed with <code><nobr>0p</nobr></code>, +and can include up to 18 decimal digits. +<p>As with other numeric constants, underscores can be used to separate +digits. +<p>For example: +<p><pre> + dt 12_345_678_901_245_678p + dt -12_345_678_901_245_678p + dt +0p33 + dt 33p +</pre> +<h3><a name="section-3.5">3.5 Expressions</a></h3> +<p>Expressions in NASM are similar in syntax to those in C. Expressions are +evaluated as 64-bit integers which are then adjusted to the appropriate +size. +<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>, <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, <code><nobr>!</nobr></code> +is the logical negation operator, 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.22">section 2.1.22</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>, <code><nobr>TWORD</nobr></code>, +<code><nobr>OWORD</nobr></code> or <code><nobr>YWORD</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>Although NASM has an optional multi-pass optimizer, there are some +expressions which must be resolvable on the first pass. These are called +<em>Critical Expressions</em>. +<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. +<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="nasmdoc7.html#section-7.4.6">section 7.4.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> diff --git a/doc/html/nasmdoc4.html b/doc/html/nasmdoc4.html new file mode 100644 index 0000000..8c71881 --- /dev/null +++ b/doc/html/nasmdoc4.html @@ -0,0 +1,1970 @@ +<html><head><title>NASM Manual</title></head> +<body><h1 align=center>The Netwide Assembler: NASM</h1> + +<p align=center><a href="nasmdoc5.html">Next Chapter</a> | +<a href="nasmdoc3.html">Previous Chapter</a> | +<a href="nasmdoc0.html">Contents</a> | +<a href="nasmdoci.html">Index</a> +<h2><a name="chapter-4">Chapter 4: The NASM Preprocessor</a></h2> +<p>NASM contains a powerful macro processor, which supports conditional +assembly, multi-level file inclusion, two forms of macro (single-line and +multi-line), and a `context stack' mechanism for extra macro power. +Preprocessor directives all begin with a <code><nobr>%</nobr></code> sign. +<p>The preprocessor collapses all lines which end with a backslash (\) +character into a single line. Thus: +<p><pre> +%define THIS_VERY_LONG_MACRO_NAME_IS_DEFINED_TO \ + THIS_VALUE +</pre> +<p>will work like a single-line macro without the backslash-newline +sequence. +<h3><a name="section-4.1">4.1 Single-Line Macros</a></h3> +<h4><a name="section-4.1.1">4.1.1 The Normal Way: <code><nobr>%define</nobr></code></a></h4> +<p>Single-line macros are defined using the +<code><nobr>%define</nobr></code> preprocessor directive. The definitions +work in a similar way to C; so you can do things like +<p><pre> +%define ctrl 0x1F & +%define param(a,b) ((a)+(a)*(b)) + + mov byte [param(2,ebx)], ctrl 'D' +</pre> +<p>which will expand to +<p><pre> + mov byte [(2)+(2)*(ebx)], 0x1F & 'D' +</pre> +<p>When the expansion of a single-line macro contains tokens which invoke +another macro, the expansion is performed at invocation time, not at +definition time. Thus the code +<p><pre> +%define a(x) 1+b(x) +%define b(x) 2*x + + mov ax,a(8) +</pre> +<p>will evaluate in the expected way to +<code><nobr>mov ax,1+2*8</nobr></code>, even though the macro +<code><nobr>b</nobr></code> wasn't defined at the time of definition of +<code><nobr>a</nobr></code>. +<p>Macros defined with <code><nobr>%define</nobr></code> are case +sensitive: after <code><nobr>%define foo bar</nobr></code>, only +<code><nobr>foo</nobr></code> will expand to <code><nobr>bar</nobr></code>: +<code><nobr>Foo</nobr></code> or <code><nobr>FOO</nobr></code> will not. By +using <code><nobr>%idefine</nobr></code> instead of +<code><nobr>%define</nobr></code> (the `i' stands for `insensitive') you +can define all the case variants of a macro at once, so that +<code><nobr>%idefine foo bar</nobr></code> would cause +<code><nobr>foo</nobr></code>, <code><nobr>Foo</nobr></code>, +<code><nobr>FOO</nobr></code>, <code><nobr>fOO</nobr></code> and so on all +to expand to <code><nobr>bar</nobr></code>. +<p>There is a mechanism which detects when a macro call has occurred as a +result of a previous expansion of the same macro, to guard against circular +references and infinite loops. If this happens, the preprocessor will only +expand the first occurrence of the macro. Hence, if you code +<p><pre> +%define a(x) 1+a(x) + + mov ax,a(3) +</pre> +<p>the macro <code><nobr>a(3)</nobr></code> will expand once, becoming +<code><nobr>1+a(3)</nobr></code>, and will then expand no further. This +behaviour can be useful: see <a href="nasmdoc9.html#section-9.1">section +9.1</a> for an example of its use. +<p>You can overload single-line macros: if you write +<p><pre> +%define foo(x) 1+x +%define foo(x,y) 1+x*y +</pre> +<p>the preprocessor will be able to handle both types of macro call, by +counting the parameters you pass; so <code><nobr>foo(3)</nobr></code> will +become <code><nobr>1+3</nobr></code> whereas +<code><nobr>foo(ebx,2)</nobr></code> will become +<code><nobr>1+ebx*2</nobr></code>. However, if you define +<p><pre> +%define foo bar +</pre> +<p>then no other definition of <code><nobr>foo</nobr></code> will be +accepted: a macro with no parameters prohibits the definition of the same +name as a macro <em>with</em> parameters, and vice versa. +<p>This doesn't prevent single-line macros being <em>redefined</em>: you +can perfectly well define a macro with +<p><pre> +%define foo bar +</pre> +<p>and then re-define it later in the same source file with +<p><pre> +%define foo baz +</pre> +<p>Then everywhere the macro <code><nobr>foo</nobr></code> is invoked, it +will be expanded according to the most recent definition. This is +particularly useful when defining single-line macros with +<code><nobr>%assign</nobr></code> (see <a href="#section-4.1.7">section +4.1.7</a>). +<p>You can pre-define single-line macros using the `-d' option on the NASM +command line: see <a href="nasmdoc2.html#section-2.1.18">section +2.1.18</a>. +<h4><a name="section-4.1.2">4.1.2 Resolving <code><nobr>%define</nobr></code>: <code><nobr>%xdefine</nobr></code></a></h4> +<p>To have a reference to an embedded single-line macro resolved at the +time that the embedding macro is <em>defined</em>, as opposed to when the +embedding macro is <em>expanded</em>, you need a different mechanism to the +one offered by <code><nobr>%define</nobr></code>. The solution is to use +<code><nobr>%xdefine</nobr></code>, or it's case-insensitive counterpart +<code><nobr>%ixdefine</nobr></code>. +<p>Suppose you have the following code: +<p><pre> +%define isTrue 1 +%define isFalse isTrue +%define isTrue 0 + +val1: db isFalse + +%define isTrue 1 + +val2: db isFalse +</pre> +<p>In this case, <code><nobr>val1</nobr></code> is equal to 0, and +<code><nobr>val2</nobr></code> is equal to 1. This is because, when a +single-line macro is defined using <code><nobr>%define</nobr></code>, it is +expanded only when it is called. As <code><nobr>isFalse</nobr></code> +expands to <code><nobr>isTrue</nobr></code>, the expansion will be the +current value of <code><nobr>isTrue</nobr></code>. The first time it is +called that is 0, and the second time it is 1. +<p>If you wanted <code><nobr>isFalse</nobr></code> to expand to the value +assigned to the embedded macro <code><nobr>isTrue</nobr></code> at the time +that <code><nobr>isFalse</nobr></code> was defined, you need to change the +above code to use <code><nobr>%xdefine</nobr></code>. +<p><pre> +%xdefine isTrue 1 +%xdefine isFalse isTrue +%xdefine isTrue 0 + +val1: db isFalse + +%xdefine isTrue 1 + +val2: db isFalse +</pre> +<p>Now, each time that <code><nobr>isFalse</nobr></code> is called, it +expands to 1, as that is what the embedded macro +<code><nobr>isTrue</nobr></code> expanded to at the time that +<code><nobr>isFalse</nobr></code> was defined. +<h4><a name="section-4.1.3">4.1.3 Macro Indirection: <code><nobr>%[...]</nobr></code></a></h4> +<p>The <code><nobr>%[...]</nobr></code> construct can be used to expand +macros in contexts where macro expansion would otherwise not occur, +including in the names other macros. For example, if you have a set of +macros named <code><nobr>Foo16</nobr></code>, +<code><nobr>Foo32</nobr></code> and <code><nobr>Foo64</nobr></code>, you +could write: +<p><pre> + mov ax,Foo%[__BITS__] ; The Foo value +</pre> +<p>to use the builtin macro <code><nobr>__BITS__</nobr></code> (see +<a href="#section-4.11.5">section 4.11.5</a>) to automatically select +between them. Similarly, the two statements: +<p><pre> +%xdefine Bar Quux ; Expands due to %xdefine +%define Bar %[Quux] ; Expands due to %[...] +</pre> +<p>have, in fact, exactly the same effect. +<p><code><nobr>%[...]</nobr></code> concatenates to adjacent tokens in the +same way that multi-line macro parameters do, see +<a href="#section-4.3.8">section 4.3.8</a> for details. +<h4><a name="section-4.1.4">4.1.4 Concatenating Single Line Macro Tokens: <code><nobr>%+</nobr></code></a></h4> +<p>Individual tokens in single line macros can be concatenated, to produce +longer tokens for later processing. This can be useful if there are several +similar macros that perform similar functions. +<p>Please note that a space is required after <code><nobr>%+</nobr></code>, +in order to disambiguate it from the syntax <code><nobr>%+1</nobr></code> +used in multiline macros. +<p>As an example, consider the following: +<p><pre> +%define BDASTART 400h ; Start of BIOS data area +</pre> +<p><pre> +struc tBIOSDA ; its structure + .COM1addr RESW 1 + .COM2addr RESW 1 + ; ..and so on +endstruc +</pre> +<p>Now, if we need to access the elements of tBIOSDA in different places, +we can end up with: +<p><pre> + mov ax,BDASTART + tBIOSDA.COM1addr + mov bx,BDASTART + tBIOSDA.COM2addr +</pre> +<p>This will become pretty ugly (and tedious) if used in many places, and +can be reduced in size significantly by using the following macro: +<p><pre> +; Macro to access BIOS variables by their names (from tBDA): +</pre> +<p><pre> +%define BDA(x) BDASTART + tBIOSDA. %+ x +</pre> +<p>Now the above code can be written as: +<p><pre> + mov ax,BDA(COM1addr) + mov bx,BDA(COM2addr) +</pre> +<p>Using this feature, we can simplify references to a lot of macros (and, +in turn, reduce typing errors). +<h4><a name="section-4.1.5">4.1.5 The Macro Name Itself: <code><nobr>%?</nobr></code> and <code><nobr>%??</nobr></code></a></h4> +<p>The special symbols <code><nobr>%?</nobr></code> and +<code><nobr>%??</nobr></code> can be used to reference the macro name +itself inside a macro expansion, this is supported for both single-and +multi-line macros. <code><nobr>%?</nobr></code> refers to the macro name as +<em>invoked</em>, whereas <code><nobr>%??</nobr></code> refers to the macro +name as <em>declared</em>. The two are always the same for case-sensitive +macros, but for case-insensitive macros, they can differ. +<p>For example: +<p><pre> +%idefine Foo mov %?,%?? + + foo + FOO +</pre> +<p>will expand to: +<p><pre> + mov foo,Foo + mov FOO,Foo +</pre> +<p>The sequence: +<p><pre> +%idefine keyword $%? +</pre> +<p>can be used to make a keyword "disappear", for example in case a new +instruction has been used as a label in older code. For example: +<p><pre> +%idefine pause $%? ; Hide the PAUSE instruction +</pre> +<h4><a name="section-4.1.6">4.1.6 Undefining Single-Line Macros: <code><nobr>%undef</nobr></code></a></h4> +<p>Single-line macros can be removed with the +<code><nobr>%undef</nobr></code> directive. For example, the following +sequence: +<p><pre> +%define foo bar +%undef foo + + mov eax, foo +</pre> +<p>will expand to the instruction <code><nobr>mov eax, foo</nobr></code>, +since after <code><nobr>%undef</nobr></code> the macro +<code><nobr>foo</nobr></code> is no longer defined. +<p>Macros that would otherwise be pre-defined can be undefined on the +command-line using the `-u' option on the NASM command line: see +<a href="nasmdoc2.html#section-2.1.19">section 2.1.19</a>. +<h4><a name="section-4.1.7">4.1.7 Preprocessor Variables: <code><nobr>%assign</nobr></code></a></h4> +<p>An alternative way to define single-line macros is by means of the +<code><nobr>%assign</nobr></code> command (and its case-insensitive +counterpart <code><nobr>%iassign</nobr></code>, which differs from +<code><nobr>%assign</nobr></code> in exactly the same way that +<code><nobr>%idefine</nobr></code> differs from +<code><nobr>%define</nobr></code>). +<p><code><nobr>%assign</nobr></code> is used to define single-line macros +which take no parameters and have a numeric value. This value can be +specified in the form of an expression, and it will be evaluated once, when +the <code><nobr>%assign</nobr></code> directive is processed. +<p>Like <code><nobr>%define</nobr></code>, macros defined using +<code><nobr>%assign</nobr></code> can be re-defined later, so you can do +things like +<p><pre> +%assign i i+1 +</pre> +<p>to increment the numeric value of a macro. +<p><code><nobr>%assign</nobr></code> is useful for controlling the +termination of <code><nobr>%rep</nobr></code> preprocessor loops: see +<a href="#section-4.5">section 4.5</a> for an example of this. Another use +for <code><nobr>%assign</nobr></code> is given in +<a href="nasmdoc8.html#section-8.4">section 8.4</a> and +<a href="nasmdoc9.html#section-9.1">section 9.1</a>. +<p>The expression passed to <code><nobr>%assign</nobr></code> is a critical +expression (see <a href="nasmdoc3.html#section-3.8">section 3.8</a>), and +must also evaluate to a pure number (rather than a relocatable reference +such as a code or data address, or anything involving a register). +<h4><a name="section-4.1.8">4.1.8 Defining Strings: <code><nobr>%defstr</nobr></code></a></h4> +<p><code><nobr>%defstr</nobr></code>, and its case-insensitive counterpart +<code><nobr>%idefstr</nobr></code>, define or redefine a single-line macro +without parameters but converts the entire right-hand side, after macro +expansion, to a quoted string before definition. +<p>For example: +<p><pre> +%defstr test TEST +</pre> +<p>is equivalent to +<p><pre> +%define test 'TEST' +</pre> +<p>This can be used, for example, with the <code><nobr>%!</nobr></code> +construct (see <a href="#section-4.10.2">section 4.10.2</a>): +<p><pre> +%defstr PATH %!PATH ; The operating system PATH variable +</pre> +<h4><a name="section-4.1.9">4.1.9 Defining Tokens: <code><nobr>%deftok</nobr></code></a></h4> +<p><code><nobr>%deftok</nobr></code>, and its case-insensitive counterpart +<code><nobr>%ideftok</nobr></code>, define or redefine a single-line macro +without parameters but converts the second parameter, after string +conversion, to a sequence of tokens. +<p>For example: +<p><pre> +%deftok test 'TEST' +</pre> +<p>is equivalent to +<p><pre> +%define test TEST +</pre> +<h3><a name="section-4.2">4.2 String Manipulation in Macros</a></h3> +<p>It's often useful to be able to handle strings in macros. NASM supports +a few simple string handling macro operators from which more complex +operations can be constructed. +<p>All the string operators define or redefine a value (either a string or +a numeric value) to a single-line macro. When producing a string value, it +may change the style of quoting of the input string or strings, and +possibly use <code><nobr>\</nobr></code>-escapes inside +<code><nobr>`</nobr></code>-quoted strings. +<h4><a name="section-4.2.1">4.2.1 Concatenating Strings: <code><nobr>%strcat</nobr></code></a></h4> +<p>The <code><nobr>%strcat</nobr></code> operator concatenates quoted +strings and assign them to a single-line macro. +<p>For example: +<p><pre> +%strcat alpha "Alpha: ", '12" screen' +</pre> +<p>... would assign the value <code><nobr>'Alpha: 12" screen'</nobr></code> +to <code><nobr>alpha</nobr></code>. Similarly: +<p><pre> +%strcat beta '"foo"\', "'bar'" +</pre> +<p>... would assign the value <code><nobr>`"foo"\\'bar'`</nobr></code> to +<code><nobr>beta</nobr></code>. +<p>The use of commas to separate strings is permitted but optional. +<h4><a name="section-4.2.2">4.2.2 String Length: <code><nobr>%strlen</nobr></code></a></h4> +<p>The <code><nobr>%strlen</nobr></code> operator assigns the length of a +string to a macro. For example: +<p><pre> +%strlen charcnt 'my string' +</pre> +<p>In this example, <code><nobr>charcnt</nobr></code> would receive the +value 9, just as if an <code><nobr>%assign</nobr></code> had been used. In +this example, <code><nobr>'my string'</nobr></code> was a literal string +but it could also have been a single-line macro that expands to a string, +as in the following example: +<p><pre> +%define sometext 'my string' +%strlen charcnt sometext +</pre> +<p>As in the first case, this would result in +<code><nobr>charcnt</nobr></code> being assigned the value of 9. +<h4><a name="section-4.2.3">4.2.3 Extracting Substrings: <code><nobr>%substr</nobr></code></a></h4> +<p>Individual letters or substrings in strings can be extracted using the +<code><nobr>%substr</nobr></code> operator. An example of its use is +probably more useful than the description: +<p><pre> +%substr mychar 'xyzw' 1 ; equivalent to %define mychar 'x' +%substr mychar 'xyzw' 2 ; equivalent to %define mychar 'y' +%substr mychar 'xyzw' 3 ; equivalent to %define mychar 'z' +%substr mychar 'xyzw' 2,2 ; equivalent to %define mychar 'yz' +%substr mychar 'xyzw' 2,-1 ; equivalent to %define mychar 'yzw' +%substr mychar 'xyzw' 2,-2 ; equivalent to %define mychar 'yz' +</pre> +<p>As with <code><nobr>%strlen</nobr></code> (see +<a href="#section-4.2.2">section 4.2.2</a>), the first parameter is the +single-line macro to be created and the second is the string. The third +parameter specifies the first character to be selected, and the optional +fourth parameter preceeded by comma) is the length. Note that the first +index is 1, not 0 and the last index is equal to the value that +<code><nobr>%strlen</nobr></code> would assign given the same string. Index +values out of range result in an empty string. A negative length means +"until N-1 characters before the end of string", i.e. +<code><nobr>-1</nobr></code> means until end of string, +<code><nobr>-2</nobr></code> until one character before, etc. +<h3><a name="section-4.3">4.3 Multi-Line Macros: <code><nobr>%macro</nobr></code></a></h3> +<p>Multi-line macros are much more like the type of macro seen in MASM and +TASM: a multi-line macro definition in NASM looks something like this. +<p><pre> +%macro prologue 1 + + push ebp + mov ebp,esp + sub esp,%1 + +%endmacro +</pre> +<p>This defines a C-like function prologue as a macro: so you would invoke +the macro with a call such as +<p><pre> +myfunc: prologue 12 +</pre> +<p>which would expand to the three lines of code +<p><pre> +myfunc: push ebp + mov ebp,esp + sub esp,12 +</pre> +<p>The number <code><nobr>1</nobr></code> after the macro name in the +<code><nobr>%macro</nobr></code> line defines the number of parameters the +macro <code><nobr>prologue</nobr></code> expects to receive. The use of +<code><nobr>%1</nobr></code> inside the macro definition refers to the +first parameter to the macro call. With a macro taking more than one +parameter, subsequent parameters would be referred to as +<code><nobr>%2</nobr></code>, <code><nobr>%3</nobr></code> and so on. +<p>Multi-line macros, like single-line macros, are case-sensitive, unless +you define them using the alternative directive +<code><nobr>%imacro</nobr></code>. +<p>If you need to pass a comma as <em>part</em> of a parameter to a +multi-line macro, you can do that by enclosing the entire parameter in +braces. So you could code things like +<p><pre> +%macro silly 2 + + %2: db %1 + +%endmacro + + silly 'a', letter_a ; letter_a: db 'a' + silly 'ab', string_ab ; string_ab: db 'ab' + silly {13,10}, crlf ; crlf: db 13,10 +</pre> +<h4><a name="section-4.3.1">4.3.1 Recursive Multi-Line Macros: <code><nobr>%rmacro</nobr></code></a></h4> +<p>A multi-line macro cannot be referenced within itself, in order to +prevent accidental infinite recursion. +<p>Recursive multi-line macros allow for self-referencing, with the caveat +that the user is aware of the existence, use and purpose of recursive +multi-line macros. There is also a generous, but sane, upper limit to the +number of recursions, in order to prevent run-away memory consumption in +case of accidental infinite recursion. +<p>As with non-recursive multi-line macros, recursive multi-line macros are +case-sensitive, unless you define them using the alternative directive +<code><nobr>%irmacro</nobr></code>. +<h4><a name="section-4.3.2">4.3.2 Overloading Multi-Line Macros</a></h4> +<p>As with single-line macros, multi-line macros can be overloaded by +defining the same macro name several times with different numbers of +parameters. This time, no exception is made for macros with no parameters +at all. So you could define +<p><pre> +%macro prologue 0 + + push ebp + mov ebp,esp + +%endmacro +</pre> +<p>to define an alternative form of the function prologue which allocates +no local stack space. +<p>Sometimes, however, you might want to `overload' a machine instruction; +for example, you might want to define +<p><pre> +%macro push 2 + + push %1 + push %2 + +%endmacro +</pre> +<p>so that you could code +<p><pre> + push ebx ; this line is not a macro call + push eax,ecx ; but this one is +</pre> +<p>Ordinarily, NASM will give a warning for the first of the above two +lines, since <code><nobr>push</nobr></code> is now defined to be a macro, +and is being invoked with a number of parameters for which no definition +has been given. The correct code will still be generated, but the assembler +will give a warning. This warning can be disabled by the use of the +<code><nobr>-w-macro-params</nobr></code> command-line option (see +<a href="nasmdoc2.html#section-2.1.24">section 2.1.24</a>). +<h4><a name="section-4.3.3">4.3.3 Macro-Local Labels</a></h4> +<p>NASM allows you to define labels within a multi-line macro definition in +such a way as to make them local to the macro call: so calling the same +macro multiple times will use a different label each time. You do this by +prefixing <code><nobr>%%</nobr></code> to the label name. So you can invent +an instruction which executes a <code><nobr>RET</nobr></code> if the +<code><nobr>Z</nobr></code> flag is set by doing this: +<p><pre> +%macro retz 0 + + jnz %%skip + ret + %%skip: + +%endmacro +</pre> +<p>You can call this macro as many times as you want, and every time you +call it NASM will make up a different `real' name to substitute for the +label <code><nobr>%%skip</nobr></code>. The names NASM invents are of the +form <code><nobr>..@2345.skip</nobr></code>, where the number 2345 changes +with every macro call. The <code><nobr>..@</nobr></code> prefix prevents +macro-local labels from interfering with the local label mechanism, as +described in <a href="nasmdoc3.html#section-3.9">section 3.9</a>. You +should avoid defining your own labels in this form (the +<code><nobr>..@</nobr></code> prefix, then a number, then another period) +in case they interfere with macro-local labels. +<h4><a name="section-4.3.4">4.3.4 Greedy Macro Parameters</a></h4> +<p>Occasionally it is useful to define a macro which lumps its entire +command line into one parameter definition, possibly after extracting one +or two smaller parameters from the front. An example might be a macro to +write a text string to a file in MS-DOS, where you might want to be able to +write +<p><pre> + writefile [filehandle],"hello, world",13,10 +</pre> +<p>NASM allows you to define the last parameter of a macro to be +<em>greedy</em>, meaning that if you invoke the macro with more parameters +than it expects, all the spare parameters get lumped into the last defined +one along with the separating commas. So if you code: +<p><pre> +%macro writefile 2+ + + jmp %%endstr + %%str: db %2 + %%endstr: + mov dx,%%str + mov cx,%%endstr-%%str + mov bx,%1 + mov ah,0x40 + int 0x21 + +%endmacro +</pre> +<p>then the example call to <code><nobr>writefile</nobr></code> above will +work as expected: the text before the first comma, +<code><nobr>[filehandle]</nobr></code>, is used as the first macro +parameter and expanded when <code><nobr>%1</nobr></code> is referred to, +and all the subsequent text is lumped into <code><nobr>%2</nobr></code> and +placed after the <code><nobr>db</nobr></code>. +<p>The greedy nature of the macro is indicated to NASM by the use of the +<code><nobr>+</nobr></code> sign after the parameter count on the +<code><nobr>%macro</nobr></code> line. +<p>If you define a greedy macro, you are effectively telling NASM how it +should expand the macro given <em>any</em> number of parameters from the +actual number specified up to infinity; in this case, for example, NASM now +knows what to do when it sees a call to <code><nobr>writefile</nobr></code> +with 2, 3, 4 or more parameters. NASM will take this into account when +overloading macros, and will not allow you to define another form of +<code><nobr>writefile</nobr></code> taking 4 parameters (for example). +<p>Of course, the above macro could have been implemented as a non-greedy +macro, in which case the call to it would have had to look like +<p><pre> + writefile [filehandle], {"hello, world",13,10} +</pre> +<p>NASM provides both mechanisms for putting commas in macro parameters, +and you choose which one you prefer for each macro definition. +<p>See <a href="nasmdoc6.html#section-6.3.1">section 6.3.1</a> for a better +way to write the above macro. +<h4><a name="section-4.3.5">4.3.5 Default Macro Parameters</a></h4> +<p>NASM also allows you to define a multi-line macro with a <em>range</em> +of allowable parameter counts. If you do this, you can specify defaults for +omitted parameters. So, for example: +<p><pre> +%macro die 0-1 "Painful program death has occurred." + + writefile 2,%1 + mov ax,0x4c01 + int 0x21 + +%endmacro +</pre> +<p>This macro (which makes use of the <code><nobr>writefile</nobr></code> +macro defined in <a href="#section-4.3.4">section 4.3.4</a>) can be called +with an explicit error message, which it will display on the error output +stream before exiting, or it can be called with no parameters, in which +case it will use the default error message supplied in the macro +definition. +<p>In general, you supply a minimum and maximum number of parameters for a +macro of this type; the minimum number of parameters are then required in +the macro call, and then you provide defaults for the optional ones. So if +a macro definition began with the line +<p><pre> +%macro foobar 1-3 eax,[ebx+2] +</pre> +<p>then it could be called with between one and three parameters, and +<code><nobr>%1</nobr></code> would always be taken from the macro call. +<code><nobr>%2</nobr></code>, if not specified by the macro call, would +default to <code><nobr>eax</nobr></code>, and <code><nobr>%3</nobr></code> +if not specified would default to <code><nobr>[ebx+2]</nobr></code>. +<p>You can provide extra information to a macro by providing too many +default parameters: +<p><pre> +%macro quux 1 something +</pre> +<p>This will trigger a warning by default; see +<a href="nasmdoc2.html#section-2.1.24">section 2.1.24</a> for more +information. When <code><nobr>quux</nobr></code> is invoked, it receives +not one but two parameters. <code><nobr>something</nobr></code> can be +referred to as <code><nobr>%2</nobr></code>. The difference between passing +<code><nobr>something</nobr></code> this way and writing +<code><nobr>something</nobr></code> in the macro body is that with this way +<code><nobr>something</nobr></code> is evaluated when the macro is defined, +not when it is expanded. +<p>You may omit parameter defaults from the macro definition, in which case +the parameter default is taken to be blank. This can be useful for macros +which can take a variable number of parameters, since the +<code><nobr>%0</nobr></code> token (see <a href="#section-4.3.6">section +4.3.6</a>) allows you to determine how many parameters were really passed +to the macro call. +<p>This defaulting mechanism can be combined with the greedy-parameter +mechanism; so the <code><nobr>die</nobr></code> macro above could be made +more powerful, and more useful, by changing the first line of the +definition to +<p><pre> +%macro die 0-1+ "Painful program death has occurred.",13,10 +</pre> +<p>The maximum parameter count can be infinite, denoted by +<code><nobr>*</nobr></code>. In this case, of course, it is impossible to +provide a <em>full</em> set of default parameters. Examples of this usage +are shown in <a href="#section-4.3.7">section 4.3.7</a>. +<h4><a name="section-4.3.6">4.3.6 <code><nobr>%0</nobr></code>: Macro Parameter Counter</a></h4> +<p>The parameter reference <code><nobr>%0</nobr></code> will return a +numeric constant giving the number of parameters received, that is, if +<code><nobr>%0</nobr></code> is n then <code><nobr>%</nobr></code>n is the +last parameter. <code><nobr>%0</nobr></code> is mostly useful for macros +that can take a variable number of parameters. It can be used as an +argument to <code><nobr>%rep</nobr></code> (see +<a href="#section-4.5">section 4.5</a>) in order to iterate through all the +parameters of a macro. Examples are given in +<a href="#section-4.3.7">section 4.3.7</a>. +<h4><a name="section-4.3.7">4.3.7 <code><nobr>%rotate</nobr></code>: Rotating Macro Parameters</a></h4> +<p>Unix shell programmers will be familiar with the +<code><nobr>shift</nobr></code> shell command, which allows the arguments +passed to a shell script (referenced as <code><nobr>$1</nobr></code>, +<code><nobr>$2</nobr></code> and so on) to be moved left by one place, so +that the argument previously referenced as <code><nobr>$2</nobr></code> +becomes available as <code><nobr>$1</nobr></code>, and the argument +previously referenced as <code><nobr>$1</nobr></code> is no longer +available at all. +<p>NASM provides a similar mechanism, in the form of +<code><nobr>%rotate</nobr></code>. As its name suggests, it differs from +the Unix <code><nobr>shift</nobr></code> in that no parameters are lost: +parameters rotated off the left end of the argument list reappear on the +right, and vice versa. +<p><code><nobr>%rotate</nobr></code> is invoked with a single numeric +argument (which may be an expression). The macro parameters are rotated to +the left by that many places. If the argument to +<code><nobr>%rotate</nobr></code> is negative, the macro parameters are +rotated to the right. +<p>So a pair of macros to save and restore a set of registers might work as +follows: +<p><pre> +%macro multipush 1-* + + %rep %0 + push %1 + %rotate 1 + %endrep + +%endmacro +</pre> +<p>This macro invokes the <code><nobr>PUSH</nobr></code> instruction on +each of its arguments in turn, from left to right. It begins by pushing its +first argument, <code><nobr>%1</nobr></code>, then invokes +<code><nobr>%rotate</nobr></code> to move all the arguments one place to +the left, so that the original second argument is now available as +<code><nobr>%1</nobr></code>. Repeating this procedure as many times as +there were arguments (achieved by supplying <code><nobr>%0</nobr></code> as +the argument to <code><nobr>%rep</nobr></code>) causes each argument in +turn to be pushed. +<p>Note also the use of <code><nobr>*</nobr></code> as the maximum +parameter count, indicating that there is no upper limit on the number of +parameters you may supply to the <code><nobr>multipush</nobr></code> macro. +<p>It would be convenient, when using this macro, to have a +<code><nobr>POP</nobr></code> equivalent, which <em>didn't</em> require the +arguments to be given in reverse order. Ideally, you would write the +<code><nobr>multipush</nobr></code> macro call, then cut-and-paste the line +to where the pop needed to be done, and change the name of the called macro +to <code><nobr>multipop</nobr></code>, and the macro would take care of +popping the registers in the opposite order from the one in which they were +pushed. +<p>This can be done by the following definition: +<p><pre> +%macro multipop 1-* + + %rep %0 + %rotate -1 + pop %1 + %endrep + +%endmacro +</pre> +<p>This macro begins by rotating its arguments one place to the +<em>right</em>, so that the original <em>last</em> argument appears as +<code><nobr>%1</nobr></code>. This is then popped, and the arguments are +rotated right again, so the second-to-last argument becomes +<code><nobr>%1</nobr></code>. Thus the arguments are iterated through in +reverse order. +<h4><a name="section-4.3.8">4.3.8 Concatenating Macro Parameters</a></h4> +<p>NASM can concatenate macro parameters and macro indirection constructs +on to other text surrounding them. This allows you to declare a family of +symbols, for example, in a macro definition. If, for example, you wanted to +generate a table of key codes along with offsets into the table, you could +code something like +<p><pre> +%macro keytab_entry 2 + + keypos%1 equ $-keytab + db %2 + +%endmacro + +keytab: + keytab_entry F1,128+1 + keytab_entry F2,128+2 + keytab_entry Return,13 +</pre> +<p>which would expand to +<p><pre> +keytab: +keyposF1 equ $-keytab + db 128+1 +keyposF2 equ $-keytab + db 128+2 +keyposReturn equ $-keytab + db 13 +</pre> +<p>You can just as easily concatenate text on to the other end of a macro +parameter, by writing <code><nobr>%1foo</nobr></code>. +<p>If you need to append a <em>digit</em> to a macro parameter, for example +defining labels <code><nobr>foo1</nobr></code> and +<code><nobr>foo2</nobr></code> when passed the parameter +<code><nobr>foo</nobr></code>, you can't code <code><nobr>%11</nobr></code> +because that would be taken as the eleventh macro parameter. Instead, you +must code <code><nobr>%{1}1</nobr></code>, which will separate the first +<code><nobr>1</nobr></code> (giving the number of the macro parameter) from +the second (literal text to be concatenated to the parameter). +<p>This concatenation can also be applied to other preprocessor in-line +objects, such as macro-local labels (<a href="#section-4.3.3">section +4.3.3</a>) and context-local labels (<a href="#section-4.7.2">section +4.7.2</a>). In all cases, ambiguities in syntax can be resolved by +enclosing everything after the <code><nobr>%</nobr></code> sign and before +the literal text in braces: so <code><nobr>%{%foo}bar</nobr></code> +concatenates the text <code><nobr>bar</nobr></code> to the end of the real +name of the macro-local label <code><nobr>%%foo</nobr></code>. (This is +unnecessary, since the form NASM uses for the real names of macro-local +labels means that the two usages <code><nobr>%{%foo}bar</nobr></code> and +<code><nobr>%%foobar</nobr></code> would both expand to the same thing +anyway; nevertheless, the capability is there.) +<p>The single-line macro indirection construct, +<code><nobr>%[...]</nobr></code> (<a href="#section-4.1.3">section +4.1.3</a>), behaves the same way as macro parameters for the purpose of +concatenation. +<p>See also the <code><nobr>%+</nobr></code> operator, +<a href="#section-4.1.4">section 4.1.4</a>. +<h4><a name="section-4.3.9">4.3.9 Condition Codes as Macro Parameters</a></h4> +<p>NASM can give special treatment to a macro parameter which contains a +condition code. For a start, you can refer to the macro parameter +<code><nobr>%1</nobr></code> by means of the alternative syntax +<code><nobr>%+1</nobr></code>, which informs NASM that this macro parameter +is supposed to contain a condition code, and will cause the preprocessor to +report an error message if the macro is called with a parameter which is +<em>not</em> a valid condition code. +<p>Far more usefully, though, you can refer to the macro parameter by means +of <code><nobr>%-1</nobr></code>, which NASM will expand as the +<em>inverse</em> condition code. So the <code><nobr>retz</nobr></code> +macro defined in <a href="#section-4.3.3">section 4.3.3</a> can be replaced +by a general conditional-return macro like this: +<p><pre> +%macro retc 1 + + j%-1 %%skip + ret + %%skip: + +%endmacro +</pre> +<p>This macro can now be invoked using calls like +<code><nobr>retc ne</nobr></code>, which will cause the conditional-jump +instruction in the macro expansion to come out as +<code><nobr>JE</nobr></code>, or <code><nobr>retc po</nobr></code> which +will make the jump a <code><nobr>JPE</nobr></code>. +<p>The <code><nobr>%+1</nobr></code> macro-parameter reference is quite +happy to interpret the arguments <code><nobr>CXZ</nobr></code> and +<code><nobr>ECXZ</nobr></code> as valid condition codes; however, +<code><nobr>%-1</nobr></code> will report an error if passed either of +these, because no inverse condition code exists. +<h4><a name="section-4.3.10">4.3.10 Disabling Listing Expansion</a></h4> +<p>When NASM is generating a listing file from your program, it will +generally expand multi-line macros by means of writing the macro call and +then listing each line of the expansion. This allows you to see which +instructions in the macro expansion are generating what code; however, for +some macros this clutters the listing up unnecessarily. +<p>NASM therefore provides the <code><nobr>.nolist</nobr></code> qualifier, +which you can include in a macro definition to inhibit the expansion of the +macro in the listing file. The <code><nobr>.nolist</nobr></code> qualifier +comes directly after the number of parameters, like this: +<p><pre> +%macro foo 1.nolist +</pre> +<p>Or like this: +<p><pre> +%macro bar 1-5+.nolist a,b,c,d,e,f,g,h +</pre> +<h4><a name="section-4.3.11">4.3.11 Undefining Multi-Line Macros: <code><nobr>%unmacro</nobr></code></a></h4> +<p>Multi-line macros can be removed with the +<code><nobr>%unmacro</nobr></code> directive. Unlike the +<code><nobr>%undef</nobr></code> directive, however, +<code><nobr>%unmacro</nobr></code> takes an argument specification, and +will only remove exact matches with that argument specification. +<p>For example: +<p><pre> +%macro foo 1-3 + ; Do something +%endmacro +%unmacro foo 1-3 +</pre> +<p>removes the previously defined macro <code><nobr>foo</nobr></code>, but +<p><pre> +%macro bar 1-3 + ; Do something +%endmacro +%unmacro bar 1 +</pre> +<p>does <em>not</em> remove the macro <code><nobr>bar</nobr></code>, since +the argument specification does not match exactly. +<h4><a name="section-4.3.12">4.3.12 Exiting Multi-Line Macros: <code><nobr>%exitmacro</nobr></code></a></h4> +<p>Multi-line macro expansions can be arbitrarily terminated with the +<code><nobr>%exitmacro</nobr></code> directive. +<p>For example: +<p><pre> +%macro foo 1-3 + ; Do something + %if<condition> + %exitmacro + %endif + ; Do something +%endmacro +</pre> +<h3><a name="section-4.4">4.4 Conditional Assembly</a></h3> +<p>Similarly to the C preprocessor, NASM allows sections of a source file +to be assembled only if certain conditions are met. The general syntax of +this feature looks like this: +<p><pre> +%if<condition> + ; some code which only appears if <condition> is met +%elif<condition2> + ; only appears if <condition> is not met but <condition2> is +%else + ; this appears if neither <condition> nor <condition2> was met +%endif +</pre> +<p>The inverse forms <code><nobr>%ifn</nobr></code> and +<code><nobr>%elifn</nobr></code> are also supported. +<p>The <code><nobr>%else</nobr></code> clause is optional, as is the +<code><nobr>%elif</nobr></code> clause. You can have more than one +<code><nobr>%elif</nobr></code> clause as well. +<p>There are a number of variants of the <code><nobr>%if</nobr></code> +directive. Each has its corresponding <code><nobr>%elif</nobr></code>, +<code><nobr>%ifn</nobr></code>, and <code><nobr>%elifn</nobr></code> +directives; for example, the equivalents to the +<code><nobr>%ifdef</nobr></code> directive are +<code><nobr>%elifdef</nobr></code>, <code><nobr>%ifndef</nobr></code>, and +<code><nobr>%elifndef</nobr></code>. +<h4><a name="section-4.4.1">4.4.1 <code><nobr>%ifdef</nobr></code>: Testing Single-Line Macro Existence</a></h4> +<p>Beginning a conditional-assembly block with the line +<code><nobr>%ifdef MACRO</nobr></code> will assemble the subsequent code +if, and only if, a single-line macro called <code><nobr>MACRO</nobr></code> +is defined. If not, then the <code><nobr>%elif</nobr></code> and +<code><nobr>%else</nobr></code> blocks (if any) will be processed instead. +<p>For example, when debugging a program, you might want to write code such +as +<p><pre> + ; perform some function +%ifdef DEBUG + writefile 2,"Function performed successfully",13,10 +%endif + ; go and do something else +</pre> +<p>Then you could use the command-line option +<code><nobr>-dDEBUG</nobr></code> to create a version of the program which +produced debugging messages, and remove the option to generate the final +release version of the program. +<p>You can test for a macro <em>not</em> being defined by using +<code><nobr>%ifndef</nobr></code> instead of +<code><nobr>%ifdef</nobr></code>. You can also test for macro definitions +in <code><nobr>%elif</nobr></code> blocks by using +<code><nobr>%elifdef</nobr></code> and <code><nobr>%elifndef</nobr></code>. +<h4><a name="section-4.4.2">4.4.2 <code><nobr>%ifmacro</nobr></code>: Testing Multi-Line Macro Existence</a></h4> +<p>The <code><nobr>%ifmacro</nobr></code> directive operates in the same +way as the <code><nobr>%ifdef</nobr></code> directive, except that it +checks for the existence of a multi-line macro. +<p>For example, you may be working with a large project and not have +control over the macros in a library. You may want to create a macro with +one name if it doesn't already exist, and another name if one with that +name does exist. +<p>The <code><nobr>%ifmacro</nobr></code> is considered true if defining a +macro with the given name and number of arguments would cause a definitions +conflict. For example: +<p><pre> +%ifmacro MyMacro 1-3 + + %error "MyMacro 1-3" causes a conflict with an existing macro. + +%else + + %macro MyMacro 1-3 + + ; insert code to define the macro + + %endmacro + +%endif +</pre> +<p>This will create the macro "MyMacro 1-3" if no macro already exists +which would conflict with it, and emits a warning if there would be a +definition conflict. +<p>You can test for the macro not existing by using the +<code><nobr>%ifnmacro</nobr></code> instead of +<code><nobr>%ifmacro</nobr></code>. Additional tests can be performed in +<code><nobr>%elif</nobr></code> blocks by using +<code><nobr>%elifmacro</nobr></code> and +<code><nobr>%elifnmacro</nobr></code>. +<h4><a name="section-4.4.3">4.4.3 <code><nobr>%ifctx</nobr></code>: Testing the Context Stack</a></h4> +<p>The conditional-assembly construct <code><nobr>%ifctx</nobr></code> will +cause the subsequent code to be assembled if and only if the top context on +the preprocessor's context stack has the same name as one of the arguments. +As with <code><nobr>%ifdef</nobr></code>, the inverse and +<code><nobr>%elif</nobr></code> forms <code><nobr>%ifnctx</nobr></code>, +<code><nobr>%elifctx</nobr></code> and <code><nobr>%elifnctx</nobr></code> +are also supported. +<p>For more details of the context stack, see +<a href="#section-4.7">section 4.7</a>. For a sample use of +<code><nobr>%ifctx</nobr></code>, see <a href="#section-4.7.5">section +4.7.5</a>. +<h4><a name="section-4.4.4">4.4.4 <code><nobr>%if</nobr></code>: Testing Arbitrary Numeric Expressions</a></h4> +<p>The conditional-assembly construct <code><nobr>%if expr</nobr></code> +will cause the subsequent code to be assembled if and only if the value of +the numeric expression <code><nobr>expr</nobr></code> is non-zero. An +example of the use of this feature is in deciding when to break out of a +<code><nobr>%rep</nobr></code> preprocessor loop: see +<a href="#section-4.5">section 4.5</a> for a detailed example. +<p>The expression given to <code><nobr>%if</nobr></code>, and its +counterpart <code><nobr>%elif</nobr></code>, is a critical expression (see +<a href="nasmdoc3.html#section-3.8">section 3.8</a>). +<p><code><nobr>%if</nobr></code> extends the normal NASM expression syntax, +by providing a set of relational operators which are not normally available +in expressions. The operators <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> test equality, less-than, greater-than, +less-or-equal, greater-or-equal and not-equal respectively. The C-like +forms <code><nobr>==</nobr></code> and <code><nobr>!=</nobr></code> are +supported as alternative forms of <code><nobr>=</nobr></code> and +<code><nobr><></nobr></code>. In addition, low-priority logical +operators <code><nobr>&&</nobr></code>, +<code><nobr>^^</nobr></code> and <code><nobr>||</nobr></code> are provided, +supplying logical AND, logical XOR and logical OR. These work like the C +logical operators (although C has no logical XOR), in that they always +return either 0 or 1, and treat any non-zero input as 1 (so that +<code><nobr>^^</nobr></code>, for example, returns 1 if exactly one of its +inputs is zero, and 0 otherwise). The relational operators also return 1 +for true and 0 for false. +<p>Like other <code><nobr>%if</nobr></code> constructs, +<code><nobr>%if</nobr></code> has a counterpart +<code><nobr>%elif</nobr></code>, and negative forms +<code><nobr>%ifn</nobr></code> and <code><nobr>%elifn</nobr></code>. +<h4><a name="section-4.4.5">4.4.5 <code><nobr>%ifidn</nobr></code> and <code><nobr>%ifidni</nobr></code>: Testing Exact Text Identity</a></h4> +<p>The construct <code><nobr>%ifidn text1,text2</nobr></code> will cause +the subsequent code to be assembled if and only if +<code><nobr>text1</nobr></code> and <code><nobr>text2</nobr></code>, after +expanding single-line macros, are identical pieces of text. Differences in +white space are not counted. +<p><code><nobr>%ifidni</nobr></code> is similar to +<code><nobr>%ifidn</nobr></code>, but is case-insensitive. +<p>For example, the following macro pushes a register or number on the +stack, and allows you to treat <code><nobr>IP</nobr></code> as a real +register: +<p><pre> +%macro pushparam 1 + + %ifidni %1,ip + call %%label + %%label: + %else + push %1 + %endif + +%endmacro +</pre> +<p>Like other <code><nobr>%if</nobr></code> constructs, +<code><nobr>%ifidn</nobr></code> has a counterpart +<code><nobr>%elifidn</nobr></code>, and negative forms +<code><nobr>%ifnidn</nobr></code> and <code><nobr>%elifnidn</nobr></code>. +Similarly, <code><nobr>%ifidni</nobr></code> has counterparts +<code><nobr>%elifidni</nobr></code>, <code><nobr>%ifnidni</nobr></code> and +<code><nobr>%elifnidni</nobr></code>. +<h4><a name="section-4.4.6">4.4.6 <code><nobr>%ifid</nobr></code>, <code><nobr>%ifnum</nobr></code>, <code><nobr>%ifstr</nobr></code>: Testing Token Types</a></h4> +<p>Some macros will want to perform different tasks depending on whether +they are passed a number, a string, or an identifier. For example, a string +output macro might want to be able to cope with being passed either a +string constant or a pointer to an existing string. +<p>The conditional assembly construct <code><nobr>%ifid</nobr></code>, +taking one parameter (which may be blank), assembles the subsequent code if +and only if the first token in the parameter exists and is an identifier. +<code><nobr>%ifnum</nobr></code> works similarly, but tests for the token +being a numeric constant; <code><nobr>%ifstr</nobr></code> tests for it +being a string. +<p>For example, the <code><nobr>writefile</nobr></code> macro defined in +<a href="#section-4.3.4">section 4.3.4</a> can be extended to take +advantage of <code><nobr>%ifstr</nobr></code> in the following fashion: +<p><pre> +%macro writefile 2-3+ + + %ifstr %2 + jmp %%endstr + %if %0 = 3 + %%str: db %2,%3 + %else + %%str: db %2 + %endif + %%endstr: mov dx,%%str + mov cx,%%endstr-%%str + %else + mov dx,%2 + mov cx,%3 + %endif + mov bx,%1 + mov ah,0x40 + int 0x21 + +%endmacro +</pre> +<p>Then the <code><nobr>writefile</nobr></code> macro can cope with being +called in either of the following two ways: +<p><pre> + writefile [file], strpointer, length + writefile [file], "hello", 13, 10 +</pre> +<p>In the first, <code><nobr>strpointer</nobr></code> is used as the +address of an already-declared string, and <code><nobr>length</nobr></code> +is used as its length; in the second, a string is given to the macro, which +therefore declares it itself and works out the address and length for +itself. +<p>Note the use of <code><nobr>%if</nobr></code> inside the +<code><nobr>%ifstr</nobr></code>: this is to detect whether the macro was +passed two arguments (so the string would be a single string constant, and +<code><nobr>db %2</nobr></code> would be adequate) or more (in which case, +all but the first two would be lumped together into +<code><nobr>%3</nobr></code>, and <code><nobr>db %2,%3</nobr></code> would +be required). +<p>The usual <code><nobr>%elif</nobr></code>..., +<code><nobr>%ifn</nobr></code>..., and <code><nobr>%elifn</nobr></code>... +versions exist for each of <code><nobr>%ifid</nobr></code>, +<code><nobr>%ifnum</nobr></code> and <code><nobr>%ifstr</nobr></code>. +<h4><a name="section-4.4.7">4.4.7 <code><nobr>%iftoken</nobr></code>: Test for a Single Token</a></h4> +<p>Some macros will want to do different things depending on if it is +passed a single token (e.g. paste it to something else using +<code><nobr>%+</nobr></code>) versus a multi-token sequence. +<p>The conditional assembly construct <code><nobr>%iftoken</nobr></code> +assembles the subsequent code if and only if the expanded parameters +consist of exactly one token, possibly surrounded by whitespace. +<p>For example: +<p><pre> +%iftoken 1 +</pre> +<p>will assemble the subsequent code, but +<p><pre> +%iftoken -1 +</pre> +<p>will not, since <code><nobr>-1</nobr></code> contains two tokens: the +unary minus operator <code><nobr>-</nobr></code>, and the number +<code><nobr>1</nobr></code>. +<p>The usual <code><nobr>%eliftoken</nobr></code>, +<code><nobr>%ifntoken</nobr></code>, and +<code><nobr>%elifntoken</nobr></code> variants are also provided. +<h4><a name="section-4.4.8">4.4.8 <code><nobr>%ifempty</nobr></code>: Test for Empty Expansion</a></h4> +<p>The conditional assembly construct <code><nobr>%ifempty</nobr></code> +assembles the subsequent code if and only if the expanded parameters do not +contain any tokens at all, whitespace excepted. +<p>The usual <code><nobr>%elifempty</nobr></code>, +<code><nobr>%ifnempty</nobr></code>, and +<code><nobr>%elifnempty</nobr></code> variants are also provided. +<h3><a name="section-4.5">4.5 Preprocessor Loops: <code><nobr>%rep</nobr></code></a></h3> +<p>NASM's <code><nobr>TIMES</nobr></code> prefix, though useful, cannot be +used to invoke a multi-line macro multiple times, because it is processed +by NASM after macros have already been expanded. Therefore NASM provides +another form of loop, this time at the preprocessor level: +<code><nobr>%rep</nobr></code>. +<p>The directives <code><nobr>%rep</nobr></code> and +<code><nobr>%endrep</nobr></code> (<code><nobr>%rep</nobr></code> takes a +numeric argument, which can be an expression; +<code><nobr>%endrep</nobr></code> takes no arguments) can be used to +enclose a chunk of code, which is then replicated as many times as +specified by the preprocessor: +<p><pre> +%assign i 0 +%rep 64 + inc word [table+2*i] +%assign i i+1 +%endrep +</pre> +<p>This will generate a sequence of 64 <code><nobr>INC</nobr></code> +instructions, incrementing every word of memory from +<code><nobr>[table]</nobr></code> to <code><nobr>[table+126]</nobr></code>. +<p>For more complex termination conditions, or to break out of a repeat +loop part way along, you can use the <code><nobr>%exitrep</nobr></code> +directive to terminate the loop, like this: +<p><pre> +fibonacci: +%assign i 0 +%assign j 1 +%rep 100 +%if j > 65535 + %exitrep +%endif + dw j +%assign k j+i +%assign i j +%assign j k +%endrep + +fib_number equ ($-fibonacci)/2 +</pre> +<p>This produces a list of all the Fibonacci numbers that will fit in 16 +bits. Note that a maximum repeat count must still be given to +<code><nobr>%rep</nobr></code>. This is to prevent the possibility of NASM +getting into an infinite loop in the preprocessor, which (on multitasking +or multi-user systems) would typically cause all the system memory to be +gradually used up and other applications to start crashing. +<h3><a name="section-4.6">4.6 Source Files and Dependencies</a></h3> +<p>These commands allow you to split your sources into multiple files. +<h4><a name="section-4.6.1">4.6.1 <code><nobr>%include</nobr></code>: Including Other Files</a></h4> +<p>Using, once again, a very similar syntax to the C preprocessor, NASM's +preprocessor lets you include other source files into your code. This is +done by the use of the <code><nobr>%include</nobr></code> directive: +<p><pre> +%include "macros.mac" +</pre> +<p>will include the contents of the file +<code><nobr>macros.mac</nobr></code> into the source file containing the +<code><nobr>%include</nobr></code> directive. +<p>Include files are searched for in the current directory (the directory +you're in when you run NASM, as opposed to the location of the NASM +executable or the location of the source file), plus any directories +specified on the NASM command line using the <code><nobr>-i</nobr></code> +option. +<p>The standard C idiom for preventing a file being included more than once +is just as applicable in NASM: if the file +<code><nobr>macros.mac</nobr></code> has the form +<p><pre> +%ifndef MACROS_MAC + %define MACROS_MAC + ; now define some macros +%endif +</pre> +<p>then including the file more than once will not cause errors, because +the second time the file is included nothing will happen because the macro +<code><nobr>MACROS_MAC</nobr></code> will already be defined. +<p>You can force a file to be included even if there is no +<code><nobr>%include</nobr></code> directive that explicitly includes it, +by using the <code><nobr>-p</nobr></code> option on the NASM command line +(see <a href="nasmdoc2.html#section-2.1.17">section 2.1.17</a>). +<h4><a name="section-4.6.2">4.6.2 <code><nobr>%pathsearch</nobr></code>: Search the Include Path</a></h4> +<p>The <code><nobr>%pathsearch</nobr></code> directive takes a single-line +macro name and a filename, and declare or redefines the specified +single-line macro to be the include-path-resolved version of the filename, +if the file exists (otherwise, it is passed unchanged.) +<p>For example, +<p><pre> +%pathsearch MyFoo "foo.bin" +</pre> +<p>... with <code><nobr>-Ibins/</nobr></code> in the include path may end +up defining the macro <code><nobr>MyFoo</nobr></code> to be +<code><nobr>"bins/foo.bin"</nobr></code>. +<h4><a name="section-4.6.3">4.6.3 <code><nobr>%depend</nobr></code>: Add Dependent Files</a></h4> +<p>The <code><nobr>%depend</nobr></code> directive takes a filename and +adds it to the list of files to be emitted as dependency generation when +the <code><nobr>-M</nobr></code> options and its relatives (see +<a href="nasmdoc2.html#section-2.1.4">section 2.1.4</a>) are used. It +produces no output. +<p>This is generally used in conjunction with +<code><nobr>%pathsearch</nobr></code>. For example, a simplified version of +the standard macro wrapper for the <code><nobr>INCBIN</nobr></code> +directive looks like: +<p><pre> +%imacro incbin 1-2+ 0 +%pathsearch dep %1 +%depend dep + incbin dep,%2 +%endmacro +</pre> +<p>This first resolves the location of the file into the macro +<code><nobr>dep</nobr></code>, then adds it to the dependency lists, and +finally issues the assembler-level <code><nobr>INCBIN</nobr></code> +directive. +<h4><a name="section-4.6.4">4.6.4 <code><nobr>%use</nobr></code>: Include Standard Macro Package</a></h4> +<p>The <code><nobr>%use</nobr></code> directive is similar to +<code><nobr>%include</nobr></code>, but rather than including the contents +of a file, it includes a named standard macro package. The standard macro +packages are part of NASM, and are described in +<a href="nasmdoc5.html">chapter 5</a>. +<p>Unlike the <code><nobr>%include</nobr></code> directive, package names +for the <code><nobr>%use</nobr></code> directive do not require quotes, but +quotes are permitted. In NASM 2.04 and 2.05 the unquoted form would be +macro-expanded; this is no longer true. Thus, the following lines are +equivalent: +<p><pre> +%use altreg +%use 'altreg' +</pre> +<p>Standard macro packages are protected from multiple inclusion. When a +standard macro package is used, a testable single-line macro of the form +<code><nobr>__USE_</nobr></code><em>package</em><code><nobr>__</nobr></code> +is also defined, see <a href="#section-4.11.8">section 4.11.8</a>. +<h3><a name="section-4.7">4.7 The Context Stack</a></h3> +<p>Having labels that are local to a macro definition is sometimes not +quite powerful enough: sometimes you want to be able to share labels +between several macro calls. An example might be a +<code><nobr>REPEAT</nobr></code> ... <code><nobr>UNTIL</nobr></code> loop, +in which the expansion of the <code><nobr>REPEAT</nobr></code> macro would +need to be able to refer to a label which the +<code><nobr>UNTIL</nobr></code> macro had defined. However, for such a +macro you would also want to be able to nest these loops. +<p>NASM provides this level of power by means of a <em>context stack</em>. +The preprocessor maintains a stack of <em>contexts</em>, each of which is +characterized by a name. You add a new context to the stack using the +<code><nobr>%push</nobr></code> directive, and remove one using +<code><nobr>%pop</nobr></code>. You can define labels that are local to a +particular context on the stack. +<h4><a name="section-4.7.1">4.7.1 <code><nobr>%push</nobr></code> and <code><nobr>%pop</nobr></code>: Creating and Removing Contexts</a></h4> +<p>The <code><nobr>%push</nobr></code> directive is used to create a new +context and place it on the top of the context stack. +<code><nobr>%push</nobr></code> takes an optional argument, which is the +name of the context. For example: +<p><pre> +%push foobar +</pre> +<p>This pushes a new context called <code><nobr>foobar</nobr></code> on the +stack. You can have several contexts on the stack with the same name: they +can still be distinguished. If no name is given, the context is unnamed +(this is normally used when both the <code><nobr>%push</nobr></code> and +the <code><nobr>%pop</nobr></code> are inside a single macro definition.) +<p>The directive <code><nobr>%pop</nobr></code>, taking one optional +argument, removes the top context from the context stack and destroys it, +along with any labels associated with it. If an argument is given, it must +match the name of the current context, otherwise it will issue an error. +<h4><a name="section-4.7.2">4.7.2 Context-Local Labels</a></h4> +<p>Just as the usage <code><nobr>%%foo</nobr></code> defines a label which +is local to the particular macro call in which it is used, the usage +<code><nobr>%$foo</nobr></code> is used to define a label which is local to +the context on the top of the context stack. So the +<code><nobr>REPEAT</nobr></code> and <code><nobr>UNTIL</nobr></code> +example given above could be implemented by means of: +<p><pre> +%macro repeat 0 + + %push repeat + %$begin: + +%endmacro + +%macro until 1 + + j%-1 %$begin + %pop + +%endmacro +</pre> +<p>and invoked by means of, for example, +<p><pre> + mov cx,string + repeat + add cx,3 + scasb + until e +</pre> +<p>which would scan every fourth byte of a string in search of the byte in +<code><nobr>AL</nobr></code>. +<p>If you need to define, or access, labels local to the context +<em>below</em> the top one on the stack, you can use +<code><nobr>%$$foo</nobr></code>, or <code><nobr>%$$$foo</nobr></code> for +the context below that, and so on. +<h4><a name="section-4.7.3">4.7.3 Context-Local Single-Line Macros</a></h4> +<p>NASM also allows you to define single-line macros which are local to a +particular context, in just the same way: +<p><pre> +%define %$localmac 3 +</pre> +<p>will define the single-line macro <code><nobr>%$localmac</nobr></code> +to be local to the top context on the stack. Of course, after a subsequent +<code><nobr>%push</nobr></code>, it can then still be accessed by the name +<code><nobr>%$$localmac</nobr></code>. +<h4><a name="section-4.7.4">4.7.4 <code><nobr>%repl</nobr></code>: Renaming a Context</a></h4> +<p>If you need to change the name of the top context on the stack (in +order, for example, to have it respond differently to +<code><nobr>%ifctx</nobr></code>), you can execute a +<code><nobr>%pop</nobr></code> followed by a +<code><nobr>%push</nobr></code>; but this will have the side effect of +destroying all context-local labels and macros associated with the context +that was just popped. +<p>NASM provides the directive <code><nobr>%repl</nobr></code>, which +<em>replaces</em> a context with a different name, without touching the +associated macros and labels. So you could replace the destructive code +<p><pre> +%pop +%push newname +</pre> +<p>with the non-destructive version +<code><nobr>%repl newname</nobr></code>. +<h4><a name="section-4.7.5">4.7.5 Example Use of the Context Stack: Block IFs</a></h4> +<p>This example makes use of almost all the context-stack features, +including the conditional-assembly construct +<code><nobr>%ifctx</nobr></code>, to implement a block IF statement as a +set of macros. +<p><pre> +%macro if 1 + + %push if + j%-1 %$ifnot + +%endmacro + +%macro else 0 + + %ifctx if + %repl else + jmp %$ifend + %$ifnot: + %else + %error "expected `if' before `else'" + %endif + +%endmacro + +%macro endif 0 + + %ifctx if + %$ifnot: + %pop + %elifctx else + %$ifend: + %pop + %else + %error "expected `if' or `else' before `endif'" + %endif + +%endmacro +</pre> +<p>This code is more robust than the <code><nobr>REPEAT</nobr></code> and +<code><nobr>UNTIL</nobr></code> macros given in +<a href="#section-4.7.2">section 4.7.2</a>, because it uses conditional +assembly to check that the macros are issued in the right order (for +example, not calling <code><nobr>endif</nobr></code> before +<code><nobr>if</nobr></code>) and issues a <code><nobr>%error</nobr></code> +if they're not. +<p>In addition, the <code><nobr>endif</nobr></code> macro has to be able to +cope with the two distinct cases of either directly following an +<code><nobr>if</nobr></code>, or following an +<code><nobr>else</nobr></code>. It achieves this, again, by using +conditional assembly to do different things depending on whether the +context on top of the stack is <code><nobr>if</nobr></code> or +<code><nobr>else</nobr></code>. +<p>The <code><nobr>else</nobr></code> macro has to preserve the context on +the stack, in order to have the <code><nobr>%$ifnot</nobr></code> referred +to by the <code><nobr>if</nobr></code> macro be the same as the one defined +by the <code><nobr>endif</nobr></code> macro, but has to change the +context's name so that <code><nobr>endif</nobr></code> will know there was +an intervening <code><nobr>else</nobr></code>. It does this by the use of +<code><nobr>%repl</nobr></code>. +<p>A sample usage of these macros might look like: +<p><pre> + cmp ax,bx + + if ae + cmp bx,cx + + if ae + mov ax,cx + else + mov ax,bx + endif + + else + cmp ax,cx + + if ae + mov ax,cx + endif + + endif +</pre> +<p>The block-<code><nobr>IF</nobr></code> macros handle nesting quite +happily, by means of pushing another context, describing the inner +<code><nobr>if</nobr></code>, on top of the one describing the outer +<code><nobr>if</nobr></code>; thus <code><nobr>else</nobr></code> and +<code><nobr>endif</nobr></code> always refer to the last unmatched +<code><nobr>if</nobr></code> or <code><nobr>else</nobr></code>. +<h3><a name="section-4.8">4.8 Stack Relative Preprocessor Directives</a></h3> +<p>The following preprocessor directives provide a way to use labels to +refer to local variables allocated on the stack. +<ul> +<li><code><nobr>%arg</nobr></code> (see <a href="#section-4.8.1">section +4.8.1</a>) +<li><code><nobr>%stacksize</nobr></code> (see +<a href="#section-4.8.2">section 4.8.2</a>) +<li><code><nobr>%local</nobr></code> (see <a href="#section-4.8.3">section +4.8.3</a>) +</ul> +<h4><a name="section-4.8.1">4.8.1 <code><nobr>%arg</nobr></code> Directive</a></h4> +<p>The <code><nobr>%arg</nobr></code> directive is used to simplify the +handling of parameters passed on the stack. Stack based parameter passing +is used by many high level languages, including C, C++ and Pascal. +<p>While NASM has macros which attempt to duplicate this functionality (see +<a href="nasmdoc8.html#section-8.4.5">section 8.4.5</a>), the syntax is not +particularly convenient to use. and is not TASM compatible. Here is an +example which shows the use of <code><nobr>%arg</nobr></code> without any +external macros: +<p><pre> +some_function: + + %push mycontext ; save the current context + %stacksize large ; tell NASM to use bp + %arg i:word, j_ptr:word + + mov ax,[i] + mov bx,[j_ptr] + add ax,[bx] + ret + + %pop ; restore original context +</pre> +<p>This is similar to the procedure defined in +<a href="nasmdoc8.html#section-8.4.5">section 8.4.5</a> and adds the value +in i to the value pointed to by j_ptr and returns the sum in the ax +register. See <a href="#section-4.7.1">section 4.7.1</a> for an explanation +of <code><nobr>push</nobr></code> and <code><nobr>pop</nobr></code> and the +use of context stacks. +<h4><a name="section-4.8.2">4.8.2 <code><nobr>%stacksize</nobr></code> Directive</a></h4> +<p>The <code><nobr>%stacksize</nobr></code> directive is used in +conjunction with the <code><nobr>%arg</nobr></code> (see +<a href="#section-4.8.1">section 4.8.1</a>) and the +<code><nobr>%local</nobr></code> (see <a href="#section-4.8.3">section +4.8.3</a>) directives. It tells NASM the default size to use for subsequent +<code><nobr>%arg</nobr></code> and <code><nobr>%local</nobr></code> +directives. The <code><nobr>%stacksize</nobr></code> directive takes one +required argument which is one of <code><nobr>flat</nobr></code>, +<code><nobr>flat64</nobr></code>, <code><nobr>large</nobr></code> or +<code><nobr>small</nobr></code>. +<p><pre> +%stacksize flat +</pre> +<p>This form causes NASM to use stack-based parameter addressing relative +to <code><nobr>ebp</nobr></code> and it assumes that a near form of call +was used to get to this label (i.e. that <code><nobr>eip</nobr></code> is +on the stack). +<p><pre> +%stacksize flat64 +</pre> +<p>This form causes NASM to use stack-based parameter addressing relative +to <code><nobr>rbp</nobr></code> and it assumes that a near form of call +was used to get to this label (i.e. that <code><nobr>rip</nobr></code> is +on the stack). +<p><pre> +%stacksize large +</pre> +<p>This form uses <code><nobr>bp</nobr></code> to do stack-based parameter +addressing and assumes that a far form of call was used to get to this +address (i.e. that <code><nobr>ip</nobr></code> and +<code><nobr>cs</nobr></code> are on the stack). +<p><pre> +%stacksize small +</pre> +<p>This form also uses <code><nobr>bp</nobr></code> to address stack +parameters, but it is different from <code><nobr>large</nobr></code> +because it also assumes that the old value of bp is pushed onto the stack +(i.e. it expects an <code><nobr>ENTER</nobr></code> instruction). In other +words, it expects that <code><nobr>bp</nobr></code>, +<code><nobr>ip</nobr></code> and <code><nobr>cs</nobr></code> are on the +top of the stack, underneath any local space which may have been allocated +by <code><nobr>ENTER</nobr></code>. This form is probably most useful when +used in combination with the <code><nobr>%local</nobr></code> directive +(see <a href="#section-4.8.3">section 4.8.3</a>). +<h4><a name="section-4.8.3">4.8.3 <code><nobr>%local</nobr></code> Directive</a></h4> +<p>The <code><nobr>%local</nobr></code> directive is used to simplify the +use of local temporary stack variables allocated in a stack frame. +Automatic local variables in C are an example of this kind of variable. The +<code><nobr>%local</nobr></code> directive is most useful when used with +the <code><nobr>%stacksize</nobr></code> (see +<a href="#section-4.8.2">section 4.8.2</a> and is also compatible with the +<code><nobr>%arg</nobr></code> directive (see +<a href="#section-4.8.1">section 4.8.1</a>). It allows simplified reference +to variables on the stack which have been allocated typically by using the +<code><nobr>ENTER</nobr></code> instruction. An example of its use is the +following: +<p><pre> +silly_swap: + + %push mycontext ; save the current context + %stacksize small ; tell NASM to use bp + %assign %$localsize 0 ; see text for explanation + %local old_ax:word, old_dx:word + + enter %$localsize,0 ; see text for explanation + mov [old_ax],ax ; swap ax & bx + mov [old_dx],dx ; and swap dx & cx + mov ax,bx + mov dx,cx + mov bx,[old_ax] + mov cx,[old_dx] + leave ; restore old bp + ret ; + + %pop ; restore original context +</pre> +<p>The <code><nobr>%$localsize</nobr></code> variable is used internally by +the <code><nobr>%local</nobr></code> directive and <em>must</em> be defined +within the current context before the <code><nobr>%local</nobr></code> +directive may be used. Failure to do so will result in one expression +syntax error for each <code><nobr>%local</nobr></code> variable declared. +It then may be used in the construction of an appropriately sized ENTER +instruction as shown in the example. +<h3><a name="section-4.9">4.9 Reporting User-Defined Errors: <code><nobr>%error</nobr></code>, <code><nobr>%warning</nobr></code>, <code><nobr>%fatal</nobr></code></a></h3> +<p>The preprocessor directive <code><nobr>%error</nobr></code> will cause +NASM to report an error if it occurs in assembled code. So if other users +are going to try to assemble your source files, you can ensure that they +define the right macros by means of code like this: +<p><pre> +%ifdef F1 + ; do some setup +%elifdef F2 + ; do some different setup +%else + %error "Neither F1 nor F2 was defined." +%endif +</pre> +<p>Then any user who fails to understand the way your code is supposed to +be assembled will be quickly warned of their mistake, rather than having to +wait until the program crashes on being run and then not knowing what went +wrong. +<p>Similarly, <code><nobr>%warning</nobr></code> issues a warning, but +allows assembly to continue: +<p><pre> +%ifdef F1 + ; do some setup +%elifdef F2 + ; do some different setup +%else + %warning "Neither F1 nor F2 was defined, assuming F1." + %define F1 +%endif +</pre> +<p><code><nobr>%error</nobr></code> and <code><nobr>%warning</nobr></code> +are issued only on the final assembly pass. This makes them safe to use in +conjunction with tests that depend on symbol values. +<p><code><nobr>%fatal</nobr></code> terminates assembly immediately, +regardless of pass. This is useful when there is no point in continuing the +assembly further, and doing so is likely just going to cause a spew of +confusing error messages. +<p>It is optional for the message string after +<code><nobr>%error</nobr></code>, <code><nobr>%warning</nobr></code> or +<code><nobr>%fatal</nobr></code> to be quoted. If it is <em>not</em>, then +single-line macros are expanded in it, which can be used to display more +information to the user. For example: +<p><pre> +%if foo > 64 + %assign foo_over foo-64 + %error foo is foo_over bytes too large +%endif +</pre> +<h3><a name="section-4.10">4.10 Other Preprocessor Directives</a></h3> +<p>NASM also has preprocessor directives which allow access to information +from external sources. Currently they include: +<ul> +<li><code><nobr>%line</nobr></code> enables NASM to correctly handle the +output of another preprocessor (see <a href="#section-4.10.1">section +4.10.1</a>). +<li><code><nobr>%!</nobr></code> enables NASM to read in the value of an +environment variable, which can then be used in your program (see +<a href="#section-4.10.2">section 4.10.2</a>). +</ul> +<h4><a name="section-4.10.1">4.10.1 <code><nobr>%line</nobr></code> Directive</a></h4> +<p>The <code><nobr>%line</nobr></code> directive is used to notify NASM +that the input line corresponds to a specific line number in another file. +Typically this other file would be an original source file, with the +current NASM input being the output of a pre-processor. The +<code><nobr>%line</nobr></code> directive allows NASM to output messages +which indicate the line number of the original source file, instead of the +file that is being read by NASM. +<p>This preprocessor directive is not generally of use to programmers, by +may be of interest to preprocessor authors. The usage of the +<code><nobr>%line</nobr></code> preprocessor directive is as follows: +<p><pre> +%line nnn[+mmm] [filename] +</pre> +<p>In this directive, <code><nobr>nnn</nobr></code> identifies the line of +the original source file which this line corresponds to. +<code><nobr>mmm</nobr></code> is an optional parameter which specifies a +line increment value; each line of the input file read in is considered to +correspond to <code><nobr>mmm</nobr></code> lines of the original source +file. Finally, <code><nobr>filename</nobr></code> is an optional parameter +which specifies the file name of the original source file. +<p>After reading a <code><nobr>%line</nobr></code> preprocessor directive, +NASM will report all file name and line numbers relative to the values +specified therein. +<h4><a name="section-4.10.2">4.10.2 <code><nobr>%!</nobr></code><code><nobr><env></nobr></code>: Read an environment variable.</a></h4> +<p>The <code><nobr>%!<env></nobr></code> directive makes it possible +to read the value of an environment variable at assembly time. This could, +for example, be used to store the contents of an environment variable into +a string, which could be used at some other point in your code. +<p>For example, suppose that you have an environment variable +<code><nobr>FOO</nobr></code>, and you want the contents of +<code><nobr>FOO</nobr></code> to be embedded in your program. You could do +that as follows: +<p><pre> +%defstr FOO %!FOO +</pre> +<p>See <a href="#section-4.1.8">section 4.1.8</a> for notes on the +<code><nobr>%defstr</nobr></code> directive. +<h3><a name="section-4.11">4.11 Standard Macros</a></h3> +<p>NASM defines a set of standard macros, which are already defined when it +starts to process any source file. If you really need a program to be +assembled with no pre-defined macros, you can use the +<code><nobr>%clear</nobr></code> directive to empty the preprocessor of +everything but context-local preprocessor variables and single-line macros. +<p>Most user-level assembler directives (see +<a href="nasmdoc6.html">chapter 6</a>) are implemented as macros which +invoke primitive directives; these are described in +<a href="nasmdoc6.html">chapter 6</a>. The rest of the standard macro set +is described here. +<h4><a name="section-4.11.1">4.11.1 NASM Version Macros</a></h4> +<p>The single-line macros <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> expand to the major, minor, +subminor and patch level parts of the version number of NASM being used. +So, under NASM 0.98.32p1 for example, +<code><nobr>__NASM_MAJOR__</nobr></code> would be defined to be 0, +<code><nobr>__NASM_MINOR__</nobr></code> would be defined as 98, +<code><nobr>__NASM_SUBMINOR__</nobr></code> would be defined to 32, and +<code><nobr>___NASM_PATCHLEVEL__</nobr></code> would be defined as 1. +<p>Additionally, the macro <code><nobr>__NASM_SNAPSHOT__</nobr></code> is +defined for automatically generated snapshot releases <em>only</em>. +<h4><a name="section-4.11.2">4.11.2 <code><nobr>__NASM_VERSION_ID__</nobr></code>: NASM Version ID</a></h4> +<p>The single-line macro <code><nobr>__NASM_VERSION_ID__</nobr></code> +expands to a dword integer representing the full version number of the +version of nasm being used. The value is the equivalent to +<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> concatenated to produce a +single doubleword. Hence, for 0.98.32p1, the returned number would be +equivalent to: +<p><pre> + dd 0x00622001 +</pre> +<p>or +<p><pre> + db 1,32,98,0 +</pre> +<p>Note that the above lines are generate exactly the same code, the second +line is used just to give an indication of the order that the separate +values will be present in memory. +<h4><a name="section-4.11.3">4.11.3 <code><nobr>__NASM_VER__</nobr></code>: NASM Version string</a></h4> +<p>The single-line macro <code><nobr>__NASM_VER__</nobr></code> expands to +a string which defines the version number of nasm being used. So, under +NASM 0.98.32 for example, +<p><pre> + db __NASM_VER__ +</pre> +<p>would expand to +<p><pre> + db "0.98.32" +</pre> +<h4><a name="section-4.11.4">4.11.4 <code><nobr>__FILE__</nobr></code> and <code><nobr>__LINE__</nobr></code>: File Name and Line Number</a></h4> +<p>Like the C preprocessor, NASM allows the user to find out the file name +and line number containing the current instruction. The macro +<code><nobr>__FILE__</nobr></code> expands to a string constant giving the +name of the current input file (which may change through the course of +assembly if <code><nobr>%include</nobr></code> directives are used), and +<code><nobr>__LINE__</nobr></code> expands to a numeric constant giving the +current line number in the input file. +<p>These macros could be used, for example, to communicate debugging +information to a macro, since invoking <code><nobr>__LINE__</nobr></code> +inside a macro definition (either single-line or multi-line) will return +the line number of the macro <em>call</em>, rather than +<em>definition</em>. So to determine where in a piece of code a crash is +occurring, for example, one could write a routine +<code><nobr>stillhere</nobr></code>, which is passed a line number in +<code><nobr>EAX</nobr></code> and outputs something like `line 155: still +here'. You could then write a macro +<p><pre> +%macro notdeadyet 0 + + push eax + mov eax,__LINE__ + call stillhere + pop eax + +%endmacro +</pre> +<p>and then pepper your code with calls to +<code><nobr>notdeadyet</nobr></code> until you find the crash point. +<h4><a name="section-4.11.5">4.11.5 <code><nobr>__BITS__</nobr></code>: Current BITS Mode</a></h4> +<p>The <code><nobr>__BITS__</nobr></code> standard macro is updated every +time that the BITS mode is set using the <code><nobr>BITS XX</nobr></code> +or <code><nobr>[BITS XX]</nobr></code> directive, where XX is a valid mode +number of 16, 32 or 64. <code><nobr>__BITS__</nobr></code> receives the +specified mode number and makes it globally available. This can be very +useful for those who utilize mode-dependent macros. +<h4><a name="section-4.11.6">4.11.6 <code><nobr>__OUTPUT_FORMAT__</nobr></code>: Current Output Format</a></h4> +<p>The <code><nobr>__OUTPUT_FORMAT__</nobr></code> standard macro holds the +current Output Format, as given by the <code><nobr>-f</nobr></code> option +or NASM's default. Type <code><nobr>nasm -hf</nobr></code> for a list. +<p><pre> +%ifidn __OUTPUT_FORMAT__, win32 + %define NEWLINE 13, 10 +%elifidn __OUTPUT_FORMAT__, elf32 + %define NEWLINE 10 +%endif +</pre> +<h4><a name="section-4.11.7">4.11.7 Assembly Date and Time Macros</a></h4> +<p>NASM provides a variety of macros that represent the timestamp of the +assembly session. +<ul> +<li>The <code><nobr>__DATE__</nobr></code> and +<code><nobr>__TIME__</nobr></code> macros give the assembly date and time +as strings, in ISO 8601 format (<code><nobr>"YYYY-MM-DD"</nobr></code> and +<code><nobr>"HH:MM:SS"</nobr></code>, respectively.) +<li>The <code><nobr>__DATE_NUM__</nobr></code> and +<code><nobr>__TIME_NUM__</nobr></code> macros give the assembly date and +time in numeric form; in the format <code><nobr>YYYYMMDD</nobr></code> and +<code><nobr>HHMMSS</nobr></code> respectively. +<li>The <code><nobr>__UTC_DATE__</nobr></code> and +<code><nobr>__UTC_TIME__</nobr></code> macros give the assembly date and +time in universal time (UTC) as strings, in ISO 8601 format +(<code><nobr>"YYYY-MM-DD"</nobr></code> and +<code><nobr>"HH:MM:SS"</nobr></code>, respectively.) If the host platform +doesn't provide UTC time, these macros are undefined. +<li>The <code><nobr>__UTC_DATE_NUM__</nobr></code> and +<code><nobr>__UTC_TIME_NUM__</nobr></code> macros give the assembly date +and time universal time (UTC) in numeric form; in the format +<code><nobr>YYYYMMDD</nobr></code> and <code><nobr>HHMMSS</nobr></code> +respectively. If the host platform doesn't provide UTC time, these macros +are undefined. +<li>The <code><nobr>__POSIX_TIME__</nobr></code> macro is defined as a +number containing the number of seconds since the POSIX epoch, 1 January +1970 00:00:00 UTC; excluding any leap seconds. This is computed using UTC +time if available on the host platform, otherwise it is computed using the +local time as if it was UTC. +</ul> +<p>All instances of time and date macros in the same assembly session +produce consistent output. For example, in an assembly session started at +42 seconds after midnight on January 1, 2010 in Moscow (timezone UTC+3) +these macros would have the following values, assuming, of course, a +properly configured environment with a correct clock: +<p><pre> + __DATE__ "2010-01-01" + __TIME__ "00:00:42" + __DATE_NUM__ 20100101 + __TIME_NUM__ 000042 + __UTC_DATE__ "2009-12-31" + __UTC_TIME__ "21:00:42" + __UTC_DATE_NUM__ 20091231 + __UTC_TIME_NUM__ 210042 + __POSIX_TIME__ 1262293242 +</pre> +<h4><a name="section-4.11.8">4.11.8 <code><nobr>__USE_</nobr></code><em>package</em><code><nobr>__</nobr></code>: Package Include Test</a></h4> +<p>When a standard macro package (see <a href="nasmdoc5.html">chapter +5</a>) is included with the <code><nobr>%use</nobr></code> directive (see +<a href="#section-4.6.4">section 4.6.4</a>), a single-line macro of the +form +<code><nobr>__USE_</nobr></code><em>package</em><code><nobr>__</nobr></code> +is automatically defined. This allows testing if a particular package is +invoked or not. +<p>For example, if the <code><nobr>altreg</nobr></code> package is included +(see <a href="nasmdoc5.html#section-5.1">section 5.1</a>), then the macro +<code><nobr>__USE_ALTREG__</nobr></code> is defined. +<h4><a name="section-4.11.9">4.11.9 <code><nobr>__PASS__</nobr></code>: Assembly Pass</a></h4> +<p>The macro <code><nobr>__PASS__</nobr></code> is defined to be +<code><nobr>1</nobr></code> on preparatory passes, and +<code><nobr>2</nobr></code> on the final pass. In preprocess-only mode, it +is set to <code><nobr>3</nobr></code>, and when running only to generate +dependencies (due to the <code><nobr>-M</nobr></code> or +<code><nobr>-MG</nobr></code> option, see +<a href="nasmdoc2.html#section-2.1.4">section 2.1.4</a>) it is set to +<code><nobr>0</nobr></code>. +<p><em>Avoid using this macro if at all possible. It is tremendously easy +to generate very strange errors by misusing it, and the semantics may +change in future versions of NASM.</em> +<h4><a name="section-4.11.10">4.11.10 <code><nobr>STRUC</nobr></code> and <code><nobr>ENDSTRUC</nobr></code>: Declaring Structure Data Types</a></h4> +<p>The core of NASM contains no intrinsic means of defining data +structures; instead, the preprocessor is sufficiently powerful that data +structures can be implemented as a set of macros. The macros +<code><nobr>STRUC</nobr></code> and <code><nobr>ENDSTRUC</nobr></code> are +used to define a structure data type. +<p><code><nobr>STRUC</nobr></code> takes one or two parameters. The first +parameter is the name of the data type. The second, optional parameter is +the base offset of the structure. The name of the data type is defined as a +symbol with the value of the base offset, and the name of the data type +with the suffix <code><nobr>_size</nobr></code> appended to it is defined +as an <code><nobr>EQU</nobr></code> giving the size of the structure. Once +<code><nobr>STRUC</nobr></code> has been issued, you are defining the +structure, and should define fields using the +<code><nobr>RESB</nobr></code> family of pseudo-instructions, and then +invoke <code><nobr>ENDSTRUC</nobr></code> to finish the definition. +<p>For example, to define a structure called +<code><nobr>mytype</nobr></code> containing a longword, a word, a byte and +a string of bytes, you might code +<p><pre> +struc mytype + + mt_long: resd 1 + mt_word: resw 1 + mt_byte: resb 1 + mt_str: resb 32 + +endstruc +</pre> +<p>The above code defines six symbols: <code><nobr>mt_long</nobr></code> as +0 (the offset from the beginning of a <code><nobr>mytype</nobr></code> +structure to the longword field), <code><nobr>mt_word</nobr></code> as 4, +<code><nobr>mt_byte</nobr></code> as 6, <code><nobr>mt_str</nobr></code> as +7, <code><nobr>mytype_size</nobr></code> as 39, and +<code><nobr>mytype</nobr></code> itself as zero. +<p>The reason why the structure type name is defined at zero by default is +a side effect of allowing structures to work with the local label +mechanism: if your structure members tend to have the same names in more +than one structure, you can define the above structure like this: +<p><pre> +struc mytype + + .long: resd 1 + .word: resw 1 + .byte: resb 1 + .str: resb 32 + +endstruc +</pre> +<p>This defines the offsets to the structure fields as +<code><nobr>mytype.long</nobr></code>, +<code><nobr>mytype.word</nobr></code>, +<code><nobr>mytype.byte</nobr></code> and +<code><nobr>mytype.str</nobr></code>. +<p>NASM, since it has no <em>intrinsic</em> structure support, does not +support any form of period notation to refer to the elements of a structure +once you have one (except the above local-label notation), so code such as +<code><nobr>mov ax,[mystruc.mt_word]</nobr></code> is not valid. +<code><nobr>mt_word</nobr></code> is a constant just like any other +constant, so the correct syntax is +<code><nobr>mov ax,[mystruc+mt_word]</nobr></code> or +<code><nobr>mov ax,[mystruc+mytype.word]</nobr></code>. +<p>Sometimes you only have the address of the structure displaced by an +offset. For example, consider this standard stack frame setup: +<p><pre> +push ebp +mov ebp, esp +sub esp, 40 +</pre> +<p>In this case, you could access an element by subtracting the offset: +<p><pre> +mov [ebp - 40 + mytype.word], ax +</pre> +<p>However, if you do not want to repeat this offset, you can use -40 as a +base offset: +<p><pre> +struc mytype, -40 +</pre> +<p>And access an element this way: +<p><pre> +mov [ebp + mytype.word], ax +</pre> +<h4><a name="section-4.11.11">4.11.11 <code><nobr>ISTRUC</nobr></code>, <code><nobr>AT</nobr></code> and <code><nobr>IEND</nobr></code>: Declaring Instances of Structures</a></h4> +<p>Having defined a structure type, the next thing you typically want to do +is to declare instances of that structure in your data segment. NASM +provides an easy way to do this in the <code><nobr>ISTRUC</nobr></code> +mechanism. To declare a structure of type <code><nobr>mytype</nobr></code> +in a program, you code something like this: +<p><pre> +mystruc: + istruc mytype + + at mt_long, dd 123456 + at mt_word, dw 1024 + at mt_byte, db 'x' + at mt_str, db 'hello, world', 13, 10, 0 + + iend +</pre> +<p>The function of the <code><nobr>AT</nobr></code> macro is to make use of +the <code><nobr>TIMES</nobr></code> prefix to advance the assembly position +to the correct point for the specified structure field, and then to declare +the specified data. Therefore the structure fields must be declared in the +same order as they were specified in the structure definition. +<p>If the data to go in a structure field requires more than one source +line to specify, the remaining source lines can easily come after the +<code><nobr>AT</nobr></code> line. For example: +<p><pre> + at mt_str, db 123,134,145,156,167,178,189 + db 190,100,0 +</pre> +<p>Depending on personal taste, you can also omit the code part of the +<code><nobr>AT</nobr></code> line completely, and start the structure field +on the next line: +<p><pre> + at mt_str + db 'hello, world' + db 13,10,0 +</pre> +<h4><a name="section-4.11.12">4.11.12 <code><nobr>ALIGN</nobr></code> and <code><nobr>ALIGNB</nobr></code>: Data Alignment</a></h4> +<p>The <code><nobr>ALIGN</nobr></code> and <code><nobr>ALIGNB</nobr></code> +macros provides a convenient way to align code or data on a word, longword, +paragraph or other boundary. (Some assemblers call this directive +<code><nobr>EVEN</nobr></code>.) The syntax of the +<code><nobr>ALIGN</nobr></code> and <code><nobr>ALIGNB</nobr></code> macros +is +<p><pre> + align 4 ; align on 4-byte boundary + align 16 ; align on 16-byte boundary + align 8,db 0 ; pad with 0s rather than NOPs + align 4,resb 1 ; align to 4 in the BSS + alignb 4 ; equivalent to previous line +</pre> +<p>Both macros require their first argument to be a power of two; they both +compute the number of additional bytes required to bring the length of the +current section up to a multiple of that power of two, and then apply the +<code><nobr>TIMES</nobr></code> prefix to their second argument to perform +the alignment. +<p>If the second argument is not specified, the default for +<code><nobr>ALIGN</nobr></code> is <code><nobr>NOP</nobr></code>, and the +default for <code><nobr>ALIGNB</nobr></code> is +<code><nobr>RESB 1</nobr></code>. So if the second argument is specified, +the two macros are equivalent. Normally, you can just use +<code><nobr>ALIGN</nobr></code> in code and data sections and +<code><nobr>ALIGNB</nobr></code> in BSS sections, and never need the second +argument except for special purposes. +<p><code><nobr>ALIGN</nobr></code> and <code><nobr>ALIGNB</nobr></code>, +being simple macros, perform no error checking: they cannot warn you if +their first argument fails to be a power of two, or if their second +argument generates more than one byte of code. In each of these cases they +will silently do the wrong thing. +<p><code><nobr>ALIGNB</nobr></code> (or <code><nobr>ALIGN</nobr></code> +with a second argument of <code><nobr>RESB 1</nobr></code>) can be used +within structure definitions: +<p><pre> +struc mytype2 + + mt_byte: + resb 1 + alignb 2 + mt_word: + resw 1 + alignb 4 + mt_long: + resd 1 + mt_str: + resb 32 + +endstruc +</pre> +<p>This will ensure that the structure members are sensibly aligned +relative to the base of the structure. +<p>A final caveat: <code><nobr>ALIGN</nobr></code> and +<code><nobr>ALIGNB</nobr></code> work relative to the beginning of the +<em>section</em>, not the beginning of the address space in the final +executable. Aligning to a 16-byte boundary when the section you're in is +only guaranteed to be aligned to a 4-byte boundary, for example, is a waste +of effort. Again, NASM does not check that the section's alignment +characteristics are sensible for the use of <code><nobr>ALIGN</nobr></code> +or <code><nobr>ALIGNB</nobr></code>. +<p>See also the <code><nobr>smartalign</nobr></code> standard macro +package, <a href="nasmdoc5.html#section-5.2">section 5.2</a>. +<p align=center><a href="nasmdoc5.html">Next Chapter</a> | +<a href="nasmdoc3.html">Previous Chapter</a> | +<a href="nasmdoc0.html">Contents</a> | +<a href="nasmdoci.html">Index</a> +</body></html> diff --git a/doc/html/nasmdoc5.html b/doc/html/nasmdoc5.html new file mode 100644 index 0000000..7effbbb --- /dev/null +++ b/doc/html/nasmdoc5.html @@ -0,0 +1,83 @@ +<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: Standard Macro Packages</a></h2> +<p>The <code><nobr>%use</nobr></code> directive (see +<a href="nasmdoc4.html#section-4.6.4">section 4.6.4</a>) includes one of +the standard macro packages included with the NASM distribution and +compiled into the NASM binary. It operates like the +<code><nobr>%include</nobr></code> directive (see +<a href="nasmdoc4.html#section-4.6.1">section 4.6.1</a>), but the included +contents is provided by NASM itself. +<p>The names of standard macro packages are case insensitive, and can be +quoted or not. +<h3><a name="section-5.1">5.1 <code><nobr>altreg</nobr></code>: Alternate Register Names</a></h3> +<p>The <code><nobr>altreg</nobr></code> standard macro package provides +alternate register names. It provides numeric register names for all +registers (not just +<code><nobr>R8</nobr></code>-<code><nobr>R15</nobr></code>), the +Intel-defined aliases +<code><nobr>R8L</nobr></code>-<code><nobr>R15L</nobr></code> for the low +bytes of register (as opposed to the NASM/AMD standard names +<code><nobr>R8B</nobr></code>-<code><nobr>R15B</nobr></code>), and the +names <code><nobr>R0H</nobr></code>-<code><nobr>R3H</nobr></code> (by +analogy with <code><nobr>R0L</nobr></code>-<code><nobr>R3L</nobr></code>) +for <code><nobr>AH</nobr></code>, <code><nobr>CH</nobr></code>, +<code><nobr>DH</nobr></code>, and <code><nobr>BH</nobr></code>. +<p>Example use: +<p><pre> +%use altreg + +proc: + mov r0l,r3h ; mov al,bh + ret +</pre> +<p>See also <a href="nasmdo11.html#section-11.1">section 11.1</a>. +<h3><a name="section-5.2">5.2 <code><nobr>smartalign</nobr></code>: Smart <code><nobr>ALIGN</nobr></code> Macro</a></h3> +<p>The <code><nobr>smartalign</nobr></code> standard macro package provides +for an <code><nobr>ALIGN</nobr></code> macro which is more powerful than +the default (and backwards-compatible) one (see +<a href="nasmdoc4.html#section-4.11.12">section 4.11.12</a>). When the +<code><nobr>smartalign</nobr></code> package is enabled, when +<code><nobr>ALIGN</nobr></code> is used without a second argument, NASM +will generate a sequence of instructions more efficient than a series of +<code><nobr>NOP</nobr></code>. Furthermore, if the padding exceeds a +specific threshold, then NASM will generate a jump over the entire padding +sequence. +<p>The specific instructions generated can be controlled with the new +<code><nobr>ALIGNMODE</nobr></code> macro. This macro takes two parameters: +one mode, and an optional jump threshold override. The modes are as +follows: +<ul> +<li><code><nobr>generic</nobr></code>: Works on all x86 CPUs and should +have reasonable performance. The default jump threshold is 8. This is the +default. +<li><code><nobr>nop</nobr></code>: Pad out with +<code><nobr>NOP</nobr></code> instructions. The only difference compared to +the standard <code><nobr>ALIGN</nobr></code> macro is that NASM can still +jump over a large padding area. The default jump threshold is 16. +<li><code><nobr>k7</nobr></code>: Optimize for the AMD K7 (Athlon/Althon +XP). These instructions should still work on all x86 CPUs. The default jump +threshold is 16. +<li><code><nobr>k8</nobr></code>: Optimize for the AMD K8 (Opteron/Althon +64). These instructions should still work on all x86 CPUs. The default jump +threshold is 16. +<li><code><nobr>p6</nobr></code>: Optimize for Intel CPUs. This uses the +long <code><nobr>NOP</nobr></code> instructions first introduced in Pentium +Pro. This is incompatible with all CPUs of family 5 or lower, as well as +some VIA CPUs and several virtualization solutions. The default jump +threshold is 16. +</ul> +<p>The macro <code><nobr>__ALIGNMODE__</nobr></code> is defined to contain +the current alignment mode. A number of other macros beginning with +<code><nobr>__ALIGN_</nobr></code> are used internally by this macro +package. +<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> diff --git a/doc/html/nasmdoc6.html b/doc/html/nasmdoc6.html new file mode 100644 index 0000000..144a661 --- /dev/null +++ b/doc/html/nasmdoc6.html @@ -0,0 +1,371 @@ +<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: 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="nasmdoc7.html">chapter 7</a>. +<h3><a name="section-6.1">6.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, 32-bit mode or 64-bit mode. The syntax is +<code><nobr>BITS XX</nobr></code>, where XX is 16, 32 or 64. +<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>, +<code><nobr>macho</nobr></code>, <code><nobr>win32</nobr></code> and +<code><nobr>win64</nobr></code> object formats, which are designed for use +in 32-bit or 64-bit operating systems, all cause NASM to select 32-bit or +64-bit mode, respectively, 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 or 64-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> mode, 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> mode, 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>When NASM is in <code><nobr>BITS 64</nobr></code> mode, most +instructions operate the same as they do for +<code><nobr>BITS 32</nobr></code> mode. However, there are 8 more general +and SSE registers, and 16-bit addressing is no longer supported. +<p>The default address size is 64 bits; 32-bit addressing can be selected +with the 0x67 prefix. The default operand size is still 32 bits, however, +and the 0x66 prefix selects 16-bit operand size. The +<code><nobr>REX</nobr></code> prefix is used both to select 64-bit operand +size, and to access the new registers. NASM automatically inserts REX +prefixes when necessary. +<p>When the <code><nobr>REX</nobr></code> prefix is used, the processor +does not know how to address the AH, BH, CH or DH (high 8-bit legacy) +registers. Instead, it is possible to access the the low 8-bits of the SP, +BP SI and DI registers as SPL, BPL, SIL and DIL, respectively; but only +when the REX prefix is used. +<p>The <code><nobr>BITS</nobr></code> directive has an exactly equivalent +primitive form, <code><nobr>[BITS 16]</nobr></code>, +<code><nobr>[BITS 32]</nobr></code> and +<code><nobr>[BITS 64]</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, e.g. <code><nobr>BITS32</nobr></code> +will <em>not</em> work! +<h4><a name="section-6.1.1">6.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-6.2">6.2 <code><nobr>DEFAULT</nobr></code>: Change the assembler defaults</a></h3> +<p>The <code><nobr>DEFAULT</nobr></code> directive changes the assembler +defaults. Normally, NASM defaults to a mode where the programmer is +expected to explicitly specify most features directly. However, this is +occationally obnoxious, as the explicit form is pretty much the only one +one wishes to use. +<p>Currently, the only <code><nobr>DEFAULT</nobr></code> that is settable +is whether or not registerless instructions in 64-bit mode are +<code><nobr>RIP</nobr></code>-relative or not. By default, they are +absolute unless overridden with the <code><nobr>REL</nobr></code> specifier +(see <a href="nasmdoc3.html#section-3.3">section 3.3</a>). However, if +<code><nobr>DEFAULT REL</nobr></code> is specified, +<code><nobr>REL</nobr></code> is default, unless overridden with the +<code><nobr>ABS</nobr></code> specifier, <em>except when used with an FS or +GS segment override</em>. +<p>The special handling of <code><nobr>FS</nobr></code> and +<code><nobr>GS</nobr></code> overrides are due to the fact that these +registers are generally used as thread pointers or other special functions +in 64-bit mode, and generating <code><nobr>RIP</nobr></code>-relative +addresses would be extremely confusing. +<p><code><nobr>DEFAULT REL</nobr></code> is disabled with +<code><nobr>DEFAULT ABS</nobr></code>. +<h3><a name="section-6.3">6.3 <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="nasmdoc7.html#section-7.1.3">section 7.1.3</a>, +all support the standardized section names <code><nobr>.text</nobr></code>, +<code><nobr>.data</nobr></code> and <code><nobr>.bss</nobr></code> for the +code, data and uninitialized-data sections. The +<code><nobr>obj</nobr></code> format, by contrast, does not recognize 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-6.3.1">6.3.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.4">section 4.3.4</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-6.4">6.4 <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-6.5">6.5 <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-6.6">6.6 <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-6.7">6.7 <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 uninitialized 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-6.8">6.8 <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 X64</nobr></code> x86-64 (x64/AMD64/Intel 64) +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. +<h3><a name="section-6.9">6.9 <code><nobr>FLOAT</nobr></code>: Handling of floating-point constants</a></h3> +<p>By default, floating-point constants are rounded to nearest, and IEEE +denormals are supported. The following options can be set to alter this +behaviour: +<ul> +<li><code><nobr>FLOAT DAZ</nobr></code> Flush denormals to zero +<li><code><nobr>FLOAT NODAZ</nobr></code> Do not flush denormals to zero +(default) +<li><code><nobr>FLOAT NEAR</nobr></code> Round to nearest (default) +<li><code><nobr>FLOAT UP</nobr></code> Round up (toward +Infinity) +<li><code><nobr>FLOAT DOWN</nobr></code> Round down (toward -Infinity) +<li><code><nobr>FLOAT ZERO</nobr></code> Round toward zero +<li><code><nobr>FLOAT DEFAULT</nobr></code> Restore default settings +</ul> +<p>The standard macros <code><nobr>__FLOAT_DAZ__</nobr></code>, +<code><nobr>__FLOAT_ROUND__</nobr></code>, and +<code><nobr>__FLOAT__</nobr></code> contain the current state, as long as +the programmer has avoided the use of the brackeded primitive form, +(<code><nobr>[FLOAT]</nobr></code>). +<p><code><nobr>__FLOAT__</nobr></code> contains the full set of +floating-point settings; this value can be saved away and invoked later to +restore the setting. +<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> diff --git a/doc/html/nasmdoc7.html b/doc/html/nasmdoc7.html new file mode 100644 index 0000000..d1339a8 --- /dev/null +++ b/doc/html/nasmdoc7.html @@ -0,0 +1,1267 @@ +<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: 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-7.1">7.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-7.1.3">section +7.1.3</a>. +<p>Using the <code><nobr>bin</nobr></code> format puts NASM by default into +16-bit mode (see <a href="nasmdoc6.html#section-6.1">section 6.1</a>). In +order to use <code><nobr>bin</nobr></code> to write 32-bit or 64-bit code, +such as an OS kernel, you need to explicitly issue the +<code><nobr>BITS 32</nobr></code> or <code><nobr>BITS 64</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-7.1.1">7.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="nasmdoc6.html">chapter 6</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="nasmdo12.html#section-12.1.3">section 12.1.3</a> for further +comments. +<h4><a name="section-7.1.2">7.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-7.1.3">7.1.3 Multisection Support for the <code><nobr>bin</nobr></code> 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-7.1.4">7.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-7.2">7.2 <code><nobr>ith</nobr></code>: Intel Hex Output</a></h3> +<p>The <code><nobr>ith</nobr></code> file format produces Intel hex-format +files. Just as the <code><nobr>bin</nobr></code> format, this is a flat +memory image format with no support for relocation or linking. It is +usually used with ROM programmers and similar utilities. +<p>All extensions supported by the <code><nobr>bin</nobr></code> file +format is also supported by the <code><nobr>ith</nobr></code> file format. +<p><code><nobr>ith</nobr></code> provides a default output file-name +extension of <code><nobr>.ith</nobr></code>. +<h3><a name="section-7.3">7.3 <code><nobr>srec</nobr></code>: Motorola S-Records Output</a></h3> +<p>The <code><nobr>srec</nobr></code> file format produces Motorola +S-records files. Just as the <code><nobr>bin</nobr></code> format, this is +a flat memory image format with no support for relocation or linking. It is +usually used with ROM programmers and similar utilities. +<p>All extensions supported by the <code><nobr>bin</nobr></code> file +format is also supported by the <code><nobr>srec</nobr></code> file format. +<p><code><nobr>srec</nobr></code> provides a default output file-name +extension of <code><nobr>.srec</nobr></code>. +<h3><a name="section-7.4">7.4 <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-7.4.1">7.4.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-7.4.2">7.4.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 uninitialized 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-7.4.3">7.4.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-7.4.4">7.4.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-7.4.5">7.4.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 initialized 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-7.4.6">7.4.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-7.4.7">7.4.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-7.4.8">section 7.4.8</a>. +<h4><a name="section-7.4.8">7.4.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-7.4.7">section 7.4.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-7.5">7.5 <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-7.4">section 7.4</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-7.5.1">7.5.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 +initialized data section, whereas <code><nobr>bss</nobr></code> declares an +uninitialized data section. +<li><code><nobr>rdata</nobr></code> declares an initialized 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>. +<h4><a name="section-7.5.2">7.5.2 <code><nobr>win32</nobr></code>: Safe Structured Exception Handling</a></h4> +<p>Among other improvements in Windows XP SP2 and Windows Server 2003 +Microsoft has introduced concept of "safe structured exception handling." +General idea is to collect handlers' entry points in designated read-only +table and have alleged entry point verified against this table prior +exception control is passed to the handler. In order for an executable +module to be equipped with such "safe exception handler table," all object +modules on linker command line has to comply with certain criteria. If one +single module among them does not, then the table in question is omitted +and above mentioned run-time checks will not be performed for application +in question. Table omission is by default silent and therefore can be +easily overlooked. One can instruct linker to refuse to produce binary +without such table by passing <code><nobr>/safeseh</nobr></code> command +line option. +<p>Without regard to this run-time check merits it's natural to expect NASM +to be capable of generating modules suitable for +<code><nobr>/safeseh</nobr></code> linking. From developer's viewpoint the +problem is two-fold: +<ul> +<li>how to adapt modules not deploying exception handlers of their own; +<li>how to adapt/develop modules utilizing custom exception handling; +</ul> +<p>Former can be easily achieved with any NASM version by adding following +line to source code: +<p><pre> +$@feat.00 equ 1 +</pre> +<p>As of version 2.03 NASM adds this absolute symbol automatically. If it's +not already present to be precise. I.e. if for whatever reason developer +would choose to assign another value in source file, it would still be +perfectly possible. +<p>Registering custom exception handler on the other hand requires certain +"magic." As of version 2.03 additional directive is implemented, +<code><nobr>safeseh</nobr></code>, which instructs the assembler to produce +appropriately formatted input data for above mentioned "safe exception +handler table." Its typical use would be: +<p><pre> +section .text +extern _MessageBoxA@16 +%if __NASM_VERSION_ID__ >= 0x02030000 +safeseh handler ; register handler as "safe handler" +%endif +handler: + push DWORD 1 ; MB_OKCANCEL + push DWORD caption + push DWORD text + push DWORD 0 + call _MessageBoxA@16 + sub eax,1 ; incidentally suits as return value + ; for exception handler + ret +global _main +_main: + push DWORD handler + push DWORD [fs:0] + mov DWORD [fs:0],esp ; engage exception handler + xor eax,eax + mov eax,DWORD[eax] ; cause exception + pop DWORD [fs:0] ; disengage exception handler + add esp,4 + ret +text: db 'OK to rethrow, CANCEL to generate core dump',0 +caption:db 'SEGV',0 + +section .drectve info + db '/defaultlib:user32.lib /defaultlib:msvcrt.lib ' +</pre> +<p>As you might imagine, it's perfectly possible to produce .exe binary +with "safe exception handler table" and yet engage unregistered exception +handler. Indeed, handler is engaged by simply manipulating +<code><nobr>[fs:0]</nobr></code> location at run-time, something linker has +no power over, run-time that is. It should be explicitly mentioned that +such failure to register handler's entry point with +<code><nobr>safeseh</nobr></code> directive has undesired side effect at +run-time. If exception is raised and unregistered handler is to be +executed, the application is abruptly terminated without any notification +whatsoever. One can argue that system could at least have logged some kind +"non-safe exception handler in x.exe at address n" message in event log, +but no, literally no notification is provided and user is left with no clue +on what caused application failure. +<p>Finally, all mentions of linker in this paragraph refer to Microsoft +linker version 7.x and later. Presence of +<code><nobr>@feat.00</nobr></code> symbol and input data for "safe +exception handler table" causes no backward incompatibilities and "safeseh" +modules generated by NASM 2.03 and later can still be linked by earlier +versions or non-Microsoft linkers. +<h3><a name="section-7.6">7.6 <code><nobr>win64</nobr></code>: Microsoft Win64 Object Files</a></h3> +<p>The <code><nobr>win64</nobr></code> output format generates Microsoft +Win64 object files, which is nearly 100% identical to the +<code><nobr>win32</nobr></code> object format +(<a href="#section-7.5">section 7.5</a>) with the exception that it is +meant to target 64-bit code and the x86-64 platform altogether. This object +file is used exactly the same as the <code><nobr>win32</nobr></code> object +format (<a href="#section-7.5">section 7.5</a>), in NASM, with regard to +this exception. +<h4><a name="section-7.6.1">7.6.1 <code><nobr>win64</nobr></code>: Writing Position-Independent Code</a></h4> +<p>While <code><nobr>REL</nobr></code> takes good care of RIP-relative +addressing, there is one aspect that is easy to overlook for a Win64 +programmer: indirect references. Consider a switch dispatch table: +<p><pre> + jmp QWORD[dsptch+rax*8] + ... +dsptch: dq case0 + dq case1 + ... +</pre> +<p>Even novice Win64 assembler programmer will soon realize that the code +is not 64-bit savvy. Most notably linker will refuse to link it with +"<code><nobr>'ADDR32' relocation to '.text' invalid without /LARGEADDRESSAWARE:NO</nobr></code>". +So [s]he will have to split jmp instruction as following: +<p><pre> + lea rbx,[rel dsptch] + jmp QWORD[rbx+rax*8] +</pre> +<p>What happens behind the scene is that effective address in +<code><nobr>lea</nobr></code> is encoded relative to instruction pointer, +or in perfectly position-independent manner. But this is only part of the +problem! Trouble is that in .dll context <code><nobr>caseN</nobr></code> +relocations will make their way to the final module and might have to be +adjusted at .dll load time. To be specific when it can't be loaded at +preferred address. And when this occurs, pages with such relocations will +be rendered private to current process, which kind of undermines the idea +of sharing .dll. But no worry, it's trivial to fix: +<p><pre> + lea rbx,[rel dsptch] + add rbx,QWORD[rbx+rax*8] + jmp rbx + ... +dsptch: dq case0-dsptch + dq case1-dsptch + ... +</pre> +<p>NASM version 2.03 and later provides another alternative, +<code><nobr>wrt ..imagebase</nobr></code> operator, which returns offset +from base address of the current image, be it .exe or .dll module, +therefore the name. For those acquainted with PE-COFF format base address +denotes start of <code><nobr>IMAGE_DOS_HEADER</nobr></code> structure. Here +is how to implement switch with these image-relative references: +<p><pre> + lea rbx,[rel dsptch] + mov eax,DWORD[rbx+rax*4] + sub rbx,dsptch wrt ..imagebase + add rbx,rax + jmp rbx + ... +dsptch: dd case0 wrt ..imagebase + dd case1 wrt ..imagebase +</pre> +<p>One can argue that the operator is redundant. Indeed, snippet before +last works just fine with any NASM version and is not even Windows +specific... The real reason for implementing +<code><nobr>wrt ..imagebase</nobr></code> will become apparent in next +paragraph. +<p>It should be noted that <code><nobr>wrt ..imagebase</nobr></code> is +defined as 32-bit operand only: +<p><pre> + dd label wrt ..imagebase ; ok + dq label wrt ..imagebase ; bad + mov eax,label wrt ..imagebase ; ok + mov rax,label wrt ..imagebase ; bad +</pre> +<h4><a name="section-7.6.2">7.6.2 <code><nobr>win64</nobr></code>: Structured Exception Handling</a></h4> +<p>Structured exception handing in Win64 is completely different matter +from Win32. Upon exception program counter value is noted, and +linker-generated table comprising start and end addresses of all the +functions [in given executable module] is traversed and compared to the +saved program counter. Thus so called <code><nobr>UNWIND_INFO</nobr></code> +structure is identified. If it's not found, then offending subroutine is +assumed to be "leaf" and just mentioned lookup procedure is attempted for +its caller. In Win64 leaf function is such function that does not call any +other function <em>nor</em> modifies any Win64 non-volatile registers, +including stack pointer. The latter ensures that it's possible to identify +leaf function's caller by simply pulling the value from the top of the +stack. +<p>While majority of subroutines written in assembler are not calling any +other function, requirement for non-volatile registers' immutability leaves +developer with not more than 7 registers and no stack frame, which is not +necessarily what [s]he counted with. Customarily one would meet the +requirement by saving non-volatile registers on stack and restoring them +upon return, so what can go wrong? If [and only if] an exception is raised +at run-time and no <code><nobr>UNWIND_INFO</nobr></code> structure is +associated with such "leaf" function, the stack unwind procedure will +expect to find caller's return address on the top of stack immediately +followed by its frame. Given that developer pushed caller's non-volatile +registers on stack, would the value on top point at some code segment or +even addressable space? Well, developer can attempt copying caller's return +address to the top of stack and this would actually work in some very +specific circumstances. But unless developer can guarantee that these +circumstances are always met, it's more appropriate to assume worst case +scenario, i.e. stack unwind procedure going berserk. Relevant question is +what happens then? Application is abruptly terminated without any +notification whatsoever. Just like in Win32 case, one can argue that system +could at least have logged "unwind procedure went berserk in x.exe at +address n" in event log, but no, no trace of failure is left. +<p>Now, when we understand significance of the +<code><nobr>UNWIND_INFO</nobr></code> structure, let's discuss what's in it +and/or how it's processed. First of all it is checked for presence of +reference to custom language-specific exception handler. If there is one, +then it's invoked. Depending on the return value, execution flow is resumed +(exception is said to be "handled"), <em>or</em> rest of +<code><nobr>UNWIND_INFO</nobr></code> structure is processed as following. +Beside optional reference to custom handler, it carries information about +current callee's stack frame and where non-volatile registers are saved. +Information is detailed enough to be able to reconstruct contents of +caller's non-volatile registers upon call to current callee. And so +caller's context is reconstructed, and then unwind procedure is repeated, +i.e. another <code><nobr>UNWIND_INFO</nobr></code> structure is associated, +this time, with caller's instruction pointer, which is then checked for +presence of reference to language-specific handler, etc. The procedure is +recursively repeated till exception is handled. As last resort system +"handles" it by generating memory core dump and terminating the +application. +<p>As for the moment of this writing NASM unfortunately does not facilitate +generation of above mentioned detailed information about stack frame +layout. But as of version 2.03 it implements building blocks for generating +structures involved in stack unwinding. As simplest example, here is how to +deploy custom exception handler for leaf function: +<p><pre> +default rel +section .text +extern MessageBoxA +handler: + sub rsp,40 + mov rcx,0 + lea rdx,[text] + lea r8,[caption] + mov r9,1 ; MB_OKCANCEL + call MessageBoxA + sub eax,1 ; incidentally suits as return value + ; for exception handler + add rsp,40 + ret +global main +main: + xor rax,rax + mov rax,QWORD[rax] ; cause exception + ret +main_end: +text: db 'OK to rethrow, CANCEL to generate core dump',0 +caption:db 'SEGV',0 + +section .pdata rdata align=4 + dd main wrt ..imagebase + dd main_end wrt ..imagebase + dd xmain wrt ..imagebase +section .xdata rdata align=8 +xmain: db 9,0,0,0 + dd handler wrt ..imagebase +section .drectve info + db '/defaultlib:user32.lib /defaultlib:msvcrt.lib ' +</pre> +<p>What you see in <code><nobr>.pdata</nobr></code> section is element of +the "table comprising start and end addresses of function" along with +reference to associated <code><nobr>UNWIND_INFO</nobr></code> structure. +And what you see in <code><nobr>.xdata</nobr></code> section is +<code><nobr>UNWIND_INFO</nobr></code> structure describing function with no +frame, but with designated exception handler. References are +<em>required</em> to be image-relative (which is the real reason for +implementing <code><nobr>wrt ..imagebase</nobr></code> operator). It should +be noted that <code><nobr>rdata align=n</nobr></code>, as well as +<code><nobr>wrt ..imagebase</nobr></code>, are optional in these two +segments' contexts, i.e. can be omitted. Latter means that <em>all</em> +32-bit references, not only above listed required ones, placed into these +two segments turn out image-relative. Why is it important to understand? +Developer is allowed to append handler-specific data to +<code><nobr>UNWIND_INFO</nobr></code> structure, and if [s]he adds a 32-bit +reference, then [s]he will have to remember to adjust its value to obtain +the real pointer. +<p>As already mentioned, in Win64 terms leaf function is one that does not +call any other function <em>nor</em> modifies any non-volatile register, +including stack pointer. But it's not uncommon that assembler programmer +plans to utilize every single register and sometimes even have variable +stack frame. Is there anything one can do with bare building blocks? I.e. +besides manually composing fully-fledged +<code><nobr>UNWIND_INFO</nobr></code> structure, which would surely be +considered error-prone? Yes, there is. Recall that exception handler is +called first, before stack layout is analyzed. As it turned out, it's +perfectly possible to manipulate current callee's context in custom handler +in manner that permits further stack unwinding. General idea is that +handler would not actually "handle" the exception, but instead restore +callee's context, as it was at its entry point and thus mimic leaf +function. In other words, handler would simply undertake part of unwinding +procedure. Consider following example: +<p><pre> +function: + mov rax,rsp ; copy rsp to volatile register + push r15 ; save non-volatile registers + push rbx + push rbp + mov r11,rsp ; prepare variable stack frame + sub r11,rcx + and r11,-64 + mov QWORD[r11],rax ; check for exceptions + mov rsp,r11 ; allocate stack frame + mov QWORD[rsp],rax ; save original rsp value +magic_point: + ... + mov r11,QWORD[rsp] ; pull original rsp value + mov rbp,QWORD[r11-24] + mov rbx,QWORD[r11-16] + mov r15,QWORD[r11-8] + mov rsp,r11 ; destroy frame + ret +</pre> +<p>The keyword is that up to <code><nobr>magic_point</nobr></code> original +<code><nobr>rsp</nobr></code> value remains in chosen volatile register and +no non-volatile register, except for <code><nobr>rsp</nobr></code>, is +modified. While past <code><nobr>magic_point</nobr></code> +<code><nobr>rsp</nobr></code> remains constant till the very end of the +<code><nobr>function</nobr></code>. In this case custom language-specific +exception handler would look like this: +<p><pre> +EXCEPTION_DISPOSITION handler (EXCEPTION_RECORD *rec,ULONG64 frame, + CONTEXT *context,DISPATCHER_CONTEXT *disp) +{ ULONG64 *rsp; + if (context->Rip<(ULONG64)magic_point) + rsp = (ULONG64 *)context->Rax; + else + { rsp = ((ULONG64 **)context->Rsp)[0]; + context->Rbp = rsp[-3]; + context->Rbx = rsp[-2]; + context->R15 = rsp[-1]; + } + context->Rsp = (ULONG64)rsp; + + memcpy (disp->ContextRecord,context,sizeof(CONTEXT)); + RtlVirtualUnwind(UNW_FLAG_NHANDLER,disp->ImageBase, + dips->ControlPc,disp->FunctionEntry,disp->ContextRecord, + &disp->HandlerData,&disp->EstablisherFrame,NULL); + return ExceptionContinueSearch; +} +</pre> +<p>As custom handler mimics leaf function, corresponding +<code><nobr>UNWIND_INFO</nobr></code> structure does not have to contain +any information about stack frame and its layout. +<h3><a name="section-7.7">7.7 <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-7.8">7.8 <code><nobr>macho32</nobr></code> and <code><nobr>macho64</nobr></code>: Mach Object File Format</a></h3> +<p>The <code><nobr>macho32</nobr></code> and +<code><nobr>macho64</nobr></code> output formts produces +<code><nobr>Mach-O</nobr></code> object files suitable for linking with the +MacOS X linker. <code><nobr>macho</nobr></code> is a synonym for +<code><nobr>macho32</nobr></code>. +<p><code><nobr>macho</nobr></code> provides a default output file-name +extension of <code><nobr>.o</nobr></code>. +<h3><a name="section-7.9">7.9 <code><nobr>elf32</nobr></code> and <code><nobr>elf64</nobr></code>: Executable and Linkable Format Object Files</a></h3> +<p>The <code><nobr>elf32</nobr></code> and <code><nobr>elf64</nobr></code> +output formats generate <code><nobr>ELF32 and ELF64</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>. <code><nobr>elf</nobr></code> is a synonym +for <code><nobr>elf32</nobr></code>. +<h4><a name="section-7.9.1">7.9.1 ELF specific directive <code><nobr>osabi</nobr></code></a></h4> +<p>The ELF header specifies the application binary interface for the target +operating system (OSABI). This field can be set by using the +<code><nobr>osabi</nobr></code> directive with the numeric value (0-255) of +the target system. If this directive is not used, the default value will be +"UNIX System V ABI" (0) which will work on most systems which support ELF. +<h4><a name="section-7.9.2">7.9.2 <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, 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. +<li><code><nobr>tls</nobr></code> defines the section to be one which +contains thread local variables. +</ul> +<p>The defaults assumed by NASM if you do not specify the above qualifiers +are: +<p> +<p><pre> +section .text progbits alloc exec nowrite align=16 +section .rodata progbits alloc noexec nowrite align=4 +section .lrodata progbits alloc noexec nowrite align=4 +section .data progbits alloc noexec write align=4 +section .ldata progbits alloc noexec write align=4 +section .bss nobits alloc noexec write align=4 +section .lbss nobits alloc noexec write align=4 +section .tdata progbits alloc noexec write align=4 tls +section .tbss nobits alloc noexec write align=4 tls +section .comment progbits noalloc noexec nowrite align=1 +section other progbits alloc noexec nowrite align=1 +</pre> +<p>(Any section name other than those in the above table is treated by +default like <code><nobr>other</nobr></code> in the above table. Please +note that section names are case sensitive.) +<h4><a name="section-7.9.3">7.9.3 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 ELF specific 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 summarized 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="nasmdoc9.html#section-9.2">section 9.2</a>. +<h4><a name="section-7.9.4">7.9.4 Thread Local Storage: <code><nobr>elf</nobr></code> Special Symbols and <code><nobr>WRT</nobr></code></a></h4> +<ul> +<li>In ELF32 mode, referring to an external or global symbol using +<code><nobr>wrt ..tlsie</nobr></code> causes the linker to build an entry +<em>in</em> the GOT containing the offset of the symbol within the TLS +block, so you can access the value of the symbol with code such as: +</ul> +<p><pre> + mov eax,[tid wrt ..tlsie] + mov [gs:eax],ebx +</pre> +<ul> +<li>In ELF64 mode, referring to an external or global symbol using +<code><nobr>wrt ..gottpoff</nobr></code> causes the linker to build an +entry <em>in</em> the GOT containing the offset of the symbol within the +TLS block, so you can access the value of the symbol with code such as: +</ul> +<p><pre> + mov rax,[rel tid wrt ..gottpoff] + mov rcx,[fs:rax] +</pre> +<h4><a name="section-7.9.5">7.9.5 <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>Optionally, you can control the ELF visibility of the symbol. Just add +one of the visibility keywords: <code><nobr>default</nobr></code>, +<code><nobr>internal</nobr></code>, <code><nobr>hidden</nobr></code>, or +<code><nobr>protected</nobr></code>. The default is +<code><nobr>default</nobr></code> of course. For example, to make +<code><nobr>hashlookup</nobr></code> hidden: +<p><pre> +global hashlookup:function hidden +</pre> +<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="nasmdoc9.html#section-9.2.4">section 9.2.4</a>. +<h4><a name="section-7.9.6">7.9.6 <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-7.9.7">7.9.7 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. +<h4><a name="section-7.9.8">7.9.8 Debug formats and ELF </a></h4> +<p><code><nobr>ELF32</nobr></code> and <code><nobr>ELF64</nobr></code> +provide debug information in <code><nobr>STABS</nobr></code> and +<code><nobr>DWARF</nobr></code> formats. Line number information is +generated for all executable sections, but please note that only the +".text" section is executable by default. +<h3><a name="section-7.10">7.10 <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-7.9">section 7.9</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-7.11">7.11 <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-7.9.3">section 7.9.3</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-7.9.5">section 7.9.5</a> for documentation of +this. +<h3><a name="section-7.12">7.12 <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 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>. The +only special symbol supported is <code><nobr>..start</nobr></code>. +<h3><a name="section-7.13">7.13 <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-7.13.1">7.13.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-7.13.2">7.13.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-7.13.3">7.13.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> +<h4><a name="section-7.13.4">7.13.4 <code><nobr>rdf</nobr></code> Extensions to the <code><nobr>EXTERN</nobr></code> Directive</a></h4> +<p>By default the <code><nobr>EXTERN</nobr></code> directive in +<code><nobr>RDOFF</nobr></code> declares a "pure external" symbol (i.e. the +static linker will complain if such a symbol is not resolved). To declare +an "imported" symbol, which must be resolved later during a dynamic linking +phase, <code><nobr>RDOFF</nobr></code> offers an additional +<code><nobr>import</nobr></code> modifier. As in +<code><nobr>GLOBAL</nobr></code>, you can also specify whether an imported +symbol is a procedure (function) or data object. For example: +<p><pre> + library $libc + extern _open:import + extern _printf:import proc + extern _errno:import data +</pre> +<p>Here the directive <code><nobr>LIBRARY</nobr></code> is also included, +which gives the dynamic linker a hint as to where to find requested +symbols. +<h3><a name="section-7.14">7.14 <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>output/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="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> diff --git a/doc/html/nasmdoc8.html b/doc/html/nasmdoc8.html new file mode 100644 index 0000000..a7c2869 --- /dev/null +++ b/doc/html/nasmdoc8.html @@ -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="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 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-8.1">8.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-8.1.1">8.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="nasmdoc7.html#section-7.4.6">section 7.4.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 initializes <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 +uninitialized 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-8.1.2">8.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-8.2">8.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-8.2.1">8.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 uninitialized 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 (uninitialized 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 initialized 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-8.2.2">8.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-8.3">8.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-8.4">8.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-8.4.1">8.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.27">section 2.1.27</a>. +<h4><a name="section-8.4.2">8.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-8.4.3">8.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-8.5.1">section 8.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 initialize 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-8.4.4">8.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-8.4.1">section 8.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 organizes 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-8.4.5">8.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.8">section 4.8</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-8.5">8.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-8.5.1">8.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-8.5.2">8.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>initialized 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>Uninitialized 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-8.5.3">8.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-8.4.5">section 8.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-8.4.5">section 8.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="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> diff --git a/doc/html/nasmdoc9.html b/doc/html/nasmdoc9.html new file mode 100644 index 0000000..811af7c --- /dev/null +++ b/doc/html/nasmdoc9.html @@ -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="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: 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-9.1">9.1 Interfacing to 32-bit C Programs</a></h3> +<p>A lot of the discussion in <a href="nasmdoc8.html#section-8.4">section +8.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-9.1.1">9.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="nasmdoc8.html#section-8.4.1">section 8.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.27">section 2.1.27</a>. +<h4><a name="section-9.1.2">9.1.2 Function Definitions and Function Calls</a></h4> +<p>The 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-9.1.3">9.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-9.1.1">section 9.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 organizes 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-9.1.4">9.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-9.2">9.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-9.2.4">section 9.2.4</a> for a caveat). +<h4><a name="section-9.2.1">9.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-9.2.2">9.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-9.2.3">9.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-9.2.4">9.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-9.2.5">9.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-9.2.6">9.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="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> diff --git a/doc/html/nasmdoca.html b/doc/html/nasmdoca.html new file mode 100644 index 0000000..fda553d --- /dev/null +++ b/doc/html/nasmdoca.html @@ -0,0 +1,165 @@ +<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="nasmdo12.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 -b {16|32|64} filename +</pre> +<p>NDISASM can disassemble 16-, 32- or 64-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 +2147483647 sync points internally). The definition of a sync point is this: +NDISASM guarantees to hit sync points exactly during disassembly. If it is +thinking about generating an instruction which 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 synchronize 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:nasm-bugs@lists.sourceforge.net"><code><nobr>nasm-bugs@lists.sourceforge.net</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 align=center><a href="nasmdocb.html">Next Chapter</a> | +<a href="nasmdo12.html">Previous Chapter</a> | +<a href="nasmdoc0.html">Contents</a> | +<a href="nasmdoci.html">Index</a> +</body></html> diff --git a/doc/html/nasmdocb.html b/doc/html/nasmdocb.html new file mode 100644 index 0000000..15bca45 --- /dev/null +++ b/doc/html/nasmdocb.html @@ -0,0 +1,3148 @@ +<html><head><title>NASM Manual</title></head> +<body><h1 align=center>The Netwide Assembler: NASM</h1> + +<p align=center><a href="nasmdocc.html">Next Chapter</a> | +<a href="nasmdoca.html">Previous Chapter</a> | +<a href="nasmdoc0.html">Contents</a> | +<a href="nasmdoci.html">Index</a> +<h2><a name="appendix-B">Appendix B: Instruction List</a></h2> +<h3><a name="section-B.1">B.1 Introduction</a></h3> +<p>The following sections show the instructions which NASM currently +supports. For each instruction, there is a separate entry for each +supported addressing mode. The third column shows the processor type in +which the instruction was introduced and, when appropriate, one or more +usage flags. +<h4><a name="section-B.1.1">B.1.1 Special instructions...</a></h4> +<p><pre> +DB +DW +DD +DQ +DT +DO +DY +RESB imm 8086 +RESW +RESD +RESQ +REST +RESO +RESY +</pre> +<h4><a name="section-B.1.2">B.1.2 Conventional instructions</a></h4> +<p><pre> +AAA 8086,NOLONG +AAD 8086,NOLONG +AAD imm 8086,NOLONG +AAM 8086,NOLONG +AAM imm 8086,NOLONG +AAS 8086,NOLONG +ADC mem,reg8 8086 +ADC reg8,reg8 8086 +ADC mem,reg16 8086 +ADC reg16,reg16 8086 +ADC mem,reg32 386 +ADC reg32,reg32 386 +ADC mem,reg64 X64 +ADC reg64,reg64 X64 +ADC reg8,mem 8086 +ADC reg8,reg8 8086 +ADC reg16,mem 8086 +ADC reg16,reg16 8086 +ADC reg32,mem 386 +ADC reg32,reg32 386 +ADC reg64,mem X64 +ADC reg64,reg64 X64 +ADC rm16,imm8 8086 +ADC rm32,imm8 386 +ADC rm64,imm8 X64 +ADC reg_al,imm 8086 +ADC reg_ax,sbyte16 8086 +ADC reg_ax,imm 8086 +ADC reg_eax,sbyte32 386 +ADC reg_eax,imm 386 +ADC reg_rax,sbyte64 X64 +ADC reg_rax,imm X64 +ADC rm8,imm 8086 +ADC rm16,imm 8086 +ADC rm32,imm 386 +ADC rm64,imm X64 +ADC mem,imm8 8086 +ADC mem,imm16 8086 +ADC mem,imm32 386 +ADD mem,reg8 8086 +ADD reg8,reg8 8086 +ADD mem,reg16 8086 +ADD reg16,reg16 8086 +ADD mem,reg32 386 +ADD reg32,reg32 386 +ADD mem,reg64 X64 +ADD reg64,reg64 X64 +ADD reg8,mem 8086 +ADD reg8,reg8 8086 +ADD reg16,mem 8086 +ADD reg16,reg16 8086 +ADD reg32,mem 386 +ADD reg32,reg32 386 +ADD reg64,mem X64 +ADD reg64,reg64 X64 +ADD rm16,imm8 8086 +ADD rm32,imm8 386 +ADD rm64,imm8 X64 +ADD reg_al,imm 8086 +ADD reg_ax,sbyte16 8086 +ADD reg_ax,imm 8086 +ADD reg_eax,sbyte32 386 +ADD reg_eax,imm 386 +ADD reg_rax,sbyte64 X64 +ADD reg_rax,imm X64 +ADD rm8,imm 8086 +ADD rm16,imm 8086 +ADD rm32,imm 386 +ADD rm64,imm X64 +ADD mem,imm8 8086 +ADD mem,imm16 8086 +ADD mem,imm32 386 +AND mem,reg8 8086 +AND reg8,reg8 8086 +AND mem,reg16 8086 +AND reg16,reg16 8086 +AND mem,reg32 386 +AND reg32,reg32 386 +AND mem,reg64 X64 +AND reg64,reg64 X64 +AND reg8,mem 8086 +AND reg8,reg8 8086 +AND reg16,mem 8086 +AND reg16,reg16 8086 +AND reg32,mem 386 +AND reg32,reg32 386 +AND reg64,mem X64 +AND reg64,reg64 X64 +AND rm16,imm8 8086 +AND rm32,imm8 386 +AND rm64,imm8 X64 +AND reg_al,imm 8086 +AND reg_ax,sbyte16 8086 +AND reg_ax,imm 8086 +AND reg_eax,sbyte32 386 +AND reg_eax,imm 386 +AND reg_rax,sbyte64 X64 +AND reg_rax,imm X64 +AND rm8,imm 8086 +AND rm16,imm 8086 +AND rm32,imm 386 +AND rm64,imm X64 +AND mem,imm8 8086 +AND mem,imm16 8086 +AND mem,imm32 386 +ARPL mem,reg16 286,PROT,NOLONG +ARPL reg16,reg16 286,PROT,NOLONG +BB0_RESET PENT,CYRIX,ND +BB1_RESET PENT,CYRIX,ND +BOUND reg16,mem 186,NOLONG +BOUND reg32,mem 386,NOLONG +BSF reg16,mem 386 +BSF reg16,reg16 386 +BSF reg32,mem 386 +BSF reg32,reg32 386 +BSF reg64,mem X64 +BSF reg64,reg64 X64 +BSR reg16,mem 386 +BSR reg16,reg16 386 +BSR reg32,mem 386 +BSR reg32,reg32 386 +BSR reg64,mem X64 +BSR reg64,reg64 X64 +BSWAP reg32 486 +BSWAP reg64 X64 +BT mem,reg16 386 +BT reg16,reg16 386 +BT mem,reg32 386 +BT reg32,reg32 386 +BT mem,reg64 X64 +BT reg64,reg64 X64 +BT rm16,imm 386 +BT rm32,imm 386 +BT rm64,imm X64 +BTC mem,reg16 386 +BTC reg16,reg16 386 +BTC mem,reg32 386 +BTC reg32,reg32 386 +BTC mem,reg64 X64 +BTC reg64,reg64 X64 +BTC rm16,imm 386 +BTC rm32,imm 386 +BTC rm64,imm X64 +BTR mem,reg16 386 +BTR reg16,reg16 386 +BTR mem,reg32 386 +BTR reg32,reg32 386 +BTR mem,reg64 X64 +BTR reg64,reg64 X64 +BTR rm16,imm 386 +BTR rm32,imm 386 +BTR rm64,imm X64 +BTS mem,reg16 386 +BTS reg16,reg16 386 +BTS mem,reg32 386 +BTS reg32,reg32 386 +BTS mem,reg64 X64 +BTS reg64,reg64 X64 +BTS rm16,imm 386 +BTS rm32,imm 386 +BTS rm64,imm X64 +CALL imm 8086 +CALL imm|near 8086 +CALL imm|far 8086,ND,NOLONG +CALL imm16 8086 +CALL imm16|near 8086 +CALL imm16|far 8086,ND,NOLONG +CALL imm32 386 +CALL imm32|near 386 +CALL imm32|far 386,ND,NOLONG +CALL imm:imm 8086,NOLONG +CALL imm16:imm 8086,NOLONG +CALL imm:imm16 8086,NOLONG +CALL imm32:imm 386,NOLONG +CALL imm:imm32 386,NOLONG +CALL mem|far 8086,NOLONG +CALL mem|far X64 +CALL mem16|far 8086 +CALL mem32|far 386 +CALL mem64|far X64 +CALL mem|near 8086 +CALL mem16|near 8086 +CALL mem32|near 386,NOLONG +CALL mem64|near X64 +CALL reg16 8086 +CALL reg32 386,NOLONG +CALL reg64 X64 +CALL mem 8086 +CALL mem16 8086 +CALL mem32 386,NOLONG +CALL mem64 X64 +CBW 8086 +CDQ 386 +CDQE X64 +CLC 8086 +CLD 8086 +CLGI X64,AMD +CLI 8086 +CLTS 286,PRIV +CMC 8086 +CMP mem,reg8 8086 +CMP reg8,reg8 8086 +CMP mem,reg16 8086 +CMP reg16,reg16 8086 +CMP mem,reg32 386 +CMP reg32,reg32 386 +CMP mem,reg64 X64 +CMP reg64,reg64 X64 +CMP reg8,mem 8086 +CMP reg8,reg8 8086 +CMP reg16,mem 8086 +CMP reg16,reg16 8086 +CMP reg32,mem 386 +CMP reg32,reg32 386 +CMP reg64,mem X64 +CMP reg64,reg64 X64 +CMP rm16,imm8 8086 +CMP rm32,imm8 386 +CMP rm64,imm8 X64 +CMP reg_al,imm 8086 +CMP reg_ax,sbyte16 8086 +CMP reg_ax,imm 8086 +CMP reg_eax,sbyte32 386 +CMP reg_eax,imm 386 +CMP reg_rax,sbyte64 X64 +CMP reg_rax,imm X64 +CMP rm8,imm 8086 +CMP rm16,imm 8086 +CMP rm32,imm 386 +CMP rm64,imm X64 +CMP mem,imm8 8086 +CMP mem,imm16 8086 +CMP mem,imm32 386 +CMPSB 8086 +CMPSD 386 +CMPSQ X64 +CMPSW 8086 +CMPXCHG mem,reg8 PENT +CMPXCHG reg8,reg8 PENT +CMPXCHG mem,reg16 PENT +CMPXCHG reg16,reg16 PENT +CMPXCHG mem,reg32 PENT +CMPXCHG reg32,reg32 PENT +CMPXCHG mem,reg64 X64 +CMPXCHG reg64,reg64 X64 +CMPXCHG486 mem,reg8 486,UNDOC,ND +CMPXCHG486 reg8,reg8 486,UNDOC,ND +CMPXCHG486 mem,reg16 486,UNDOC,ND +CMPXCHG486 reg16,reg16 486,UNDOC,ND +CMPXCHG486 mem,reg32 486,UNDOC,ND +CMPXCHG486 reg32,reg32 486,UNDOC,ND +CMPXCHG8B mem PENT +CMPXCHG16B mem X64 +CPUID PENT +CPU_READ PENT,CYRIX +CPU_WRITE PENT,CYRIX +CQO X64 +CWD 8086 +CWDE 386 +DAA 8086,NOLONG +DAS 8086,NOLONG +DEC reg16 8086,NOLONG +DEC reg32 386,NOLONG +DEC rm8 8086 +DEC rm16 8086 +DEC rm32 386 +DEC rm64 X64 +DIV rm8 8086 +DIV rm16 8086 +DIV rm32 386 +DIV rm64 X64 +DMINT P6,CYRIX +EMMS PENT,MMX +ENTER imm,imm 186 +EQU imm 8086 +EQU imm:imm 8086 +F2XM1 8086,FPU +FABS 8086,FPU +FADD mem32 8086,FPU +FADD mem64 8086,FPU +FADD fpureg|to 8086,FPU +FADD fpureg 8086,FPU +FADD fpureg,fpu0 8086,FPU +FADD fpu0,fpureg 8086,FPU +FADD 8086,FPU,ND +FADDP fpureg 8086,FPU +FADDP fpureg,fpu0 8086,FPU +FADDP 8086,FPU,ND +FBLD mem80 8086,FPU +FBLD mem 8086,FPU +FBSTP mem80 8086,FPU +FBSTP mem 8086,FPU +FCHS 8086,FPU +FCLEX 8086,FPU +FCMOVB fpureg P6,FPU +FCMOVB fpu0,fpureg P6,FPU +FCMOVB P6,FPU,ND +FCMOVBE fpureg P6,FPU +FCMOVBE fpu0,fpureg P6,FPU +FCMOVBE P6,FPU,ND +FCMOVE fpureg P6,FPU +FCMOVE fpu0,fpureg P6,FPU +FCMOVE P6,FPU,ND +FCMOVNB fpureg P6,FPU +FCMOVNB fpu0,fpureg P6,FPU +FCMOVNB P6,FPU,ND +FCMOVNBE fpureg P6,FPU +FCMOVNBE fpu0,fpureg P6,FPU +FCMOVNBE P6,FPU,ND +FCMOVNE fpureg P6,FPU +FCMOVNE fpu0,fpureg P6,FPU +FCMOVNE P6,FPU,ND +FCMOVNU fpureg P6,FPU +FCMOVNU fpu0,fpureg P6,FPU +FCMOVNU P6,FPU,ND +FCMOVU fpureg P6,FPU +FCMOVU fpu0,fpureg P6,FPU +FCMOVU P6,FPU,ND +FCOM mem32 8086,FPU +FCOM mem64 8086,FPU +FCOM fpureg 8086,FPU +FCOM fpu0,fpureg 8086,FPU +FCOM 8086,FPU,ND +FCOMI fpureg P6,FPU +FCOMI fpu0,fpureg P6,FPU +FCOMI P6,FPU,ND +FCOMIP fpureg P6,FPU +FCOMIP fpu0,fpureg P6,FPU +FCOMIP P6,FPU,ND +FCOMP mem32 8086,FPU +FCOMP mem64 8086,FPU +FCOMP fpureg 8086,FPU +FCOMP fpu0,fpureg 8086,FPU +FCOMP 8086,FPU,ND +FCOMPP 8086,FPU +FCOS 386,FPU +FDECSTP 8086,FPU +FDISI 8086,FPU +FDIV mem32 8086,FPU +FDIV mem64 8086,FPU +FDIV fpureg|to 8086,FPU +FDIV fpureg 8086,FPU +FDIV fpureg,fpu0 8086,FPU +FDIV fpu0,fpureg 8086,FPU +FDIV 8086,FPU,ND +FDIVP fpureg 8086,FPU +FDIVP fpureg,fpu0 8086,FPU +FDIVP 8086,FPU,ND +FDIVR mem32 8086,FPU +FDIVR mem64 8086,FPU +FDIVR fpureg|to 8086,FPU +FDIVR fpureg,fpu0 8086,FPU +FDIVR fpureg 8086,FPU +FDIVR fpu0,fpureg 8086,FPU +FDIVR 8086,FPU,ND +FDIVRP fpureg 8086,FPU +FDIVRP fpureg,fpu0 8086,FPU +FDIVRP 8086,FPU,ND +FEMMS PENT,3DNOW +FENI 8086,FPU +FFREE fpureg 8086,FPU +FFREE 8086,FPU +FFREEP fpureg 286,FPU,UNDOC +FFREEP 286,FPU,UNDOC +FIADD mem32 8086,FPU +FIADD mem16 8086,FPU +FICOM mem32 8086,FPU +FICOM mem16 8086,FPU +FICOMP mem32 8086,FPU +FICOMP mem16 8086,FPU +FIDIV mem32 8086,FPU +FIDIV mem16 8086,FPU +FIDIVR mem32 8086,FPU +FIDIVR mem16 8086,FPU +FILD mem32 8086,FPU +FILD mem16 8086,FPU +FILD mem64 8086,FPU +FIMUL mem32 8086,FPU +FIMUL mem16 8086,FPU +FINCSTP 8086,FPU +FINIT 8086,FPU +FIST mem32 8086,FPU +FIST mem16 8086,FPU +FISTP mem32 8086,FPU +FISTP mem16 8086,FPU +FISTP mem64 8086,FPU +FISTTP mem16 PRESCOTT,FPU +FISTTP mem32 PRESCOTT,FPU +FISTTP mem64 PRESCOTT,FPU +FISUB mem32 8086,FPU +FISUB mem16 8086,FPU +FISUBR mem32 8086,FPU +FISUBR mem16 8086,FPU +FLD mem32 8086,FPU +FLD mem64 8086,FPU +FLD mem80 8086,FPU +FLD fpureg 8086,FPU +FLD 8086,FPU,ND +FLD1 8086,FPU +FLDCW mem 8086,FPU,SW +FLDENV mem 8086,FPU +FLDL2E 8086,FPU +FLDL2T 8086,FPU +FLDLG2 8086,FPU +FLDLN2 8086,FPU +FLDPI 8086,FPU +FLDZ 8086,FPU +FMUL mem32 8086,FPU +FMUL mem64 8086,FPU +FMUL fpureg|to 8086,FPU +FMUL fpureg,fpu0 8086,FPU +FMUL fpureg 8086,FPU +FMUL fpu0,fpureg 8086,FPU +FMUL 8086,FPU,ND +FMULP fpureg 8086,FPU +FMULP fpureg,fpu0 8086,FPU +FMULP 8086,FPU,ND +FNCLEX 8086,FPU +FNDISI 8086,FPU +FNENI 8086,FPU +FNINIT 8086,FPU +FNOP 8086,FPU +FNSAVE mem 8086,FPU +FNSTCW mem 8086,FPU,SW +FNSTENV mem 8086,FPU +FNSTSW mem 8086,FPU,SW +FNSTSW reg_ax 286,FPU +FPATAN 8086,FPU +FPREM 8086,FPU +FPREM1 386,FPU +FPTAN 8086,FPU +FRNDINT 8086,FPU +FRSTOR mem 8086,FPU +FSAVE mem 8086,FPU +FSCALE 8086,FPU +FSETPM 286,FPU +FSIN 386,FPU +FSINCOS 386,FPU +FSQRT 8086,FPU +FST mem32 8086,FPU +FST mem64 8086,FPU +FST fpureg 8086,FPU +FST 8086,FPU,ND +FSTCW mem 8086,FPU,SW +FSTENV mem 8086,FPU +FSTP mem32 8086,FPU +FSTP mem64 8086,FPU +FSTP mem80 8086,FPU +FSTP fpureg 8086,FPU +FSTP 8086,FPU,ND +FSTSW mem 8086,FPU,SW +FSTSW reg_ax 286,FPU +FSUB mem32 8086,FPU +FSUB mem64 8086,FPU +FSUB fpureg|to 8086,FPU +FSUB fpureg,fpu0 8086,FPU +FSUB fpureg 8086,FPU +FSUB fpu0,fpureg 8086,FPU +FSUB 8086,FPU,ND +FSUBP fpureg 8086,FPU +FSUBP fpureg,fpu0 8086,FPU +FSUBP 8086,FPU,ND +FSUBR mem32 8086,FPU +FSUBR mem64 8086,FPU +FSUBR fpureg|to 8086,FPU +FSUBR fpureg,fpu0 8086,FPU +FSUBR fpureg 8086,FPU +FSUBR fpu0,fpureg 8086,FPU +FSUBR 8086,FPU,ND +FSUBRP fpureg 8086,FPU +FSUBRP fpureg,fpu0 8086,FPU +FSUBRP 8086,FPU,ND +FTST 8086,FPU +FUCOM fpureg 386,FPU +FUCOM fpu0,fpureg 386,FPU +FUCOM 386,FPU,ND +FUCOMI fpureg P6,FPU +FUCOMI fpu0,fpureg P6,FPU +FUCOMI P6,FPU,ND +FUCOMIP fpureg P6,FPU +FUCOMIP fpu0,fpureg P6,FPU +FUCOMIP P6,FPU,ND +FUCOMP fpureg 386,FPU +FUCOMP fpu0,fpureg 386,FPU +FUCOMP 386,FPU,ND +FUCOMPP 386,FPU +FXAM 8086,FPU +FXCH fpureg 8086,FPU +FXCH fpureg,fpu0 8086,FPU +FXCH fpu0,fpureg 8086,FPU +FXCH 8086,FPU,ND +FXTRACT 8086,FPU +FYL2X 8086,FPU +FYL2XP1 8086,FPU +HLT 8086,PRIV +IBTS mem,reg16 386,SW,UNDOC,ND +IBTS reg16,reg16 386,UNDOC,ND +IBTS mem,reg32 386,SD,UNDOC,ND +IBTS reg32,reg32 386,UNDOC,ND +ICEBP 386,ND +IDIV rm8 8086 +IDIV rm16 8086 +IDIV rm32 386 +IDIV rm64 X64 +IMUL rm8 8086 +IMUL rm16 8086 +IMUL rm32 386 +IMUL rm64 X64 +IMUL reg16,mem 386 +IMUL reg16,reg16 386 +IMUL reg32,mem 386 +IMUL reg32,reg32 386 +IMUL reg64,mem X64 +IMUL reg64,reg64 X64 +IMUL reg16,mem,imm8 186 +IMUL reg16,mem,sbyte16 186,ND +IMUL reg16,mem,imm16 186 +IMUL reg16,mem,imm 186,ND +IMUL reg16,reg16,imm8 186 +IMUL reg16,reg16,sbyte16 186,ND +IMUL reg16,reg16,imm16 186 +IMUL reg16,reg16,imm 186,ND +IMUL reg32,mem,imm8 386 +IMUL reg32,mem,sbyte32 386,ND +IMUL reg32,mem,imm32 386 +IMUL reg32,mem,imm 386,ND +IMUL reg32,reg32,imm8 386 +IMUL reg32,reg32,sbyte32 386,ND +IMUL reg32,reg32,imm32 386 +IMUL reg32,reg32,imm 386,ND +IMUL reg64,mem,imm8 X64 +IMUL reg64,mem,sbyte64 X64,ND +IMUL reg64,mem,imm32 X64 +IMUL reg64,mem,imm X64,ND +IMUL reg64,reg64,imm8 X64 +IMUL reg64,reg64,sbyte64 X64,ND +IMUL reg64,reg64,imm32 X64 +IMUL reg64,reg64,imm X64,ND +IMUL reg16,imm8 186 +IMUL reg16,sbyte16 186,ND +IMUL reg16,imm16 186 +IMUL reg16,imm 186,ND +IMUL reg32,imm8 386 +IMUL reg32,sbyte32 386,ND +IMUL reg32,imm32 386 +IMUL reg32,imm 386,ND +IMUL reg64,imm8 X64 +IMUL reg64,sbyte64 X64,ND +IMUL reg64,imm32 X64 +IMUL reg64,imm X64,ND +IN reg_al,imm 8086 +IN reg_ax,imm 8086 +IN reg_eax,imm 386 +IN reg_al,reg_dx 8086 +IN reg_ax,reg_dx 8086 +IN reg_eax,reg_dx 386 +INC reg16 8086,NOLONG +INC reg32 386,NOLONG +INC rm8 8086 +INC rm16 8086 +INC rm32 386 +INC rm64 X64 +INCBIN +INSB 186 +INSD 386 +INSW 186 +INT imm 8086 +INT01 386,ND +INT1 386 +INT03 8086,ND +INT3 8086 +INTO 8086,NOLONG +INVD 486,PRIV +INVLPG mem 486,PRIV +INVLPGA reg_ax,reg_ecx X86_64,AMD,NOLONG +INVLPGA reg_eax,reg_ecx X86_64,AMD +INVLPGA reg_rax,reg_ecx X64,AMD +INVLPGA X86_64,AMD +IRET 8086 +IRETD 386 +IRETQ X64 +IRETW 8086 +JCXZ imm 8086,NOLONG +JECXZ imm 386 +JRCXZ imm X64 +JMP imm|short 8086 +JMP imm 8086,ND +JMP imm 8086 +JMP imm|near 8086,ND +JMP imm|far 8086,ND,NOLONG +JMP imm16 8086 +JMP imm16|near 8086,ND +JMP imm16|far 8086,ND,NOLONG +JMP imm32 386 +JMP imm32|near 386,ND +JMP imm32|far 386,ND,NOLONG +JMP imm:imm 8086,NOLONG +JMP imm16:imm 8086,NOLONG +JMP imm:imm16 8086,NOLONG +JMP imm32:imm 386,NOLONG +JMP imm:imm32 386,NOLONG +JMP mem|far 8086,NOLONG +JMP mem|far X64 +JMP mem16|far 8086 +JMP mem32|far 386 +JMP mem64|far X64 +JMP mem|near 8086 +JMP mem16|near 8086 +JMP mem32|near 386,NOLONG +JMP mem64|near X64 +JMP reg16 8086 +JMP reg32 386,NOLONG +JMP reg64 X64 +JMP mem 8086 +JMP mem16 8086 +JMP mem32 386,NOLONG +JMP mem64 X64 +JMPE imm IA64 +JMPE imm16 IA64 +JMPE imm32 IA64 +JMPE rm16 IA64 +JMPE rm32 IA64 +LAHF 8086 +LAR reg16,mem 286,PROT,SW +LAR reg16,reg16 286,PROT +LAR reg16,reg32 386,PROT +LAR reg16,reg64 X64,PROT,ND +LAR reg32,mem 386,PROT,SW +LAR reg32,reg16 386,PROT +LAR reg32,reg32 386,PROT +LAR reg32,reg64 X64,PROT,ND +LAR reg64,mem X64,PROT,SW +LAR reg64,reg16 X64,PROT +LAR reg64,reg32 X64,PROT +LAR reg64,reg64 X64,PROT +LDS reg16,mem 8086,NOLONG +LDS reg32,mem 386,NOLONG +LEA reg16,mem 8086 +LEA reg32,mem 386 +LEA reg64,mem X64 +LEAVE 186 +LES reg16,mem 8086,NOLONG +LES reg32,mem 386,NOLONG +LFENCE X64,AMD +LFS reg16,mem 386 +LFS reg32,mem 386 +LGDT mem 286,PRIV +LGS reg16,mem 386 +LGS reg32,mem 386 +LIDT mem 286,PRIV +LLDT mem 286,PROT,PRIV +LLDT mem16 286,PROT,PRIV +LLDT reg16 286,PROT,PRIV +LMSW mem 286,PRIV +LMSW mem16 286,PRIV +LMSW reg16 286,PRIV +LOADALL 386,UNDOC +LOADALL286 286,UNDOC +LODSB 8086 +LODSD 386 +LODSQ X64 +LODSW 8086 +LOOP imm 8086 +LOOP imm,reg_cx 8086,NOLONG +LOOP imm,reg_ecx 386 +LOOP imm,reg_rcx X64 +LOOPE imm 8086 +LOOPE imm,reg_cx 8086,NOLONG +LOOPE imm,reg_ecx 386 +LOOPE imm,reg_rcx X64 +LOOPNE imm 8086 +LOOPNE imm,reg_cx 8086,NOLONG +LOOPNE imm,reg_ecx 386 +LOOPNE imm,reg_rcx X64 +LOOPNZ imm 8086 +LOOPNZ imm,reg_cx 8086,NOLONG +LOOPNZ imm,reg_ecx 386 +LOOPNZ imm,reg_rcx X64 +LOOPZ imm 8086 +LOOPZ imm,reg_cx 8086,NOLONG +LOOPZ imm,reg_ecx 386 +LOOPZ imm,reg_rcx X64 +LSL reg16,mem 286,PROT,SW +LSL reg16,reg16 286,PROT +LSL reg16,reg32 386,PROT +LSL reg16,reg64 X64,PROT,ND +LSL reg32,mem 386,PROT,SW +LSL reg32,reg16 386,PROT +LSL reg32,reg32 386,PROT +LSL reg32,reg64 X64,PROT,ND +LSL reg64,mem X64,PROT,SW +LSL reg64,reg16 X64,PROT +LSL reg64,reg32 X64,PROT +LSL reg64,reg64 X64,PROT +LSS reg16,mem 386 +LSS reg32,mem 386 +LTR mem 286,PROT,PRIV +LTR mem16 286,PROT,PRIV +LTR reg16 286,PROT,PRIV +MFENCE X64,AMD +MONITOR PRESCOTT +MONITOR reg_eax,reg_ecx,reg_edx PRESCOTT,ND +MONITOR reg_rax,reg_ecx,reg_edx X64,ND +MOV mem,reg_sreg 8086 +MOV reg16,reg_sreg 8086 +MOV reg32,reg_sreg 386 +MOV reg_sreg,mem 8086 +MOV reg_sreg,reg16 8086 +MOV reg_sreg,reg32 386 +MOV reg_al,mem_offs 8086 +MOV reg_ax,mem_offs 8086 +MOV reg_eax,mem_offs 386 +MOV reg_rax,mem_offs X64 +MOV mem_offs,reg_al 8086 +MOV mem_offs,reg_ax 8086 +MOV mem_offs,reg_eax 386 +MOV mem_offs,reg_rax X64 +MOV reg32,reg_creg 386,PRIV,NOLONG +MOV reg64,reg_creg X64,PRIV +MOV reg_creg,reg32 386,PRIV,NOLONG +MOV reg_creg,reg64 X64,PRIV +MOV reg32,reg_dreg 386,PRIV,NOLONG +MOV reg64,reg_dreg X64,PRIV +MOV reg_dreg,reg32 386,PRIV,NOLONG +MOV reg_dreg,reg64 X64,PRIV +MOV reg32,reg_treg 386,NOLONG,ND +MOV reg_treg,reg32 386,NOLONG,ND +MOV mem,reg8 8086 +MOV reg8,reg8 8086 +MOV mem,reg16 8086 +MOV reg16,reg16 8086 +MOV mem,reg32 386 +MOV reg32,reg32 386 +MOV mem,reg64 X64 +MOV reg64,reg64 X64 +MOV reg8,mem 8086 +MOV reg8,reg8 8086 +MOV reg16,mem 8086 +MOV reg16,reg16 8086 +MOV reg32,mem 386 +MOV reg32,reg32 386 +MOV reg64,mem X64 +MOV reg64,reg64 X64 +MOV reg8,imm 8086 +MOV reg16,imm 8086 +MOV reg32,imm 386 +MOV reg64,imm X64 +MOV reg64,imm32 X64 +MOV rm8,imm 8086 +MOV rm16,imm 8086 +MOV rm32,imm 386 +MOV rm64,imm X64 +MOV mem,imm8 8086 +MOV mem,imm16 8086 +MOV mem,imm32 386 +MOVD mmxreg,mem PENT,MMX,SD +MOVD mmxreg,reg32 PENT,MMX +MOVD mem,mmxreg PENT,MMX,SD +MOVD reg32,mmxreg PENT,MMX +MOVD xmmreg,mem X64,SD +MOVD xmmreg,reg32 X64 +MOVD mem,xmmreg X64,SD +MOVD reg32,xmmreg X64,SSE +MOVQ mmxreg,mmxrm PENT,MMX +MOVQ mmxrm,mmxreg PENT,MMX +MOVQ mmxreg,rm64 X64,MMX +MOVQ rm64,mmxreg X64,MMX +MOVSB 8086 +MOVSD 386 +MOVSQ X64 +MOVSW 8086 +MOVSX reg16,mem 386 +MOVSX reg16,reg8 386 +MOVSX reg32,rm8 386 +MOVSX reg32,rm16 386 +MOVSX reg64,rm8 X64 +MOVSX reg64,rm16 X64 +MOVSXD reg64,rm32 X64 +MOVSX reg64,rm32 X64,ND +MOVZX reg16,mem 386 +MOVZX reg16,reg8 386 +MOVZX reg32,rm8 386 +MOVZX reg32,rm16 386 +MOVZX reg64,rm8 X64 +MOVZX reg64,rm16 X64 +MUL rm8 8086 +MUL rm16 8086 +MUL rm32 386 +MUL rm64 X64 +MWAIT PRESCOTT +MWAIT reg_eax,reg_ecx PRESCOTT,ND +NEG rm8 8086 +NEG rm16 8086 +NEG rm32 386 +NEG rm64 X64 +NOP 8086 +NOP rm16 P6 +NOP rm32 P6 +NOP rm64 X64 +NOT rm8 8086 +NOT rm16 8086 +NOT rm32 386 +NOT rm64 X64 +OR mem,reg8 8086 +OR reg8,reg8 8086 +OR mem,reg16 8086 +OR reg16,reg16 8086 +OR mem,reg32 386 +OR reg32,reg32 386 +OR mem,reg64 X64 +OR reg64,reg64 X64 +OR reg8,mem 8086 +OR reg8,reg8 8086 +OR reg16,mem 8086 +OR reg16,reg16 8086 +OR reg32,mem 386 +OR reg32,reg32 386 +OR reg64,mem X64 +OR reg64,reg64 X64 +OR rm16,imm8 8086 +OR rm32,imm8 386 +OR rm64,imm8 X64 +OR reg_al,imm 8086 +OR reg_ax,sbyte16 8086 +OR reg_ax,imm 8086 +OR reg_eax,sbyte32 386 +OR reg_eax,imm 386 +OR reg_rax,sbyte64 X64 +OR reg_rax,imm X64 +OR rm8,imm 8086 +OR rm16,imm 8086 +OR rm32,imm 386 +OR rm64,imm X64 +OR mem,imm8 8086 +OR mem,imm16 8086 +OR mem,imm32 386 +OUT imm,reg_al 8086 +OUT imm,reg_ax 8086 +OUT imm,reg_eax 386 +OUT reg_dx,reg_al 8086 +OUT reg_dx,reg_ax 8086 +OUT reg_dx,reg_eax 386 +OUTSB 186 +OUTSD 386 +OUTSW 186 +PACKSSDW mmxreg,mmxrm PENT,MMX +PACKSSWB mmxreg,mmxrm PENT,MMX +PACKUSWB mmxreg,mmxrm PENT,MMX +PADDB mmxreg,mmxrm PENT,MMX +PADDD mmxreg,mmxrm PENT,MMX +PADDSB mmxreg,mmxrm PENT,MMX +PADDSIW mmxreg,mmxrm PENT,MMX,CYRIX +PADDSW mmxreg,mmxrm PENT,MMX +PADDUSB mmxreg,mmxrm PENT,MMX +PADDUSW mmxreg,mmxrm PENT,MMX +PADDW mmxreg,mmxrm PENT,MMX +PAND mmxreg,mmxrm PENT,MMX +PANDN mmxreg,mmxrm PENT,MMX +PAUSE 8086 +PAVEB mmxreg,mmxrm PENT,MMX,CYRIX +PAVGUSB mmxreg,mmxrm PENT,3DNOW +PCMPEQB mmxreg,mmxrm PENT,MMX +PCMPEQD mmxreg,mmxrm PENT,MMX +PCMPEQW mmxreg,mmxrm PENT,MMX +PCMPGTB mmxreg,mmxrm PENT,MMX +PCMPGTD mmxreg,mmxrm PENT,MMX +PCMPGTW mmxreg,mmxrm PENT,MMX +PDISTIB mmxreg,mem PENT,MMX,CYRIX +PF2ID mmxreg,mmxrm PENT,3DNOW +PFACC mmxreg,mmxrm PENT,3DNOW +PFADD mmxreg,mmxrm PENT,3DNOW +PFCMPEQ mmxreg,mmxrm PENT,3DNOW +PFCMPGE mmxreg,mmxrm PENT,3DNOW +PFCMPGT mmxreg,mmxrm PENT,3DNOW +PFMAX mmxreg,mmxrm PENT,3DNOW +PFMIN mmxreg,mmxrm PENT,3DNOW +PFMUL mmxreg,mmxrm PENT,3DNOW +PFRCP mmxreg,mmxrm PENT,3DNOW +PFRCPIT1 mmxreg,mmxrm PENT,3DNOW +PFRCPIT2 mmxreg,mmxrm PENT,3DNOW +PFRSQIT1 mmxreg,mmxrm PENT,3DNOW +PFRSQRT mmxreg,mmxrm PENT,3DNOW +PFSUB mmxreg,mmxrm PENT,3DNOW +PFSUBR mmxreg,mmxrm PENT,3DNOW +PI2FD mmxreg,mmxrm PENT,3DNOW +PMACHRIW mmxreg,mem PENT,MMX,CYRIX +PMADDWD mmxreg,mmxrm PENT,MMX +PMAGW mmxreg,mmxrm PENT,MMX,CYRIX +PMULHRIW mmxreg,mmxrm PENT,MMX,CYRIX +PMULHRWA mmxreg,mmxrm PENT,3DNOW +PMULHRWC mmxreg,mmxrm PENT,MMX,CYRIX +PMULHW mmxreg,mmxrm PENT,MMX +PMULLW mmxreg,mmxrm PENT,MMX +PMVGEZB mmxreg,mem PENT,MMX,CYRIX +PMVLZB mmxreg,mem PENT,MMX,CYRIX +PMVNZB mmxreg,mem PENT,MMX,CYRIX +PMVZB mmxreg,mem PENT,MMX,CYRIX +POP reg16 8086 +POP reg32 386,NOLONG +POP reg64 X64 +POP rm16 8086 +POP rm32 386,NOLONG +POP rm64 X64 +POP reg_cs 8086,UNDOC,ND +POP reg_dess 8086,NOLONG +POP reg_fsgs 386 +POPA 186,NOLONG +POPAD 386,NOLONG +POPAW 186,NOLONG +POPF 8086 +POPFD 386,NOLONG +POPFQ X64 +POPFW 8086 +POR mmxreg,mmxrm PENT,MMX +PREFETCH mem PENT,3DNOW +PREFETCHW mem PENT,3DNOW +PSLLD mmxreg,mmxrm PENT,MMX +PSLLD mmxreg,imm PENT,MMX +PSLLQ mmxreg,mmxrm PENT,MMX +PSLLQ mmxreg,imm PENT,MMX +PSLLW mmxreg,mmxrm PENT,MMX +PSLLW mmxreg,imm PENT,MMX +PSRAD mmxreg,mmxrm PENT,MMX +PSRAD mmxreg,imm PENT,MMX +PSRAW mmxreg,mmxrm PENT,MMX +PSRAW mmxreg,imm PENT,MMX +PSRLD mmxreg,mmxrm PENT,MMX +PSRLD mmxreg,imm PENT,MMX +PSRLQ mmxreg,mmxrm PENT,MMX +PSRLQ mmxreg,imm PENT,MMX +PSRLW mmxreg,mmxrm PENT,MMX +PSRLW mmxreg,imm PENT,MMX +PSUBB mmxreg,mmxrm PENT,MMX +PSUBD mmxreg,mmxrm PENT,MMX +PSUBSB mmxreg,mmxrm PENT,MMX +PSUBSIW mmxreg,mmxrm PENT,MMX,CYRIX +PSUBSW mmxreg,mmxrm PENT,MMX +PSUBUSB mmxreg,mmxrm PENT,MMX +PSUBUSW mmxreg,mmxrm PENT,MMX +PSUBW mmxreg,mmxrm PENT,MMX +PUNPCKHBW mmxreg,mmxrm PENT,MMX +PUNPCKHDQ mmxreg,mmxrm PENT,MMX +PUNPCKHWD mmxreg,mmxrm PENT,MMX +PUNPCKLBW mmxreg,mmxrm PENT,MMX +PUNPCKLDQ mmxreg,mmxrm PENT,MMX +PUNPCKLWD mmxreg,mmxrm PENT,MMX +PUSH reg16 8086 +PUSH reg32 386,NOLONG +PUSH reg64 X64 +PUSH rm16 8086 +PUSH rm32 386,NOLONG +PUSH rm64 X64 +PUSH reg_cs 8086,NOLONG +PUSH reg_dess 8086,NOLONG +PUSH reg_fsgs 386 +PUSH imm8 186 +PUSH imm16 186,AR0,SZ +PUSH imm32 386,NOLONG,AR0,SZ +PUSH imm32 386,NOLONG,SD +PUSH imm64 X64,AR0,SZ +PUSHA 186,NOLONG +PUSHAD 386,NOLONG +PUSHAW 186,NOLONG +PUSHF 8086 +PUSHFD 386,NOLONG +PUSHFQ X64 +PUSHFW 8086 +PXOR mmxreg,mmxrm PENT,MMX +RCL rm8,unity 8086 +RCL rm8,reg_cl 8086 +RCL rm8,imm 186 +RCL rm16,unity 8086 +RCL rm16,reg_cl 8086 +RCL rm16,imm 186 +RCL rm32,unity 386 +RCL rm32,reg_cl 386 +RCL rm32,imm 386 +RCL rm64,unity X64 +RCL rm64,reg_cl X64 +RCL rm64,imm X64 +RCR rm8,unity 8086 +RCR rm8,reg_cl 8086 +RCR rm8,imm 186 +RCR rm16,unity 8086 +RCR rm16,reg_cl 8086 +RCR rm16,imm 186 +RCR rm32,unity 386 +RCR rm32,reg_cl 386 +RCR rm32,imm 386 +RCR rm64,unity X64 +RCR rm64,reg_cl X64 +RCR rm64,imm X64 +RDSHR rm32 P6,CYRIXM +RDMSR PENT,PRIV +RDPMC P6 +RDTSC PENT +RDTSCP X86_64 +RET 8086 +RET imm 8086,SW +RETF 8086 +RETF imm 8086,SW +RETN 8086 +RETN imm 8086,SW +ROL rm8,unity 8086 +ROL rm8,reg_cl 8086 +ROL rm8,imm 186 +ROL rm16,unity 8086 +ROL rm16,reg_cl 8086 +ROL rm16,imm 186 +ROL rm32,unity 386 +ROL rm32,reg_cl 386 +ROL rm32,imm 386 +ROL rm64,unity X64 +ROL rm64,reg_cl X64 +ROL rm64,imm X64 +ROR rm8,unity 8086 +ROR rm8,reg_cl 8086 +ROR rm8,imm 186 +ROR rm16,unity 8086 +ROR rm16,reg_cl 8086 +ROR rm16,imm 186 +ROR rm32,unity 386 +ROR rm32,reg_cl 386 +ROR rm32,imm 386 +ROR rm64,unity X64 +ROR rm64,reg_cl X64 +ROR rm64,imm X64 +RDM P6,CYRIX,ND +RSDC reg_sreg,mem80 486,CYRIXM +RSLDT mem80 486,CYRIXM +RSM PENTM +RSTS mem80 486,CYRIXM +SAHF 8086 +SAL rm8,unity 8086,ND +SAL rm8,reg_cl 8086,ND +SAL rm8,imm 186,ND +SAL rm16,unity 8086,ND +SAL rm16,reg_cl 8086,ND +SAL rm16,imm 186,ND +SAL rm32,unity 386,ND +SAL rm32,reg_cl 386,ND +SAL rm32,imm 386,ND +SAL rm64,unity X64,ND +SAL rm64,reg_cl X64,ND +SAL rm64,imm X64,ND +SALC 8086,UNDOC +SAR rm8,unity 8086 +SAR rm8,reg_cl 8086 +SAR rm8,imm 186 +SAR rm16,unity 8086 +SAR rm16,reg_cl 8086 +SAR rm16,imm 186 +SAR rm32,unity 386 +SAR rm32,reg_cl 386 +SAR rm32,imm 386 +SAR rm64,unity X64 +SAR rm64,reg_cl X64 +SAR rm64,imm X64 +SBB mem,reg8 8086 +SBB reg8,reg8 8086 +SBB mem,reg16 8086 +SBB reg16,reg16 8086 +SBB mem,reg32 386 +SBB reg32,reg32 386 +SBB mem,reg64 X64 +SBB reg64,reg64 X64 +SBB reg8,mem 8086 +SBB reg8,reg8 8086 +SBB reg16,mem 8086 +SBB reg16,reg16 8086 +SBB reg32,mem 386 +SBB reg32,reg32 386 +SBB reg64,mem X64 +SBB reg64,reg64 X64 +SBB rm16,imm8 8086 +SBB rm32,imm8 386 +SBB rm64,imm8 X64 +SBB reg_al,imm 8086 +SBB reg_ax,sbyte16 8086 +SBB reg_ax,imm 8086 +SBB reg_eax,sbyte32 386 +SBB reg_eax,imm 386 +SBB reg_rax,sbyte64 X64 +SBB reg_rax,imm X64 +SBB rm8,imm 8086 +SBB rm16,imm 8086 +SBB rm32,imm 386 +SBB rm64,imm X64 +SBB mem,imm8 8086 +SBB mem,imm16 8086 +SBB mem,imm32 386 +SCASB 8086 +SCASD 386 +SCASQ X64 +SCASW 8086 +SFENCE X64,AMD +SGDT mem 286 +SHL rm8,unity 8086 +SHL rm8,reg_cl 8086 +SHL rm8,imm 186 +SHL rm16,unity 8086 +SHL rm16,reg_cl 8086 +SHL rm16,imm 186 +SHL rm32,unity 386 +SHL rm32,reg_cl 386 +SHL rm32,imm 386 +SHL rm64,unity X64 +SHL rm64,reg_cl X64 +SHL rm64,imm X64 +SHLD mem,reg16,imm 3862 +SHLD reg16,reg16,imm 3862 +SHLD mem,reg32,imm 3862 +SHLD reg32,reg32,imm 3862 +SHLD mem,reg64,imm X642 +SHLD reg64,reg64,imm X642 +SHLD mem,reg16,reg_cl 386 +SHLD reg16,reg16,reg_cl 386 +SHLD mem,reg32,reg_cl 386 +SHLD reg32,reg32,reg_cl 386 +SHLD mem,reg64,reg_cl X64 +SHLD reg64,reg64,reg_cl X64 +SHR rm8,unity 8086 +SHR rm8,reg_cl 8086 +SHR rm8,imm 186 +SHR rm16,unity 8086 +SHR rm16,reg_cl 8086 +SHR rm16,imm 186 +SHR rm32,unity 386 +SHR rm32,reg_cl 386 +SHR rm32,imm 386 +SHR rm64,unity X64 +SHR rm64,reg_cl X64 +SHR rm64,imm X64 +SHRD mem,reg16,imm 3862 +SHRD reg16,reg16,imm 3862 +SHRD mem,reg32,imm 3862 +SHRD reg32,reg32,imm 3862 +SHRD mem,reg64,imm X642 +SHRD reg64,reg64,imm X642 +SHRD mem,reg16,reg_cl 386 +SHRD reg16,reg16,reg_cl 386 +SHRD mem,reg32,reg_cl 386 +SHRD reg32,reg32,reg_cl 386 +SHRD mem,reg64,reg_cl X64 +SHRD reg64,reg64,reg_cl X64 +SIDT mem 286 +SLDT mem 286 +SLDT mem16 286 +SLDT reg16 286 +SLDT reg32 386 +SLDT reg64 X64,ND +SLDT reg64 X64 +SKINIT X64 +SMI 386,UNDOC +SMINT P6,CYRIX,ND +SMINTOLD 486,CYRIX,ND +SMSW mem 286 +SMSW mem16 286 +SMSW reg16 286 +SMSW reg32 386 +STC 8086 +STD 8086 +STGI X64 +STI 8086 +STOSB 8086 +STOSD 386 +STOSQ X64 +STOSW 8086 +STR mem 286,PROT +STR mem16 286,PROT +STR reg16 286,PROT +STR reg32 386,PROT +STR reg64 X64 +SUB mem,reg8 8086 +SUB reg8,reg8 8086 +SUB mem,reg16 8086 +SUB reg16,reg16 8086 +SUB mem,reg32 386 +SUB reg32,reg32 386 +SUB mem,reg64 X64 +SUB reg64,reg64 X64 +SUB reg8,mem 8086 +SUB reg8,reg8 8086 +SUB reg16,mem 8086 +SUB reg16,reg16 8086 +SUB reg32,mem 386 +SUB reg32,reg32 386 +SUB reg64,mem X64 +SUB reg64,reg64 X64 +SUB rm16,imm8 8086 +SUB rm32,imm8 386 +SUB rm64,imm8 X64 +SUB reg_al,imm 8086 +SUB reg_ax,sbyte16 8086 +SUB reg_ax,imm 8086 +SUB reg_eax,sbyte32 386 +SUB reg_eax,imm 386 +SUB reg_rax,sbyte64 X64 +SUB reg_rax,imm X64 +SUB rm8,imm 8086 +SUB rm16,imm 8086 +SUB rm32,imm 386 +SUB rm64,imm X64 +SUB mem,imm8 8086 +SUB mem,imm16 8086 +SUB mem,imm32 386 +SVDC mem80,reg_sreg 486,CYRIXM +SVLDT mem80 486,CYRIXM,ND +SVTS mem80 486,CYRIXM +SWAPGS X64 +SYSCALL P6,AMD +SYSENTER P6 +SYSEXIT P6,PRIV +SYSRET P6,PRIV,AMD +TEST mem,reg8 8086 +TEST reg8,reg8 8086 +TEST mem,reg16 8086 +TEST reg16,reg16 8086 +TEST mem,reg32 386 +TEST reg32,reg32 386 +TEST mem,reg64 X64 +TEST reg64,reg64 X64 +TEST reg8,mem 8086 +TEST reg16,mem 8086 +TEST reg32,mem 386 +TEST reg64,mem X64 +TEST reg_al,imm 8086 +TEST reg_ax,imm 8086 +TEST reg_eax,imm 386 +TEST reg_rax,imm X64 +TEST rm8,imm 8086 +TEST rm16,imm 8086 +TEST rm32,imm 386 +TEST rm64,imm X64 +TEST mem,imm8 8086 +TEST mem,imm16 8086 +TEST mem,imm32 386 +UD0 186,UNDOC +UD1 186,UNDOC +UD2B 186,UNDOC,ND +UD2 186 +UD2A 186,ND +UMOV mem,reg8 386,UNDOC,ND +UMOV reg8,reg8 386,UNDOC,ND +UMOV mem,reg16 386,UNDOC,ND +UMOV reg16,reg16 386,UNDOC,ND +UMOV mem,reg32 386,UNDOC,ND +UMOV reg32,reg32 386,UNDOC,ND +UMOV reg8,mem 386,UNDOC,ND +UMOV reg8,reg8 386,UNDOC,ND +UMOV reg16,mem 386,UNDOC,ND +UMOV reg16,reg16 386,UNDOC,ND +UMOV reg32,mem 386,UNDOC,ND +UMOV reg32,reg32 386,UNDOC,ND +VERR mem 286,PROT +VERR mem16 286,PROT +VERR reg16 286,PROT +VERW mem 286,PROT +VERW mem16 286,PROT +VERW reg16 286,PROT +FWAIT 8086 +WBINVD 486,PRIV +WRSHR rm32 P6,CYRIXM +WRMSR PENT,PRIV +XADD mem,reg8 486 +XADD reg8,reg8 486 +XADD mem,reg16 486 +XADD reg16,reg16 486 +XADD mem,reg32 486 +XADD reg32,reg32 486 +XADD mem,reg64 X64 +XADD reg64,reg64 X64 +XBTS reg16,mem 386,SW,UNDOC,ND +XBTS reg16,reg16 386,UNDOC,ND +XBTS reg32,mem 386,SD,UNDOC,ND +XBTS reg32,reg32 386,UNDOC,ND +XCHG reg_ax,reg16 8086 +XCHG reg_eax,reg32na 386 +XCHG reg_rax,reg64 X64 +XCHG reg16,reg_ax 8086 +XCHG reg32na,reg_eax 386 +XCHG reg64,reg_rax X64 +XCHG reg_eax,reg_eax 386,NOLONG +XCHG reg8,mem 8086 +XCHG reg8,reg8 8086 +XCHG reg16,mem 8086 +XCHG reg16,reg16 8086 +XCHG reg32,mem 386 +XCHG reg32,reg32 386 +XCHG reg64,mem X64 +XCHG reg64,reg64 X64 +XCHG mem,reg8 8086 +XCHG reg8,reg8 8086 +XCHG mem,reg16 8086 +XCHG reg16,reg16 8086 +XCHG mem,reg32 386 +XCHG reg32,reg32 386 +XCHG mem,reg64 X64 +XCHG reg64,reg64 X64 +XLATB 8086 +XLAT 8086 +XOR mem,reg8 8086 +XOR reg8,reg8 8086 +XOR mem,reg16 8086 +XOR reg16,reg16 8086 +XOR mem,reg32 386 +XOR reg32,reg32 386 +XOR mem,reg64 X64 +XOR reg64,reg64 X64 +XOR reg8,mem 8086 +XOR reg8,reg8 8086 +XOR reg16,mem 8086 +XOR reg16,reg16 8086 +XOR reg32,mem 386 +XOR reg32,reg32 386 +XOR reg64,mem X64 +XOR reg64,reg64 X64 +XOR rm16,imm8 8086 +XOR rm32,imm8 386 +XOR rm64,imm8 X64 +XOR reg_al,imm 8086 +XOR reg_ax,sbyte16 8086 +XOR reg_ax,imm 8086 +XOR reg_eax,sbyte32 386 +XOR reg_eax,imm 386 +XOR reg_rax,sbyte64 X64 +XOR reg_rax,imm X64 +XOR rm8,imm 8086 +XOR rm16,imm 8086 +XOR rm32,imm 386 +XOR rm64,imm X64 +XOR mem,imm8 8086 +XOR mem,imm16 8086 +XOR mem,imm32 386 +CMOVcc reg16,mem P6 +CMOVcc reg16,reg16 P6 +CMOVcc reg32,mem P6 +CMOVcc reg32,reg32 P6 +CMOVcc reg64,mem X64 +CMOVcc reg64,reg64 X64 +Jcc imm|near 386 +Jcc imm16|near 386 +Jcc imm32|near 386 +Jcc imm|short 8086,ND +Jcc imm 8086,ND +Jcc imm 386,ND +Jcc imm 8086,ND +Jcc imm 8086 +SETcc mem 386 +SETcc reg8 386 +</pre> +<h4><a name="section-B.1.3">B.1.3 Katmai Streaming SIMD instructions (SSE -- a.k.a. KNI, XMM, MMX2)</a></h4> +<p><pre> +ADDPS xmmreg,xmmrm KATMAI,SSE +ADDSS xmmreg,xmmrm KATMAI,SSE,SD +ANDNPS xmmreg,xmmrm KATMAI,SSE +ANDPS xmmreg,xmmrm KATMAI,SSE +CMPEQPS xmmreg,xmmrm KATMAI,SSE +CMPEQSS xmmreg,xmmrm KATMAI,SSE +CMPLEPS xmmreg,xmmrm KATMAI,SSE +CMPLESS xmmreg,xmmrm KATMAI,SSE +CMPLTPS xmmreg,xmmrm KATMAI,SSE +CMPLTSS xmmreg,xmmrm KATMAI,SSE +CMPNEQPS xmmreg,xmmrm KATMAI,SSE +CMPNEQSS xmmreg,xmmrm KATMAI,SSE +CMPNLEPS xmmreg,xmmrm KATMAI,SSE +CMPNLESS xmmreg,xmmrm KATMAI,SSE +CMPNLTPS xmmreg,xmmrm KATMAI,SSE +CMPNLTSS xmmreg,xmmrm KATMAI,SSE +CMPORDPS xmmreg,xmmrm KATMAI,SSE +CMPORDSS xmmreg,xmmrm KATMAI,SSE +CMPUNORDPS xmmreg,xmmrm KATMAI,SSE +CMPUNORDSS xmmreg,xmmrm KATMAI,SSE +CMPPS xmmreg,mem,imm KATMAI,SSE +CMPPS xmmreg,xmmreg,imm KATMAI,SSE +CMPSS xmmreg,mem,imm KATMAI,SSE +CMPSS xmmreg,xmmreg,imm KATMAI,SSE +COMISS xmmreg,xmmrm KATMAI,SSE +CVTPI2PS xmmreg,mmxrm KATMAI,SSE,MMX +CVTPS2PI mmxreg,xmmrm KATMAI,SSE,MMX +CVTSI2SS xmmreg,mem KATMAI,SSE,SD,AR1,ND +CVTSI2SS xmmreg,rm32 KATMAI,SSE,SD,AR1 +CVTSI2SS xmmreg,rm64 X64,SSE,AR1 +CVTSS2SI reg32,xmmreg KATMAI,SSE,SD,AR1 +CVTSS2SI reg32,mem KATMAI,SSE,SD,AR1 +CVTSS2SI reg64,xmmreg X64,SSE,SD,AR1 +CVTSS2SI reg64,mem X64,SSE,SD,AR1 +CVTTPS2PI mmxreg,xmmrm KATMAI,SSE,MMX +CVTTSS2SI reg32,xmmrm KATMAI,SSE,SD,AR1 +CVTTSS2SI reg64,xmmrm X64,SSE,SD,AR1 +DIVPS xmmreg,xmmrm KATMAI,SSE +DIVSS xmmreg,xmmrm KATMAI,SSE +LDMXCSR mem KATMAI,SSE,SD +MAXPS xmmreg,xmmrm KATMAI,SSE +MAXSS xmmreg,xmmrm KATMAI,SSE +MINPS xmmreg,xmmrm KATMAI,SSE +MINSS xmmreg,xmmrm KATMAI,SSE +MOVAPS xmmreg,mem KATMAI,SSE +MOVAPS mem,xmmreg KATMAI,SSE +MOVAPS xmmreg,xmmreg KATMAI,SSE +MOVAPS xmmreg,xmmreg KATMAI,SSE +MOVHPS xmmreg,mem KATMAI,SSE +MOVHPS mem,xmmreg KATMAI,SSE +MOVLHPS xmmreg,xmmreg KATMAI,SSE +MOVLPS xmmreg,mem KATMAI,SSE +MOVLPS mem,xmmreg KATMAI,SSE +MOVHLPS xmmreg,xmmreg KATMAI,SSE +MOVMSKPS reg32,xmmreg KATMAI,SSE +MOVMSKPS reg64,xmmreg X64,SSE +MOVNTPS mem,xmmreg KATMAI,SSE +MOVSS xmmreg,mem KATMAI,SSE +MOVSS mem,xmmreg KATMAI,SSE +MOVSS xmmreg,xmmreg KATMAI,SSE +MOVSS xmmreg,xmmreg KATMAI,SSE +MOVUPS xmmreg,mem KATMAI,SSE +MOVUPS mem,xmmreg KATMAI,SSE +MOVUPS xmmreg,xmmreg KATMAI,SSE +MOVUPS xmmreg,xmmreg KATMAI,SSE +MULPS xmmreg,xmmrm KATMAI,SSE +MULSS xmmreg,xmmrm KATMAI,SSE +ORPS xmmreg,xmmrm KATMAI,SSE +RCPPS xmmreg,xmmrm KATMAI,SSE +RCPSS xmmreg,xmmrm KATMAI,SSE +RSQRTPS xmmreg,xmmrm KATMAI,SSE +RSQRTSS xmmreg,xmmrm KATMAI,SSE +SHUFPS xmmreg,mem,imm KATMAI,SSE +SHUFPS xmmreg,xmmreg,imm KATMAI,SSE +SQRTPS xmmreg,xmmrm KATMAI,SSE +SQRTSS xmmreg,xmmrm KATMAI,SSE +STMXCSR mem KATMAI,SSE,SD +SUBPS xmmreg,xmmrm KATMAI,SSE +SUBSS xmmreg,xmmrm KATMAI,SSE +UCOMISS xmmreg,xmmrm KATMAI,SSE +UNPCKHPS xmmreg,xmmrm KATMAI,SSE +UNPCKLPS xmmreg,xmmrm KATMAI,SSE +XORPS xmmreg,xmmrm KATMAI,SSE +</pre> +<h4><a name="section-B.1.4">B.1.4 Introduced in Deschutes but necessary for SSE support</a></h4> +<p><pre> +FXRSTOR mem P6,SSE,FPU +FXSAVE mem P6,SSE,FPU +</pre> +<h4><a name="section-B.1.5">B.1.5 XSAVE group (AVX and extended state)</a></h4> +<p><pre> +XGETBV NEHALEM +XSETBV NEHALEM,PRIV +XSAVE mem NEHALEM +XRSTOR mem NEHALEM +</pre> +<h4><a name="section-B.1.6">B.1.6 Generic memory operations</a></h4> +<p><pre> +PREFETCHNTA mem KATMAI +PREFETCHT0 mem KATMAI +PREFETCHT1 mem KATMAI +PREFETCHT2 mem KATMAI +SFENCE KATMAI +</pre> +<h4><a name="section-B.1.7">B.1.7 New MMX instructions introduced in Katmai</a></h4> +<p><pre> +MASKMOVQ mmxreg,mmxreg KATMAI,MMX +MOVNTQ mem,mmxreg KATMAI,MMX +PAVGB mmxreg,mmxrm KATMAI,MMX +PAVGW mmxreg,mmxrm KATMAI,MMX +PEXTRW reg32,mmxreg,imm KATMAI,MMX +PINSRW mmxreg,mem,imm KATMAI,MMX +PINSRW mmxreg,rm16,imm KATMAI,MMX +PINSRW mmxreg,reg32,imm KATMAI,MMX +PMAXSW mmxreg,mmxrm KATMAI,MMX +PMAXUB mmxreg,mmxrm KATMAI,MMX +PMINSW mmxreg,mmxrm KATMAI,MMX +PMINUB mmxreg,mmxrm KATMAI,MMX +PMOVMSKB reg32,mmxreg KATMAI,MMX +PMULHUW mmxreg,mmxrm KATMAI,MMX +PSADBW mmxreg,mmxrm KATMAI,MMX +PSHUFW mmxreg,mmxrm,imm KATMAI,MMX2 +</pre> +<h4><a name="section-B.1.8">B.1.8 AMD Enhanced 3DNow! (Athlon) instructions</a></h4> +<p><pre> +PF2IW mmxreg,mmxrm PENT,3DNOW +PFNACC mmxreg,mmxrm PENT,3DNOW +PFPNACC mmxreg,mmxrm PENT,3DNOW +PI2FW mmxreg,mmxrm PENT,3DNOW +PSWAPD mmxreg,mmxrm PENT,3DNOW +</pre> +<h4><a name="section-B.1.9">B.1.9 Willamette SSE2 Cacheability Instructions</a></h4> +<p><pre> +MASKMOVDQU xmmreg,xmmreg WILLAMETTE,SSE2 +CLFLUSH mem WILLAMETTE,SSE2 +MOVNTDQ mem,xmmreg WILLAMETTE,SSE2,SO +MOVNTI mem,reg32 WILLAMETTE,SD +MOVNTI mem,reg64 X64 +MOVNTPD mem,xmmreg WILLAMETTE,SSE2,SO +LFENCE WILLAMETTE,SSE2 +MFENCE WILLAMETTE,SSE2 +</pre> +<h4><a name="section-B.1.10">B.1.10 Willamette MMX instructions (SSE2 SIMD Integer Instructions)</a></h4> +<p><pre> +MOVD mem,xmmreg WILLAMETTE,SSE2,SD +MOVD xmmreg,mem WILLAMETTE,SSE2,SD +MOVD xmmreg,rm32 WILLAMETTE,SSE2 +MOVD rm32,xmmreg WILLAMETTE,SSE2 +MOVDQA xmmreg,xmmreg WILLAMETTE,SSE2 +MOVDQA mem,xmmreg WILLAMETTE,SSE2,SO +MOVDQA xmmreg,mem WILLAMETTE,SSE2,SO +MOVDQA xmmreg,xmmreg WILLAMETTE,SSE2 +MOVDQU xmmreg,xmmreg WILLAMETTE,SSE2 +MOVDQU mem,xmmreg WILLAMETTE,SSE2,SO +MOVDQU xmmreg,mem WILLAMETTE,SSE2,SO +MOVDQU xmmreg,xmmreg WILLAMETTE,SSE2 +MOVDQ2Q mmxreg,xmmreg WILLAMETTE,SSE2 +MOVQ xmmreg,xmmreg WILLAMETTE,SSE2 +MOVQ xmmreg,xmmreg WILLAMETTE,SSE2 +MOVQ mem,xmmreg WILLAMETTE,SSE2 +MOVQ xmmreg,mem WILLAMETTE,SSE2 +MOVQ xmmreg,rm64 X64,SSE2 +MOVQ rm64,xmmreg X64,SSE2 +MOVQ2DQ xmmreg,mmxreg WILLAMETTE,SSE2 +PACKSSWB xmmreg,xmmrm WILLAMETTE,SSE2,SO +PACKSSDW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PACKUSWB xmmreg,xmmrm WILLAMETTE,SSE2,SO +PADDB xmmreg,xmmrm WILLAMETTE,SSE2,SO +PADDW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PADDD xmmreg,xmmrm WILLAMETTE,SSE2,SO +PADDQ mmxreg,mmxrm WILLAMETTE,MMX +PADDQ xmmreg,xmmrm WILLAMETTE,SSE2,SO +PADDSB xmmreg,xmmrm WILLAMETTE,SSE2,SO +PADDSW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PADDUSB xmmreg,xmmrm WILLAMETTE,SSE2,SO +PADDUSW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PAND xmmreg,xmmrm WILLAMETTE,SSE2,SO +PANDN xmmreg,xmmrm WILLAMETTE,SSE2,SO +PAVGB xmmreg,xmmrm WILLAMETTE,SSE2,SO +PAVGW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PCMPEQB xmmreg,xmmrm WILLAMETTE,SSE2,SO +PCMPEQW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PCMPEQD xmmreg,xmmrm WILLAMETTE,SSE2,SO +PCMPGTB xmmreg,xmmrm WILLAMETTE,SSE2,SO +PCMPGTW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PCMPGTD xmmreg,xmmrm WILLAMETTE,SSE2,SO +PEXTRW reg32,xmmreg,imm WILLAMETTE,SSE2 +PINSRW xmmreg,reg16,imm WILLAMETTE,SSE2 +PINSRW xmmreg,reg32,imm WILLAMETTE,SSE2,ND +PINSRW xmmreg,mem,imm WILLAMETTE,SSE2 +PINSRW xmmreg,mem16,imm WILLAMETTE,SSE2 +PMADDWD xmmreg,xmmrm WILLAMETTE,SSE2,SO +PMAXSW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PMAXUB xmmreg,xmmrm WILLAMETTE,SSE2,SO +PMINSW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PMINUB xmmreg,xmmrm WILLAMETTE,SSE2,SO +PMOVMSKB reg32,xmmreg WILLAMETTE,SSE2 +PMULHUW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PMULHW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PMULLW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PMULUDQ mmxreg,mmxrm WILLAMETTE,SSE2,SO +PMULUDQ xmmreg,xmmrm WILLAMETTE,SSE2,SO +POR xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSADBW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSHUFD xmmreg,xmmreg,imm WILLAMETTE,SSE2 +PSHUFD xmmreg,mem,imm WILLAMETTE,SSE22 +PSHUFHW xmmreg,xmmreg,imm WILLAMETTE,SSE2 +PSHUFHW xmmreg,mem,imm WILLAMETTE,SSE22 +PSHUFLW xmmreg,xmmreg,imm WILLAMETTE,SSE2 +PSHUFLW xmmreg,mem,imm WILLAMETTE,SSE22 +PSLLDQ xmmreg,imm WILLAMETTE,SSE2,AR1 +PSLLW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSLLW xmmreg,imm WILLAMETTE,SSE2,AR1 +PSLLD xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSLLD xmmreg,imm WILLAMETTE,SSE2,AR1 +PSLLQ xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSLLQ xmmreg,imm WILLAMETTE,SSE2,AR1 +PSRAW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSRAW xmmreg,imm WILLAMETTE,SSE2,AR1 +PSRAD xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSRAD xmmreg,imm WILLAMETTE,SSE2,AR1 +PSRLDQ xmmreg,imm WILLAMETTE,SSE2,AR1 +PSRLW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSRLW xmmreg,imm WILLAMETTE,SSE2,AR1 +PSRLD xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSRLD xmmreg,imm WILLAMETTE,SSE2,AR1 +PSRLQ xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSRLQ xmmreg,imm WILLAMETTE,SSE2,AR1 +PSUBB xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSUBW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSUBD xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSUBQ mmxreg,mmxrm WILLAMETTE,SSE2,SO +PSUBQ xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSUBSB xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSUBSW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSUBUSB xmmreg,xmmrm WILLAMETTE,SSE2,SO +PSUBUSW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PUNPCKHBW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PUNPCKHWD xmmreg,xmmrm WILLAMETTE,SSE2,SO +PUNPCKHDQ xmmreg,xmmrm WILLAMETTE,SSE2,SO +PUNPCKHQDQ xmmreg,xmmrm WILLAMETTE,SSE2,SO +PUNPCKLBW xmmreg,xmmrm WILLAMETTE,SSE2,SO +PUNPCKLWD xmmreg,xmmrm WILLAMETTE,SSE2,SO +PUNPCKLDQ xmmreg,xmmrm WILLAMETTE,SSE2,SO +PUNPCKLQDQ xmmreg,xmmrm WILLAMETTE,SSE2,SO +PXOR xmmreg,xmmrm WILLAMETTE,SSE2,SO +</pre> +<h4><a name="section-B.1.11">B.1.11 Willamette Streaming SIMD instructions (SSE2)</a></h4> +<p><pre> +ADDPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +ADDSD xmmreg,xmmrm WILLAMETTE,SSE2 +ANDNPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +ANDPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +CMPEQPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +CMPEQSD xmmreg,xmmrm WILLAMETTE,SSE2 +CMPLEPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +CMPLESD xmmreg,xmmrm WILLAMETTE,SSE2 +CMPLTPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +CMPLTSD xmmreg,xmmrm WILLAMETTE,SSE2 +CMPNEQPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +CMPNEQSD xmmreg,xmmrm WILLAMETTE,SSE2 +CMPNLEPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +CMPNLESD xmmreg,xmmrm WILLAMETTE,SSE2 +CMPNLTPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +CMPNLTSD xmmreg,xmmrm WILLAMETTE,SSE2 +CMPORDPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +CMPORDSD xmmreg,xmmrm WILLAMETTE,SSE2 +CMPUNORDPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +CMPUNORDSD xmmreg,xmmrm WILLAMETTE,SSE2 +CMPPD xmmreg,xmmrm,imm WILLAMETTE,SSE22 +CMPSD xmmreg,xmmrm,imm WILLAMETTE,SSE2 +COMISD xmmreg,xmmrm WILLAMETTE,SSE2 +CVTDQ2PD xmmreg,xmmrm WILLAMETTE,SSE2 +CVTDQ2PS xmmreg,xmmrm WILLAMETTE,SSE2,SO +CVTPD2DQ xmmreg,xmmrm WILLAMETTE,SSE2,SO +CVTPD2PI mmxreg,xmmrm WILLAMETTE,SSE2,SO +CVTPD2PS xmmreg,xmmrm WILLAMETTE,SSE2,SO +CVTPI2PD xmmreg,mmxrm WILLAMETTE,SSE2 +CVTPS2DQ xmmreg,xmmrm WILLAMETTE,SSE2,SO +CVTPS2PD xmmreg,xmmrm WILLAMETTE,SSE2 +CVTSD2SI reg32,xmmreg WILLAMETTE,SSE2,AR1 +CVTSD2SI reg32,mem WILLAMETTE,SSE2,AR1 +CVTSD2SI reg64,xmmreg X64,SSE2,AR1 +CVTSD2SI reg64,mem X64,SSE2,AR1 +CVTSD2SS xmmreg,xmmrm WILLAMETTE,SSE2 +CVTSI2SD xmmreg,mem WILLAMETTE,SSE2,SD,AR1,ND +CVTSI2SD xmmreg,rm32 WILLAMETTE,SSE2,SD,AR1 +CVTSI2SD xmmreg,rm64 X64,SSE2,AR1 +CVTSS2SD xmmreg,xmmrm WILLAMETTE,SSE2,SD +CVTTPD2PI mmxreg,xmmrm WILLAMETTE,SSE2,SO +CVTTPD2DQ xmmreg,xmmrm WILLAMETTE,SSE2,SO +CVTTPS2DQ xmmreg,xmmrm WILLAMETTE,SSE2,SO +CVTTSD2SI reg32,xmmreg WILLAMETTE,SSE2,AR1 +CVTTSD2SI reg32,mem WILLAMETTE,SSE2,AR1 +CVTTSD2SI reg64,xmmreg X64,SSE2,AR1 +CVTTSD2SI reg64,mem X64,SSE2,AR1 +DIVPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +DIVSD xmmreg,xmmrm WILLAMETTE,SSE2 +MAXPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +MAXSD xmmreg,xmmrm WILLAMETTE,SSE2 +MINPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +MINSD xmmreg,xmmrm WILLAMETTE,SSE2 +MOVAPD xmmreg,xmmreg WILLAMETTE,SSE2 +MOVAPD xmmreg,xmmreg WILLAMETTE,SSE2 +MOVAPD mem,xmmreg WILLAMETTE,SSE2,SO +MOVAPD xmmreg,mem WILLAMETTE,SSE2,SO +MOVHPD mem,xmmreg WILLAMETTE,SSE2 +MOVHPD xmmreg,mem WILLAMETTE,SSE2 +MOVLPD mem,xmmreg WILLAMETTE,SSE2 +MOVLPD xmmreg,mem WILLAMETTE,SSE2 +MOVMSKPD reg32,xmmreg WILLAMETTE,SSE2 +MOVMSKPD reg64,xmmreg X64,SSE2 +MOVSD xmmreg,xmmreg WILLAMETTE,SSE2 +MOVSD xmmreg,xmmreg WILLAMETTE,SSE2 +MOVSD mem,xmmreg WILLAMETTE,SSE2 +MOVSD xmmreg,mem WILLAMETTE,SSE2 +MOVUPD xmmreg,xmmreg WILLAMETTE,SSE2 +MOVUPD xmmreg,xmmreg WILLAMETTE,SSE2 +MOVUPD mem,xmmreg WILLAMETTE,SSE2,SO +MOVUPD xmmreg,mem WILLAMETTE,SSE2,SO +MULPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +MULSD xmmreg,xmmrm WILLAMETTE,SSE2 +ORPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +SHUFPD xmmreg,xmmreg,imm WILLAMETTE,SSE2 +SHUFPD xmmreg,mem,imm WILLAMETTE,SSE2 +SQRTPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +SQRTSD xmmreg,xmmrm WILLAMETTE,SSE2 +SUBPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +SUBSD xmmreg,xmmrm WILLAMETTE,SSE2 +UCOMISD xmmreg,xmmrm WILLAMETTE,SSE2 +UNPCKHPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +UNPCKLPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +XORPD xmmreg,xmmrm WILLAMETTE,SSE2,SO +</pre> +<h4><a name="section-B.1.12">B.1.12 Prescott New Instructions (SSE3)</a></h4> +<p><pre> +ADDSUBPD xmmreg,xmmrm PRESCOTT,SSE3,SO +ADDSUBPS xmmreg,xmmrm PRESCOTT,SSE3,SO +HADDPD xmmreg,xmmrm PRESCOTT,SSE3,SO +HADDPS xmmreg,xmmrm PRESCOTT,SSE3,SO +HSUBPD xmmreg,xmmrm PRESCOTT,SSE3,SO +HSUBPS xmmreg,xmmrm PRESCOTT,SSE3,SO +LDDQU xmmreg,mem PRESCOTT,SSE3,SO +MOVDDUP xmmreg,xmmrm PRESCOTT,SSE3 +MOVSHDUP xmmreg,xmmrm PRESCOTT,SSE3 +MOVSLDUP xmmreg,xmmrm PRESCOTT,SSE3 +</pre> +<h4><a name="section-B.1.13">B.1.13 VMX Instructions</a></h4> +<p><pre> +VMCALL VMX +VMCLEAR mem VMX +VMLAUNCH VMX +VMLOAD X64,VMX +VMMCALL X64,VMX +VMPTRLD mem VMX +VMPTRST mem VMX +VMREAD rm32,reg32 VMX,NOLONG,SD +VMREAD rm64,reg64 X64,VMX +VMRESUME VMX +VMRUN X64,VMX +VMSAVE X64,VMX +VMWRITE reg32,rm32 VMX,NOLONG,SD +VMWRITE reg64,rm64 X64,VMX +VMXOFF VMX +VMXON mem VMX +</pre> +<h4><a name="section-B.1.14">B.1.14 Extended Page Tables VMX instructions</a></h4> +<p><pre> +INVEPT reg32,mem VMX,SO,NOLONG +INVEPT reg64,mem VMX,SO,LONG +INVVPID reg32,mem VMX,SO,NOLONG +INVVPID reg64,mem VMX,SO,LONG +</pre> +<h4><a name="section-B.1.15">B.1.15 Tejas New Instructions (SSSE3)</a></h4> +<p><pre> +PABSB mmxreg,mmxrm SSSE3,MMX +PABSB xmmreg,xmmrm SSSE3 +PABSW mmxreg,mmxrm SSSE3,MMX +PABSW xmmreg,xmmrm SSSE3 +PABSD mmxreg,mmxrm SSSE3,MMX +PABSD xmmreg,xmmrm SSSE3 +PALIGNR mmxreg,mmxrm,imm SSSE3,MMX +PALIGNR xmmreg,xmmrm,imm SSSE3 +PHADDW mmxreg,mmxrm SSSE3,MMX +PHADDW xmmreg,xmmrm SSSE3 +PHADDD mmxreg,mmxrm SSSE3,MMX +PHADDD xmmreg,xmmrm SSSE3 +PHADDSW mmxreg,mmxrm SSSE3,MMX +PHADDSW xmmreg,xmmrm SSSE3 +PHSUBW mmxreg,mmxrm SSSE3,MMX +PHSUBW xmmreg,xmmrm SSSE3 +PHSUBD mmxreg,mmxrm SSSE3,MMX +PHSUBD xmmreg,xmmrm SSSE3 +PHSUBSW mmxreg,mmxrm SSSE3,MMX +PHSUBSW xmmreg,xmmrm SSSE3 +PMADDUBSW mmxreg,mmxrm SSSE3,MMX +PMADDUBSW xmmreg,xmmrm SSSE3 +PMULHRSW mmxreg,mmxrm SSSE3,MMX +PMULHRSW xmmreg,xmmrm SSSE3 +PSHUFB mmxreg,mmxrm SSSE3,MMX +PSHUFB xmmreg,xmmrm SSSE3 +PSIGNB mmxreg,mmxrm SSSE3,MMX +PSIGNB xmmreg,xmmrm SSSE3 +PSIGNW mmxreg,mmxrm SSSE3,MMX +PSIGNW xmmreg,xmmrm SSSE3 +PSIGND mmxreg,mmxrm SSSE3,MMX +PSIGND xmmreg,xmmrm SSSE3 +</pre> +<h4><a name="section-B.1.16">B.1.16 AMD SSE4A</a></h4> +<p><pre> +EXTRQ xmmreg,imm,imm SSE4A,AMD +EXTRQ xmmreg,xmmreg SSE4A,AMD +INSERTQ xmmreg,xmmreg,imm,imm SSE4A,AMD +INSERTQ xmmreg,xmmreg SSE4A,AMD +MOVNTSD mem,xmmreg SSE4A,AMD +MOVNTSS mem,xmmreg SSE4A,AMD,SD +</pre> +<h4><a name="section-B.1.17">B.1.17 New instructions in Barcelona</a></h4> +<p><pre> +LZCNT reg16,rm16 P6,AMD +LZCNT reg32,rm32 P6,AMD +LZCNT reg64,rm64 X64,AMD +</pre> +<h4><a name="section-B.1.18">B.1.18 Penryn New Instructions (SSE4.1)</a></h4> +<p><pre> +BLENDPD xmmreg,xmmrm,imm SSE41 +BLENDPS xmmreg,xmmrm,imm SSE41 +BLENDVPD xmmreg,xmmrm,xmm0 SSE41 +BLENDVPS xmmreg,xmmrm,xmm0 SSE41 +DPPD xmmreg,xmmrm,imm SSE41 +DPPS xmmreg,xmmrm,imm SSE41 +EXTRACTPS rm32,xmmreg,imm SSE41 +EXTRACTPS reg64,xmmreg,imm SSE41,X64 +INSERTPS xmmreg,xmmrm,imm SSE41,SD +MOVNTDQA xmmreg,mem SSE41 +MPSADBW xmmreg,xmmrm,imm SSE41 +PACKUSDW xmmreg,xmmrm SSE41 +PBLENDVB xmmreg,xmmrm,xmm0 SSE41 +PBLENDW xmmreg,xmmrm,imm SSE41 +PCMPEQQ xmmreg,xmmrm SSE41 +PEXTRB reg32,xmmreg,imm SSE41 +PEXTRB mem8,xmmreg,imm SSE41 +PEXTRB reg64,xmmreg,imm SSE41,X64 +PEXTRD rm32,xmmreg,imm SSE41 +PEXTRQ rm64,xmmreg,imm SSE41,X64 +PEXTRW reg32,xmmreg,imm SSE41 +PEXTRW mem16,xmmreg,imm SSE41 +PEXTRW reg64,xmmreg,imm SSE41,X64 +PHMINPOSUW xmmreg,xmmrm SSE41 +PINSRB xmmreg,mem,imm SSE41 +PINSRB xmmreg,rm8,imm SSE41 +PINSRB xmmreg,reg32,imm SSE41 +PINSRD xmmreg,mem,imm SSE41 +PINSRD xmmreg,rm32,imm SSE41 +PINSRQ xmmreg,mem,imm SSE41,X64 +PINSRQ xmmreg,rm64,imm SSE41,X64 +PMAXSB xmmreg,xmmrm SSE41 +PMAXSD xmmreg,xmmrm SSE41 +PMAXUD xmmreg,xmmrm SSE41 +PMAXUW xmmreg,xmmrm SSE41 +PMINSB xmmreg,xmmrm SSE41 +PMINSD xmmreg,xmmrm SSE41 +PMINUD xmmreg,xmmrm SSE41 +PMINUW xmmreg,xmmrm SSE41 +PMOVSXBW xmmreg,xmmrm SSE41 +PMOVSXBD xmmreg,xmmrm SSE41,SD +PMOVSXBQ xmmreg,xmmrm SSE41,SW +PMOVSXWD xmmreg,xmmrm SSE41 +PMOVSXWQ xmmreg,xmmrm SSE41,SD +PMOVSXDQ xmmreg,xmmrm SSE41 +PMOVZXBW xmmreg,xmmrm SSE41 +PMOVZXBD xmmreg,xmmrm SSE41,SD +PMOVZXBQ xmmreg,xmmrm SSE41,SW +PMOVZXWD xmmreg,xmmrm SSE41 +PMOVZXWQ xmmreg,xmmrm SSE41,SD +PMOVZXDQ xmmreg,xmmrm SSE41 +PMULDQ xmmreg,xmmrm SSE41 +PMULLD xmmreg,xmmrm SSE41 +PTEST xmmreg,xmmrm SSE41 +ROUNDPD xmmreg,xmmrm,imm SSE41 +ROUNDPS xmmreg,xmmrm,imm SSE41 +ROUNDSD xmmreg,xmmrm,imm SSE41 +ROUNDSS xmmreg,xmmrm,imm SSE41 +</pre> +<h4><a name="section-B.1.19">B.1.19 Nehalem New Instructions (SSE4.2)</a></h4> +<p><pre> +CRC32 reg32,rm8 SSE42 +CRC32 reg32,rm16 SSE42 +CRC32 reg32,rm32 SSE42 +CRC32 reg64,rm8 SSE42,X64 +CRC32 reg64,rm64 SSE42,X64 +PCMPESTRI xmmreg,xmmrm,imm SSE42 +PCMPESTRM xmmreg,xmmrm,imm SSE42 +PCMPISTRI xmmreg,xmmrm,imm SSE42 +PCMPISTRM xmmreg,xmmrm,imm SSE42 +PCMPGTQ xmmreg,xmmrm SSE42 +POPCNT reg16,rm16 NEHALEM,SW +POPCNT reg32,rm32 NEHALEM,SD +POPCNT reg64,rm64 NEHALEM,X64 +</pre> +<h4><a name="section-B.1.20">B.1.20 Intel SMX</a></h4> +<p><pre> +GETSEC KATMAI +</pre> +<h4><a name="section-B.1.21">B.1.21 Geode (Cyrix) 3DNow! additions</a></h4> +<p><pre> +PFRCPV mmxreg,mmxrm PENT,3DNOW,CYRIX +PFRSQRTV mmxreg,mmxrm PENT,3DNOW,CYRIX +</pre> +<h4><a name="section-B.1.22">B.1.22 Intel new instructions in ???</a></h4> +<p><pre> +MOVBE reg16,mem16 NEHALEM +MOVBE reg32,mem32 NEHALEM +MOVBE reg64,mem64 NEHALEM +MOVBE mem16,reg16 NEHALEM +MOVBE mem32,reg32 NEHALEM +MOVBE mem64,reg64 NEHALEM +</pre> +<h4><a name="section-B.1.23">B.1.23 Intel AES instructions</a></h4> +<p><pre> +AESENC xmmreg,xmmrm128 SSE,WESTMERE +AESENCLAST xmmreg,xmmrm128 SSE,WESTMERE +AESDEC xmmreg,xmmrm128 SSE,WESTMERE +AESDECLAST xmmreg,xmmrm128 SSE,WESTMERE +AESIMC xmmreg,xmmrm128 SSE,WESTMERE +AESKEYGENASSIST xmmreg,xmmrm128,imm8 SSE,WESTMERE +</pre> +<h4><a name="section-B.1.24">B.1.24 Intel AVX AES instructions</a></h4> +<p><pre> +VAESENC xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VAESENCLAST xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VAESDEC xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VAESDECLAST xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VAESIMC xmmreg,xmmrm128 AVX,SANDYBRIDGE +VAESKEYGENASSIST xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +</pre> +<h4><a name="section-B.1.25">B.1.25 Intel AVX instructions</a></h4> +<p><pre> +VADDPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VADDPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VADDPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VADDPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VADDSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VADDSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VADDSUBPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VADDSUBPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VADDSUBPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VADDSUBPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VANDPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VANDPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VANDPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VANDPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VANDNPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VANDNPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VANDNPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VANDNPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VBLENDPD xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE +VBLENDPD ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE +VBLENDPS xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE +VBLENDPS ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE +VBLENDVPD xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE +VBLENDVPD xmmreg,xmmrm128,xmm0 AVX,SANDYBRIDGE +VBLENDVPD ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE +VBLENDVPD ymmreg,ymmrm256,ymm0 AVX,SANDYBRIDGE +VBLENDVPS xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE +VBLENDVPS xmmreg,xmmrm128,xmm0 AVX,SANDYBRIDGE +VBLENDVPS ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE +VBLENDVPD ymmreg,ymmrm256,ymm0 AVX,SANDYBRIDGE +VBROADCASTSS xmmreg,mem32 AVX,SANDYBRIDGE +VBROADCASTSS ymmreg,mem32 AVX,SANDYBRIDGE +VBROADCASTSD ymmreg,mem64 AVX,SANDYBRIDGE +VBROADCASTF128 ymmreg,mem128 AVX,SANDYBRIDGE +VCMPEQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPEQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPLTPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPLTPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPLEPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPLEPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPUNORDPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPUNORDPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNEQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNEQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNLTPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNLTPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNLEPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNLEPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPORDPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPORDPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPEQ_UQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPEQ_UQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNGEPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNGEPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNGTPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNGTPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPFALSEPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPFALSEPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNEQ_OQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNEQ_OQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPGEPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPGEPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPGTPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPGTPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPTRUEPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPTRUEPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPEQ_OSPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPEQ_OSPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPLT_OQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPLT_OQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPLE_OQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPLE_OQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPUNORD_SPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPUNORD_SPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNEQ_USPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNEQ_USPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNLT_UQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNLT_UQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNLE_UQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNLE_UQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPORD_SPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPORD_SPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPEQ_USPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPEQ_USPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNGE_UQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNGE_UQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNGT_UQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNGT_UQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPFALSE_OSPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPFALSE_OSPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNEQ_OSPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNEQ_OSPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPGE_OQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPGE_OQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPGT_OQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPGT_OQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPTRUE_USPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPTRUE_USPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPPD xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE +VCMPPD ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE +VCMPEQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPEQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPLTPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPLTPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPLEPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPLEPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPUNORDPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPUNORDPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNEQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNEQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNLTPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNLTPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNLEPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNLEPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPORDPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPORDPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPEQ_UQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPEQ_UQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNGEPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNGEPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNGTPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNGTPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPFALSEPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPFALSEPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNEQ_OQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNEQ_OQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPGEPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPGEPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPGTPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPGTPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPTRUEPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPTRUEPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPEQ_OSPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPEQ_OSPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPLT_OQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPLT_OQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPLE_OQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPLE_OQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPUNORD_SPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPUNORD_SPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNEQ_USPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNEQ_USPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNLT_UQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNLT_UQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNLE_UQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNLE_UQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPORD_SPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPORD_SPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPEQ_USPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPEQ_USPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNGE_UQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNGE_UQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNGT_UQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNGT_UQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPFALSE_OSPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPFALSE_OSPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPNEQ_OSPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPNEQ_OSPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPGE_OQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPGE_OQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPGT_OQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPGT_OQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPTRUE_USPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VCMPTRUE_USPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VCMPPS xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE +VCMPPS ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE +VCMPEQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPLTSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPLESD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPUNORDSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPNEQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPNLTSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPNLESD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPORDSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPEQ_UQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPNGESD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPNGTSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPFALSESD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPNEQ_OQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPGESD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPGTSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPTRUESD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPEQ_OSSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPLT_OQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPLE_OQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPUNORD_SSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPNEQ_USSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPNLT_UQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPNLE_UQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPORD_SSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPEQ_USSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPNGE_UQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPNGT_UQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPFALSE_OSSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPNEQ_OSSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPGE_OQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPGT_OQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPTRUE_USSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCMPSD xmmreg,xmmreg*,xmmrm64,imm8 AVX,SANDYBRIDGE +VCMPEQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPLTSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPLESS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPUNORDSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPNEQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPNLTSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPNLESS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPORDSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPEQ_UQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPNGESS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPNGTSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPFALSESS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPNEQ_OQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPGESS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPGTSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPTRUESS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPEQ_OSSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPLT_OQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPLE_OQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPUNORD_SSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPNEQ_USSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPNLT_UQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPNLE_UQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPORD_SSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPEQ_USSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPNGE_UQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPNGT_UQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPFALSE_OSSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPNEQ_OSSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPGE_OQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPGT_OQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPTRUE_USSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCMPSS xmmreg,xmmreg*,xmmrm32,imm8 AVX,SANDYBRIDGE +VCOMISD xmmreg,xmmrm64 AVX,SANDYBRIDGE +VCOMISS xmmreg,xmmrm32 AVX,SANDYBRIDGE +VCVTDQ2PD xmmreg,xmmrm64 AVX,SANDYBRIDGE +VCVTDQ2PD ymmreg,xmmrm128 AVX,SANDYBRIDGE +VCVTDQ2PS xmmreg,xmmrm128 AVX,SANDYBRIDGE +VCVTDQ2PS ymmreg,ymmrm256 AVX,SANDYBRIDGE +VCVTPD2DQ xmmreg,xmmreg AVX,SANDYBRIDGE +VCVTPD2DQ xmmreg,mem128 AVX,SANDYBRIDGE,SO +VCVTPD2DQ xmmreg,ymmreg AVX,SANDYBRIDGE +VCVTPD2DQ xmmreg,mem256 AVX,SANDYBRIDGE,SY +VCVTPD2PS xmmreg,xmmreg AVX,SANDYBRIDGE +VCVTPD2PS xmmreg,mem128 AVX,SANDYBRIDGE,SO +VCVTPD2PS xmmreg,ymmreg AVX,SANDYBRIDGE +VCVTPD2PS xmmreg,mem256 AVX,SANDYBRIDGE,SY +VCVTPS2DQ xmmreg,xmmrm128 AVX,SANDYBRIDGE +VCVTPS2DQ ymmreg,ymmrm256 AVX,SANDYBRIDGE +VCVTPS2PD xmmreg,xmmrm64 AVX,SANDYBRIDGE +VCVTPS2PD ymmreg,xmmrm128 AVX,SANDYBRIDGE +VCVTSD2SI reg32,xmmrm64 AVX,SANDYBRIDGE +VCVTSD2SI reg64,xmmrm64 AVX,SANDYBRIDGE,LONG +VCVTSD2SS xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VCVTSI2SD xmmreg,xmmreg*,rm32 AVX,SANDYBRIDGE,SD +VCVTSI2SD xmmreg,xmmreg*,mem32 AVX,SANDYBRIDGE,ND,SD +VCVTSI2SD xmmreg,xmmreg*,rm64 AVX,SANDYBRIDGE,LONG +VCVTSI2SS xmmreg,xmmreg*,rm32 AVX,SANDYBRIDGE,SD +VCVTSI2SS xmmreg,xmmreg*,mem32 AVX,SANDYBRIDGE,ND,SD +VCVTSI2SS xmmreg,xmmreg*,rm64 AVX,SANDYBRIDGE,LONG +VCVTSS2SD xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VCVTSS2SI reg32,xmmrm32 AVX,SANDYBRIDGE +VCVTSS2SI reg64,xmmrm32 AVX,SANDYBRIDGE,LONG +VCVTTPD2DQ xmmreg,xmmreg AVX,SANDYBRIDGE +VCVTTPD2DQ xmmreg,mem128 AVX,SANDYBRIDGE,SO +VCVTTPD2DQ xmmreg,ymmreg AVX,SANDYBRIDGE +VCVTTPD2DQ xmmreg,mem256 AVX,SANDYBRIDGE,SY +VCVTTPS2DQ xmmreg,xmmrm128 AVX,SANDYBRIDGE +VCVTTPS2DQ ymmreg,ymmrm256 AVX,SANDYBRIDGE +VCVTTSD2SI reg32,xmmrm64 AVX,SANDYBRIDGE +VCVTTSD2SI reg64,xmmrm64 AVX,SANDYBRIDGE,LONG +VCVTTSS2SI reg32,xmmrm32 AVX,SANDYBRIDGE +VCVTTSS2SI reg64,xmmrm32 AVX,SANDYBRIDGE,LONG +VDIVPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VDIVPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VDIVPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VDIVPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VDIVSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VDIVSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VDPPD xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE +VDPPS xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE +VDPPS ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE +VEXTRACTF128 xmmrm128,xmmreg,imm8 AVX,SANDYBRIDGE +VEXTRACTPS rm32,xmmreg,imm8 AVX,SANDYBRIDGE +VHADDPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VHADDPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VHADDPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VHADDPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VHSUBPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VHSUBPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VHSUBPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VHSUBPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VINSERTF128 ymmreg,ymmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VINSERTPS xmmreg,xmmreg*,xmmrm32,imm8 AVX,SANDYBRIDGE +VLDDQU xmmreg,mem128 AVX,SANDYBRIDGE +VLDQQU ymmreg,mem256 AVX,SANDYBRIDGE +VLDDQU ymmreg,mem256 AVX,SANDYBRIDGE +VLDMXCSR mem32 AVX,SANDYBRIDGE +VMASKMOVDQU xmmreg,xmmreg AVX,SANDYBRIDGE +VMASKMOVPS xmmreg,xmmreg,mem128 AVX,SANDYBRIDGE +VMASKMOVPS ymmreg,ymmreg,mem256 AVX,SANDYBRIDGE +VMASKMOVPS mem128,xmmreg,xmmreg AVX,SANDYBRIDGE,SO +VMASKMOVPS mem256,xmmreg,xmmreg AVX,SANDYBRIDGE,SY +VMASKMOVPD xmmreg,xmmreg,mem128 AVX,SANDYBRIDGE +VMASKMOVPD ymmreg,ymmreg,mem256 AVX,SANDYBRIDGE +VMASKMOVPD mem128,xmmreg,xmmreg AVX,SANDYBRIDGE +VMASKMOVPD mem256,ymmreg,ymmreg AVX,SANDYBRIDGE +VMAXPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VMAXPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VMAXPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VMAXPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VMAXSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VMAXSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VMINPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VMINPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VMINPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VMINPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VMINSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VMINSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VMOVAPD xmmreg,xmmrm128 AVX,SANDYBRIDGE +VMOVAPD xmmrm128,xmmreg AVX,SANDYBRIDGE +VMOVAPD ymmreg,ymmrm256 AVX,SANDYBRIDGE +VMOVAPD ymmrm256,ymmreg AVX,SANDYBRIDGE +VMOVAPS xmmreg,xmmrm128 AVX,SANDYBRIDGE +VMOVAPS xmmrm128,xmmreg AVX,SANDYBRIDGE +VMOVAPS ymmreg,ymmrm256 AVX,SANDYBRIDGE +VMOVAPS ymmrm256,ymmreg AVX,SANDYBRIDGE +VMOVQ xmmreg,xmmrm64 AVX,SANDYBRIDGE +VMOVQ xmmrm64,xmmreg AVX,SANDYBRIDGE +VMOVQ xmmreg,rm64 AVX,SANDYBRIDGE,LONG +VMOVQ rm64,xmmreg AVX,SANDYBRIDGE,LONG +VMOVD xmmreg,rm32 AVX,SANDYBRIDGE +VMOVD rm32,xmmreg AVX,SANDYBRIDGE +VMOVDDUP xmmreg,xmmrm64 AVX,SANDYBRIDGE +VMOVDDUP ymmreg,ymmrm256 AVX,SANDYBRIDGE +VMOVDQA xmmreg,xmmrm128 AVX,SANDYBRIDGE +VMOVDQA xmmrm128,xmmreg AVX,SANDYBRIDGE +VMOVQQA ymmreg,ymmrm256 AVX,SANDYBRIDGE +VMOVQQA ymmrm256,ymmreg AVX,SANDYBRIDGE +VMOVDQA ymmreg,ymmrm AVX,SANDYBRIDGE +VMOVDQA ymmrm256,ymmreg AVX,SANDYBRIDGE +VMOVDQU xmmreg,xmmrm128 AVX,SANDYBRIDGE +VMOVDQU xmmrm128,xmmreg AVX,SANDYBRIDGE +VMOVQQU ymmreg,ymmrm256 AVX,SANDYBRIDGE +VMOVQQU ymmrm256,ymmreg AVX,SANDYBRIDGE +VMOVDQU ymmreg,ymmrm256 AVX,SANDYBRIDGE +VMOVDQU ymmrm256,ymmreg AVX,SANDYBRIDGE +VMOVHLPS xmmreg,xmmreg*,xmmreg AVX,SANDYBRIDGE +VMOVHPD xmmreg,xmmreg*,mem64 AVX,SANDYBRIDGE +VMOVHPD mem64,xmmreg AVX,SANDYBRIDGE +VMOVHPS xmmreg,xmmreg*,mem64 AVX,SANDYBRIDGE +VMOVHPS mem64,xmmreg AVX,SANDYBRIDGE +VMOVLHPS xmmreg,xmmreg*,xmmreg AVX,SANDYBRIDGE +VMOVLPD xmmreg,xmmreg*,mem64 AVX,SANDYBRIDGE +VMOVLPD mem64,xmmreg AVX,SANDYBRIDGE +VMOVLPS xmmreg,xmmreg*,mem64 AVX,SANDYBRIDGE +VMOVLPS mem64,xmmreg AVX,SANDYBRIDGE +VMOVMSKPD reg64,xmmreg AVX,SANDYBRIDGE,LONG +VMOVMSKPD reg32,xmmreg AVX,SANDYBRIDGE +VMOVMSKPD reg64,ymmreg AVX,SANDYBRIDGE,LONG +VMOVMSKPD reg32,ymmreg AVX,SANDYBRIDGE +VMOVMSKPS reg64,xmmreg AVX,SANDYBRIDGE,LONG +VMOVMSKPS reg32,xmmreg AVX,SANDYBRIDGE +VMOVMSKPS reg64,ymmreg AVX,SANDYBRIDGE,LONG +VMOVMSKPS reg32,ymmreg AVX,SANDYBRIDGE +VMOVNTDQ mem128,xmmreg AVX,SANDYBRIDGE +VMOVNTQQ mem256,ymmreg AVX,SANDYBRIDGE +VMOVNTDQ mem256,ymmreg AVX,SANDYBRIDGE +VMOVNTDQA xmmreg,mem128 AVX,SANDYBRIDGE +VMOVNTPD mem128,xmmreg AVX,SANDYBRIDGE +VMOVNTPD mem256,ymmreg AVX,SANDYBRIDGE +VMOVNTPS mem128,xmmreg AVX,SANDYBRIDGE +VMOVNTPS mem128,ymmreg AVX,SANDYBRIDGE +VMOVSD xmmreg,xmmreg*,xmmreg AVX,SANDYBRIDGE +VMOVSD xmmreg,mem64 AVX,SANDYBRIDGE +VMOVSD xmmreg,xmmreg*,xmmreg AVX,SANDYBRIDGE +VMOVSD mem64,xmmreg AVX,SANDYBRIDGE +VMOVSHDUP xmmreg,xmmrm128 AVX,SANDYBRIDGE +VMOVSHDUP ymmreg,ymmrm256 AVX,SANDYBRIDGE +VMOVSLDUP xmmreg,xmmrm128 AVX,SANDYBRIDGE +VMOVSLDUP ymmreg,ymmrm256 AVX,SANDYBRIDGE +VMOVSS xmmreg,xmmreg*,xmmreg AVX,SANDYBRIDGE +VMOVSS xmmreg,mem64 AVX,SANDYBRIDGE +VMOVSS xmmreg,xmmreg*,xmmreg AVX,SANDYBRIDGE +VMOVSS mem64,xmmreg AVX,SANDYBRIDGE +VMOVUPD xmmreg,xmmrm128 AVX,SANDYBRIDGE +VMOVUPD xmmrm128,xmmreg AVX,SANDYBRIDGE +VMOVUPD ymmreg,ymmrm256 AVX,SANDYBRIDGE +VMOVUPD ymmrm256,ymmreg AVX,SANDYBRIDGE +VMOVUPS xmmreg,xmmrm128 AVX,SANDYBRIDGE +VMOVUPS xmmrm128,xmmreg AVX,SANDYBRIDGE +VMOVUPS ymmreg,ymmrm256 AVX,SANDYBRIDGE +VMOVUPS ymmrm256,ymmreg AVX,SANDYBRIDGE +VMPSADBW xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE +VMULPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VMULPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VMULPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VMULPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VMULSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VMULSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VORPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VORPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VORPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VORPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VPABSB xmmreg,xmmrm128 AVX,SANDYBRIDGE +VPABSW xmmreg,xmmrm128 AVX,SANDYBRIDGE +VPABSD xmmreg,xmmrm128 AVX,SANDYBRIDGE +VPACKSSWB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPACKSSDW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPACKUSWB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPACKUSDW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPADDB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPADDW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPADDD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPADDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPADDSB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPADDSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPADDUSB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPADDUSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPALIGNR xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE +VPAND xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPANDN xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPAVGB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPAVGW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPBLENDVB xmmreg,xmmreg*,xmmrm128,xmmreg AVX,SANDYBRIDGE +VPBLENDW xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE +VPCMPESTRI xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VPCMPESTRM xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VPCMPISTRI xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VPCMPISTRM xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VPCMPEQB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPCMPEQW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPCMPEQD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPCMPEQQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPCMPGTB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPCMPGTW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPCMPGTD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPCMPGTQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPERMILPD xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE +VPERMILPD ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE +VPERMILPD xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VPERMILPD ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE +VPERMILTD2PD xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE +VPERMILTD2PD xmmreg,xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE +VPERMILTD2PD ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE +VPERMILTD2PD ymmreg,ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE +VPERMILMO2PD xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE +VPERMILMO2PD xmmreg,xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE +VPERMILMO2PD ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE +VPERMILMO2PD ymmreg,ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE +VPERMILMZ2PD xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE +VPERMILMZ2PD xmmreg,xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE +VPERMILMZ2PD ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE +VPERMILMZ2PD ymmreg,ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE +VPERMIL2PD xmmreg,xmmreg,xmmrm128,xmmreg,imm8 AVX,SANDYBRIDGE +VPERMIL2PD xmmreg,xmmreg,xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VPERMIL2PD ymmreg,ymmreg,ymmrm256,ymmreg,imm8 AVX,SANDYBRIDGE +VPERMIL2PD ymmreg,ymmreg,ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE +VPERMILPS xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE +VPERMILPS ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE +VPERMILPS xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VPERMILPS ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE +VPERMILTD2PS xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE +VPERMILTD2PS xmmreg,xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE +VPERMILTD2PS ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE +VPERMILTD2PS ymmreg,ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE +VPERMILMO2PS xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE +VPERMILMO2PS xmmreg,xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE +VPERMILMO2PS ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE +VPERMILMO2PS ymmreg,ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE +VPERMILMZ2PS xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE +VPERMILMZ2PS xmmreg,xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE +VPERMILMZ2PS ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE +VPERMILMZ2PS ymmreg,ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE +VPERMIL2PS xmmreg,xmmreg,xmmrm128,xmmreg,imm8 AVX,SANDYBRIDGE +VPERMIL2PS xmmreg,xmmreg,xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VPERMIL2PS ymmreg,ymmreg,ymmrm256,ymmreg,imm8 AVX,SANDYBRIDGE +VPERMIL2PS ymmreg,ymmreg,ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE +VPERM2F128 ymmreg,ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE +VPEXTRB reg64,xmmreg,imm8 AVX,SANDYBRIDGE,LONG +VPEXTRB reg32,xmmreg,imm8 AVX,SANDYBRIDGE +VPEXTRB mem8,xmmreg,imm8 AVX,SANDYBRIDGE +VPEXTRW reg64,xmmreg,imm8 AVX,SANDYBRIDGE,LONG +VPEXTRW reg32,xmmreg,imm8 AVX,SANDYBRIDGE +VPEXTRW mem16,xmmreg,imm8 AVX,SANDYBRIDGE +VPEXTRW reg64,xmmreg,imm8 AVX,SANDYBRIDGE,LONG +VPEXTRW reg32,xmmreg,imm8 AVX,SANDYBRIDGE +VPEXTRW mem16,xmmreg,imm8 AVX,SANDYBRIDGE +VPEXTRD reg64,xmmreg,imm8 AVX,SANDYBRIDGE,LONG +VPEXTRD rm32,xmmreg,imm8 AVX,SANDYBRIDGE +VPEXTRQ rm64,xmmreg,imm8 AVX,SANDYBRIDGE,LONG +VPHADDW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPHADDD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPHADDSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPHMINPOSUW xmmreg,xmmrm128 AVX,SANDYBRIDGE +VPHSUBW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPHSUBD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPHSUBSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPINSRB xmmreg,xmmreg*,mem8,imm8 AVX,SANDYBRIDGE +VPINSRB xmmreg,xmmreg*,rm8,imm8 AVX,SANDYBRIDGE +VPINSRB xmmreg,xmmreg*,reg32,imm8 AVX,SANDYBRIDGE +VPINSRW xmmreg,xmmreg*,mem16,imm8 AVX,SANDYBRIDGE +VPINSRW xmmreg,xmmreg*,rm16,imm8 AVX,SANDYBRIDGE +VPINSRW xmmreg,xmmreg*,reg32,imm8 AVX,SANDYBRIDGE +VPINSRD xmmreg,xmmreg*,mem32,imm8 AVX,SANDYBRIDGE +VPINSRD xmmreg,xmmreg*,rm32,imm8 AVX,SANDYBRIDGE +VPINSRQ xmmreg,xmmreg*,mem64,imm8 AVX,SANDYBRIDGE,LONG +VPINSRQ xmmreg,xmmreg*,rm64,imm8 AVX,SANDYBRIDGE,LONG +VPMADDWD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMADDUBSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMAXSB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMAXSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMAXSD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMAXUB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMAXUW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMAXUD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMINSB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMINSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMINSD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMINUB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMINUW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMINUD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMOVMSKB reg64,xmmreg AVX,SANDYBRIDGE,LONG +VPMOVMSKB reg32,xmmreg AVX,SANDYBRIDGE +VPMOVSXBW xmmreg,xmmrm64 AVX,SANDYBRIDGE +VPMOVSXBD xmmreg,xmmrm32 AVX,SANDYBRIDGE +VPMOVSXBQ xmmreg,xmmrm16 AVX,SANDYBRIDGE +VPMOVSXWD xmmreg,xmmrm64 AVX,SANDYBRIDGE +VPMOVSXWQ xmmreg,xmmrm32 AVX,SANDYBRIDGE +VPMOVSXDQ xmmreg,xmmrm64 AVX,SANDYBRIDGE +VPMOVZXBW xmmreg,xmmrm64 AVX,SANDYBRIDGE +VPMOVZXBD xmmreg,xmmrm32 AVX,SANDYBRIDGE +VPMOVZXBQ xmmreg,xmmrm16 AVX,SANDYBRIDGE +VPMOVZXWD xmmreg,xmmrm64 AVX,SANDYBRIDGE +VPMOVZXWQ xmmreg,xmmrm32 AVX,SANDYBRIDGE +VPMOVZXDQ xmmreg,xmmrm64 AVX,SANDYBRIDGE +VPMULHUW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMULHRSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMULHW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMULLW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMULLD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMULUDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPMULDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPOR xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSADBW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSHUFB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSHUFD xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VPSHUFHW xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VPSHUFLW xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VPSIGNB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSIGNW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSIGND xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSLLDQ xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE +VPSRLDQ xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE +VPSLLW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSLLW xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE +VPSLLD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSLLD xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE +VPSLLQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSLLQ xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE +VPSRAW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSRAW xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE +VPSRAD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSRAD xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE +VPSRLW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSRLW xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE +VPSRLD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSRLD xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE +VPSRLQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSRLQ xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE +VPTEST xmmreg,xmmrm128 AVX,SANDYBRIDGE +VPTEST ymmreg,ymmrm256 AVX,SANDYBRIDGE +VPSUBB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSUBW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSUBD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSUBQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSUBSB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSUBSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSUBUSB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPSUBUSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPUNPCKHBW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPUNPCKHWD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPUNPCKHDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPUNPCKHQDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPUNPCKLBW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPUNPCKLWD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPUNPCKLDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPUNPCKLQDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPXOR xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VRCPPS xmmreg,xmmrm128 AVX,SANDYBRIDGE +VRCPPS ymmreg,ymmrm256 AVX,SANDYBRIDGE +VRCPSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VRSQRTPS xmmreg,xmmrm128 AVX,SANDYBRIDGE +VRSQRTPS ymmreg,ymmrm256 AVX,SANDYBRIDGE +VRSQRTSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VROUNDPD xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VROUNDPD ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE +VROUNDPS xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE +VROUNDPS ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE +VROUNDSD xmmreg,xmmreg*,xmmrm64,imm8 AVX,SANDYBRIDGE +VROUNDSS xmmreg,xmmreg*,xmmrm32,imm8 AVX,SANDYBRIDGE +VSHUFPD xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE +VSHUFPD ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE +VSHUFPS xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE +VSHUFPS ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE +VSQRTPD xmmreg,xmmrm128 AVX,SANDYBRIDGE +VSQRTPD ymmreg,ymmrm256 AVX,SANDYBRIDGE +VSQRTPS xmmreg,xmmrm128 AVX,SANDYBRIDGE +VSQRTPS ymmreg,ymmrm256 AVX,SANDYBRIDGE +VSQRTSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VSQRTSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VSTMXCSR mem32 AVX,SANDYBRIDGE +VSUBPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VSUBPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VSUBPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VSUBPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VSUBSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE +VSUBSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE +VTESTPS xmmreg,xmmrm128 AVX,SANDYBRIDGE +VTESTPS ymmreg,ymmrm256 AVX,SANDYBRIDGE +VTESTPD xmmreg,xmmrm128 AVX,SANDYBRIDGE +VTESTPD ymmreg,ymmrm256 AVX,SANDYBRIDGE +VUCOMISD xmmreg,xmmrm64 AVX,SANDYBRIDGE +VUCOMISS xmmreg,xmmrm32 AVX,SANDYBRIDGE +VUNPCKHPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VUNPCKHPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VUNPCKHPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VUNPCKHPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VUNPCKLPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VUNPCKLPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VUNPCKLPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VUNPCKLPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VXORPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VXORPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VXORPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VXORPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE +VZEROALL AVX,SANDYBRIDGE +VZEROUPPER AVX,SANDYBRIDGE +</pre> +<h4><a name="section-B.1.26">B.1.26 Intel Carry-Less Multiplication instructions (CLMUL)</a></h4> +<p><pre> +PCLMULLQLQDQ xmmreg,xmmrm128 SSE,WESTMERE +PCLMULHQLQDQ xmmreg,xmmrm128 SSE,WESTMERE +PCLMULLQHQDQ xmmreg,xmmrm128 SSE,WESTMERE +PCLMULHQHQDQ xmmreg,xmmrm128 SSE,WESTMERE +PCLMULQDQ xmmreg,xmmrm128,imm8 SSE,WESTMERE +</pre> +<h4><a name="section-B.1.27">B.1.27 Intel AVX Carry-Less Multiplication instructions (CLMUL)</a></h4> +<p><pre> +VPCLMULLQLQDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPCLMULHQLQDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPCLMULLQHQDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPCLMULHQHQDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE +VPCLMULQDQ xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE +</pre> +<h4><a name="section-B.1.28">B.1.28 Intel Fused Multiply-Add instructions (FMA)</a></h4> +<p><pre> +VFMADD132PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADD132PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADD132PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADD132PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADD312PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADD312PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADD312PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADD312PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADD213PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADD213PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADD213PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADD213PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADD123PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADD123PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADD123PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADD123PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADD231PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADD231PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADD231PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADD231PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADD321PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADD321PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADD321PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADD321PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADDSUB132PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADDSUB132PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADDSUB132PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADDSUB132PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADDSUB312PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADDSUB312PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADDSUB312PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADDSUB312PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADDSUB213PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADDSUB213PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADDSUB213PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADDSUB213PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADDSUB123PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADDSUB123PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADDSUB123PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADDSUB123PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADDSUB231PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADDSUB231PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADDSUB231PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADDSUB231PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADDSUB321PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADDSUB321PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADDSUB321PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMADDSUB321PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUB132PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUB132PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUB132PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUB132PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUB312PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUB312PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUB312PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUB312PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUB213PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUB213PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUB213PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUB213PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUB123PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUB123PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUB123PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUB123PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUB231PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUB231PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUB231PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUB231PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUB321PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUB321PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUB321PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUB321PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUBADD132PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUBADD132PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUBADD132PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUBADD132PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUBADD312PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUBADD312PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUBADD312PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUBADD312PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUBADD213PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUBADD213PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUBADD213PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUBADD213PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUBADD123PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUBADD123PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUBADD123PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUBADD123PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUBADD231PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUBADD231PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUBADD231PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUBADD231PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUBADD321PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUBADD321PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMSUBADD321PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFMSUBADD321PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMADD132PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMADD132PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMADD132PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMADD132PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMADD312PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMADD312PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMADD312PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMADD312PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMADD213PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMADD213PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMADD213PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMADD213PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMADD123PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMADD123PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMADD123PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMADD123PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMADD231PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMADD231PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMADD231PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMADD231PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMADD321PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMADD321PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMADD321PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMADD321PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMSUB132PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMSUB132PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMSUB132PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMSUB132PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMSUB312PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMSUB312PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMSUB312PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMSUB312PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMSUB213PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMSUB213PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMSUB213PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMSUB213PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMSUB123PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMSUB123PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMSUB123PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMSUB123PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMSUB231PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMSUB231PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMSUB231PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMSUB231PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMSUB321PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMSUB321PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFNMSUB321PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE +VFNMSUB321PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE +VFMADD132SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFMADD132SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFMADD312SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFMADD312SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFMADD213SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFMADD213SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFMADD123SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFMADD123SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFMADD231SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFMADD231SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFMADD321SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFMADD321SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFMSUB132SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFMSUB132SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFMSUB312SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFMSUB312SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFMSUB213SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFMSUB213SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFMSUB123SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFMSUB123SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFMSUB231SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFMSUB231SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFMSUB321SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFMSUB321SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFNMADD132SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFNMADD132SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFNMADD312SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFNMADD312SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFNMADD213SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFNMADD213SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFNMADD123SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFNMADD123SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFNMADD231SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFNMADD231SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFNMADD321SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFNMADD321SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFNMSUB132SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFNMSUB132SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFNMSUB312SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFNMSUB312SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFNMSUB213SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFNMSUB213SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFNMSUB123SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFNMSUB123SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFNMSUB231SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFNMSUB231SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +VFNMSUB321SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE +VFNMSUB321SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE +</pre> +<h4><a name="section-B.1.29">B.1.29 VIA (Centaur) security instructions</a></h4> +<p><pre> +XSTORE PENT,CYRIX +XCRYPTECB PENT,CYRIX +XCRYPTCBC PENT,CYRIX +XCRYPTCTR PENT,CYRIX +XCRYPTCFB PENT,CYRIX +XCRYPTOFB PENT,CYRIX +MONTMUL PENT,CYRIX +XSHA1 PENT,CYRIX +XSHA256 PENT,CYRIX +</pre> +<h4><a name="section-B.1.30">B.1.30 AMD Lightweight Profiling (LWP) instructions</a></h4> +<p><pre> +LLWPCB reg16 AMD +LLWPCB reg32 AMD,386 +LLWPCB reg64 AMD,X64 +SLWPCB reg16 AMD +SLWPCB reg32 AMD,386 +SLWPCB reg64 AMD,X64 +LWPVAL reg16,rm32,imm16 AMD,386 +LWPVAL reg32,rm32,imm32 AMD,386 +LWPVAL reg64,rm32,imm32 AMD,X64 +LWPINS reg16,rm32,imm16 AMD,386 +LWPINS reg32,rm32,imm32 AMD,386 +LWPINS reg64,rm32,imm32 AMD,X64 +</pre> +<h4><a name="section-B.1.31">B.1.31 AMD XOP, FMA4 and CVT16 instructions (SSE5)</a></h4> +<p><pre> +VCVTPH2PS xmmreg,xmmrm64*,imm8 AMD,SSE5 +VCVTPH2PS ymmreg,xmmrm128,imm8 AMD,SSE5 +VCVTPH2PS ymmreg,ymmrm128*,imm8 AMD,SSE5 +VCVTPS2PH xmmrm64,xmmreg*,imm8 AMD,SSE5 +VCVTPS2PH xmmrm128,ymmreg,imm8 AMD,SSE5 +VCVTPS2PH ymmrm128,ymmreg*,imm8 AMD,SSE5 +VFMADDPD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VFMADDPD ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 +VFMADDPD xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VFMADDPD ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 +VFMADDPS xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VFMADDPS ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 +VFMADDPS xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VFMADDPS ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 +VFMADDSD xmmreg,xmmreg*,xmmrm64,xmmreg AMD,SSE5 +VFMADDSD xmmreg,xmmreg*,xmmreg,xmmrm64 AMD,SSE5 +VFMADDSS xmmreg,xmmreg*,xmmrm32,xmmreg AMD,SSE5 +VFMADDSS xmmreg,xmmreg*,xmmreg,xmmrm32 AMD,SSE5 +VFMADDSUBPD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VFMADDSUBPD ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 +VFMADDSUBPD xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VFMADDSUBPD ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 +VFMADDSUBPS xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VFMADDSUBPS ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 +VFMADDSUBPS xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VFMADDSUBPS ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 +VFMSUBADDPD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VFMSUBADDPD ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 +VFMSUBADDPD xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VFMSUBADDPD ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 +VFMSUBADDPS xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VFMSUBADDPS ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 +VFMSUBADDPS xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VFMSUBADDPS ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 +VFMSUBPD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VFMSUBPD ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 +VFMSUBPD xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VFMSUBPD ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 +VFMSUBPS xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VFMSUBPS ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 +VFMSUBPS xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VFMSUBPS ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 +VFMSUBSD xmmreg,xmmreg*,xmmrm64,xmmreg AMD,SSE5 +VFMSUBSD xmmreg,xmmreg*,xmmreg,xmmrm64 AMD,SSE5 +VFMSUBSS xmmreg,xmmreg*,xmmrm32,xmmreg AMD,SSE5 +VFMSUBSS xmmreg,xmmreg*,xmmreg,xmmrm32 AMD,SSE5 +VFNMADDPD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VFNMADDPD ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 +VFNMADDPD xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VFNMADDPD ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 +VFNMADDPS xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VFNMADDPS ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 +VFNMADDPS xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VFNMADDPS ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 +VFNMADDSD xmmreg,xmmreg*,xmmrm64,xmmreg AMD,SSE5 +VFNMADDSD xmmreg,xmmreg*,xmmreg,xmmrm64 AMD,SSE5 +VFNMADDSS xmmreg,xmmreg*,xmmrm32,xmmreg AMD,SSE5 +VFNMADDSS xmmreg,xmmreg*,xmmreg,xmmrm32 AMD,SSE5 +VFNMSUBPD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VFNMSUBPD ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 +VFNMSUBPD xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VFNMSUBPD ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 +VFNMSUBPS xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VFNMSUBPS ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 +VFNMSUBPS xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VFNMSUBPS ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 +VFNMSUBSD xmmreg,xmmreg*,xmmrm64,xmmreg AMD,SSE5 +VFNMSUBSD xmmreg,xmmreg*,xmmreg,xmmrm64 AMD,SSE5 +VFNMSUBSS xmmreg,xmmreg*,xmmrm32,xmmreg AMD,SSE5 +VFNMSUBSS xmmreg,xmmreg*,xmmreg,xmmrm32 AMD,SSE5 +VFRCZPD xmmreg,xmmrm128* AMD,SSE5 +VFRCZPD ymmreg,ymmrm256* AMD,SSE5 +VFRCZPS xmmreg,xmmrm128* AMD,SSE5 +VFRCZPS ymmreg,ymmrm256* AMD,SSE5 +VFRCZSD xmmreg,xmmrm64* AMD,SSE5 +VFRCZSS xmmreg,xmmrm32* AMD,SSE5 +VPCMOV xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPCMOV ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 +VPCMOV xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VPCMOV ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 +VPCOMB xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 +VPCOMD xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 +VPCOMQ xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 +VPCOMUB xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 +VPCOMUD xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 +VPCOMUQ xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 +VPCOMUW xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 +VPCOMW xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 +VPHADDBD xmmreg,xmmrm128* AMD,SSE5 +VPHADDBQ xmmreg,xmmrm128* AMD,SSE5 +VPHADDBW xmmreg,xmmrm128* AMD,SSE5 +VPHADDDQ xmmreg,xmmrm128* AMD,SSE5 +VPHADDUBD xmmreg,xmmrm128* AMD,SSE5 +VPHADDUBQ xmmreg,xmmrm128* AMD,SSE5 +VPHADDUBW xmmreg,xmmrm128* AMD,SSE5 +VPHADDUDQ xmmreg,xmmrm128* AMD,SSE5 +VPHADDUWD xmmreg,xmmrm128* AMD,SSE5 +VPHADDUWQ xmmreg,xmmrm128* AMD,SSE5 +VPHADDWD xmmreg,xmmrm128* AMD,SSE5 +VPHADDWQ xmmreg,xmmrm128* AMD,SSE5 +VPHSUBBW xmmreg,xmmrm128* AMD,SSE5 +VPHSUBDQ xmmreg,xmmrm128* AMD,SSE5 +VPHSUBWD xmmreg,xmmrm128* AMD,SSE5 +VPMACSDD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPMACSDQH xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPMACSDQL xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPMACSSDD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPMACSSDQH xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPMACSSDQL xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPMACSSWD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPMACSSWW xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPMACSWD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPMACSWW xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPMADCSSWD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPMADCSWD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPPERM xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 +VPPERM xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 +VPROTB xmmreg,xmmrm128*,xmmreg AMD,SSE5 +VPROTB xmmreg,xmmreg*,xmmrm128 AMD,SSE5 +VPROTB xmmreg,xmmrm128*,imm8 AMD,SSE5 +VPROTD xmmreg,xmmrm128*,xmmreg AMD,SSE5 +VPROTD xmmreg,xmmreg*,xmmrm128 AMD,SSE5 +VPROTD xmmreg,xmmrm128*,imm8 AMD,SSE5 +VPROTQ xmmreg,xmmrm128*,xmmreg AMD,SSE5 +VPROTQ xmmreg,xmmreg*,xmmrm128 AMD,SSE5 +VPROTQ xmmreg,xmmrm128*,imm8 AMD,SSE5 +VPROTW xmmreg,xmmrm128*,xmmreg AMD,SSE5 +VPROTW xmmreg,xmmreg*,xmmrm128 AMD,SSE5 +VPROTW xmmreg,xmmrm128*,imm8 AMD,SSE5 +VPSHAB xmmreg,xmmrm128*,xmmreg AMD,SSE5 +VPSHAB xmmreg,xmmreg*,xmmrm128 AMD,SSE5 +VPSHAD xmmreg,xmmrm128*,xmmreg AMD,SSE5 +VPSHAD xmmreg,xmmreg*,xmmrm128 AMD,SSE5 +VPSHAQ xmmreg,xmmrm128*,xmmreg AMD,SSE5 +VPSHAQ xmmreg,xmmreg*,xmmrm128 AMD,SSE5 +VPSHAW xmmreg,xmmrm128*,xmmreg AMD,SSE5 +VPSHAW xmmreg,xmmreg*,xmmrm128 AMD,SSE5 +VPSHLB xmmreg,xmmrm128*,xmmreg AMD,SSE5 +VPSHLB xmmreg,xmmreg*,xmmrm128 AMD,SSE5 +VPSHLD xmmreg,xmmrm128*,xmmreg AMD,SSE5 +VPSHLD xmmreg,xmmreg*,xmmrm128 AMD,SSE5 +VPSHLQ xmmreg,xmmrm128*,xmmreg AMD,SSE5 +VPSHLQ xmmreg,xmmreg*,xmmrm128 AMD,SSE5 +VPSHLW xmmreg,xmmrm128*,xmmreg AMD,SSE5 +VPSHLW xmmreg,xmmreg*,xmmrm128 AMD,SSE5 +</pre> +<h4><a name="section-B.1.32">B.1.32 Systematic names for the hinting nop instructions</a></h4> +<p><pre> +HINT_NOP0 rm16 P6,UNDOC +HINT_NOP0 rm32 P6,UNDOC +HINT_NOP0 rm64 X64,UNDOC +HINT_NOP1 rm16 P6,UNDOC +HINT_NOP1 rm32 P6,UNDOC +HINT_NOP1 rm64 X64,UNDOC +HINT_NOP2 rm16 P6,UNDOC +HINT_NOP2 rm32 P6,UNDOC +HINT_NOP2 rm64 X64,UNDOC +HINT_NOP3 rm16 P6,UNDOC +HINT_NOP3 rm32 P6,UNDOC +HINT_NOP3 rm64 X64,UNDOC +HINT_NOP4 rm16 P6,UNDOC +HINT_NOP4 rm32 P6,UNDOC +HINT_NOP4 rm64 X64,UNDOC +HINT_NOP5 rm16 P6,UNDOC +HINT_NOP5 rm32 P6,UNDOC +HINT_NOP5 rm64 X64,UNDOC +HINT_NOP6 rm16 P6,UNDOC +HINT_NOP6 rm32 P6,UNDOC +HINT_NOP6 rm64 X64,UNDOC +HINT_NOP7 rm16 P6,UNDOC +HINT_NOP7 rm32 P6,UNDOC +HINT_NOP7 rm64 X64,UNDOC +HINT_NOP8 rm16 P6,UNDOC +HINT_NOP8 rm32 P6,UNDOC +HINT_NOP8 rm64 X64,UNDOC +HINT_NOP9 rm16 P6,UNDOC +HINT_NOP9 rm32 P6,UNDOC +HINT_NOP9 rm64 X64,UNDOC +HINT_NOP10 rm16 P6,UNDOC +HINT_NOP10 rm32 P6,UNDOC +HINT_NOP10 rm64 X64,UNDOC +HINT_NOP11 rm16 P6,UNDOC +HINT_NOP11 rm32 P6,UNDOC +HINT_NOP11 rm64 X64,UNDOC +HINT_NOP12 rm16 P6,UNDOC +HINT_NOP12 rm32 P6,UNDOC +HINT_NOP12 rm64 X64,UNDOC +HINT_NOP13 rm16 P6,UNDOC +HINT_NOP13 rm32 P6,UNDOC +HINT_NOP13 rm64 X64,UNDOC +HINT_NOP14 rm16 P6,UNDOC +HINT_NOP14 rm32 P6,UNDOC +HINT_NOP14 rm64 X64,UNDOC +HINT_NOP15 rm16 P6,UNDOC +HINT_NOP15 rm32 P6,UNDOC +HINT_NOP15 rm64 X64,UNDOC +HINT_NOP16 rm16 P6,UNDOC +HINT_NOP16 rm32 P6,UNDOC +HINT_NOP16 rm64 X64,UNDOC +HINT_NOP17 rm16 P6,UNDOC +HINT_NOP17 rm32 P6,UNDOC +HINT_NOP17 rm64 X64,UNDOC +HINT_NOP18 rm16 P6,UNDOC +HINT_NOP18 rm32 P6,UNDOC +HINT_NOP18 rm64 X64,UNDOC +HINT_NOP19 rm16 P6,UNDOC +HINT_NOP19 rm32 P6,UNDOC +HINT_NOP19 rm64 X64,UNDOC +HINT_NOP20 rm16 P6,UNDOC +HINT_NOP20 rm32 P6,UNDOC +HINT_NOP20 rm64 X64,UNDOC +HINT_NOP21 rm16 P6,UNDOC +HINT_NOP21 rm32 P6,UNDOC +HINT_NOP21 rm64 X64,UNDOC +HINT_NOP22 rm16 P6,UNDOC +HINT_NOP22 rm32 P6,UNDOC +HINT_NOP22 rm64 X64,UNDOC +HINT_NOP23 rm16 P6,UNDOC +HINT_NOP23 rm32 P6,UNDOC +HINT_NOP23 rm64 X64,UNDOC +HINT_NOP24 rm16 P6,UNDOC +HINT_NOP24 rm32 P6,UNDOC +HINT_NOP24 rm64 X64,UNDOC +HINT_NOP25 rm16 P6,UNDOC +HINT_NOP25 rm32 P6,UNDOC +HINT_NOP25 rm64 X64,UNDOC +HINT_NOP26 rm16 P6,UNDOC +HINT_NOP26 rm32 P6,UNDOC +HINT_NOP26 rm64 X64,UNDOC +HINT_NOP27 rm16 P6,UNDOC +HINT_NOP27 rm32 P6,UNDOC +HINT_NOP27 rm64 X64,UNDOC +HINT_NOP28 rm16 P6,UNDOC +HINT_NOP28 rm32 P6,UNDOC +HINT_NOP28 rm64 X64,UNDOC +HINT_NOP29 rm16 P6,UNDOC +HINT_NOP29 rm32 P6,UNDOC +HINT_NOP29 rm64 X64,UNDOC +HINT_NOP30 rm16 P6,UNDOC +HINT_NOP30 rm32 P6,UNDOC +HINT_NOP30 rm64 X64,UNDOC +HINT_NOP31 rm16 P6,UNDOC +HINT_NOP31 rm32 P6,UNDOC +HINT_NOP31 rm64 X64,UNDOC +HINT_NOP32 rm16 P6,UNDOC +HINT_NOP32 rm32 P6,UNDOC +HINT_NOP32 rm64 X64,UNDOC +HINT_NOP33 rm16 P6,UNDOC +HINT_NOP33 rm32 P6,UNDOC +HINT_NOP33 rm64 X64,UNDOC +HINT_NOP34 rm16 P6,UNDOC +HINT_NOP34 rm32 P6,UNDOC +HINT_NOP34 rm64 X64,UNDOC +HINT_NOP35 rm16 P6,UNDOC +HINT_NOP35 rm32 P6,UNDOC +HINT_NOP35 rm64 X64,UNDOC +HINT_NOP36 rm16 P6,UNDOC +HINT_NOP36 rm32 P6,UNDOC +HINT_NOP36 rm64 X64,UNDOC +HINT_NOP37 rm16 P6,UNDOC +HINT_NOP37 rm32 P6,UNDOC +HINT_NOP37 rm64 X64,UNDOC +HINT_NOP38 rm16 P6,UNDOC +HINT_NOP38 rm32 P6,UNDOC +HINT_NOP38 rm64 X64,UNDOC +HINT_NOP39 rm16 P6,UNDOC +HINT_NOP39 rm32 P6,UNDOC +HINT_NOP39 rm64 X64,UNDOC +HINT_NOP40 rm16 P6,UNDOC +HINT_NOP40 rm32 P6,UNDOC +HINT_NOP40 rm64 X64,UNDOC +HINT_NOP41 rm16 P6,UNDOC +HINT_NOP41 rm32 P6,UNDOC +HINT_NOP41 rm64 X64,UNDOC +HINT_NOP42 rm16 P6,UNDOC +HINT_NOP42 rm32 P6,UNDOC +HINT_NOP42 rm64 X64,UNDOC +HINT_NOP43 rm16 P6,UNDOC +HINT_NOP43 rm32 P6,UNDOC +HINT_NOP43 rm64 X64,UNDOC +HINT_NOP44 rm16 P6,UNDOC +HINT_NOP44 rm32 P6,UNDOC +HINT_NOP44 rm64 X64,UNDOC +HINT_NOP45 rm16 P6,UNDOC +HINT_NOP45 rm32 P6,UNDOC +HINT_NOP45 rm64 X64,UNDOC +HINT_NOP46 rm16 P6,UNDOC +HINT_NOP46 rm32 P6,UNDOC +HINT_NOP46 rm64 X64,UNDOC +HINT_NOP47 rm16 P6,UNDOC +HINT_NOP47 rm32 P6,UNDOC +HINT_NOP47 rm64 X64,UNDOC +HINT_NOP48 rm16 P6,UNDOC +HINT_NOP48 rm32 P6,UNDOC +HINT_NOP48 rm64 X64,UNDOC +HINT_NOP49 rm16 P6,UNDOC +HINT_NOP49 rm32 P6,UNDOC +HINT_NOP49 rm64 X64,UNDOC +HINT_NOP50 rm16 P6,UNDOC +HINT_NOP50 rm32 P6,UNDOC +HINT_NOP50 rm64 X64,UNDOC +HINT_NOP51 rm16 P6,UNDOC +HINT_NOP51 rm32 P6,UNDOC +HINT_NOP51 rm64 X64,UNDOC +HINT_NOP52 rm16 P6,UNDOC +HINT_NOP52 rm32 P6,UNDOC +HINT_NOP52 rm64 X64,UNDOC +HINT_NOP53 rm16 P6,UNDOC +HINT_NOP53 rm32 P6,UNDOC +HINT_NOP53 rm64 X64,UNDOC +HINT_NOP54 rm16 P6,UNDOC +HINT_NOP54 rm32 P6,UNDOC +HINT_NOP54 rm64 X64,UNDOC +HINT_NOP55 rm16 P6,UNDOC +HINT_NOP55 rm32 P6,UNDOC +HINT_NOP55 rm64 X64,UNDOC +HINT_NOP56 rm16 P6,UNDOC +HINT_NOP56 rm32 P6,UNDOC +HINT_NOP56 rm64 X64,UNDOC +HINT_NOP57 rm16 P6,UNDOC +HINT_NOP57 rm32 P6,UNDOC +HINT_NOP57 rm64 X64,UNDOC +HINT_NOP58 rm16 P6,UNDOC +HINT_NOP58 rm32 P6,UNDOC +HINT_NOP58 rm64 X64,UNDOC +HINT_NOP59 rm16 P6,UNDOC +HINT_NOP59 rm32 P6,UNDOC +HINT_NOP59 rm64 X64,UNDOC +HINT_NOP60 rm16 P6,UNDOC +HINT_NOP60 rm32 P6,UNDOC +HINT_NOP60 rm64 X64,UNDOC +HINT_NOP61 rm16 P6,UNDOC +HINT_NOP61 rm32 P6,UNDOC +HINT_NOP61 rm64 X64,UNDOC +HINT_NOP62 rm16 P6,UNDOC +HINT_NOP62 rm32 P6,UNDOC +HINT_NOP62 rm64 X64,UNDOC +HINT_NOP63 rm16 P6,UNDOC +HINT_NOP63 rm32 P6,UNDOC +HINT_NOP63 rm64 X64,UNDOC +</pre> +<p align=center><a href="nasmdocc.html">Next Chapter</a> | +<a href="nasmdoca.html">Previous Chapter</a> | +<a href="nasmdoc0.html">Contents</a> | +<a href="nasmdoci.html">Index</a> +</body></html> diff --git a/doc/html/nasmdocc.html b/doc/html/nasmdocc.html new file mode 100644 index 0000000..b7ec3b2 --- /dev/null +++ b/doc/html/nasmdocc.html @@ -0,0 +1,1468 @@ +<html><head><title>NASM Manual</title></head> +<body><h1 align=center>The Netwide Assembler: NASM</h1> + +<p align=center><a href="nasmdocb.html">Previous Chapter</a> | +<a href="nasmdoc0.html">Contents</a> | +<a href="nasmdoci.html">Index</a> +<h2><a name="appendix-C">Appendix C: NASM Version History</a></h2> +<h3><a name="section-C.1">C.1 NASM 2 Series</a></h3> +<p>The NASM 2 series support x86-64, and is the production version of NASM +since 2007. +<h4><a name="section-C.1.1">C.1.1 Version 2.08</a></h4> +<ul> +<li>A number of enhancements/fixes in macros area. +<li>Support for arbitrarily terminating macro expansions +<code><nobr>%exitmacro</nobr></code>. See +<a href="nasmdoc4.html#section-4.3.12">section 4.3.12</a>. +<li>Support for recursive macro expansion +<code><nobr>%rmacro/irmacro</nobr></code>. See +<a href="nasmdoc4.html#section-4.3.1">section 4.3.1</a>. +<li>Support for converting strings to tokens. See +<a href="nasmdoc4.html#section-4.1.9">section 4.1.9</a>. +<li>Fuzzy operand size logic introduced. +<li>Fix COFF stack overrun on too long export identifiers. +<li>Fix Macho-O alignment bug. +<li>Fix crashes with -fwin32 on file with many exports. +<li>Fix stack overrun for too long [DEBUG id]. +<li>Fix incorrect sbyte usage in IMUL (hit only if optimization flag +passed). +<li>Append ending token for <code><nobr>.stabs</nobr></code> records in the +ELF output format. +<li>New NSIS script which uses ModernUI and MultiUser approach. +<li>Visual Studio 2008 NASM integration (rules file). +<li>Warn a user if a constant is too long (and as result will be stripped). +<li>The obsoleted pre-XOP AMD SSE5 instruction set which was never +actualized was removed. +<li>Fix stack overrun on too long error file name passed from the command +line. +<li>Bind symbols to the .text section by default (ie in case if SECTION +directive was omitted) in the ELF output format. +<li>Fix sync points array index wrapping. +<li>A few fixes for FMA4 and XOP instruction templates. +<li>Add AMD Lightweight Profiling (LWP) instructions. +</ul> +<h4><a name="section-C.1.2">C.1.2 Version 2.07</a></h4> +<ul> +<li>NASM is now under the 2-clause BSD license. See +<a href="nasmdoc1.html#section-1.1.2">section 1.1.2</a>. +<li>Fix the section type for the <code><nobr>.strtab</nobr></code> section +in the <code><nobr>elf64</nobr></code> output format. +<li>Fix the handling of <code><nobr>COMMON</nobr></code> directives in the +<code><nobr>obj</nobr></code> output format. +<li>New <code><nobr>ith</nobr></code> and <code><nobr>srec</nobr></code> +output formats; these are variants of the <code><nobr>bin</nobr></code> +output format which output Intel hex and Motorola S-records, respectively. +See <a href="nasmdoc7.html#section-7.2">section 7.2</a> and +<a href="nasmdoc7.html#section-7.3">section 7.3</a>. +<li><code><nobr>rdf2ihx</nobr></code> replaced with an enhanced +<code><nobr>rdf2bin</nobr></code>, which can output binary, COM, Intel hex +or Motorola S-records. +<li>The Windows installer now puts the NASM directory first in the +<code><nobr>PATH</nobr></code> of the "NASM Shell". +<li>Revert the early expansion behavior of <code><nobr>%+</nobr></code> to +pre-2.06 behavior: <code><nobr>%+</nobr></code> is only expanded late. +<li>Yet another Mach-O alignment fix. +<li>Don't delete the list file on errors. Also, include error and warning +information in the list file. +<li>Support for 64-bit Mach-O output, see +<a href="nasmdoc7.html#section-7.8">section 7.8</a>. +<li>Fix assert failure on certain operations that involve strings with +high-bit bytes. +</ul> +<h4><a name="section-C.1.3">C.1.3 Version 2.06</a></h4> +<ul> +<li>This release is dedicated to the memory of Charles A. Crayne, long time +NASM developer as well as moderator of +<code><nobr>comp.lang.asm.x86</nobr></code> and author of the book +<em>Serious Assembler</em>. We miss you, Chuck. +<li>Support for indirect macro expansion +(<code><nobr>%[...]</nobr></code>). See +<a href="nasmdoc4.html#section-4.1.3">section 4.1.3</a>. +<li><code><nobr>%pop</nobr></code> can now take an argument, see +<a href="nasmdoc4.html#section-4.7.1">section 4.7.1</a>. +<li>The argument to <code><nobr>%use</nobr></code> is no longer +macro-expanded. Use <code><nobr>%[...]</nobr></code> if macro expansion is +desired. +<li>Support for thread-local storage in ELF32 and ELF64. See +<a href="nasmdoc7.html#section-7.9.4">section 7.9.4</a>. +<li>Fix crash on <code><nobr>%ifmacro</nobr></code> without an argument. +<li>Correct the arguments to the <code><nobr>POPCNT</nobr></code> +instruction. +<li>Fix section alignment in the Mach-O format. +<li>Update AVX support to version 5 of the Intel specification. +<li>Fix the handling of accesses to context-local macros from higher levels +in the context stack. +<li>Treat <code><nobr>WAIT</nobr></code> as a prefix rather than as an +instruction, thereby allowing constructs like +<code><nobr>O16 FSAVE</nobr></code> to work correctly. +<li>Support for structures with a non-zero base offset. See +<a href="nasmdoc4.html#section-4.11.10">section 4.11.10</a>. +<li>Correctly handle preprocessor token concatenation (see +<a href="nasmdoc4.html#section-4.3.8">section 4.3.8</a>) involving +floating-point numbers. +<li>The <code><nobr>PINSR</nobr></code> series of instructions have been +corrected and rationalized. +<li>Removed AMD SSE5, replaced with the new XOP/FMA4/CVT16 (rev 3.03) spec. +<li>The ELF backends no longer automatically generate a +<code><nobr>.comment</nobr></code> section. +<li>Add additional "well-known" ELF sections with default attributes. See +<a href="nasmdoc7.html#section-7.9.2">section 7.9.2</a>. +</ul> +<h4><a name="section-C.1.4">C.1.4 Version 2.05.01</a></h4> +<ul> +<li>Fix the <code><nobr>-w</nobr></code>/<code><nobr>-W</nobr></code> +option parsing, which was broken in NASM 2.05. +</ul> +<h4><a name="section-C.1.5">C.1.5 Version 2.05</a></h4> +<ul> +<li>Fix redundant REX.W prefix on <code><nobr>JMP reg64</nobr></code>. +<li>Make the behaviour of <code><nobr>-O0</nobr></code> match NASM 0.98 +legacy behavior. See <a href="nasmdoc2.html#section-2.1.22">section +2.1.22</a>. +<li><code><nobr>-w-user</nobr></code> can be used to suppress the output of +<code><nobr>%warning</nobr></code> directives. See +<a href="nasmdoc2.html#section-2.1.24">section 2.1.24</a>. +<li>Fix bug where <code><nobr>ALIGN</nobr></code> would issue a full +alignment datum instead of zero bytes. +<li>Fix offsets in list files. +<li>Fix <code><nobr>%include</nobr></code> inside multi-line macros or +loops. +<li>Fix error where NASM would generate a spurious warning on valid +optimizations of immediate values. +<li>Fix arguments to a number of the <code><nobr>CVT</nobr></code> SSE +instructions. +<li>Fix RIP-relative offsets when the instruction carries an immediate. +<li>Massive overhaul of the ELF64 backend for spec compliance. +<li>Fix the Geode <code><nobr>PFRCPV</nobr></code> and +<code><nobr>PFRSQRTV</nobr></code> instruction. +<li>Fix the SSE 4.2 <code><nobr>CRC32</nobr></code> instruction. +</ul> +<h4><a name="section-C.1.6">C.1.6 Version 2.04</a></h4> +<ul> +<li>Sanitize macro handing in the <code><nobr>%error</nobr></code> +directive. +<li>New <code><nobr>%warning</nobr></code> directive to issue +user-controlled warnings. +<li><code><nobr>%error</nobr></code> directives are now deferred to the +final assembly phase. +<li>New <code><nobr>%fatal</nobr></code> directive to immediately terminate +assembly. +<li>New <code><nobr>%strcat</nobr></code> directive to join quoted strings +together. +<li>New <code><nobr>%use</nobr></code> macro directive to support standard +macro directives. See <a href="nasmdoc4.html#section-4.6.4">section +4.6.4</a>. +<li>Excess default parameters to <code><nobr>%macro</nobr></code> now +issues a warning by default. See +<a href="nasmdoc4.html#section-4.3">section 4.3</a>. +<li>Fix <code><nobr>%ifn</nobr></code> and +<code><nobr>%elifn</nobr></code>. +<li>Fix nested <code><nobr>%else</nobr></code> clauses. +<li>Correct the handling of nested <code><nobr>%rep</nobr></code>s. +<li>New <code><nobr>%unmacro</nobr></code> directive to undeclare a +multi-line macro. See <a href="nasmdoc4.html#section-4.3.11">section +4.3.11</a>. +<li>Builtin macro <code><nobr>__PASS__</nobr></code> which expands to the +current assembly pass. See <a href="nasmdoc4.html#section-4.11.9">section +4.11.9</a>. +<li><code><nobr>__utf16__</nobr></code> and +<code><nobr>__utf32__</nobr></code> operators to generate UTF-16 and UTF-32 +strings. See <a href="nasmdoc3.html#section-3.4.5">section 3.4.5</a>. +<li>Fix bug in case-insensitive matching when compiled on platforms that +don't use the <code><nobr>configure</nobr></code> script. Of the official +release binaries, that only affected the OS/2 binary. +<li>Support for x87 packed BCD constants. See +<a href="nasmdoc3.html#section-3.4.7">section 3.4.7</a>. +<li>Correct the <code><nobr>LTR</nobr></code> and +<code><nobr>SLDT</nobr></code> instructions in 64-bit mode. +<li>Fix unnecessary REX.W prefix on indirect jumps in 64-bit mode. +<li>Add AVX versions of the AES instructions +(<code><nobr>VAES</nobr></code>...). +<li>Fix the 256-bit FMA instructions. +<li>Add 256-bit AVX stores per the latest AVX spec. +<li>VIA XCRYPT instructions can now be written either with or without +<code><nobr>REP</nobr></code>, apparently different versions of the VIA +spec wrote them differently. +<li>Add missing 64-bit <code><nobr>MOVNTI</nobr></code> instruction. +<li>Fix the operand size of <code><nobr>VMREAD</nobr></code> and +<code><nobr>VMWRITE</nobr></code>. +<li>Numerous bug fixes, especially to the AES, AVX and VTX instructions. +<li>The optimizer now always runs until it converges. It also runs even +when disabled, but doesn't optimize. This allows most forward references to +be resolved properly. +<li><code><nobr>%push</nobr></code> no longer needs a context identifier; +omitting the context identifier results in an anonymous context. +</ul> +<h4><a name="section-C.1.7">C.1.7 Version 2.03.01</a></h4> +<ul> +<li>Fix buffer overflow in the listing module. +<li>Fix the handling of hexadecimal escape codes in `...` strings. +<li>The Postscript/PDF documentation has been reformatted. +<li>The <code><nobr>-F</nobr></code> option now implies +<code><nobr>-g</nobr></code>. +</ul> +<h4><a name="section-C.1.8">C.1.8 Version 2.03</a></h4> +<ul> +<li>Add support for Intel AVX, CLMUL and FMA instructions, including YMM +registers. +<li><code><nobr>dy</nobr></code>, <code><nobr>resy</nobr></code> and +<code><nobr>yword</nobr></code> for 32-byte operands. +<li>Fix some SSE5 instructions. +<li>Intel <code><nobr>INVEPT</nobr></code>, +<code><nobr>INVVPID</nobr></code> and <code><nobr>MOVBE</nobr></code> +instructions. +<li>Fix checking for critical expressions when the optimizer is enabled. +<li>Support the DWARF debugging format for ELF targets. +<li>Fix optimizations of signed bytes. +<li>Fix operation on bigendian machines. +<li>Fix buffer overflow in the preprocessor. +<li><code><nobr>SAFESEH</nobr></code> support for Win32, +<code><nobr>IMAGEREL</nobr></code> for Win64 (SEH). +<li><code><nobr>%?</nobr></code> and <code><nobr>%??</nobr></code> to refer +to the name of a macro itself. In particular, +<code><nobr>%idefine keyword $%?</nobr></code> can be used to make a +keyword "disappear". +<li>New options for dependency generation: <code><nobr>-MD</nobr></code>, +<code><nobr>-MF</nobr></code>, <code><nobr>-MP</nobr></code>, +<code><nobr>-MT</nobr></code>, <code><nobr>-MQ</nobr></code>. +<li>New preprocessor directives <code><nobr>%pathsearch</nobr></code> and +<code><nobr>%depend</nobr></code>; INCBIN reimplemented as a macro. +<li><code><nobr>%include</nobr></code> now resolves macros in a sane +manner. +<li><code><nobr>%substr</nobr></code> can now be used to get other than +one-character substrings. +<li>New type of character/string constants, using backquotes +(<code><nobr>`...`</nobr></code>), which support C-style escape sequences. +<li><code><nobr>%defstr</nobr></code> and +<code><nobr>%idefstr</nobr></code> to stringize macro definitions before +creation. +<li>Fix forward references used in <code><nobr>EQU</nobr></code> +statements. +</ul> +<h4><a name="section-C.1.9">C.1.9 Version 2.02</a></h4> +<ul> +<li>Additional fixes for MMX operands with explicit +<code><nobr>qword</nobr></code>, as well as (hopefully) SSE operands with +<code><nobr>oword</nobr></code>. +<li>Fix handling of truncated strings with <code><nobr>DO</nobr></code>. +<li>Fix segfaults due to memory overwrites when floating-point constants +were used. +<li>Fix segfaults due to missing include files. +<li>Fix OpenWatcom Makefiles for DOS and OS/2. +<li>Add autogenerated instruction list back into the documentation. +<li>ELF: Fix segfault when generating stabs, and no symbols have been +defined. +<li>ELF: Experimental support for DWARF debugging information. +<li>New compile date and time standard macros. +<li><code><nobr>%ifnum</nobr></code> now returns true for negative numbers. +<li>New <code><nobr>%iftoken</nobr></code> test for a single token. +<li>New <code><nobr>%ifempty</nobr></code> test for empty expansion. +<li>Add support for the <code><nobr>XSAVE</nobr></code> instruction group. +<li>Makefile for Netware/gcc. +<li>Fix issue with some warnings getting emitted way too many times. +<li>Autogenerated instruction list added to the documentation. +</ul> +<h4><a name="section-C.1.10">C.1.10 Version 2.01</a></h4> +<ul> +<li>Fix the handling of MMX registers with explicit +<code><nobr>qword</nobr></code> tags on memory (broken in 2.00 due to +64-bit changes.) +<li>Fix the PREFETCH instructions. +<li>Fix the documentation. +<li>Fix debugging info when using <code><nobr>-f elf</nobr></code> +(backwards compatibility alias for <code><nobr>-f elf32</nobr></code>). +<li>Man pages for rdoff tools (from the Debian project.) +<li>ELF: handle large numbers of sections. +<li>Fix corrupt output when the optimizer runs out of passes. +</ul> +<h4><a name="section-C.1.11">C.1.11 Version 2.00</a></h4> +<ul> +<li>Added c99 data-type compliance. +<li>Added general x86-64 support. +<li>Added win64 (x86-64 COFF) output format. +<li>Added <code><nobr>__BITS__</nobr></code> standard macro. +<li>Renamed the <code><nobr>elf</nobr></code> output format to +<code><nobr>elf32</nobr></code> for clarity. +<li>Added <code><nobr>elf64</nobr></code> and +<code><nobr>macho</nobr></code> (MacOS X) output formats. +<li>Added Numeric constants in <code><nobr>dq</nobr></code> directive. +<li>Added <code><nobr>oword</nobr></code>, <code><nobr>do</nobr></code> and +<code><nobr>reso</nobr></code> pseudo operands. +<li>Allow underscores in numbers. +<li>Added 8-, 16- and 128-bit floating-point formats. +<li>Added binary, octal and hexadecimal floating-point. +<li>Correct the generation of floating-point constants. +<li>Added floating-point option control. +<li>Added Infinity and NaN floating point support. +<li>Added ELF Symbol Visibility support. +<li>Added setting OSABI value in ELF header directive. +<li>Added Generate Makefile Dependencies option. +<li>Added Unlimited Optimization Passes option. +<li>Added <code><nobr>%IFN</nobr></code> and +<code><nobr>%ELIFN</nobr></code> support. +<li>Added Logical Negation Operator. +<li>Enhanced Stack Relative Preprocessor Directives. +<li>Enhanced ELF Debug Formats. +<li>Enhanced Send Errors to a File option. +<li>Added SSSE3, SSE4.1, SSE4.2, SSE5 support. +<li>Added a large number of additional instructions. +<li>Significant performance improvements. +<li><code><nobr>-w+warning</nobr></code> and +<code><nobr>-w-warning</nobr></code> can now be written as -Wwarning and +-Wno-warning, respectively. See +<a href="nasmdoc2.html#section-2.1.24">section 2.1.24</a>. +<li>Add <code><nobr>-w+error</nobr></code> to treat warnings as errors. See +<a href="nasmdoc2.html#section-2.1.24">section 2.1.24</a>. +<li>Add <code><nobr>-w+all</nobr></code> and +<code><nobr>-w-all</nobr></code> to enable or disable all suppressible +warnings. See <a href="nasmdoc2.html#section-2.1.24">section 2.1.24</a>. +</ul> +<h3><a name="section-C.2">C.2 NASM 0.98 Series</a></h3> +<p>The 0.98 series was the production versions of NASM from 1999 to 2007. +<h4><a name="section-C.2.1">C.2.1 Version 0.98.39</a></h4> +<ul> +<li>fix buffer overflow +<li>fix outas86's <code><nobr>.bss</nobr></code> handling +<li>"make spotless" no longer deletes config.h.in. +<li><code><nobr>%(el)if(n)idn</nobr></code> insensitivity to string quotes +difference (#809300). +<li>(nasm.c)<code><nobr>__OUTPUT_FORMAT__</nobr></code> changed to string +value instead of symbol. +</ul> +<h4><a name="section-C.2.2">C.2.2 Version 0.98.38</a></h4> +<ul> +<li>Add Makefile for 16-bit DOS binaries under OpenWatcom, and modify +<code><nobr>mkdep.pl</nobr></code> to be able to generate completely +pathless dependencies, as required by OpenWatcom wmake (it supports path +searches, but not explicit paths.) +<li>Fix the <code><nobr>STR</nobr></code> instruction. +<li>Fix the ELF output format, which was broken under certain circumstances +due to the addition of stabs support. +<li>Quick-fix Borland format debug-info for +<code><nobr>-f obj</nobr></code> +<li>Fix for <code><nobr>%rep</nobr></code> with no arguments (#560568) +<li>Fix concatenation of preprocessor function call (#794686) +<li>Fix long label causes coredump (#677841) +<li>Use autoheader as well as autoconf to keep configure from generating +ridiculously long command lines. +<li>Make sure that all of the formats which support debugging output +actually will suppress debugging output when <code><nobr>-g</nobr></code> +not specified. +</ul> +<h4><a name="section-C.2.3">C.2.3 Version 0.98.37</a></h4> +<ul> +<li>Paths given in <code><nobr>-I</nobr></code> switch searched for +<code><nobr>incbin</nobr></code>-ed as well as +<code><nobr>%include</nobr></code>-ed files. +<li>Added stabs debugging for the ELF output format, patch from Martin +Wawro. +<li>Fix <code><nobr>output/outbin.c</nobr></code> to allow origin > +80000000h. +<li>Make <code><nobr>-U</nobr></code> switch work. +<li>Fix the use of relative offsets with explicit prefixes, e.g. +<code><nobr>a32 loop foo</nobr></code>. +<li>Remove <code><nobr>backslash()</nobr></code>. +<li>Fix the <code><nobr>SMSW</nobr></code> and +<code><nobr>SLDT</nobr></code> instructions. +<li><code><nobr>-O2</nobr></code> and <code><nobr>-O3</nobr></code> are no +longer aliases for <code><nobr>-O10</nobr></code> and +<code><nobr>-O15</nobr></code>. If you mean the latter, please say so! :) +</ul> +<h4><a name="section-C.2.4">C.2.4 Version 0.98.36</a></h4> +<ul> +<li>Update rdoff - librarian/archiver - common rec - docs! +<li>Fix signed/unsigned problems. +<li>Fix <code><nobr>JMP FAR label</nobr></code> and +<code><nobr>CALL FAR label</nobr></code>. +<li>Add new multisection support - map files - fix align bug +<li>Fix sysexit, movhps/movlps reg,reg bugs in insns.dat +<li><code><nobr>Q</nobr></code> or <code><nobr>O</nobr></code> suffixes +indicate octal +<li>Support Prescott new instructions (PNI). +<li>Cyrix <code><nobr>XSTORE</nobr></code> instruction. +</ul> +<h4><a name="section-C.2.5">C.2.5 Version 0.98.35</a></h4> +<ul> +<li>Fix build failure on 16-bit DOS (Makefile.bc3 workaround for compiler +bug.) +<li>Fix dependencies and compiler warnings. +<li>Add "const" in a number of places. +<li>Add -X option to specify error reporting format (use -Xvc to integrate +with Microsoft Visual Studio.) +<li>Minor changes for code legibility. +<li>Drop use of tmpnam() in rdoff (security fix.) +</ul> +<h4><a name="section-C.2.6">C.2.6 Version 0.98.34</a></h4> +<ul> +<li>Correct additional address-size vs. operand-size confusions. +<li>Generate dependencies for all Makefiles automatically. +<li>Add support for unimplemented (but theoretically available) registers +such as tr0 and cr5. Segment registers 6 and 7 are called segr6 and segr7 +for the operations which they can be represented. +<li>Correct some disassembler bugs related to redundant address-size +prefixes. Some work still remains in this area. +<li>Correctly generate an error for things like "SEG eax". +<li>Add the JMPE instruction, enabled by "CPU IA64". +<li>Correct compilation on newer gcc/glibc platforms. +<li>Issue an error on things like "jmp far eax". +</ul> +<h4><a name="section-C.2.7">C.2.7 Version 0.98.33</a></h4> +<ul> +<li>New __NASM_PATCHLEVEL__ and __NASM_VERSION_ID__ standard macros to +round out the version-query macros. version.pl now understands X.YYplWW or +X.YY.ZZplWW as a version number, equivalent to X.YY.ZZ.WW (or X.YY.0.WW, as +appropriate). +<li>New keyword "strict" to disable the optimization of specific operands. +<li>Fix the handing of size overrides with JMP instructions (instructions +such as "jmp dword foo".) +<li>Fix the handling of "ABSOLUTE label", where "label" points into a +relocatable segment. +<li>Fix OBJ output format with lots of externs. +<li>More documentation updates. +<li>Add -Ov option to get verbose information about optimizations. +<li>Undo a braindead change which broke <code><nobr>%elif</nobr></code> +directives. +<li>Makefile updates. +</ul> +<h4><a name="section-C.2.8">C.2.8 Version 0.98.32</a></h4> +<ul> +<li>Fix NASM crashing when <code><nobr>%macro</nobr></code> directives were +left unterminated. +<li>Lots of documentation updates. +<li>Complete rewrite of the PostScript/PDF documentation generator. +<li>The MS Visual C++ Makefile was updated and corrected. +<li>Recognize .rodata as a standard section name in ELF. +<li>Fix some obsolete Perl4-isms in Perl scripts. +<li>Fix configure.in to work with autoconf 2.5x. +<li>Fix a couple of "make cleaner" misses. +<li>Make the normal "./configure && make" work with Cygwin. +</ul> +<h4><a name="section-C.2.9">C.2.9 Version 0.98.31</a></h4> +<ul> +<li>Correctly build in a separate object directory again. +<li>Derive all references to the version number from the version file. +<li>New standard macros __NASM_SUBMINOR__ and __NASM_VER__ macros. +<li>Lots of Makefile updates and bug fixes. +<li>New <code><nobr>%ifmacro</nobr></code> directive to test for multiline +macros. +<li>Documentation updates. +<li>Fixes for 16-bit OBJ format output. +<li>Changed the NASM environment variable to NASMENV. +</ul> +<h4><a name="section-C.2.10">C.2.10 Version 0.98.30</a></h4> +<ul> +<li>Changed doc files a lot: completely removed old READMExx and Wishlist +files, incorporating all information in CHANGES and TODO. +<li>I waited a long time to rename zoutieee.c to (original) outieee.c +<li>moved all output modules to output/ subdirectory. +<li>Added 'make strip' target to strip debug info from nasm & ndisasm. +<li>Added INSTALL file with installation instructions. +<li>Added -v option description to nasm man. +<li>Added dist makefile target to produce source distributions. +<li>16-bit support for ELF output format (GNU extension, but useful.) +</ul> +<h4><a name="section-C.2.11">C.2.11 Version 0.98.28</a></h4> +<ul> +<li>Fastcooked this for Debian's Woody release: Frank applied the INCBIN +bug patch to 0.98.25alt and called it 0.98.28 to not confuse poor little +apt-get. +</ul> +<h4><a name="section-C.2.12">C.2.12 Version 0.98.26</a></h4> +<ul> +<li>Reorganised files even better from 0.98.25alt +</ul> +<h4><a name="section-C.2.13">C.2.13 Version 0.98.25alt</a></h4> +<ul> +<li>Prettified the source tree. Moved files to more reasonable places. +<li>Added findleak.pl script to misc/ directory. +<li>Attempted to fix doc. +</ul> +<h4><a name="section-C.2.14">C.2.14 Version 0.98.25</a></h4> +<ul> +<li>Line continuation character <code><nobr>\</nobr></code>. +<li>Docs inadvertantly reverted - "dos packaging". +</ul> +<h4><a name="section-C.2.15">C.2.15 Version 0.98.24p1</a></h4> +<ul> +<li>FIXME: Someone, document this please. +</ul> +<h4><a name="section-C.2.16">C.2.16 Version 0.98.24</a></h4> +<ul> +<li>Documentation - Ndisasm doc added to Nasm.doc. +</ul> +<h4><a name="section-C.2.17">C.2.17 Version 0.98.23</a></h4> +<ul> +<li>Attempted to remove rdoff version1 +<li>Lino Mastrodomenico's patches to preproc.c (%$$ bug?). +</ul> +<h4><a name="section-C.2.18">C.2.18 Version 0.98.22</a></h4> +<ul> +<li>Update rdoff2 - attempt to remove v1. +</ul> +<h4><a name="section-C.2.19">C.2.19 Version 0.98.21</a></h4> +<ul> +<li>Optimization fixes. +</ul> +<h4><a name="section-C.2.20">C.2.20 Version 0.98.20</a></h4> +<ul> +<li>Optimization fixes. +</ul> +<h4><a name="section-C.2.21">C.2.21 Version 0.98.19</a></h4> +<ul> +<li>H. J. Lu's patch back out. +</ul> +<h4><a name="section-C.2.22">C.2.22 Version 0.98.18</a></h4> +<ul> +<li>Added ".rdata" to "-f win32". +</ul> +<h4><a name="section-C.2.23">C.2.23 Version 0.98.17</a></h4> +<ul> +<li>H. J. Lu's "bogus elf" patch. (Red Hat problem?) +</ul> +<h4><a name="section-C.2.24">C.2.24 Version 0.98.16</a></h4> +<ul> +<li>Fix whitespace before "[section ..." bug. +</ul> +<h4><a name="section-C.2.25">C.2.25 Version 0.98.15</a></h4> +<ul> +<li>Rdoff changes (?). +<li>Fix fixes to memory leaks. +</ul> +<h4><a name="section-C.2.26">C.2.26 Version 0.98.14</a></h4> +<ul> +<li>Fix memory leaks. +</ul> +<h4><a name="section-C.2.27">C.2.27 Version 0.98.13</a></h4> +<ul> +<li>There was no 0.98.13 +</ul> +<h4><a name="section-C.2.28">C.2.28 Version 0.98.12</a></h4> +<ul> +<li>Update optimization (new function of "-O1") +<li>Changes to test/bintest.asm (?). +</ul> +<h4><a name="section-C.2.29">C.2.29 Version 0.98.11</a></h4> +<ul> +<li>Optimization changes. +<li>Ndisasm fixed. +</ul> +<h4><a name="section-C.2.30">C.2.30 Version 0.98.10</a></h4> +<ul> +<li>There was no 0.98.10 +</ul> +<h4><a name="section-C.2.31">C.2.31 Version 0.98.09</a></h4> +<ul> +<li>Add multiple sections support to "-f bin". +<li>Changed GLOBAL_TEMP_BASE in outelf.c from 6 to 15. +<li>Add "-v" as an alias to the "-r" switch. +<li>Remove "#ifdef" from Tasm compatibility options. +<li>Remove redundant size-overrides on "mov ds, ex", etc. +<li>Fixes to SSE2, other insns.dat (?). +<li>Enable uppercase "I" and "P" switches. +<li>Case insinsitive "seg" and "wrt". +<li>Update install.sh (?). +<li>Allocate tokens in blocks. +<li>Improve "invalid effective address" messages. +</ul> +<h4><a name="section-C.2.32">C.2.32 Version 0.98.08</a></h4> +<ul> +<li>Add "<code><nobr>%strlen</nobr></code>" and +"<code><nobr>%substr</nobr></code>" macro operators +<li>Fixed broken c16.mac. +<li>Unterminated string error reported. +<li>Fixed bugs as per 0.98bf +</ul> +<h4><a name="section-C.2.33">C.2.33 Version 0.98.09b with John Coffman patches released 28-Oct-2001</a></h4> +<p>Changes from 0.98.07 release to 98.09b as of 28-Oct-2001 +<ul> +<li>More closely compatible with 0.98 when -O0 is implied or specified. Not +strictly identical, since backward branches in range of short offsets are +recognized, and signed byte values with no explicit size specification will +be assembled as a single byte. +<li>More forgiving with the PUSH instruction. 0.98 requires a size to be +specified always. 0.98.09b will imply the size from the current BITS +setting (16 or 32). +<li>Changed definition of the optimization flag: +</ul> +<p>-O0 strict two-pass assembly, JMP and Jcc are handled more like 0.98, +except that back- ward JMPs are short, if possible. +<p>-O1 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. +<p>-O2 multi-pass optimization, minimize branch offsets; also will minimize +signed immed- iate bytes, overriding size specification. +<p>-O3 like -O2, but more passes taken, if needed +<h4><a name="section-C.2.34">C.2.34 Version 0.98.07 released 01/28/01</a></h4> +<ul> +<li>Added Stepane Denis' SSE2 instructions to a *working* version of the +code - some earlier versions were based on broken code - sorry 'bout that. +version "0.98.07" +</ul> +<p>01/28/01 +<ul> +<li>Cosmetic modifications to nasm.c, nasm.h, AUTHORS, MODIFIED +</ul> +<h4><a name="section-C.2.35">C.2.35 Version 0.98.06f released 01/18/01</a></h4> +<ul> +<li>- Add "metalbrain"s jecxz bug fix in insns.dat - alter nasmdoc.src to +match - version "0.98.06f" +</ul> +<h4><a name="section-C.2.36">C.2.36 Version 0.98.06e released 01/09/01</a></h4> +<ul> +<li>Removed the "outforms.h" file - it appears to be someone's old backup +of "outform.h". version "0.98.06e" +</ul> +<p>01/09/01 +<ul> +<li>fbk - finally added the fix for the "multiple %includes bug", known +since 7/27/99 - reported originally (?) and sent to us by Austin Lunnen - +he reports that John Fine had a fix within the day. Here it is... +<li>Nelson Rush resigns from the group. Big thanks to Nelson for his +leadership and enthusiasm in getting these changes incorporated into Nasm! +<li>fbk - [list +], [list -] directives - ineptly implemented, should be +re-written or removed, perhaps. +<li>Brian Raiter / fbk - "elfso bug" fix - applied to aoutb format as well +- testing might be desirable... +</ul> +<p>08/07/00 +<ul> +<li>James Seter - -postfix, -prefix command line switches. +<li>Yuri Zaporogets - rdoff utility changes. +</ul> +<h4><a name="section-C.2.37">C.2.37 Version 0.98p1</a></h4> +<ul> +<li>GAS-like palign (Panos Minos) +<li>FIXME: Someone, fill this in with details +</ul> +<h4><a name="section-C.2.38">C.2.38 Version 0.98bf (bug-fixed)</a></h4> +<ul> +<li>Fixed - elf and aoutb bug - shared libraries - multiple "%include" bug +in "-f obj" - jcxz, jecxz bug - unrecognized option bug in ndisasm +</ul> +<h4><a name="section-C.2.39">C.2.39 Version 0.98.03 with John Coffman's changes released 27-Jul-2000</a></h4> +<ul> +<li>Added signed byte optimizations for the 0x81/0x83 class of +instructions: ADC, ADD, AND, CMP, OR, SBB, SUB, XOR: when used as 'ADD +reg16,imm' or 'ADD reg32,imm.' Also optimization of signed byte form of +'PUSH imm' and 'IMUL reg,imm'/'IMUL reg,reg,imm.' No size specification is +needed. +<li>Added multi-pass JMP and Jcc offset optimization. Offsets on forward +references will preferentially use the short form, without the need to code +a specific size (short or near) for the branch. Added instructions for 'Jcc +label' to use the form 'Jnotcc $+3/JMP label', in cases where a short +offset is out of bounds. If compiling for a 386 or higher CPU, then the 386 +form of Jcc will be used instead. +</ul> +<p>This feature is controlled by a new command-line switch: "O", (upper +case letter O). "-O0" reverts the assembler to no extra optimization +passes, "-O1" allows up to 5 extra passes, and "-O2"(default), allows up to +10 extra optimization passes. +<ul> +<li>Added a new directive: 'cpu XXX', where XXX is any of: 8086, 186, 286, +386, 486, 586, pentium, 686, PPro, P2, P3 or Katmai. All are case +insensitive. All instructions will be selected only if they apply to the +selected cpu or lower. Corrected a couple of bugs in cpu-dependence in +'insns.dat'. +<li>Added to 'standard.mac', the "use16" and "use32" forms of the "bits +16/32" directive. This is nothing new, just conforms to a lot of other +assemblers. (minor) +<li>Changed label allocation from 320/32 (10000 labels @ 200K+) to 32/37 +(1000 labels); makes running under DOS much easier. Since additional label +space is allocated dynamically, this should have no effect on large +programs with lots of labels. The 37 is a prime, believed to be better for +hashing. (minor) +</ul> +<h4><a name="section-C.2.40">C.2.40 Version 0.98.03</a></h4> +<p>"Integrated patchfile 0.98-0.98.01. I call this version 0.98.03 for +historical reasons: 0.98.02 was trashed." --John Coffman +<johninsd@san.rr.com>, 27-Jul-2000 +<ul> +<li>Kendall Bennett's SciTech MGL changes +<li>Note that you must define "TASM_COMPAT" at compile-time to get the Tasm +Ideal Mode compatibility. +<li>All changes can be compiled in and out using the TASM_COMPAT macros, +and when compiled without TASM_COMPAT defined we get the exact same binary +as the unmodified 0.98 sources. +<li>standard.mac, macros.c: Added macros to ignore TASM directives before +first include +<li>nasm.h: Added extern declaration for tasm_compatible_mode +<li>nasm.c: Added global variable tasm_compatible_mode +<li>Added command line switch for TASM compatible mode (-t) +<li>Changed version command line to reflect when compiled with TASM +additions +<li>Added response file processing to allow all arguments on a single line +(response file is @resp rather than -@resp for NASM format). +<li>labels.c: Changes islocal() macro to support TASM style @@local labels. +<li>Added islocalchar() macro to support TASM style @@local labels. +<li>parser.c: Added support for TASM style memory references (ie: mov +[DWORD eax],10 rather than the NASM style mov DWORD [eax],10). +<li>preproc.c: Added new directives, <code><nobr>%arg</nobr></code>, +<code><nobr>%local</nobr></code>, <code><nobr>%stacksize</nobr></code> to +directives table +<li>Added support for TASM style directives without a leading % symbol. +<li>Integrated a block of changes from Andrew Zabolotny +<bit@eltech.ru>: +<li>A new keyword <code><nobr>%xdefine</nobr></code> and its +case-insensitive counterpart <code><nobr>%ixdefine</nobr></code>. They work +almost the same way as <code><nobr>%define</nobr></code> and +<code><nobr>%idefine</nobr></code> but expand the definition immediately, +not on the invocation. Something like a cross between +<code><nobr>%define</nobr></code> and <code><nobr>%assign</nobr></code>. +The "x" suffix stands for "eXpand", so "xdefine" can be deciphered as +"expand-and-define". Thus you can do things like this: +</ul> +<p><pre> + %assign ofs 0 + + %macro arg 1 + %xdefine %1 dword [esp+ofs] + %assign ofs ofs+4 + %endmacro +</pre> +<ul> +<li>Changed the place where the expansion of %$name macros are expanded. +Now they are converted into ..@ctxnum.name form when detokenizing, so there +are no quirks as before when using %$name arguments to macros, in macros +etc. For example: +</ul> +<p><pre> + %macro abc 1 + %define %1 hello + %endm + + abc %$here + %$here +</pre> +<p>Now last line will be expanded into "hello" as expected. This also +allows for lots of goodies, a good example are extended "proc" macros +included in this archive. +<ul> +<li>Added a check for "cstk" in smacro_defined() before calling get_ctx() - +this allows for things like: +</ul> +<p><pre> + %ifdef %$abc + %endif +</pre> +<p>to work without warnings even in no context. +<ul> +<li>Added a check for "cstk" in %if*ctx and %elif*ctx directives - this +allows to use <code><nobr>%ifctx</nobr></code> without excessive warnings. +If there is no active context, <code><nobr>%ifctx</nobr></code> goes +through "false" branch. +<li>Removed "user error: " prefix with <code><nobr>%error</nobr></code> +directive: it just clobbers the output and has absolutely no functionality. +Besides, this allows to write macros that does not differ from built-in +functions in any way. +<li>Added expansion of string that is output by +<code><nobr>%error</nobr></code> directive. Now you can do things like: +</ul> +<p><pre> + %define hello(x) Hello, x! + + %define %$name andy + %error "hello(%$name)" +</pre> +<p>Same happened with <code><nobr>%include</nobr></code> directive. +<ul> +<li>Now all directives that expect an identifier will try to expand and +concatenate everything without whitespaces in between before usage. For +example, with "unfixed" nasm the commands +</ul> +<p><pre> + %define %$abc hello + %define __%$abc goodbye + __%$abc +</pre> +<p>would produce "incorrect" output: last line will expand to +<p><pre> + hello goodbyehello +</pre> +<p>Not quite what you expected, eh? :-) The answer is that preprocessor +treats the <code><nobr>%define</nobr></code> construct as if it would be +<p><pre> + %define __ %$abc goodbye +</pre> +<p>(note the white space between __ and %$abc). After my "fix" it will +"correctly" expand into +<p><pre> + goodbye +</pre> +<p>as expected. Note that I use quotes around words "correct", "incorrect" +etc because this is rather a feature not a bug; however current behaviour +is more logical (and allows more advanced macro usage :-). +<p>Same change was applied to: +<code><nobr>%push</nobr></code>,<code><nobr>%macro</nobr></code>,<code><nobr>%imacro</nobr></code>,<code><nobr>%define</nobr></code>,<code><nobr>%idefine</nobr></code>,<code><nobr>%xdefine</nobr></code>,<code><nobr>%ixdefine</nobr></code>, +<code><nobr>%assign</nobr></code>,<code><nobr>%iassign</nobr></code>,<code><nobr>%undef</nobr></code> +<ul> +<li>A new directive [WARNING {+|-}warning-id] have been added. It works +only if the assembly phase is enabled (i.e. it doesn't work with nasm -e). +<li>A new warning type: macro-selfref. By default this warning is disabled; +when enabled NASM warns when a macro self-references itself; for example +the following source: +</ul> +<p><pre> + [WARNING macro-selfref] + + %macro push 1-* + %rep %0 + push %1 + %rotate 1 + %endrep + %endmacro + + push eax,ebx,ecx +</pre> +<p>will produce a warning, but if we remove the first line we won't see it +anymore (which is The Right Thing To Do {tm} IMHO since C preprocessor eats +such constructs without warnings at all). +<ul> +<li>Added a "error" routine to preprocessor which always will set ERR_PASS1 +bit in severity_code. This removes annoying repeated errors on first and +second passes from preprocessor. +<li>Added the %+ operator in single-line macros for concatenating two +identifiers. Usage example: +</ul> +<p><pre> + %define _myfunc _otherfunc + %define cextern(x) _ %+ x + cextern (myfunc) +</pre> +<p>After first expansion, third line will become "_myfunc". After this +expansion is performed again so it becomes "_otherunc". +<ul> +<li>Now if preprocessor is in a non-emitting state, no warning or error +will be emitted. Example: +</ul> +<p><pre> + %if 1 + mov eax,ebx + %else + put anything you want between these two brackets, + even macro-parameter references %1 or local + labels %$zz or macro-local labels %%zz - no + warning will be emitted. + %endif +</pre> +<ul> +<li>Context-local variables on expansion as a last resort are looked up in +outer contexts. For example, the following piece: +</ul> +<p><pre> + %push outer + %define %$a [esp] + + %push inner + %$a + %pop + %pop +</pre> +<p>will expand correctly the fourth line to [esp]; if we'll define another +%$a inside the "inner" context, it will take precedence over outer +definition. However, this modification has been applied only to +expand_smacro and not to smacro_define: as a consequence expansion looks in +outer contexts, but <code><nobr>%ifdef</nobr></code> won't look in outer +contexts. +<p>This behaviour is needed because we don't want nested contexts to act on +already defined local macros. Example: +<p><pre> + %define %$arg1 [esp+4] + test eax,eax + if nz + mov eax,%$arg1 + endif +</pre> +<p>In this example the "if" mmacro enters into the "if" context, so %$arg1 +is not valid anymore inside "if". Of course it could be worked around by +using explicitely %$$arg1 but this is ugly IMHO. +<ul> +<li>Fixed memory leak in <code><nobr>%undef</nobr></code>. The origline +wasn't freed before exiting on success. +<li>Fixed trap in preprocessor when line expanded to empty set of tokens. +This happens, for example, in the following case: +</ul> +<p><pre> + #define SOMETHING + SOMETHING +</pre> +<h4><a name="section-C.2.41">C.2.41 Version 0.98</a></h4> +<p>All changes since NASM 0.98p3 have been produced by H. Peter Anvin +<hpa@zytor.com>. +<ul> +<li>The documentation comment delimiter is +<li>Allow EQU definitions to refer to external labels; reported by Pedro +Gimeno. +<li>Re-enable support for RDOFF v1; reported by Pedro Gimeno. +<li>Updated License file per OK from Simon and Julian. +</ul> +<h4><a name="section-C.2.42">C.2.42 Version 0.98p9</a></h4> +<ul> +<li>Update documentation (although the instruction set reference will have +to wait; I don't want to hold up the 0.98 release for it.) +<li>Verified that the NASM implementation of the PEXTRW and PMOVMSKB +instructions is correct. The encoding differs from what the Intel manuals +document, but the Pentium III behaviour matches NASM, not the Intel +manuals. +<li>Fix handling of implicit sizes in PSHUFW and PINSRW, reported by Stefan +Hoffmeister. +<li>Resurrect the -s option, which was removed when changing the diagnostic +output to stdout. +</ul> +<h4><a name="section-C.2.43">C.2.43 Version 0.98p8</a></h4> +<ul> +<li>Fix for "DB" when NASM is running on a bigendian machine. +<li>Invoke insns.pl once for each output script, making Makefile.in legal +for "make -j". +<li>Improve the Unix configure-based makefiles to make package creation +easier. +<li>Included an RPM .spec file for building RPM (RedHat Package Manager) +packages on Linux or Unix systems. +<li>Fix Makefile dependency problems. +<li>Change src/rdsrc.pl to include sectioning information in info output; +required for install-info to work. +<li>Updated the RDOFF distribution to version 2 from Jules; minor massaging +to make it compile in my environment. +<li>Split doc files that can be built by anyone with a Perl interpreter off +into a separate archive. +<li>"Dress rehearsal" release! +</ul> +<h4><a name="section-C.2.44">C.2.44 Version 0.98p7</a></h4> +<ul> +<li>Fixed opcodes with a third byte-sized immediate argument to not +complain if given "byte" on the immediate. +<li>Allow <code><nobr>%undef</nobr></code> to remove single-line macros +with arguments. This matches the behaviour of #undef in the C preprocessor. +<li>Allow -d, -u, -i and -p to be specified as -D, -U, -I and -P for +compatibility with most C compilers and preprocessors. This allows Makefile +options to be shared between cc and nasm, for example. +<li>Minor cleanups. +<li>Went through the list of Katmai instructions and hopefully fixed the +(rather few) mistakes in it. +<li>(Hopefully) fixed a number of disassembler bugs related to ambiguous +instructions (disambiguated by -p) and SSE instructions with REP. +<li>Fix for bug reported by Mark Junger: "call dword 0x12345678" should +work and may add an OSP (affected CALL, JMP, Jcc). +<li>Fix for environments when "stderr" isn't a compile-time constant. +</ul> +<h4><a name="section-C.2.45">C.2.45 Version 0.98p6</a></h4> +<ul> +<li>Took officially over coordination of the 0.98 release; so drop the p3.x +notation. Skipped p4 and p5 to avoid confusion with John Fine's J4 and J5 +releases. +<li>Update the documentation; however, it still doesn't include +documentation for the various new instructions. I somehow wonder if it +makes sense to have an instruction set reference in the assembler manual +when Intel et al have PDF versions of their manuals online. +<li>Recognize "idt" or "centaur" for the -p option to ndisasm. +<li>Changed error messages back to stderr where they belong, but add an -E +option to redirect them elsewhere (the DOS shell cannot redirect stderr.) +<li>-M option to generate Makefile dependencies (based on code from Alex +Verstak.) +<li><code><nobr>%undef</nobr></code> preprocessor directive, and -u option, +that undefines a single-line macro. +<li>OS/2 Makefile (Mkfiles/Makefile.os2) for Borland under OS/2; from Chuck +Crayne. +<li>Various minor bugfixes (reported by): - Dangling +<code><nobr>%s</nobr></code> in preproc.c (Martin Junker) +<li>THERE ARE KNOWN BUGS IN SSE AND THE OTHER KATMAI INSTRUCTIONS. I am on +a trip and didn't bring the Katmai instruction reference, so I can't work +on them right now. +<li>Updated the License file per agreement with Simon and Jules to include +a GPL distribution clause. +</ul> +<h4><a name="section-C.2.46">C.2.46 Version 0.98p3.7</a></h4> +<ul> +<li>(Hopefully) fixed the canned Makefiles to include the outrdf2 and +zoutieee modules. +<li>Renamed changes.asm to changed.asm. +</ul> +<h4><a name="section-C.2.47">C.2.47 Version 0.98p3.6</a></h4> +<ul> +<li>Fixed a bunch of instructions that were added in 0.98p3.5 which had +memory operands, and the address-size prefix was missing from the +instruction pattern. +</ul> +<h4><a name="section-C.2.48">C.2.48 Version 0.98p3.5</a></h4> +<ul> +<li>Merged in changes from John S. Fine's 0.98-J5 release. John's based +0.98-J5 on my 0.98p3.3 release; this merges the changes. +<li>Expanded the instructions flag field to a long so we can fit more +flags; mark SSE (KNI) and AMD or Katmai-specific instructions as such. +<li>Fix the "PRIV" flag on a bunch of instructions, and create new "PROT" +flag for protected-mode-only instructions (orthogonal to if the instruction +is privileged!) and new "SMM" flag for SMM-only instructions. +<li>Added AMD-only SYSCALL and SYSRET instructions. +<li>Make SSE actually work, and add new Katmai MMX instructions. +<li>Added a -p (preferred vendor) option to ndisasm so that it can +distinguish e.g. Cyrix opcodes also used in SSE. For example: +</ul> +<p><pre> + ndisasm -p cyrix aliased.bin + 00000000 670F514310 paddsiw mm0,[ebx+0x10] + 00000005 670F514320 paddsiw mm0,[ebx+0x20] + ndisasm -p intel aliased.bin + 00000000 670F514310 sqrtps xmm0,[ebx+0x10] + 00000005 670F514320 sqrtps xmm0,[ebx+0x20] +</pre> +<ul> +<li>Added a bunch of Cyrix-specific instructions. +</ul> +<h4><a name="section-C.2.49">C.2.49 Version 0.98p3.4</a></h4> +<ul> +<li>Made at least an attempt to modify all the additional Makefiles (in the +Mkfiles directory). I can't test it, but this was the best I could do. +<li>DOS DJGPP+"Opus Make" Makefile from John S. Fine. +<li>changes.asm changes from John S. Fine. +</ul> +<h4><a name="section-C.2.50">C.2.50 Version 0.98p3.3</a></h4> +<ul> +<li>Patch from Conan Brink to allow nesting of +<code><nobr>%rep</nobr></code> directives. +<li>If we're going to allow INT01 as an alias for INT1/ICEBP (one of Jules +0.98p3 changes), then we should allow INT03 as an alias for INT3 as well. +<li>Updated changes.asm to include the latest changes. +<li>Tried to clean up the <CR>s that had snuck in from a DOS/Windows +environment into my Unix environment, and try to make sure than DOS/Windows +users get them back. +<li>We would silently generate broken tools if insns.dat wasn't sorted +properly. Change insns.pl so that the order doesn't matter. +<li>Fix bug in insns.pl (introduced by me) which would cause conditional +instructions to have an extra "cc" in disassembly, e.g. "jnz" disassembled +as "jccnz". +</ul> +<h4><a name="section-C.2.51">C.2.51 Version 0.98p3.2</a></h4> +<ul> +<li>Merged in John S. Fine's changes from his 0.98-J4 prerelease; see +http://www.csoft.net/cz/johnfine/ +<li>Changed previous "spotless" Makefile target (appropriate for +distribution) to "distclean", and added "cleaner" target which is same as +"clean" except deletes files generated by Perl scripts; "spotless" is +union. +<li>Removed BASIC programs from distribution. Get a Perl interpreter +instead (see below.) +<li>Calling this "pre-release 3.2" rather than "p3-hpa2" because of John's +contributions. +<li>Actually link in the IEEE output format (zoutieee.c); fix a bunch of +compiler warnings in that file. Note I don't know what IEEE output is +supposed to look like, so these changes were made "blind". +</ul> +<h4><a name="section-C.2.52">C.2.52 Version 0.98p3-hpa</a></h4> +<ul> +<li>Merged nasm098p3.zip with nasm-0.97.tar.gz to create a fully buildable +version for Unix systems (Makefile.in updates, etc.) +<li>Changed insns.pl to create the instruction tables in nasm.h and +names.c, so that a new instruction can be added by adding it *only* to +insns.dat. +<li>Added the following new instructions: SYSENTER, SYSEXIT, FXSAVE, +FXRSTOR, UD1, UD2 (the latter two are two opcodes that Intel guarantee will +never be used; one of them is documented as UD2 in Intel documentation, the +other one just as "Undefined Opcode" -- calling it UD1 seemed to make +sense.) +<li>MAX_SYMBOL was defined to be 9, but LOADALL286 and LOADALL386 are 10 +characters long. Now MAX_SYMBOL is derived from insns.dat. +<li>A note on the BASIC programs included: forget them. insns.bas is +already out of date. Get yourself a Perl interpreter for your platform of +choice at +<a href="http://www.cpan.org/ports/index.html">http://www.cpan.org/ports/index.html</a>. +</ul> +<h4><a name="section-C.2.53">C.2.53 Version 0.98 pre-release 3</a></h4> +<ul> +<li>added response file support, improved command line handling, new layout +help screen +<li>fixed limit checking bug, 'OUT byte nn, reg' bug, and a couple of rdoff +related bugs, updated Wishlist; 0.98 Prerelease 3. +</ul> +<h4><a name="section-C.2.54">C.2.54 Version 0.98 pre-release 2</a></h4> +<ul> +<li>fixed bug in outcoff.c to do with truncating section names longer than +8 characters, referencing beyond end of string; 0.98 pre-release 2 +</ul> +<h4><a name="section-C.2.55">C.2.55 Version 0.98 pre-release 1</a></h4> +<ul> +<li>Fixed a bug whereby STRUC didn't work at all in RDF. +<li>Fixed a problem with group specification in PUBDEFs in OBJ. +<li>Improved ease of adding new output formats. Contribution due to Fox +Cutter. +<li>Fixed a bug in relocations in the `bin' format: was showing up when a +relocatable reference crossed an 8192-byte boundary in any output section. +<li>Fixed a bug in local labels: local-label lookups were inconsistent +between passes one and two if an EQU occurred between the definition of a +global label and the subsequent use of a local label local to that global. +<li>Fixed a seg-fault in the preprocessor (again) which happened when you +use a blank line as the first line of a multi-line macro definition and +then defined a label on the same line as a call to that macro. +<li>Fixed a stale-pointer bug in the handling of the NASM environment +variable. Thanks to Thomas McWilliams. +<li>ELF had a hard limit on the number of sections which caused segfaults +when transgressed. Fixed. +<li>Added ability for ndisasm to read from stdin by using `-' as the +filename. +<li>ndisasm wasn't outputting the TO keyword. Fixed. +<li>Fixed error cascade on bogus expression in +<code><nobr>%if</nobr></code> - an error in evaluation was causing the +entire <code><nobr>%if</nobr></code> to be discarded, thus creating trouble +later when the <code><nobr>%else</nobr></code> or +<code><nobr>%endif</nobr></code> was encountered. +<li>Forward reference tracking was instruction-granular not operand- +granular, which was causing 286-specific code to be generated needlessly on +code of the form `shr word [forwardref],1'. Thanks to Jim Hague for sending +a patch. +<li>All messages now appear on stdout, as sending them to stderr serves no +useful purpose other than to make redirection difficult. +<li>Fixed the problem with EQUs pointing to an external symbol - this now +generates an error message. +<li>Allowed multiple size prefixes to an operand, of which only the first +is taken into account. +<li>Incorporated John Fine's changes, including fixes of a large number of +preprocessor bugs, some small problems in OBJ, and a reworking of label +handling to define labels before their line is assembled, rather than +after. +<li>Reformatted a lot of the source code to be more readable. Included +'coding.txt' as a guideline for how to format code for contributors. +<li>Stopped nested <code><nobr>%reps</nobr></code> causing a panic - they +now cause a slightly more friendly error message instead. +<li>Fixed floating point constant problems (patch by Pedro Gimeno) +<li>Fixed the return value of insn_size() not being checked for -1, +indicating an error. +<li>Incorporated 3Dnow! instructions. +<li>Fixed the 'mov eax, eax + ebx' bug. +<li>Fixed the GLOBAL EQU bug in ELF. Released developers release 3. +<li>Incorporated John Fine's command line parsing changes +<li>Incorporated David Lindauer's OMF debug support +<li>Made changes for LCC 4.0 support +(<code><nobr>__NASM_CDecl__</nobr></code>, removed register size +specification warning when sizes agree). +</ul> +<h3><a name="section-C.3">C.3 NASM 0.9 Series</a></h3> +<p>Revisions before 0.98. +<h4><a name="section-C.3.1">C.3.1 Version 0.97 released December 1997</a></h4> +<ul> +<li>This was entirely a bug-fix release to 0.96, which seems to have got +cursed. Silly me. +<li>Fixed stupid mistake in OBJ which caused `MOV EAX,<constant>' to +fail. Caused by an error in the `MOV EAX,<segment>' support. +<li>ndisasm hung at EOF when compiled with lcc on Linux because lcc on +Linux somehow breaks feof(). ndisasm now does not rely on feof(). +<li>A heading in the documentation was missing due to a markup error in the +indexing. Fixed. +<li>Fixed failure to update all pointers on realloc() within extended- +operand code in parser.c. Was causing wrong behaviour and seg faults on +lines such as `dd 0.0,0.0,0.0,0.0,...' +<li>Fixed a subtle preprocessor bug whereby invoking one multi-line macro +on the first line of the expansion of another, when the second had been +invoked with a label defined before it, didn't expand the inner macro. +<li>Added internal.doc back in to the distribution archives - it was +missing in 0.96 *blush* +<li>Fixed bug causing 0.96 to be unable to assemble its own test files, +specifically objtest.asm. *blush again* +<li>Fixed seg-faults and bogus error messages caused by mismatching +<code><nobr>%rep</nobr></code> and <code><nobr>%endrep</nobr></code> within +multi-line macro definitions. +<li>Fixed a problem with buffer overrun in OBJ, which was causing +corruption at ends of long PUBDEF records. +<li>Separated DOS archives into main-program and documentation to reduce +download size. +</ul> +<h4><a name="section-C.3.2">C.3.2 Version 0.96 released November 1997</a></h4> +<ul> +<li>Fixed a bug whereby, if `nasm sourcefile' would cause a filename +collision warning and put output into `nasm.out', then `nasm sourcefile -o +outputfile' still gave the warning even though the `-o' was honoured. Fixed +name pollution under Digital UNIX: one of its header files defined R_SP, +which broke the enum in nasm.h. +<li>Fixed minor instruction table problems: FUCOM and FUCOMP didn't have +two-operand forms; NDISASM didn't recognise the longer register forms of +PUSH and POP (eg FF F3 for PUSH BX); TEST mem,imm32 was flagged as +undocumented; the 32-bit forms of CMOV had 16-bit operand size prefixes; +`AAD imm' and `AAM imm' are no longer flagged as undocumented because the +Intel Architecture reference documents them. +<li>Fixed a problem with the local-label mechanism, whereby strange types +of symbol (EQUs, auto-defined OBJ segment base symbols) interfered with the +`previous global label' value and screwed up local labels. +<li>Fixed a bug whereby the stub preprocessor didn't communicate with the +listing file generator, so that the -a and -l options in conjunction would +produce a useless listing file. +<li>Merged `os2' object file format back into `obj', after discovering that +`obj' _also_ shouldn't have a link pass separator in a module containing a +non-trivial MODEND. Flat segments are now declared using the FLAT +attribute. `os2' is no longer a valid object format name: use `obj'. +<li>Removed the fixed-size temporary storage in the evaluator. Very very +long expressions (like `mov ax,1+1+1+1+...' for two hundred 1s or so) +should now no longer crash NASM. +<li>Fixed a bug involving segfaults on disassembly of MMX instructions, by +changing the meaning of one of the operand-type flags in nasm.h. This may +cause other apparently unrelated MMX problems; it needs to be tested +thoroughly. +<li>Fixed some buffer overrun problems with large OBJ output files. Thanks +to DJ Delorie for the bug report and fix. +<li>Made preprocess-only mode actually listen to the +<code><nobr>%line</nobr></code> markers as it prints them, so that it can +report errors more sanely. +<li>Re-designed the evaluator to keep more sensible track of expressions +involving forward references: can now cope with previously-nightmare +situations such as: +</ul> +<p><pre> + mov ax,foo | bar + foo equ 1 + bar equ 2 +</pre> +<ul> +<li>Added the ALIGN and ALIGNB standard macros. +<li>Added PIC support in ELF: use of WRT to obtain the four extra +relocation types needed. +<li>Added the ability for output file formats to define their own +extensions to the GLOBAL, COMMON and EXTERN directives. +<li>Implemented common-variable alignment, and global-symbol type and size +declarations, in ELF. +<li>Implemented NEAR and FAR keywords for common variables, plus far-common +element size specification, in OBJ. +<li>Added a feature whereby EXTERNs and COMMONs in OBJ can be given a +default WRT specification (either a segment or a group). +<li>Transformed the Unix NASM archive into an auto-configuring package. +<li>Added a sanity-check for people applying SEG to things which are +already segment bases: this previously went unnoticed by the SEG processing +and caused OBJ-driver panics later. +<li>Added the ability, in OBJ format, to deal with `MOV +EAX,<segment>' type references: OBJ doesn't directly support +dword-size segment base fixups, but as long as the low two bytes of the +constant term are zero, a word-size fixup can be generated instead and it +will work. +<li>Added the ability to specify sections' alignment requirements in Win32 +object files and pure binary files. +<li>Added preprocess-time expression evaluation: the +<code><nobr>%assign</nobr></code> (and <code><nobr>%iassign</nobr></code>) +directive and the bare <code><nobr>%if</nobr></code> (and +<code><nobr>%elif</nobr></code>) conditional. Added relational operators to +the evaluator, for use only in <code><nobr>%if</nobr></code> constructs: +the standard relationals = < > <= >= <> (and C-like +synonyms == and !=) plus low-precedence logical operators &&, ^^ +and ||. +<li>Added a preprocessor repeat construct: <code><nobr>%rep</nobr></code> / +<code><nobr>%exitrep</nobr></code> / <code><nobr>%endrep</nobr></code>. +<li>Added the __FILE__ and __LINE__ standard macros. +<li>Added a sanity check for number constants being greater than +0xFFFFFFFF. The warning can be disabled. +<li>Added the %0 token whereby a variadic multi-line macro can tell how +many parameters it's been given in a specific invocation. +<li>Added <code><nobr>%rotate</nobr></code>, allowing multi-line macro +parameters to be cycled. +<li>Added the `*' option for the maximum parameter count on multi-line +macros, allowing them to take arbitrarily many parameters. +<li>Added the ability for the user-level forms of EXTERN, GLOBAL and COMMON +to take more than one argument. +<li>Added the IMPORT and EXPORT directives in OBJ format, to deal with +Windows DLLs. +<li>Added some more preprocessor <code><nobr>%if</nobr></code> constructs: +<code><nobr>%ifidn</nobr></code> / <code><nobr>%ifidni</nobr></code> (exact +textual identity), and <code><nobr>%ifid</nobr></code> / +<code><nobr>%ifnum</nobr></code> / <code><nobr>%ifstr</nobr></code> (token +type testing). +<li>Added the ability to distinguish SHL AX,1 (the 8086 version) from SHL +AX,BYTE 1 (the 286-and-upwards version whose constant happens to be 1). +<li>Added NetBSD/FreeBSD/OpenBSD's variant of a.out format, complete with +PIC shared library features. +<li>Changed NASM's idiosyncratic handling of FCLEX, FDISI, FENI, FINIT, +FSAVE, FSTCW, FSTENV, and FSTSW to bring it into line with the otherwise +accepted standard. The previous behaviour, though it was a deliberate +feature, was a deliberate feature based on a misunderstanding. Apologies +for the inconvenience. +<li>Improved the flexibility of ABSOLUTE: you can now give it an expression +rather than being restricted to a constant, and it can take relocatable +arguments as well. +<li>Added the ability for a variable to be declared as EXTERN multiple +times, and the subsequent definitions are just ignored. +<li>We now allow instruction prefixes (CS, DS, LOCK, REPZ etc) to be alone +on a line (without a following instruction). +<li>Improved sanity checks on whether the arguments to EXTERN, GLOBAL and +COMMON are valid identifiers. +<li>Added misc/exebin.mac to allow direct generation of .EXE files by +hacking up an EXE header using DB and DW; also added test/binexe.asm to +demonstrate the use of this. Thanks to Yann Guidon for contributing the EXE +header code. +<li>ndisasm forgot to check whether the input file had been successfully +opened. Now it does. Doh! +<li>Added the Cyrix extensions to the MMX instruction set. +<li>Added a hinting mechanism to allow [EAX+EBX] and [EBX+EAX] to be +assembled differently. This is important since [ESI+EBP] and [EBP+ESI] have +different default base segment registers. +<li>Added support for the PharLap OMF extension for 4096-byte segment +alignment. +</ul> +<h4><a name="section-C.3.3">C.3.3 Version 0.95 released July 1997</a></h4> +<ul> +<li>Fixed yet another ELF bug. This one manifested if the user relied on +the default segment, and attempted to define global symbols without first +explicitly declaring the target segment. +<li>Added makefiles (for NASM and the RDF tools) to build Win32 console +apps under Symantec C++. Donated by Mark Junker. +<li>Added `macros.bas' and `insns.bas', QBasic versions of the Perl scripts +that convert `standard.mac' to `macros.c' and convert `insns.dat' to +`insnsa.c' and `insnsd.c'. Also thanks to Mark Junker. +<li>Changed the diassembled forms of the conditional instructions so that +JB is now emitted as JC, and other similar changes. Suggested list by +Ulrich Doewich. +<li>Added `@' to the list of valid characters to begin an identifier with. +<li>Documentary changes, notably the addition of the `Common Problems' +section in nasm.doc. +<li>Fixed a bug relating to 32-bit PC-relative fixups in OBJ. +<li>Fixed a bug in perm_copy() in labels.c which was causing exceptions in +cleanup_labels() on some systems. +<li>Positivity sanity check in TIMES argument changed from a warning to an +error following a further complaint. +<li>Changed the acceptable limits on byte and word operands to allow things +like `~10111001b' to work. +<li>Fixed a major problem in the preprocessor which caused seg-faults if +macro definitions contained blank lines or comment-only lines. +<li>Fixed inadequate error checking on the commas separating the arguments +to `db', `dw' etc. +<li>Fixed a crippling bug in the handling of macros with operand counts +defined with a `+' modifier. +<li>Fixed a bug whereby object file formats which stored the input file +name in the output file (such as OBJ and COFF) weren't doing so correctly +when the output file name was specified on the command line. +<li>Removed [INC] and [INCLUDE] support for good, since they were obsolete +anyway. +<li>Fixed a bug in OBJ which caused all fixups to be output in 16-bit +(old-format) FIXUPP records, rather than putting the 32-bit ones in +FIXUPP32 (new-format) records. +<li>Added, tentatively, OS/2 object file support (as a minor variant on +OBJ). +<li>Updates to Fox Cutter's Borland C makefile, Makefile.bc2. +<li>Removed a spurious second fclose() on the output file. +<li>Added the `-s' command line option to redirect all messages which would +go to stderr (errors, help text) to stdout instead. +<li>Added the `-w' command line option to selectively suppress some classes +of assembly warning messages. +<li>Added the `-p' pre-include and `-d' pre-define command-line options. +<li>Added an include file search path: the `-i' command line option. +<li>Fixed a silly little preprocessor bug whereby starting a line with a +`%!' environment-variable reference caused an `unknown directive' error. +<li>Added the long-awaited listing file support: the `-l' command line +option. +<li>Fixed a problem with OBJ format whereby, in the absence of any explicit +segment definition, non-global symbols declared in the implicit default +segment generated spurious EXTDEF records in the output. +<li>Added the NASM environment variable. +<li>From this version forward, Win32 console-mode binaries will be included +in the DOS distribution in addition to the 16-bit binaries. Added +Makefile.vc for this purpose. +<li>Added `return 0;' to test/objlink.c to prevent compiler warnings. +<li>Added the __NASM_MAJOR__ and __NASM_MINOR__ standard defines. +<li>Added an alternative memory-reference syntax in which prefixing an +operand with `&' is equivalent to enclosing it in square brackets, at +the request of Fox Cutter. +<li>Errors in pass two now cause the program to return a non-zero error +code, which they didn't before. +<li>Fixed the single-line macro cycle detection, which didn't work at all +on macros with no parameters (caused an infinite loop). Also changed the +behaviour of single-line macro cycle detection to work like cpp, so that +macros like `extrn' as given in the documentation can be implemented. +<li>Fixed the implementation of WRT, which was too restrictive in that you +couldn't do `mov ax,[di+abc wrt dgroup]' because (di+abc) wasn't a +relocatable reference. +</ul> +<h4><a name="section-C.3.4">C.3.4 Version 0.94 released April 1997</a></h4> +<ul> +<li>Major item: added the macro processor. +<li>Added undocumented instructions SMI, IBTS, XBTS and LOADALL286. Also +reorganised CMPXCHG instruction into early-486 and Pentium forms. Thanks to +Thobias Jones for the information. +<li>Fixed two more stupid bugs in ELF, which were causing `ld' to continue +to seg-fault in a lot of non-trivial cases. +<li>Fixed a seg-fault in the label manager. +<li>Stopped FBLD and FBSTP from _requiring_ the TWORD keyword, which is the +only option for BCD loads/stores in any case. +<li>Ensured FLDCW, FSTCW and FSTSW can cope with the WORD keyword, if +anyone bothers to provide it. Previously they complained unless no keyword +at all was present. +<li>Some forms of FDIV/FDIVR and FSUB/FSUBR were still inverted: a vestige +of a bug that I thought had been fixed in 0.92. This was fixed, hopefully +for good this time... +<li>Another minor phase error (insofar as a phase error can _ever_ be +minor) fixed, this one occurring in code of the form +</ul> +<p><pre> + rol ax,forward_reference + forward_reference equ 1 +</pre> +<ul> +<li>The number supplied to TIMES is now sanity-checked for positivity, and +also may be greater than 64K (which previously didn't work on 16-bit +systems). +<li>Added Watcom C makefiles, and misc/pmw.bat, donated by Dominik Behr. +<li>Added the INCBIN pseudo-opcode. +<li>Due to the advent of the preprocessor, the [INCLUDE] and [INC] +directives have become obsolete. They are still supported in this version, +with a warning, but won't be in the next. +<li>Fixed a bug in OBJ format, which caused incorrect object records to be +output when absolute labels were made global. +<li>Updates to RDOFF subdirectory, and changes to outrdf.c. +</ul> +<h4><a name="section-C.3.5">C.3.5 Version 0.93 released January 1997</a></h4> +<p>This release went out in a great hurry after semi-crippling bugs were +found in 0.92. +<ul> +<li>Really <em>did</em> fix the stack overflows this time. *blush* +<li>Had problems with EA instruction sizes changing between passes, when an +offset contained a forward reference and so 4 bytes were allocated for the +offset in pass one; by pass two the symbol had been defined and happened to +be a small absolute value, so only 1 byte got allocated, causing +instruction size mismatch between passes and hence incorrect address +calculations. Fixed. +<li>Stupid bug in the revised ELF section generation fixed (associated +string-table section for .symtab was hard-coded as 7, even when this didn't +fit with the real section table). Was causing `ld' to seg-fault under +Linux. +<li>Included a new Borland C makefile, Makefile.bc2, donated by Fox Cutter +<lmb@comtch.iea.com>. +</ul> +<h4><a name="section-C.3.6">C.3.6 Version 0.92 released January 1997</a></h4> +<ul> +<li>The FDIVP/FDIVRP and FSUBP/FSUBRP pairs had been inverted: this was +fixed. This also affected the LCC driver. +<li>Fixed a bug regarding 32-bit effective addresses of the form +<code><nobr>[other_register+ESP]</nobr></code>. +<li>Documentary changes, notably documentation of the fact that Borland +Win32 compilers use `obj' rather than `win32' object format. +<li>Fixed the COMENT record in OBJ files, which was formatted incorrectly. +<li>Fixed a bug causing segfaults in large RDF files. +<li>OBJ format now strips initial periods from segment and group +definitions, in order to avoid complications with the local label syntax. +<li>Fixed a bug in disassembling far calls and jumps in NDISASM. +<li>Added support for user-defined sections in COFF and ELF files. +<li>Compiled the DOS binaries with a sensible amount of stack, to prevent +stack overflows on any arithmetic expression containing parentheses. +<li>Fixed a bug in handling of files that do not terminate in a newline. +</ul> +<h4><a name="section-C.3.7">C.3.7 Version 0.91 released November 1996</a></h4> +<ul> +<li>Loads of bug fixes. +<li>Support for RDF added. +<li>Support for DBG debugging format added. +<li>Support for 32-bit extensions to Microsoft OBJ format added. +<li>Revised for Borland C: some variable names changed, makefile added. +<li>LCC support revised to actually work. +<li>JMP/CALL NEAR/FAR notation added. +<li>`a16', `o16', `a32' and `o32' prefixes added. +<li>Range checking on short jumps implemented. +<li>MMX instruction support added. +<li>Negative floating point constant support added. +<li>Memory handling improved to bypass 64K barrier under DOS. +<li><code><nobr>$</nobr></code> prefix to force treatment of reserved words +as identifiers added. +<li>Default-size mechanism for object formats added. +<li>Compile-time configurability added. +<li><code><nobr>#</nobr></code>, <code><nobr>@</nobr></code>, +<code><nobr>~</nobr></code> and c{?} are now valid characters in labels. +<li><code><nobr>-e</nobr></code> and <code><nobr>-k</nobr></code> options +in NDISASM added. +</ul> +<h4><a name="section-C.3.8">C.3.8 Version 0.90 released October 1996</a></h4> +<p>First release version. First support for object file output. Other +changes from previous version (0.3x) too numerous to document. +<p align=center><a href="nasmdocb.html">Previous Chapter</a> | +<a href="nasmdoc0.html">Contents</a> | +<a href="nasmdoci.html">Index</a> +</body></html> diff --git a/doc/html/nasmdoci.html b/doc/html/nasmdoci.html new file mode 100644 index 0000000..54eb6a6 --- /dev/null +++ b/doc/html/nasmdoci.html @@ -0,0 +1,2345 @@ +<html><head><title>NASM Manual</title></head> +<body><h1 align=center>The Netwide Assembler: NASM</h1> + +<p align=center><a href="nasmdoc0.html">Contents</a> +<p><code><nobr>!</nobr></code> operator, unary: +<a href="nasmdoc3.html#section-3.5.7">Section 3.5.7</a> +<br> +<code><nobr>!=</nobr></code> operator: +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>$$</nobr></code> token: +<a href="nasmdoc3.html#section-3.5">Section 3.5</a>, +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a> +<br> +<code><nobr>$</nobr></code>, Here token: +<a href="nasmdoc3.html#section-3.5">Section 3.5</a> +<br> +<code><nobr>$</nobr></code>, prefix: +<a href="nasmdoc3.html#section-3.1">Section 3.1</a>, +<a href="nasmdoc3.html#section-3.4.1">Section 3.4.1</a>, +<a href="nasmdoc7.html#section-7.13.2">Section 7.13.2</a> +<br> +<code><nobr>%</nobr></code> operator: +<a href="nasmdoc3.html#section-3.5.6">Section 3.5.6</a> +<br> +<code><nobr>%!</nobr></code>: +<a href="nasmdoc4.html#section-4.10.2">Section 4.10.2</a> +<br> +<code><nobr>%$</nobr></code> and <code><nobr>%$$</nobr></code> prefixes: +<a href="nasmdoc4.html#section-4.7.2">Section 4.7.2</a> +<br> +<code><nobr>%%</nobr></code> operator: +<a href="nasmdoc3.html#section-3.5.6">Section 3.5.6</a>, +<a href="nasmdoc4.html#section-4.3.3">Section 4.3.3</a> +<br> +<code><nobr>%+</nobr></code>: +<a href="nasmdoc4.html#section-4.1.4">Section 4.1.4</a> +<br> +<code><nobr>%?</nobr></code>: +<a href="nasmdoc4.html#section-4.1.5">Section 4.1.5</a> +<br> +<code><nobr>%??</nobr></code>: +<a href="nasmdoc4.html#section-4.1.5">Section 4.1.5</a> +<br> +<code><nobr>%[</nobr></code>: +<a href="nasmdoc4.html#section-4.1.3">Section 4.1.3</a> +<br> +<code><nobr>&</nobr></code> operator: +<a href="nasmdoc3.html#section-3.5.3">Section 3.5.3</a> +<br> +<code><nobr>&&</nobr></code> operator: +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>*</nobr></code> operator: +<a href="nasmdoc3.html#section-3.5.6">Section 3.5.6</a> +<br> +<code><nobr>+</nobr></code> modifier: +<a href="nasmdoc4.html#section-4.3.4">Section 4.3.4</a> +<br> +<code><nobr>+</nobr></code> operator, binary: +<a href="nasmdoc3.html#section-3.5.5">Section 3.5.5</a> +<br> +<code><nobr>+</nobr></code> operator, unary: +<a href="nasmdoc3.html#section-3.5.7">Section 3.5.7</a> +<br> +<code><nobr>-</nobr></code> operator, binary: +<a href="nasmdoc3.html#section-3.5.5">Section 3.5.5</a> +<br> +<code><nobr>-</nobr></code> operator, unary: +<a href="nasmdoc3.html#section-3.5.7">Section 3.5.7</a> +<br> +<code><nobr>..@</nobr></code> symbol prefix: +<a href="nasmdoc3.html#section-3.9">Section 3.9</a>, +<a href="nasmdoc4.html#section-4.3.3">Section 4.3.3</a> +<br> +<code><nobr>/</nobr></code> operator: +<a href="nasmdoc3.html#section-3.5.6">Section 3.5.6</a> +<br> +<code><nobr>//</nobr></code> operator: +<a href="nasmdoc3.html#section-3.5.6">Section 3.5.6</a> +<br> +<code><nobr><</nobr></code> operator: +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr><<</nobr></code> operator: +<a href="nasmdoc3.html#section-3.5.4">Section 3.5.4</a> +<br> +<code><nobr><=</nobr></code> operator: +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr><></nobr></code> operator: +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>=</nobr></code> operator: +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>==</nobr></code> operator: +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>></nobr></code> operator: +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>>=</nobr></code> operator: +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>>></nobr></code> operator: +<a href="nasmdoc3.html#section-3.5.4">Section 3.5.4</a> +<br> +<code><nobr>?</nobr></code> MASM syntax: +<a href="nasmdoc3.html#section-3.2.2">Section 3.2.2</a> +<br> +<code><nobr>^</nobr></code> operator: +<a href="nasmdoc3.html#section-3.5.2">Section 3.5.2</a> +<br> +<code><nobr>^^</nobr></code> operator: +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>|</nobr></code> operator: +<a href="nasmdoc3.html#section-3.5.1">Section 3.5.1</a> +<br> +<code><nobr>||</nobr></code> operator: +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>~</nobr></code> operator: +<a href="nasmdoc3.html#section-3.5.7">Section 3.5.7</a> +<br> +<code><nobr>%0</nobr></code> parameter count: +<a href="nasmdoc4.html#section-4.3.5">Section 4.3.5</a>, +<a href="nasmdoc4.html#section-4.3.6">Section 4.3.6</a> +<br> +<code><nobr>%+1</nobr></code> and <code><nobr>%-1</nobr></code> syntax: +<a href="nasmdoc4.html#section-4.3.9">Section 4.3.9</a> +<br> +16-bit mode, versus 32-bit mode: +<a href="nasmdoc6.html#section-6.1">Section 6.1</a> +<br> +64-bit displacement: <a href="nasmdo11.html#section-11.2">Section 11.2</a> +<br> +64-bit immediate: <a href="nasmdo11.html#section-11.2">Section 11.2</a> +<br> +<code><nobr>-a</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.21">Section 2.1.21</a>, +<a href="nasmdoca.html#section-A.3.3">Section A.3.3</a> +<br> +<code><nobr>A16</nobr></code>: +<a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +<code><nobr>a16</nobr></code>: +<a href="nasmdo10.html#section-10.3">Section 10.3</a> +<br> +<code><nobr>A32</nobr></code>: +<a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +<code><nobr>a32</nobr></code>: +<a href="nasmdo10.html#section-10.3">Section 10.3</a> +<br> +<code><nobr>A64</nobr></code>: +<a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +<code><nobr>a64</nobr></code>: +<a href="nasmdo10.html#section-10.3">Section 10.3</a> +<br> +<code><nobr>a86</nobr></code>: +<a href="nasmdoc1.html#section-1.1.1">Section 1.1.1</a>, +<a href="nasmdoc2.html#section-2.2">Section 2.2</a>, +<a href="nasmdoc2.html#section-2.2.2">Section 2.2.2</a>, +<a href="nasmdoc2.html#section-2.2.6">Section 2.2.6</a> +<br> +<code><nobr>ABS</nobr></code>: +<a href="nasmdoc3.html#section-3.3">Section 3.3</a> +<br> +<code><nobr>ABSOLUTE</nobr></code>: +<a href="nasmdoc6.html#section-6.4">Section 6.4</a>, +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +addition: <a href="nasmdoc3.html#section-3.5.5">Section 3.5.5</a> +<br> +addressing, mixed-size: +<a href="nasmdo10.html#section-10.2">Section 10.2</a> +<br> +address-size prefixes: <a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +algebra: <a href="nasmdoc3.html#section-3.3">Section 3.3</a> +<br> +<code><nobr>ALIGN</nobr></code>: +<a href="nasmdoc4.html#section-4.11.12">Section 4.11.12</a>, +<a href="nasmdoc5.html#section-5.2">Section 5.2</a>, +<a href="nasmdoc7.html#section-7.1.2">Section 7.1.2</a>, +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +<code><nobr>ALIGN</nobr></code>, smart: +<a href="nasmdoc5.html#section-5.2">Section 5.2</a> +<br> +<code><nobr>ALIGNB</nobr></code>: +<a href="nasmdoc4.html#section-4.11.12">Section 4.11.12</a> +<br> +alignment, in <code><nobr>bin</nobr></code> sections: +<a href="nasmdoc7.html#section-7.1.2">Section 7.1.2</a> +<br> +alignment, in <code><nobr>elf</nobr></code> sections: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +alignment, in <code><nobr>obj</nobr></code> sections: +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +alignment, in <code><nobr>win32</nobr></code> sections: +<a href="nasmdoc7.html#section-7.5.1">Section 7.5.1</a> +<br> +alignment, of <code><nobr>elf</nobr></code> common variables: +<a href="nasmdoc7.html#section-7.9.6">Section 7.9.6</a> +<br> +<code><nobr>ALIGNMODE</nobr></code>: +<a href="nasmdoc5.html#section-5.2">Section 5.2</a> +<br> +<code><nobr>__ALIGNMODE__</nobr></code>: +<a href="nasmdoc5.html#section-5.2">Section 5.2</a> +<br> +<code><nobr>ALINK</nobr></code>: +<a href="nasmdoc8.html#section-8.1.1">Section 8.1.1</a> +<br> +<code><nobr>alink.sourceforge.net</nobr></code>: +<a href="nasmdoc8.html#section-8.1.1">Section 8.1.1</a> +<br> +<code><nobr>all</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +<code><nobr>alloc</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +alternate register names: +<a href="nasmdoc5.html#section-5.1">Section 5.1</a> +<br> +<code><nobr>alt.lang.asm</nobr></code>: +<a href="nasmdoc1.html#section-1.1.1">Section 1.1.1</a> +<br> +<code><nobr>altreg</nobr></code>: +<a href="nasmdoc5.html#section-5.1">Section 5.1</a> +<br> +ambiguity: <a href="nasmdoc2.html#section-2.2.3">Section 2.2.3</a> +<br> +<code><nobr>a.out</nobr></code>, BSD version: +<a href="nasmdoc7.html#section-7.11">Section 7.11</a> +<br> +<code><nobr>a.out</nobr></code>, Linux version: +<a href="nasmdoc7.html#section-7.10">Section 7.10</a> +<br> +<code><nobr>aout</nobr></code>: +<a href="nasmdoc7.html#section-7.10">Section 7.10</a> +<br> +<code><nobr>aoutb</nobr></code>: +<a href="nasmdoc7.html#section-7.11">Section 7.11</a>, +<a href="nasmdoc9.html#section-9.2">Section 9.2</a> +<br> +<code><nobr>%arg</nobr></code>: +<a href="nasmdoc4.html#section-4.8.1">Section 4.8.1</a> +<br> +<code><nobr>arg</nobr></code>: +<a href="nasmdoc8.html#section-8.4.5">Section 8.4.5</a>, +<a href="nasmdoc9.html#section-9.1.4">Section 9.1.4</a> +<br> +<code><nobr>as86</nobr></code>: +<a href="nasmdoc1.html#section-1.1.1">Section 1.1.1</a>, +<a href="nasmdoc7.html#section-7.12">Section 7.12</a> +<br> +assembler directives: <a href="nasmdoc6.html">Chapter 6</a> +<br> +assembly-time options: +<a href="nasmdoc2.html#section-2.1.18">Section 2.1.18</a> +<br> +<code><nobr>%assign</nobr></code>: +<a href="nasmdoc4.html#section-4.1.7">Section 4.1.7</a> +<br> +<code><nobr>ASSUME</nobr></code>: +<a href="nasmdoc2.html#section-2.2.4">Section 2.2.4</a> +<br> +<code><nobr>AT</nobr></code>: +<a href="nasmdoc4.html#section-4.11.11">Section 4.11.11</a> +<br> +Autoconf: <a href="nasmdoc1.html#section-1.3.2">Section 1.3.2</a> +<br> +<code><nobr>autoexec.bat</nobr></code>: +<a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a> +<br> +<code><nobr>auto-sync</nobr></code>: +<a href="nasmdoca.html#section-A.3.3">Section A.3.3</a> +<br> +<code><nobr>-b</nobr></code>: +<a href="nasmdoca.html#section-A.3">Section A.3</a> +<br> +bin: <a href="nasmdoc2.html#section-2.1.2">Section 2.1.2</a>, +<a href="nasmdoc7.html#section-7.1">Section 7.1</a> +<br> +bin, multisection: <a href="nasmdoc7.html#section-7.1.3">Section 7.1.3</a> +<br> +binary: <a href="nasmdoc3.html#section-3.4.1">Section 3.4.1</a> +<br> +binary files: <a href="nasmdoc3.html#section-3.2.3">Section 3.2.3</a> +<br> +bit shift: <a href="nasmdoc3.html#section-3.5.4">Section 3.5.4</a> +<br> +<code><nobr>BITS</nobr></code>: +<a href="nasmdoc6.html#section-6.1">Section 6.1</a>, +<a href="nasmdoc7.html#section-7.1">Section 7.1</a> +<br> +<code><nobr>__BITS__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.5">Section 4.11.5</a> +<br> +bitwise AND: <a href="nasmdoc3.html#section-3.5.3">Section 3.5.3</a> +<br> +bitwise OR: <a href="nasmdoc3.html#section-3.5.1">Section 3.5.1</a> +<br> +bitwise XOR: <a href="nasmdoc3.html#section-3.5.2">Section 3.5.2</a> +<br> +block IFs: <a href="nasmdoc4.html#section-4.7.5">Section 4.7.5</a> +<br> +boot loader: <a href="nasmdoc7.html#section-7.1">Section 7.1</a> +<br> +boot sector: <a href="nasmdo12.html#section-12.1.3">Section 12.1.3</a> +<br> +Borland, Pascal: <a href="nasmdoc8.html#section-8.5">Section 8.5</a> +<br> +Borland, Win32 compilers: +<a href="nasmdoc7.html#section-7.4">Section 7.4</a> +<br> +braces, after <code><nobr>%</nobr></code> sign: +<a href="nasmdoc4.html#section-4.3.8">Section 4.3.8</a> +<br> +braces, around macro parameters: +<a href="nasmdoc4.html#section-4.3">Section 4.3</a> +<br> +BSD: <a href="nasmdoc9.html#section-9.2">Section 9.2</a> +<br> +<code><nobr>.bss</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a>, +<a href="nasmdoc7.html#section-7.10">Section 7.10</a>, +<a href="nasmdoc7.html#section-7.11">Section 7.11</a>, +<a href="nasmdoc7.html#section-7.12">Section 7.12</a>, +<a href="nasmdoc7.html#section-7.13">Section 7.13</a> +<br> +bugs: <a href="nasmdo12.html#section-12.2">Section 12.2</a> +<br> +<code><nobr>bugtracker</nobr></code>: +<a href="nasmdo12.html#section-12.2">Section 12.2</a> +<br> +<code><nobr>BYTE</nobr></code>: +<a href="nasmdo12.html#section-12.1.1">Section 12.1.1</a> +<br> +C calling convention: +<a href="nasmdoc8.html#section-8.4.3">Section 8.4.3</a>, +<a href="nasmdoc9.html#section-9.1.2">Section 9.1.2</a> +<br> +C symbol names: <a href="nasmdoc8.html#section-8.4.1">Section 8.4.1</a> +<br> +<code><nobr>c16.mac</nobr></code>: +<a href="nasmdoc8.html#section-8.4.5">Section 8.4.5</a>, +<a href="nasmdoc8.html#section-8.5.3">Section 8.5.3</a> +<br> +<code><nobr>c32.mac</nobr></code>: +<a href="nasmdoc9.html#section-9.1.4">Section 9.1.4</a> +<br> +<code><nobr>CALL FAR</nobr></code>: +<a href="nasmdoc3.html#section-3.6">Section 3.6</a> +<br> +case sensitivity: <a href="nasmdoc2.html#section-2.2.1">Section 2.2.1</a>, +<a href="nasmdoc4.html#section-4.1.1">Section 4.1.1</a>, +<a href="nasmdoc4.html#section-4.1.2">Section 4.1.2</a>, +<a href="nasmdoc4.html#section-4.1.7">Section 4.1.7</a>, +<a href="nasmdoc4.html#section-4.3">Section 4.3</a>, +<a href="nasmdoc4.html#section-4.3.1">Section 4.3.1</a>, +<a href="nasmdoc4.html#section-4.4.5">Section 4.4.5</a>, +<a href="nasmdoc7.html#section-7.4.3">Section 7.4.3</a> +<br> +changing sections: <a href="nasmdoc6.html#section-6.3">Section 6.3</a> +<br> +character constant: +<a href="nasmdoc3.html#section-3.2.1">Section 3.2.1</a>, +<a href="nasmdoc3.html#section-3.4.3">Section 3.4.3</a> +<br> +character strings: <a href="nasmdoc3.html#section-3.4.2">Section 3.4.2</a> +<br> +circular references: +<a href="nasmdoc4.html#section-4.1.1">Section 4.1.1</a> +<br> +<code><nobr>CLASS</nobr></code>: +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +<code><nobr>%clear</nobr></code>: +<a href="nasmdoc4.html#section-4.11">Section 4.11</a> +<br> +<code><nobr>coff</nobr></code>: +<a href="nasmdoc7.html#section-7.7">Section 7.7</a> +<br> +colon: <a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +<code><nobr>.COM</nobr></code>: +<a href="nasmdoc7.html#section-7.1">Section 7.1</a>, +<a href="nasmdoc8.html#section-8.2">Section 8.2</a> +<br> +command-line: <a href="nasmdoc2.html#section-2.1">Section 2.1</a>, +<a href="nasmdoc7.html">Chapter 7</a> +<br> +commas in macro parameters: +<a href="nasmdoc4.html#section-4.3.4">Section 4.3.4</a> +<br> +<code><nobr>.comment</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +<code><nobr>COMMON</nobr></code>: +<a href="nasmdoc6.html#section-6.7">Section 6.7</a>, +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +<code><nobr>COMMON</nobr></code>, <code><nobr>elf</nobr></code> extensions +to: <a href="nasmdoc7.html#section-7.9.6">Section 7.9.6</a> +<br> +<code><nobr>COMMON</nobr></code>, <code><nobr>obj</nobr></code> extensions +to: <a href="nasmdoc7.html#section-7.4.8">Section 7.4.8</a> +<br> +Common Object File Format: +<a href="nasmdoc7.html#section-7.7">Section 7.7</a> +<br> +common variables: <a href="nasmdoc6.html#section-6.7">Section 6.7</a> +<br> +common variables, alignment in <code><nobr>elf</nobr></code>: +<a href="nasmdoc7.html#section-7.9.6">Section 7.9.6</a> +<br> +common variables, element size: +<a href="nasmdoc7.html#section-7.4.8">Section 7.4.8</a> +<br> +<code><nobr>comp.lang.asm.x86</nobr></code>: +<a href="nasmdoc1.html#section-1.1.1">Section 1.1.1</a>, +<a href="nasmdoc1.html#section-1.2">Section 1.2</a> +<br> +<code><nobr>comp.os.msdos.programmer</nobr></code>: +<a href="nasmdoc8.html#section-8.3">Section 8.3</a> +<br> +concatenating macro parameters: +<a href="nasmdoc4.html#section-4.3.8">Section 4.3.8</a> +<br> +concatenating strings: +<a href="nasmdoc4.html#section-4.2.1">Section 4.2.1</a> +<br> +condition codes as macro parameters: +<a href="nasmdoc4.html#section-4.3.9">Section 4.3.9</a> +<br> +conditional assembly: <a href="nasmdoc4.html#section-4.4">Section 4.4</a> +<br> +conditional jumps: +<a href="nasmdo12.html#section-12.1.2">Section 12.1.2</a> +<br> +conditional-return macro: +<a href="nasmdoc4.html#section-4.3.9">Section 4.3.9</a> +<br> +<code><nobr>configure</nobr></code>: +<a href="nasmdoc1.html#section-1.3.2">Section 1.3.2</a> +<br> +constants: <a href="nasmdoc3.html#section-3.4">Section 3.4</a> +<br> +context stack: <a href="nasmdoc4.html#section-4.7">Section 4.7</a>, +<a href="nasmdoc4.html#section-4.7.5">Section 4.7.5</a> +<br> +context-local labels: +<a href="nasmdoc4.html#section-4.7.2">Section 4.7.2</a> +<br> +context-local single-line macros: +<a href="nasmdoc4.html#section-4.7.3">Section 4.7.3</a> +<br> +counting macro parameters: +<a href="nasmdoc4.html#section-4.3.6">Section 4.3.6</a> +<br> +<code><nobr>CPU</nobr></code>: +<a href="nasmdoc6.html#section-6.8">Section 6.8</a> +<br> +<code><nobr>CPUID</nobr></code>: +<a href="nasmdoc3.html#section-3.4.3">Section 3.4.3</a> +<br> +creating contexts: <a href="nasmdoc4.html#section-4.7.1">Section 4.7.1</a> +<br> +critical expression: +<a href="nasmdoc3.html#section-3.2.2">Section 3.2.2</a>, +<a href="nasmdoc3.html#section-3.8">Section 3.8</a>, +<a href="nasmdoc4.html#section-4.1.7">Section 4.1.7</a>, +<a href="nasmdoc6.html#section-6.4">Section 6.4</a> +<br> +<code><nobr>-D</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.18">Section 2.1.18</a> +<br> +<code><nobr>-d</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.18">Section 2.1.18</a> +<br> +daily development snapshots: +<a href="nasmdoc1.html#section-1.2">Section 1.2</a> +<br> +<code><nobr>.data</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a>, +<a href="nasmdoc7.html#section-7.10">Section 7.10</a>, +<a href="nasmdoc7.html#section-7.11">Section 7.11</a>, +<a href="nasmdoc7.html#section-7.12">Section 7.12</a>, +<a href="nasmdoc7.html#section-7.13">Section 7.13</a> +<br> +<code><nobr>_DATA</nobr></code>: +<a href="nasmdoc8.html#section-8.4.2">Section 8.4.2</a> +<br> +<code><nobr>data</nobr></code>: +<a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a>, +<a href="nasmdoc7.html#section-7.13.3">Section 7.13.3</a> +<br> +data structure: <a href="nasmdoc8.html#section-8.4.4">Section 8.4.4</a>, +<a href="nasmdoc9.html#section-9.1.3">Section 9.1.3</a> +<br> +<code><nobr>__DATE__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.7">Section 4.11.7</a> +<br> +<code><nobr>__DATE_NUM__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.7">Section 4.11.7</a> +<br> +<code><nobr>DB</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.1">Section 3.2.1</a>, +<a href="nasmdoc3.html#section-3.4.4">Section 3.4.4</a>, +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>dbg</nobr></code>: +<a href="nasmdoc7.html#section-7.14">Section 7.14</a> +<br> +<code><nobr>DD</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.1">Section 3.2.1</a>, +<a href="nasmdoc3.html#section-3.4.4">Section 3.4.4</a>, +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +debug information: +<a href="nasmdoc2.html#section-2.1.12">Section 2.1.12</a> +<br> +debug information format: +<a href="nasmdoc2.html#section-2.1.11">Section 2.1.11</a> +<br> +declaring structures: +<a href="nasmdoc4.html#section-4.11.10">Section 4.11.10</a> +<br> +<code><nobr>DEFAULT</nobr></code>: +<a href="nasmdoc6.html#section-6.2">Section 6.2</a> +<br> +<code><nobr>default</nobr></code>: +<a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a> +<br> +default macro parameters: +<a href="nasmdoc4.html#section-4.3.5">Section 4.3.5</a> +<br> +default name: <a href="nasmdoc7.html">Chapter 7</a> +<br> +default-<code><nobr>WRT</nobr></code> mechanism: +<a href="nasmdoc7.html#section-7.4.7">Section 7.4.7</a> +<br> +<code><nobr>%define</nobr></code>: +<a href="nasmdoc2.html#section-2.1.18">Section 2.1.18</a>, +<a href="nasmdoc4.html#section-4.1.1">Section 4.1.1</a> +<br> +defining sections: <a href="nasmdoc6.html#section-6.3">Section 6.3</a> +<br> +<code><nobr>%defstr</nobr></code>: +<a href="nasmdoc4.html#section-4.1.8">Section 4.1.8</a> +<br> +<code><nobr>%deftok</nobr></code>: +<a href="nasmdoc4.html#section-4.1.9">Section 4.1.9</a> +<br> +<code><nobr>%depend</nobr></code>: +<a href="nasmdoc4.html#section-4.6.3">Section 4.6.3</a> +<br> +design goals: <a href="nasmdoc2.html#section-2.2.2">Section 2.2.2</a> +<br> +DevPac: <a href="nasmdoc3.html#section-3.2.3">Section 3.2.3</a>, +<a href="nasmdoc3.html#section-3.9">Section 3.9</a> +<br> +disabling listing expansion: +<a href="nasmdoc4.html#section-4.3.10">Section 4.3.10</a> +<br> +division: <a href="nasmdoc3.html#section-3.5.6">Section 3.5.6</a> +<br> +DJGPP: <a href="nasmdoc7.html#section-7.7">Section 7.7</a>, +<a href="nasmdoc9.html">Chapter 9</a> +<br> +<code><nobr>djlink</nobr></code>: +<a href="nasmdoc8.html#section-8.1.1">Section 8.1.1</a> +<br> +DLL symbols, exporting: +<a href="nasmdoc7.html#section-7.4.5">Section 7.4.5</a> +<br> +DLL symbols, importing: +<a href="nasmdoc7.html#section-7.4.4">Section 7.4.4</a> +<br> +<code><nobr>DO</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.1">Section 3.2.1</a>, +<a href="nasmdoc3.html#section-3.4.4">Section 3.4.4</a>, +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +DOS: <a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a>, +<a href="nasmdoc2.html#section-2.1.14">Section 2.1.14</a>, +<a href="nasmdoc2.html#section-2.1.15">Section 2.1.15</a> +<br> +DOS archive: +<br> +DOS source archive: <a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a> +<br> +<code><nobr>DQ</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.1">Section 3.2.1</a>, +<a href="nasmdoc3.html#section-3.4.4">Section 3.4.4</a>, +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>.drectve</nobr></code>: +<a href="nasmdoc7.html#section-7.5.1">Section 7.5.1</a> +<br> +<code><nobr>DT</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.1">Section 3.2.1</a>, +<a href="nasmdoc3.html#section-3.4.4">Section 3.4.4</a>, +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>DUP</nobr></code>: +<a href="nasmdoc2.html#section-2.2.7">Section 2.2.7</a>, +<a href="nasmdoc3.html#section-3.2.5">Section 3.2.5</a> +<br> +<code><nobr>DW</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.1">Section 3.2.1</a>, +<a href="nasmdoc3.html#section-3.4.4">Section 3.4.4</a>, +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>DWORD</nobr></code>: +<a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +<code><nobr>DY</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.1">Section 3.2.1</a>, +<a href="nasmdoc3.html#section-3.4.4">Section 3.4.4</a> +<br> +<code><nobr>-E</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.20">Section 2.1.20</a> +<br> +<code><nobr>-e</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.20">Section 2.1.20</a>, +<a href="nasmdoca.html#section-A.3.4">Section A.3.4</a> +<br> +effective addresses: <a href="nasmdoc3.html#section-3.1">Section 3.1</a>, +<a href="nasmdoc3.html#section-3.3">Section 3.3</a> +<br> +element size, in common variables: +<a href="nasmdoc7.html#section-7.4.8">Section 7.4.8</a> +<br> +ELF: <a href="nasmdoc7.html#section-7.9">Section 7.9</a> +<br> +ELF, shared libraries: +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a> +<br> +ELF, 16-bit code and: +<a href="nasmdoc7.html#section-7.9.7">Section 7.9.7</a> +<br> +elf, debug formats and: +<a href="nasmdoc7.html#section-7.9.8">Section 7.9.8</a> +<br> +<code><nobr>elf32</nobr></code>: +<a href="nasmdoc7.html#section-7.9">Section 7.9</a> +<br> +<code><nobr>elf64</nobr></code>: +<a href="nasmdoc7.html#section-7.9">Section 7.9</a> +<br> +<code><nobr>%elif</nobr></code>: +<a href="nasmdoc4.html#section-4.4">Section 4.4</a>, +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>%elifctx</nobr></code>: +<a href="nasmdoc4.html#section-4.4.3">Section 4.4.3</a> +<br> +<code><nobr>%elifdef</nobr></code>: +<a href="nasmdoc4.html#section-4.4.1">Section 4.4.1</a> +<br> +<code><nobr>%elifempty</nobr></code>: +<a href="nasmdoc4.html#section-4.4.8">Section 4.4.8</a> +<br> +<code><nobr>%elifid</nobr></code>: +<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6</a> +<br> +<code><nobr>%elifidn</nobr></code>: +<a href="nasmdoc4.html#section-4.4.5">Section 4.4.5</a> +<br> +<code><nobr>%elifidni</nobr></code>: +<a href="nasmdoc4.html#section-4.4.5">Section 4.4.5</a> +<br> +<code><nobr>%elifmacro</nobr></code>: +<a href="nasmdoc4.html#section-4.4.2">Section 4.4.2</a> +<br> +<code><nobr>%elifn</nobr></code>: +<a href="nasmdoc4.html#section-4.4">Section 4.4</a>, +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>%elifnctx</nobr></code>: +<a href="nasmdoc4.html#section-4.4.3">Section 4.4.3</a> +<br> +<code><nobr>%elifndef</nobr></code>: +<a href="nasmdoc4.html#section-4.4.1">Section 4.4.1</a> +<br> +<code><nobr>%elifnempty</nobr></code>: +<a href="nasmdoc4.html#section-4.4.8">Section 4.4.8</a> +<br> +<code><nobr>%elifnid</nobr></code>: +<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6</a> +<br> +<code><nobr>%elifnidn</nobr></code>: +<a href="nasmdoc4.html#section-4.4.5">Section 4.4.5</a> +<br> +<code><nobr>%elifnidni</nobr></code>: +<a href="nasmdoc4.html#section-4.4.5">Section 4.4.5</a> +<br> +<code><nobr>%elifnmacro</nobr></code>: +<a href="nasmdoc4.html#section-4.4.2">Section 4.4.2</a> +<br> +<code><nobr>%elifnnum</nobr></code>: +<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6</a> +<br> +<code><nobr>%elifnstr</nobr></code>: +<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6</a> +<br> +<code><nobr>%elifntoken</nobr></code>: +<a href="nasmdoc4.html#section-4.4.7">Section 4.4.7</a> +<br> +<code><nobr>%elifnum</nobr></code>: +<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6</a> +<br> +<code><nobr>%elifstr</nobr></code>: +<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6</a> +<br> +<code><nobr>%eliftoken</nobr></code>: +<a href="nasmdoc4.html#section-4.4.7">Section 4.4.7</a> +<br> +<code><nobr>%else</nobr></code>: +<a href="nasmdoc4.html#section-4.4">Section 4.4</a> +<br> +<code><nobr>endproc</nobr></code>: +<a href="nasmdoc8.html#section-8.4.5">Section 8.4.5</a>, +<a href="nasmdoc9.html#section-9.1.4">Section 9.1.4</a> +<br> +<code><nobr>%endrep</nobr></code>: +<a href="nasmdoc4.html#section-4.5">Section 4.5</a> +<br> +<code><nobr>ENDSTRUC</nobr></code>: +<a href="nasmdoc4.html#section-4.11.10">Section 4.11.10</a>, +<a href="nasmdoc6.html#section-6.4">Section 6.4</a> +<br> +environment: <a href="nasmdoc2.html#section-2.1.28">Section 2.1.28</a> +<br> +<code><nobr>EQU</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.4">Section 3.2.4</a> +<br> +<code><nobr>%error</nobr></code>: +<a href="nasmdoc4.html#section-4.9">Section 4.9</a> +<br> +<code><nobr>error</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +error messages: <a href="nasmdoc2.html#section-2.1.14">Section 2.1.14</a>, +<a href="nasmdoc2.html#section-2.1.15">Section 2.1.15</a> +<br> +error reporting format: +<a href="nasmdoc2.html#section-2.1.13">Section 2.1.13</a> +<br> +escape sequences: <a href="nasmdoc3.html#section-3.4.2">Section 3.4.2</a> +<br> +<code><nobr>EVEN</nobr></code>: +<a href="nasmdoc4.html#section-4.11.12">Section 4.11.12</a> +<br> +exact matches: <a href="nasmdoc4.html#section-4.3.11">Section 4.3.11</a> +<br> +<code><nobr>.EXE</nobr></code>: +<a href="nasmdoc7.html#section-7.4">Section 7.4</a>, +<a href="nasmdoc8.html#section-8.1">Section 8.1</a> +<br> +<code><nobr>EXE2BIN</nobr></code>: +<a href="nasmdoc8.html#section-8.2.2">Section 8.2.2</a> +<br> +<code><nobr>EXE_begin</nobr></code>: +<a href="nasmdoc8.html#section-8.1.2">Section 8.1.2</a> +<br> +<code><nobr>exebin.mac</nobr></code>: +<a href="nasmdoc8.html#section-8.1.2">Section 8.1.2</a> +<br> +<code><nobr>exec</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +Executable and Linkable Format: +<a href="nasmdoc7.html#section-7.9">Section 7.9</a> +<br> +<code><nobr>EXE_end</nobr></code>: +<a href="nasmdoc8.html#section-8.1.2">Section 8.1.2</a> +<br> +<code><nobr>EXE_stack</nobr></code>: +<a href="nasmdoc8.html#section-8.1.2">Section 8.1.2</a> +<br> +<code><nobr>%exitmacro</nobr></code>: +<a href="nasmdoc4.html#section-4.3.12">Section 4.3.12</a> +<br> +<code><nobr>%exitrep</nobr></code>: +<a href="nasmdoc4.html#section-4.5">Section 4.5</a> +<br> +<code><nobr>EXPORT</nobr></code>: +<a href="nasmdoc7.html#section-7.4.5">Section 7.4.5</a> +<br> +<code><nobr>export</nobr></code>: +<a href="nasmdoc7.html#section-7.13.3">Section 7.13.3</a> +<br> +exporting symbols: <a href="nasmdoc6.html#section-6.6">Section 6.6</a> +<br> +expressions: <a href="nasmdoc2.html#section-2.1.20">Section 2.1.20</a>, +<a href="nasmdoc3.html#section-3.5">Section 3.5</a> +<br> +extension: <a href="nasmdoc2.html#section-2.1.1">Section 2.1.1</a>, +<a href="nasmdoc7.html">Chapter 7</a> +<br> +<code><nobr>EXTERN</nobr></code>: +<a href="nasmdoc6.html#section-6.5">Section 6.5</a> +<br> +<code><nobr>EXTERN</nobr></code>, <code><nobr>obj</nobr></code> extensions +to: <a href="nasmdoc7.html#section-7.4.7">Section 7.4.7</a> +<br> +<code><nobr>EXTERN</nobr></code>, <code><nobr>rdf</nobr></code> extensions +to: <a href="nasmdoc7.html#section-7.13.4">Section 7.13.4</a> +<br> +extracting substrings: +<a href="nasmdoc4.html#section-4.2.3">Section 4.2.3</a> +<br> +<code><nobr>-F</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.11">Section 2.1.11</a> +<br> +<code><nobr>-f</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.2">Section 2.1.2</a>, +<a href="nasmdoc7.html">Chapter 7</a> +<br> +far call: <a href="nasmdoc2.html#section-2.2.5">Section 2.2.5</a> +<br> +far common variables: +<a href="nasmdoc7.html#section-7.4.8">Section 7.4.8</a> +<br> +far pointer: <a href="nasmdoc3.html#section-3.6">Section 3.6</a> +<br> +<code><nobr>FARCODE</nobr></code>: +<a href="nasmdoc8.html#section-8.4.5">Section 8.4.5</a>, +<a href="nasmdoc8.html#section-8.5.3">Section 8.5.3</a> +<br> +<code><nobr>%fatal</nobr></code>: +<a href="nasmdoc4.html#section-4.9">Section 4.9</a> +<br> +<code><nobr>__FILE__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.4">Section 4.11.4</a> +<br> +<code><nobr>FLAT</nobr></code>: +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +flat memory model: <a href="nasmdoc9.html">Chapter 9</a> +<br> +flat-form binary: <a href="nasmdoc7.html#section-7.1">Section 7.1</a> +<br> +<code><nobr>FLOAT</nobr></code>: +<a href="nasmdoc6.html#section-6.9">Section 6.9</a> +<br> +<code><nobr>__FLOAT__</nobr></code>: +<a href="nasmdoc6.html#section-6.9">Section 6.9</a> +<br> +<code><nobr>__float128h__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>__float128l__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>__float16__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>__float32__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>__float64__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>__float8__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>__float80e__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>__float80m__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>__FLOAT_DAZ__</nobr></code>: +<a href="nasmdoc6.html#section-6.9">Section 6.9</a> +<br> +<code><nobr>float-denorm</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +floating-point, constants: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a>, +<a href="nasmdoc6.html#section-6.9">Section 6.9</a> +<br> +floating-point, packed BCD constants: +<a href="nasmdoc3.html#section-3.4.7">Section 3.4.7</a> +<br> +floating-point: <a href="nasmdoc2.html#section-2.2.6">Section 2.2.6</a>, +<a href="nasmdoc3.html#section-3.1">Section 3.1</a>, +<a href="nasmdoc3.html#section-3.2.1">Section 3.2.1</a>, +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>float-overflow</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +<code><nobr>__FLOAT_ROUND__</nobr></code>: +<a href="nasmdoc6.html#section-6.9">Section 6.9</a> +<br> +<code><nobr>float-toolong</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +<code><nobr>float-underflow</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +<code><nobr>follows=</nobr></code>: +<a href="nasmdoc7.html#section-7.1.3">Section 7.1.3</a> +<br> +format-specific directives: <a href="nasmdoc6.html">Chapter 6</a> +<br> +frame pointer: <a href="nasmdoc8.html#section-8.4.3">Section 8.4.3</a>, +<a href="nasmdoc8.html#section-8.5.1">Section 8.5.1</a>, +<a href="nasmdoc9.html#section-9.1.2">Section 9.1.2</a> +<br> +FreeBSD: <a href="nasmdoc7.html#section-7.11">Section 7.11</a>, +<a href="nasmdoc9.html#section-9.2">Section 9.2</a> +<br> +FreeLink: <a href="nasmdoc8.html#section-8.1.1">Section 8.1.1</a> +<br> +<code><nobr>ftp.simtel.net</nobr></code>: +<a href="nasmdoc8.html#section-8.1.1">Section 8.1.1</a> +<br> +<code><nobr>function</nobr></code>: +<a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a>, +<a href="nasmdoc7.html#section-7.13.3">Section 7.13.3</a> +<br> +functions, C calling convention: +<a href="nasmdoc8.html#section-8.4.3">Section 8.4.3</a>, +<a href="nasmdoc9.html#section-9.1.2">Section 9.1.2</a> +<br> +functions, Pascal calling convention: +<a href="nasmdoc8.html#section-8.5.1">Section 8.5.1</a> +<br> +<code><nobr>-g</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.12">Section 2.1.12</a> +<br> +<code><nobr>gas</nobr></code>: +<a href="nasmdoc1.html#section-1.1.1">Section 1.1.1</a> +<br> +<code><nobr>gcc</nobr></code>: +<a href="nasmdoc1.html#section-1.1.1">Section 1.1.1</a> +<br> +<code><nobr>GLOBAL</nobr></code>: +<a href="nasmdoc6.html#section-6.6">Section 6.6</a> +<br> +<code><nobr>GLOBAL</nobr></code>, <code><nobr>aoutb</nobr></code> +extensions to: <a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a> +<br> +<code><nobr>GLOBAL</nobr></code>, <code><nobr>elf</nobr></code> extensions +to: <a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a> +<br> +<code><nobr>GLOBAL</nobr></code>, <code><nobr>rdf</nobr></code> extensions +to: <a href="nasmdoc7.html#section-7.13.3">Section 7.13.3</a> +<br> +global offset table: <a href="nasmdoc9.html#section-9.2">Section 9.2</a> +<br> +<code><nobr>_GLOBAL_OFFSET_TABLE_</nobr></code>: +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a> +<br> +<code><nobr>gnu-elf-extensions</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +<code><nobr>..got</nobr></code>: +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a> +<br> +<code><nobr>GOT</nobr></code> relocations: +<a href="nasmdoc9.html#section-9.2.3">Section 9.2.3</a> +<br> +GOT: <a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a>, +<a href="nasmdoc9.html#section-9.2">Section 9.2</a> +<br> +<code><nobr>..gotoff</nobr></code>: +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a> +<br> +<code><nobr>GOTOFF</nobr></code> relocations: +<a href="nasmdoc9.html#section-9.2.2">Section 9.2.2</a> +<br> +<code><nobr>..gotpc</nobr></code>: +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a> +<br> +<code><nobr>GOTPC</nobr></code> relocations: +<a href="nasmdoc9.html#section-9.2.1">Section 9.2.1</a> +<br> +<code><nobr>..gottpoff</nobr></code>: +<a href="nasmdoc7.html#section-7.9.4">Section 7.9.4</a> +<br> +graphics: <a href="nasmdoc3.html#section-3.2.3">Section 3.2.3</a> +<br> +greedy macro parameters: +<a href="nasmdoc4.html#section-4.3.4">Section 4.3.4</a> +<br> +<code><nobr>GROUP</nobr></code>: +<a href="nasmdoc7.html#section-7.4.2">Section 7.4.2</a> +<br> +groups: <a href="nasmdoc3.html#section-3.6">Section 3.6</a> +<br> +<code><nobr>-h</nobr></code>: +<a href="nasmdoca.html#section-A.3">Section A.3</a> +<br> +hexadecimal: <a href="nasmdoc3.html#section-3.4.1">Section 3.4.1</a> +<br> +<code><nobr>hidden</nobr></code>: +<a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a> +<br> +hybrid syntaxes: <a href="nasmdoc2.html#section-2.2.2">Section 2.2.2</a> +<br> +<code><nobr>-I</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.16">Section 2.1.16</a> +<br> +<code><nobr>-i</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.16">Section 2.1.16</a>, +<a href="nasmdoca.html#section-A.3.3">Section A.3.3</a> +<br> +<code><nobr>%iassign</nobr></code>: +<a href="nasmdoc4.html#section-4.1.7">Section 4.1.7</a> +<br> +<code><nobr>%idefine</nobr></code>: +<a href="nasmdoc4.html#section-4.1.1">Section 4.1.1</a> +<br> +<code><nobr>%idefstr</nobr></code>: +<a href="nasmdoc4.html#section-4.1.8">Section 4.1.8</a> +<br> +<code><nobr>%ideftok</nobr></code>: +<a href="nasmdoc4.html#section-4.1.9">Section 4.1.9</a> +<br> +<code><nobr>IEND</nobr></code>: +<a href="nasmdoc4.html#section-4.11.11">Section 4.11.11</a> +<br> +<code><nobr>%if</nobr></code>: +<a href="nasmdoc4.html#section-4.4">Section 4.4</a>, +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>%ifctx</nobr></code>: +<a href="nasmdoc4.html#section-4.4.3">Section 4.4.3</a>, +<a href="nasmdoc4.html#section-4.7.5">Section 4.7.5</a> +<br> +<code><nobr>%ifdef</nobr></code>: +<a href="nasmdoc4.html#section-4.4.1">Section 4.4.1</a> +<br> +<code><nobr>%ifempty</nobr></code>: +<a href="nasmdoc4.html#section-4.4.8">Section 4.4.8</a> +<br> +<code><nobr>%ifid</nobr></code>: +<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6</a> +<br> +<code><nobr>%ifidn</nobr></code>: +<a href="nasmdoc4.html#section-4.4.5">Section 4.4.5</a> +<br> +<code><nobr>%ifidni</nobr></code>: +<a href="nasmdoc4.html#section-4.4.5">Section 4.4.5</a> +<br> +<code><nobr>%ifmacro</nobr></code>: +<a href="nasmdoc4.html#section-4.4.2">Section 4.4.2</a> +<br> +<code><nobr>%ifn</nobr></code>: +<a href="nasmdoc4.html#section-4.4">Section 4.4</a>, +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>%ifnctx</nobr></code>: +<a href="nasmdoc4.html#section-4.4.3">Section 4.4.3</a> +<br> +<code><nobr>%ifndef</nobr></code>: +<a href="nasmdoc4.html#section-4.4.1">Section 4.4.1</a> +<br> +<code><nobr>%ifnempty</nobr></code>: +<a href="nasmdoc4.html#section-4.4.8">Section 4.4.8</a> +<br> +<code><nobr>%ifnid</nobr></code>: +<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6</a> +<br> +<code><nobr>%ifnidn</nobr></code>: +<a href="nasmdoc4.html#section-4.4.5">Section 4.4.5</a> +<br> +<code><nobr>%ifnidni</nobr></code>: +<a href="nasmdoc4.html#section-4.4.5">Section 4.4.5</a> +<br> +<code><nobr>%ifnmacro</nobr></code>: +<a href="nasmdoc4.html#section-4.4.2">Section 4.4.2</a> +<br> +<code><nobr>%ifnnum</nobr></code>: +<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6</a> +<br> +<code><nobr>%ifnstr</nobr></code>: +<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6</a> +<br> +<code><nobr>%ifntoken</nobr></code>: +<a href="nasmdoc4.html#section-4.4.7">Section 4.4.7</a> +<br> +<code><nobr>%ifnum</nobr></code>: +<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6</a> +<br> +<code><nobr>%ifstr</nobr></code>: +<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6</a> +<br> +<code><nobr>%iftoken</nobr></code>: +<a href="nasmdoc4.html#section-4.4.7">Section 4.4.7</a> +<br> +<code><nobr>%imacro</nobr></code>: +<a href="nasmdoc4.html#section-4.3">Section 4.3</a> +<br> +<code><nobr>IMPORT</nobr></code>: +<a href="nasmdoc7.html#section-7.4.4">Section 7.4.4</a> +<br> +import library: <a href="nasmdoc7.html#section-7.4.4">Section 7.4.4</a> +<br> +importing symbols: <a href="nasmdoc6.html#section-6.5">Section 6.5</a> +<br> +<code><nobr>INCBIN</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.3">Section 3.2.3</a>, +<a href="nasmdoc3.html#section-3.4.4">Section 3.4.4</a> +<br> +<code><nobr>%include</nobr></code>: +<a href="nasmdoc2.html#section-2.1.16">Section 2.1.16</a>, +<a href="nasmdoc2.html#section-2.1.17">Section 2.1.17</a>, +<a href="nasmdoc4.html#section-4.6.1">Section 4.6.1</a> +<br> +include search path: +<a href="nasmdoc2.html#section-2.1.16">Section 2.1.16</a> +<br> +including other files: +<a href="nasmdoc4.html#section-4.6.1">Section 4.6.1</a> +<br> +inefficient code: <a href="nasmdo12.html#section-12.1.1">Section 12.1.1</a> +<br> +infinite loop: <a href="nasmdoc3.html#section-3.5">Section 3.5</a> +<br> +<code><nobr>__Infinity__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +infinity: <a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +informational section: +<a href="nasmdoc7.html#section-7.5.1">Section 7.5.1</a> +<br> +<code><nobr>INSTALL</nobr></code>: +<a href="nasmdoc1.html#section-1.3.2">Section 1.3.2</a> +<br> +installing: <a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a> +<br> +instances of structures: +<a href="nasmdoc4.html#section-4.11.11">Section 4.11.11</a> +<br> +instruction list: <a href="nasmdocb.html">Appendix B</a> +<br> +intel hex: <a href="nasmdoc7.html#section-7.2">Section 7.2</a> +<br> +Intel number formats: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +<code><nobr>internal</nobr></code>: +<a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a> +<br> +<code><nobr>%irmacro</nobr></code>: +<a href="nasmdoc4.html#section-4.3.1">Section 4.3.1</a> +<br> +<code><nobr>ISTRUC</nobr></code>: +<a href="nasmdoc4.html#section-4.11.11">Section 4.11.11</a> +<br> +iterating over macro parameters: +<a href="nasmdoc4.html#section-4.3.7">Section 4.3.7</a> +<br> +<code><nobr>ith</nobr></code>: +<a href="nasmdoc7.html#section-7.2">Section 7.2</a> +<br> +<code><nobr>%ixdefine</nobr></code>: +<a href="nasmdoc4.html#section-4.1.2">Section 4.1.2</a> +<br> +<code><nobr>Jcc NEAR</nobr></code>: +<a href="nasmdo12.html#section-12.1.2">Section 12.1.2</a> +<br> +<code><nobr>JMP DWORD</nobr></code>: +<a href="nasmdo10.html#section-10.1">Section 10.1</a> +<br> +jumps, mixed-size: <a href="nasmdo10.html#section-10.1">Section 10.1</a> +<br> +<code><nobr>-k</nobr></code>: +<a href="nasmdoca.html#section-A.3.4">Section A.3.4</a> +<br> +<code><nobr>-l</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.3">Section 2.1.3</a> +<br> +label prefix: <a href="nasmdoc3.html#section-3.9">Section 3.9</a> +<br> +<code><nobr>.lbss</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +<code><nobr>ld86</nobr></code>: +<a href="nasmdoc7.html#section-7.12">Section 7.12</a> +<br> +<code><nobr>.ldata</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +<code><nobr>LIBRARY</nobr></code>: +<a href="nasmdoc7.html#section-7.13.1">Section 7.13.1</a> +<br> +license: <a href="nasmdoc1.html#section-1.1.2">Section 1.1.2</a> +<br> +<code><nobr>%line</nobr></code>: +<a href="nasmdoc4.html#section-4.10.1">Section 4.10.1</a> +<br> +<code><nobr>__LINE__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.4">Section 4.11.4</a> +<br> +linker, free: <a href="nasmdoc8.html#section-8.1.1">Section 8.1.1</a> +<br> +Linux, <code><nobr>a.out</nobr></code>: +<a href="nasmdoc7.html#section-7.10">Section 7.10</a> +<br> +Linux, <code><nobr>as86</nobr></code>: +<a href="nasmdoc7.html#section-7.12">Section 7.12</a> +<br> +Linux, ELF: <a href="nasmdoc7.html#section-7.9">Section 7.9</a> +<br> +listing file: <a href="nasmdoc2.html#section-2.1.3">Section 2.1.3</a> +<br> +little-endian: <a href="nasmdoc3.html#section-3.4.3">Section 3.4.3</a> +<br> +<code><nobr>%local</nobr></code>: +<a href="nasmdoc4.html#section-4.8.3">Section 4.8.3</a> +<br> +local labels: <a href="nasmdoc3.html#section-3.9">Section 3.9</a> +<br> +logical AND: <a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +logical negation: <a href="nasmdoc3.html#section-3.5.7">Section 3.5.7</a> +<br> +logical OR: <a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +logical XOR: <a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +<code><nobr>.lrodata</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +<code><nobr>-M</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.4">Section 2.1.4</a> +<br> +Mach, object file format: +<a href="nasmdoc7.html#section-7.8">Section 7.8</a> +<br> +Mach-O: <a href="nasmdoc7.html#section-7.8">Section 7.8</a> +<br> +<code><nobr>macho</nobr></code>: +<a href="nasmdoc7.html#section-7.8">Section 7.8</a> +<br> +<code><nobr>macho32</nobr></code>: +<a href="nasmdoc7.html#section-7.8">Section 7.8</a> +<br> +<code><nobr>macho64</nobr></code>: +<a href="nasmdoc7.html#section-7.8">Section 7.8</a> +<br> +MacOS X: <a href="nasmdoc7.html#section-7.8">Section 7.8</a> +<br> +<code><nobr>%macro</nobr></code>: +<a href="nasmdoc4.html#section-4.3">Section 4.3</a> +<br> +macro indirection: <a href="nasmdoc4.html#section-4.1.3">Section 4.1.3</a> +<br> +macro library: <a href="nasmdoc2.html#section-2.1.16">Section 2.1.16</a> +<br> +macro processor: <a href="nasmdoc4.html">Chapter 4</a> +<br> +<code><nobr>macro-defaults</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +macro-local labels: <a href="nasmdoc4.html#section-4.3.3">Section 4.3.3</a> +<br> +<code><nobr>macro-params</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +macros: <a href="nasmdoc3.html#section-3.2.5">Section 3.2.5</a> +<br> +<code><nobr>macro-selfref</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +<code><nobr>make</nobr></code>: +<a href="nasmdoc1.html#section-1.3.2">Section 1.3.2</a> +<br> +makefile dependencies: +<a href="nasmdoc2.html#section-2.1.4">Section 2.1.4</a>, +<a href="nasmdoc2.html#section-2.1.5">Section 2.1.5</a> +<br> +makefiles: <a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a>, +<a href="nasmdoc1.html#section-1.3.2">Section 1.3.2</a> +<br> +man pages: <a href="nasmdoc1.html#section-1.3.2">Section 1.3.2</a> +<br> +map files: <a href="nasmdoc7.html#section-7.1.4">Section 7.1.4</a> +<br> +<code><nobr>MASM</nobr></code>: +<a href="nasmdoc1.html#section-1.1.1">Section 1.1.1</a> +<br> +MASM: <a href="nasmdoc2.html#section-2.2">Section 2.2</a>, +<a href="nasmdoc3.html#section-3.2.5">Section 3.2.5</a>, +<a href="nasmdoc7.html#section-7.4">Section 7.4</a> +<br> +<code><nobr>-MD</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.7">Section 2.1.7</a> +<br> +memory models: <a href="nasmdoc2.html#section-2.2.5">Section 2.2.5</a>, +<a href="nasmdoc8.html#section-8.4.2">Section 8.4.2</a> +<br> +memory operand: <a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +memory references: <a href="nasmdoc2.html#section-2.2.2">Section 2.2.2</a>, +<a href="nasmdoc3.html#section-3.3">Section 3.3</a> +<br> +<code><nobr>-MF</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.6">Section 2.1.6</a> +<br> +<code><nobr>-MG</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.5">Section 2.1.5</a> +<br> +Microsoft OMF: <a href="nasmdoc7.html#section-7.4">Section 7.4</a> +<br> +minifloat: <a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +Minix: <a href="nasmdoc7.html#section-7.12">Section 7.12</a> +<br> +<code><nobr>misc</nobr></code> subdirectory: +<a href="nasmdoc8.html#section-8.1.2">Section 8.1.2</a>, +<a href="nasmdoc8.html#section-8.4.5">Section 8.4.5</a>, +<a href="nasmdoc9.html#section-9.1.4">Section 9.1.4</a> +<br> +mixed-language program: <a href="nasmdoc8.html#section-8.4">Section 8.4</a> +<br> +mixed-size addressing: +<a href="nasmdo10.html#section-10.2">Section 10.2</a> +<br> +mixed-size instruction: +<a href="nasmdo10.html#section-10.1">Section 10.1</a> +<br> +MMX registers: +<br> +ModR/M byte: +<br> +<code><nobr>MODULE</nobr></code>: +<a href="nasmdoc7.html#section-7.13.2">Section 7.13.2</a> +<br> +modulo operators: <a href="nasmdoc3.html#section-3.5.6">Section 3.5.6</a> +<br> +motorola s-records: <a href="nasmdoc7.html#section-7.3">Section 7.3</a> +<br> +<code><nobr>-MP</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.10">Section 2.1.10</a> +<br> +<code><nobr>-MQ</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.9">Section 2.1.9</a> +<br> +MS-DOS: <a href="nasmdoc7.html#section-7.1">Section 7.1</a> +<br> +MS-DOS device drivers: <a href="nasmdoc8.html#section-8.3">Section 8.3</a> +<br> +<code><nobr>-MT</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.8">Section 2.1.8</a> +<br> +multi-line macros: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a>, +<a href="nasmdoc4.html#section-4.3">Section 4.3</a> +<br> +multipass optimization: +<a href="nasmdoc2.html#section-2.1.22">Section 2.1.22</a> +<br> +multiple section names: <a href="nasmdoc7.html#section-7.1">Section 7.1</a> +<br> +multiplication: <a href="nasmdoc3.html#section-3.5.6">Section 3.5.6</a> +<br> +<code><nobr>multipush</nobr></code> macro: +<a href="nasmdoc4.html#section-4.3.7">Section 4.3.7</a> +<br> +multisection: <a href="nasmdoc7.html#section-7.1.3">Section 7.1.3</a> +<br> +<code><nobr>__NaN__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +NaN: <a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +NASM version: <a href="nasmdoc4.html#section-4.11.1">Section 4.11.1</a> +<br> +nasm version history: <a href="nasmdocc.html">Appendix C</a> +<br> +nasm version id: <a href="nasmdoc4.html#section-4.11.2">Section 4.11.2</a> +<br> +nasm version string: +<a href="nasmdoc4.html#section-4.11.3">Section 4.11.3</a> +<br> +<code><nobr>nasm.1</nobr></code>: +<a href="nasmdoc1.html#section-1.3.2">Section 1.3.2</a> +<br> +<code><nobr>__NASMDEFSEG</nobr></code>: +<a href="nasmdoc7.html#section-7.4">Section 7.4</a> +<br> +<code><nobr>nasm-devel</nobr></code>: +<a href="nasmdoc1.html#section-1.2">Section 1.2</a> +<br> +<code><nobr>NASMENV</nobr></code>: +<a href="nasmdoc2.html#section-2.1.28">Section 2.1.28</a> +<br> +<code><nobr>nasm.exe</nobr></code>: +<a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a> +<br> +<code><nobr>nasm -hf</nobr></code>: +<a href="nasmdoc2.html#section-2.1.2">Section 2.1.2</a> +<br> +<code><nobr>__NASM_MAJOR__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.1">Section 4.11.1</a> +<br> +<code><nobr>__NASM_MINOR__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.1">Section 4.11.1</a> +<br> +<code><nobr>nasm.out</nobr></code>: +<a href="nasmdoc2.html#section-2.1.1">Section 2.1.1</a> +<br> +<code><nobr>___NASM_PATCHLEVEL__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.1">Section 4.11.1</a> +<br> +<code><nobr>__NASM_SNAPSHOT__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.1">Section 4.11.1</a> +<br> +<code><nobr>__NASM_SUBMINOR__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.1">Section 4.11.1</a> +<br> +<code><nobr>__NASM_VER__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.3">Section 4.11.3</a> +<br> +<code><nobr>__NASM_VERSION_ID__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.2">Section 4.11.2</a> +<br> +<code><nobr>nasm-XXX-dos.zip</nobr></code>: +<a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a> +<br> +<code><nobr>nasm-XXX.tar.gz</nobr></code>: +<a href="nasmdoc1.html#section-1.3.2">Section 1.3.2</a> +<br> +<code><nobr>nasm-XXX-win32.zip</nobr></code>: +<a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a> +<br> +<code><nobr>nasm-XXX.zip</nobr></code>: +<a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a> +<br> +ndisasm: <a href="nasmdoca.html">Appendix A</a> +<br> +<code><nobr>ndisasm.1</nobr></code>: +<a href="nasmdoc1.html#section-1.3.2">Section 1.3.2</a> +<br> +<code><nobr>ndisasm.exe</nobr></code>: +<a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a> +<br> +near call: <a href="nasmdoc2.html#section-2.2.5">Section 2.2.5</a> +<br> +near common variables: +<a href="nasmdoc7.html#section-7.4.8">Section 7.4.8</a> +<br> +NetBSD: <a href="nasmdoc7.html#section-7.11">Section 7.11</a>, +<a href="nasmdoc9.html#section-9.2">Section 9.2</a> +<br> +new releases: <a href="nasmdoc1.html#section-1.2">Section 1.2</a> +<br> +<code><nobr>noalloc</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +<code><nobr>nobits</nobr></code>: +<a href="nasmdoc7.html#section-7.1.3">Section 7.1.3</a>, +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +<code><nobr>noexec</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +<code><nobr>.nolist</nobr></code>: +<a href="nasmdoc4.html#section-4.3.10">Section 4.3.10</a> +<br> +`nowait': <a href="nasmdoc2.html#section-2.2.6">Section 2.2.6</a> +<br> +<code><nobr>nowrite</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +<code><nobr>number-overflow</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +numeric constants: <a href="nasmdoc3.html#section-3.2.1">Section 3.2.1</a>, +<a href="nasmdoc3.html#section-3.4.1">Section 3.4.1</a> +<br> +<code><nobr>-O</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.22">Section 2.1.22</a> +<br> +<code><nobr>-o</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.1">Section 2.1.1</a>, +<a href="nasmdoca.html#section-A.3.1">Section A.3.1</a> +<br> +<code><nobr>O16</nobr></code>: +<a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +<code><nobr>o16</nobr></code>: +<a href="nasmdo10.html#section-10.3">Section 10.3</a> +<br> +<code><nobr>O32</nobr></code>: +<a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +<code><nobr>o32</nobr></code>: +<a href="nasmdo10.html#section-10.3">Section 10.3</a> +<br> +<code><nobr>O64</nobr></code>: +<a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +<code><nobr>.OBJ</nobr></code>: +<a href="nasmdoc8.html#section-8.1">Section 8.1</a> +<br> +<code><nobr>obj</nobr></code>: +<a href="nasmdoc7.html#section-7.4">Section 7.4</a> +<br> +<code><nobr>object</nobr></code>: +<a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a>, +<a href="nasmdoc7.html#section-7.13.3">Section 7.13.3</a> +<br> +octal: <a href="nasmdoc3.html#section-3.4.1">Section 3.4.1</a> +<br> +<code><nobr>OF_DBG</nobr></code>: +<a href="nasmdoc7.html#section-7.14">Section 7.14</a> +<br> +<code><nobr>OF_DEFAULT</nobr></code>: +<a href="nasmdoc2.html#section-2.1.2">Section 2.1.2</a> +<br> +<code><nobr>OFFSET</nobr></code>: +<a href="nasmdoc2.html#section-2.2.2">Section 2.2.2</a> +<br> +OMF: <a href="nasmdoc7.html#section-7.4">Section 7.4</a> +<br> +omitted parameters: <a href="nasmdoc4.html#section-4.3.5">Section 4.3.5</a> +<br> +one's complement: <a href="nasmdoc3.html#section-3.5.7">Section 3.5.7</a> +<br> +OpenBSD: <a href="nasmdoc7.html#section-7.11">Section 7.11</a>, +<a href="nasmdoc9.html#section-9.2">Section 9.2</a> +<br> +operands: <a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +operand-size prefixes: <a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +operating system: <a href="nasmdoc7.html#section-7.1">Section 7.1</a> +<br> +operating system, writing: +<a href="nasmdo10.html#section-10.1">Section 10.1</a> +<br> +operators: <a href="nasmdoc3.html#section-3.5">Section 3.5</a> +<br> +<code><nobr>ORG</nobr></code>: +<a href="nasmdoc7.html#section-7.1.1">Section 7.1.1</a>, +<a href="nasmdoc8.html#section-8.2.1">Section 8.2.1</a>, +<a href="nasmdoc8.html#section-8.2.2">Section 8.2.2</a>, +<a href="nasmdo12.html#section-12.1.3">Section 12.1.3</a> +<br> +<code><nobr>orphan-labels</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a>, +<a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +OS/2: <a href="nasmdoc7.html#section-7.4">Section 7.4</a>, +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +<code><nobr>osabi</nobr></code>: +<a href="nasmdoc7.html#section-7.9.1">Section 7.9.1</a> +<br> +other preprocessor directives: +<a href="nasmdoc4.html#section-4.10">Section 4.10</a> +<br> +out of range, jumps: +<a href="nasmdo12.html#section-12.1.2">Section 12.1.2</a> +<br> +output file format: <a href="nasmdoc2.html#section-2.1.2">Section 2.1.2</a> +<br> +output formats: <a href="nasmdoc7.html">Chapter 7</a> +<br> +<code><nobr>__OUTPUT_FORMAT__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.6">Section 4.11.6</a> +<br> +overlapping segments: <a href="nasmdoc3.html#section-3.6">Section 3.6</a> +<br> +<code><nobr>OVERLAY</nobr></code>: +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +overloading, multi-line macros: +<a href="nasmdoc4.html#section-4.3.2">Section 4.3.2</a> +<br> +overloading, single-line macros: +<a href="nasmdoc4.html#section-4.1.1">Section 4.1.1</a> +<br> +<code><nobr>-P</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.17">Section 2.1.17</a> +<br> +<code><nobr>-p</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.17">Section 2.1.17</a>, +<a href="nasmdoc4.html#section-4.6.1">Section 4.6.1</a> +<br> +paradox: <a href="nasmdoc3.html#section-3.8">Section 3.8</a> +<br> +<code><nobr>PASCAL</nobr></code>: +<a href="nasmdoc8.html#section-8.5.3">Section 8.5.3</a> +<br> +Pascal calling convention: +<a href="nasmdoc8.html#section-8.5.1">Section 8.5.1</a> +<br> +<code><nobr>__PASS__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.9">Section 4.11.9</a> +<br> +passes, assembly: +<br> +<code><nobr>PATH</nobr></code>: +<a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a> +<br> +<code><nobr>%pathsearch</nobr></code>: +<a href="nasmdoc2.html#section-2.1.16">Section 2.1.16</a>, +<a href="nasmdoc4.html#section-4.6.2">Section 4.6.2</a> +<br> +period: <a href="nasmdoc3.html#section-3.9">Section 3.9</a> +<br> +Perl: <a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a> +<br> +perverse: <a href="nasmdoc2.html#section-2.1.16">Section 2.1.16</a> +<br> +PharLap: <a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +PIC: <a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a>, +<a href="nasmdoc7.html#section-7.11">Section 7.11</a>, +<a href="nasmdoc9.html#section-9.2">Section 9.2</a> +<br> +<code><nobr>..plt</nobr></code>: +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a> +<br> +<code><nobr>PLT</nobr></code> relocations: +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a>, +<a href="nasmdoc9.html#section-9.2.4">Section 9.2.4</a>, +<a href="nasmdoc9.html#section-9.2.5">Section 9.2.5</a> +<br> +plt relocations: <a href="nasmdoc9.html#section-9.2.5">Section 9.2.5</a> +<br> +<code><nobr>%pop</nobr></code>: +<a href="nasmdoc4.html#section-4.7">Section 4.7</a>, +<a href="nasmdoc4.html#section-4.7.1">Section 4.7.1</a> +<br> +position-independent code: +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a>, +<a href="nasmdoc7.html#section-7.11">Section 7.11</a>, +<a href="nasmdoc9.html#section-9.2">Section 9.2</a> +<br> +<code><nobr>--postfix</nobr></code>: +<a href="nasmdoc2.html#section-2.1.27">Section 2.1.27</a> +<br> +precedence: <a href="nasmdoc3.html#section-3.5">Section 3.5</a> +<br> +pre-defining macros: +<a href="nasmdoc2.html#section-2.1.18">Section 2.1.18</a>, +<a href="nasmdoc4.html#section-4.1.1">Section 4.1.1</a> +<br> +preferred: <a href="nasmdoc3.html#section-3.6">Section 3.6</a> +<br> +<code><nobr>--prefix</nobr></code>: +<a href="nasmdoc2.html#section-2.1.27">Section 2.1.27</a> +<br> +pre-including files: +<a href="nasmdoc2.html#section-2.1.17">Section 2.1.17</a> +<br> +preprocess-only mode: +<a href="nasmdoc2.html#section-2.1.20">Section 2.1.20</a> +<br> +preprocessor: <a href="nasmdoc2.html#section-2.1.20">Section 2.1.20</a>, +<a href="nasmdoc2.html#section-2.1.21">Section 2.1.21</a>, +<a href="nasmdoc3.html#section-3.2.4">Section 3.2.4</a>, +<a href="nasmdoc3.html#section-3.5.6">Section 3.5.6</a>, +<a href="nasmdoc4.html">Chapter 4</a> +<br> +preprocessor expressions: +<a href="nasmdoc2.html#section-2.1.20">Section 2.1.20</a> +<br> +preprocessor loops: <a href="nasmdoc4.html#section-4.5">Section 4.5</a> +<br> +preprocessor variables: +<a href="nasmdoc4.html#section-4.1.7">Section 4.1.7</a> +<br> +primitive directives: <a href="nasmdoc6.html">Chapter 6</a> +<br> +<code><nobr>PRIVATE</nobr></code>: +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +<code><nobr>proc</nobr></code>: +<a href="nasmdoc7.html#section-7.13.3">Section 7.13.3</a>, +<a href="nasmdoc8.html#section-8.4.5">Section 8.4.5</a>, +<a href="nasmdoc9.html#section-9.1.4">Section 9.1.4</a> +<br> +procedure linkage table: +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a>, +<a href="nasmdoc9.html#section-9.2.4">Section 9.2.4</a>, +<a href="nasmdoc9.html#section-9.2.5">Section 9.2.5</a> +<br> +processor mode: <a href="nasmdoc6.html#section-6.1">Section 6.1</a> +<br> +<code><nobr>progbits</nobr></code>: +<a href="nasmdoc7.html#section-7.1.3">Section 7.1.3</a>, +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +program entry point: +<a href="nasmdoc7.html#section-7.4.6">Section 7.4.6</a>, +<a href="nasmdoc8.html#section-8.1.1">Section 8.1.1</a> +<br> +program origin: <a href="nasmdoc7.html#section-7.1.1">Section 7.1.1</a> +<br> +<code><nobr>protected</nobr></code>: +<a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a> +<br> +pseudo-instructions: <a href="nasmdoc3.html#section-3.2">Section 3.2</a> +<br> +<code><nobr>PUBLIC</nobr></code>: +<a href="nasmdoc6.html#section-6.6">Section 6.6</a>, +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +pure binary: <a href="nasmdoc7.html#section-7.1">Section 7.1</a> +<br> +<code><nobr>%push</nobr></code>: +<a href="nasmdoc4.html#section-4.7">Section 4.7</a>, +<a href="nasmdoc4.html#section-4.7.1">Section 4.7.1</a> +<br> +<code><nobr>__QNaN__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +quick start: <a href="nasmdoc2.html#section-2.2">Section 2.2</a> +<br> +<code><nobr>QWORD</nobr></code>: +<a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +<code><nobr>-r</nobr></code>: +<a href="nasmdoca.html#section-A.3">Section A.3</a> +<br> +<code><nobr>rdf</nobr></code>: +<a href="nasmdoc7.html#section-7.13">Section 7.13</a> +<br> +<code><nobr>rdoff</nobr></code> subdirectory: +<a href="nasmdoc1.html#section-1.3.2">Section 1.3.2</a>, +<a href="nasmdoc7.html#section-7.13">Section 7.13</a> +<br> +recursive multi-line macros: +<a href="nasmdoc4.html#section-4.3.1">Section 4.3.1</a> +<br> +redirecting errors: +<a href="nasmdoc2.html#section-2.1.14">Section 2.1.14</a> +<br> +<code><nobr>REL</nobr></code>: +<a href="nasmdoc3.html#section-3.3">Section 3.3</a>, +<a href="nasmdoc6.html#section-6.2">Section 6.2</a> +<br> +relational operators: +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +release candidates: <a href="nasmdoc1.html#section-1.2">Section 1.2</a> +<br> +Relocatable Dynamic Object File Format: +<a href="nasmdoc7.html#section-7.13">Section 7.13</a> +<br> +relocations, PIC-specific: +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a> +<br> +removing contexts: <a href="nasmdoc4.html#section-4.7.1">Section 4.7.1</a> +<br> +renaming contexts: <a href="nasmdoc4.html#section-4.7.4">Section 4.7.4</a> +<br> +<code><nobr>%rep</nobr></code>: +<a href="nasmdoc3.html#section-3.2.5">Section 3.2.5</a>, +<a href="nasmdoc4.html#section-4.5">Section 4.5</a> +<br> +repeating: <a href="nasmdoc3.html#section-3.2.5">Section 3.2.5</a>, +<a href="nasmdoc4.html#section-4.5">Section 4.5</a> +<br> +<code><nobr>%repl</nobr></code>: +<a href="nasmdoc4.html#section-4.7.4">Section 4.7.4</a> +<br> +reporting bugs: <a href="nasmdo12.html#section-12.2">Section 12.2</a> +<br> +<code><nobr>RESB</nobr></code>: +<a href="nasmdoc2.html#section-2.2.7">Section 2.2.7</a>, +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.2">Section 3.2.2</a> +<br> +<code><nobr>RESD</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.2">Section 3.2.2</a> +<br> +<code><nobr>RESO</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.2">Section 3.2.2</a> +<br> +<code><nobr>RESQ</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.2">Section 3.2.2</a> +<br> +<code><nobr>REST</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.2">Section 3.2.2</a> +<br> +<code><nobr>RESW</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.2">Section 3.2.2</a> +<br> +<code><nobr>RESY</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.2">Section 3.2.2</a> +<br> +<code><nobr>%rmacro</nobr></code>: +<a href="nasmdoc4.html#section-4.3.1">Section 4.3.1</a> +<br> +<code><nobr>.rodata</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +<code><nobr>%rotate</nobr></code>: +<a href="nasmdoc4.html#section-4.3.7">Section 4.3.7</a> +<br> +rotating macro parameters: +<a href="nasmdoc4.html#section-4.3.7">Section 4.3.7</a> +<br> +<code><nobr>-s</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.15">Section 2.1.15</a>, +<a href="nasmdoca.html#section-A.3.2">Section A.3.2</a> +<br> +searching for include files: +<a href="nasmdoc4.html#section-4.6.1">Section 4.6.1</a> +<br> +<code><nobr>__SECT__</nobr></code>: +<a href="nasmdoc6.html#section-6.3.1">Section 6.3.1</a>, +<a href="nasmdoc6.html#section-6.4">Section 6.4</a> +<br> +<code><nobr>SECTION</nobr></code>: +<a href="nasmdoc6.html#section-6.3">Section 6.3</a> +<br> +<code><nobr>SECTION</nobr></code>, <code><nobr>elf</nobr></code> extensions +to: <a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +<code><nobr>SECTION</nobr></code>, <code><nobr>win32</nobr></code> +extensions to: <a href="nasmdoc7.html#section-7.5.1">Section 7.5.1</a> +<br> +section alignment, in <code><nobr>bin</nobr></code>: +<a href="nasmdoc7.html#section-7.1.2">Section 7.1.2</a> +<br> +section alignment, in <code><nobr>elf</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +section alignment, in <code><nobr>obj</nobr></code>: +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +section alignment, in <code><nobr>win32</nobr></code>: +<a href="nasmdoc7.html#section-7.5.1">Section 7.5.1</a> +<br> +section, bin extensions to: +<a href="nasmdoc7.html#section-7.1.2">Section 7.1.2</a> +<br> +<code><nobr>SEG</nobr></code>: +<a href="nasmdoc3.html#section-3.5.7">Section 3.5.7</a>, +<a href="nasmdoc3.html#section-3.6">Section 3.6</a>, +<a href="nasmdoc7.html#section-7.4">Section 7.4</a> +<br> +<code><nobr>SEGMENT</nobr></code>: +<a href="nasmdoc6.html#section-6.3">Section 6.3</a> +<br> +<code><nobr>SEGMENT</nobr></code>, <code><nobr>elf</nobr></code> extensions +to: <a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +segment address: <a href="nasmdoc3.html#section-3.5.7">Section 3.5.7</a>, +<a href="nasmdoc3.html#section-3.6">Section 3.6</a> +<br> +segment alignment, in <code><nobr>bin</nobr></code>: +<a href="nasmdoc7.html#section-7.1.2">Section 7.1.2</a> +<br> +segment alignment, in <code><nobr>obj</nobr></code>: +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +segment names, Borland Pascal: +<a href="nasmdoc8.html#section-8.5.2">Section 8.5.2</a> +<br> +segment override: <a href="nasmdoc2.html#section-2.2.4">Section 2.2.4</a>, +<a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +segments: <a href="nasmdoc3.html#section-3.6">Section 3.6</a> +<br> +segments, groups of: +<a href="nasmdoc7.html#section-7.4.2">Section 7.4.2</a> +<br> +separator character: +<a href="nasmdoc2.html#section-2.1.28">Section 2.1.28</a> +<br> +shared libraries: <a href="nasmdoc7.html#section-7.11">Section 7.11</a>, +<a href="nasmdoc9.html#section-9.2">Section 9.2</a> +<br> +shared library: <a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a> +<br> +<code><nobr>shift</nobr></code> command: +<a href="nasmdoc4.html#section-4.3.7">Section 4.3.7</a> +<br> +SIB byte: +<br> +signed division: <a href="nasmdoc3.html#section-3.5.6">Section 3.5.6</a> +<br> +signed modulo: <a href="nasmdoc3.html#section-3.5.6">Section 3.5.6</a> +<br> +single-line macros: <a href="nasmdoc4.html#section-4.1">Section 4.1</a> +<br> +size, of symbols: <a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a> +<br> +<code><nobr>smartalign</nobr></code>: +<a href="nasmdoc5.html#section-5.2">Section 5.2</a> +<br> +<code><nobr>__SNaN__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.6">Section 3.4.6</a> +<br> +snapshots, daily development: +<a href="nasmdoc1.html#section-1.2">Section 1.2</a> +<br> +Solaris x86: <a href="nasmdoc7.html#section-7.9">Section 7.9</a> +<br> +<code><nobr>-soname</nobr></code>: +<a href="nasmdoc9.html#section-9.2.6">Section 9.2.6</a> +<br> +sound: <a href="nasmdoc3.html#section-3.2.3">Section 3.2.3</a> +<br> +source code: <a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a> +<br> +source-listing file: +<a href="nasmdoc2.html#section-2.1.3">Section 2.1.3</a> +<br> +square brackets: <a href="nasmdoc2.html#section-2.2.2">Section 2.2.2</a>, +<a href="nasmdoc3.html#section-3.3">Section 3.3</a> +<br> +<code><nobr>srec</nobr></code>: +<a href="nasmdoc7.html#section-7.3">Section 7.3</a> +<br> +<code><nobr>STACK</nobr></code>: +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +stack relative preprocessor directives: +<a href="nasmdoc4.html#section-4.8">Section 4.8</a> +<br> +<code><nobr>%stacksize</nobr></code>: +<a href="nasmdoc4.html#section-4.8.2">Section 4.8.2</a> +<br> +standard macro packages: <a href="nasmdoc5.html">Chapter 5</a> +<br> +standard macros: <a href="nasmdoc4.html#section-4.11">Section 4.11</a> +<br> +standardized section names: +<a href="nasmdoc6.html#section-6.3">Section 6.3</a>, +<a href="nasmdoc7.html#section-7.5.1">Section 7.5.1</a>, +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a>, +<a href="nasmdoc7.html#section-7.10">Section 7.10</a>, +<a href="nasmdoc7.html#section-7.11">Section 7.11</a>, +<a href="nasmdoc7.html#section-7.12">Section 7.12</a>, +<a href="nasmdoc7.html#section-7.13">Section 7.13</a> +<br> +<code><nobr>..start</nobr></code>: +<a href="nasmdoc7.html#section-7.4.6">Section 7.4.6</a>, +<a href="nasmdoc8.html#section-8.1.1">Section 8.1.1</a> +<br> +<code><nobr>start=</nobr></code>: +<a href="nasmdoc7.html#section-7.1.3">Section 7.1.3</a> +<br> +<code><nobr>stderr</nobr></code>: +<a href="nasmdoc2.html#section-2.1.14">Section 2.1.14</a> +<br> +<code><nobr>stdout</nobr></code>: +<a href="nasmdoc2.html#section-2.1.15">Section 2.1.15</a> +<br> +<code><nobr>%strcat</nobr></code>: +<a href="nasmdoc4.html#section-4.2.1">Section 4.2.1</a> +<br> +<code><nobr>STRICT</nobr></code>: +<a href="nasmdoc3.html#section-3.7">Section 3.7</a> +<br> +string constant: <a href="nasmdoc3.html#section-3.2.1">Section 3.2.1</a> +<br> +string constants: <a href="nasmdoc3.html#section-3.4.4">Section 3.4.4</a> +<br> +string length: <a href="nasmdoc4.html#section-4.2.2">Section 4.2.2</a> +<br> +string manipulation in macros: +<a href="nasmdoc4.html#section-4.2">Section 4.2</a> +<br> +strings: <a href="nasmdoc3.html#section-3.4.2">Section 3.4.2</a> +<br> +<code><nobr>%strlen</nobr></code>: +<a href="nasmdoc4.html#section-4.2.2">Section 4.2.2</a> +<br> +<code><nobr>STRUC</nobr></code>: +<a href="nasmdoc4.html#section-4.11.10">Section 4.11.10</a>, +<a href="nasmdoc6.html#section-6.4">Section 6.4</a>, +<a href="nasmdoc8.html#section-8.4.4">Section 8.4.4</a>, +<a href="nasmdoc9.html#section-9.1.3">Section 9.1.3</a> +<br> +stub preprocessor: +<a href="nasmdoc2.html#section-2.1.21">Section 2.1.21</a> +<br> +<code><nobr>%substr</nobr></code>: +<a href="nasmdoc4.html#section-4.2.3">Section 4.2.3</a> +<br> +subtraction: <a href="nasmdoc3.html#section-3.5.5">Section 3.5.5</a> +<br> +suppressible warning: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +suppressing preprocessing: +<a href="nasmdoc2.html#section-2.1.21">Section 2.1.21</a> +<br> +switching between sections: +<a href="nasmdoc6.html#section-6.3">Section 6.3</a> +<br> +<code><nobr>..sym</nobr></code>: +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a> +<br> +symbol sizes, specifying: +<a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a> +<br> +symbol types, specifying: +<a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a> +<br> +symbols, exporting from DLLs: +<a href="nasmdoc7.html#section-7.4.5">Section 7.4.5</a> +<br> +symbols, importing from DLLs: +<a href="nasmdoc7.html#section-7.4.4">Section 7.4.4</a> +<br> +<code><nobr>synchronisation</nobr></code>: +<a href="nasmdoca.html#section-A.3.2">Section A.3.2</a> +<br> +<code><nobr>.SYS</nobr></code>: +<a href="nasmdoc7.html#section-7.1">Section 7.1</a>, +<a href="nasmdoc8.html#section-8.3">Section 8.3</a> +<br> +<code><nobr>-t</nobr></code>: +<a href="nasmdoc2.html#section-2.1.23">Section 2.1.23</a> +<br> +<code><nobr>TASM</nobr></code>: +<a href="nasmdoc1.html#section-1.1.1">Section 1.1.1</a>, +<a href="nasmdoc2.html#section-2.1.23">Section 2.1.23</a> +<br> +tasm: <a href="nasmdoc2.html#section-2.2">Section 2.2</a>, +<a href="nasmdoc7.html#section-7.4">Section 7.4</a> +<br> +<code><nobr>.tbss</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +<code><nobr>TBYTE</nobr></code>: +<a href="nasmdoc2.html#section-2.2.7">Section 2.2.7</a> +<br> +<code><nobr>.tdata</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +<code><nobr>test</nobr></code> subdirectory: +<a href="nasmdoc8.html#section-8.1.1">Section 8.1.1</a> +<br> +testing, arbitrary numeric expressions: +<a href="nasmdoc4.html#section-4.4.4">Section 4.4.4</a> +<br> +testing, context stack: +<a href="nasmdoc4.html#section-4.4.3">Section 4.4.3</a> +<br> +testing, exact text identity: +<a href="nasmdoc4.html#section-4.4.5">Section 4.4.5</a> +<br> +testing, multi-line macro existence: +<a href="nasmdoc4.html#section-4.4.2">Section 4.4.2</a> +<br> +testing, single-line macro existence: +<a href="nasmdoc4.html#section-4.4.1">Section 4.4.1</a> +<br> +testing, token types: +<a href="nasmdoc4.html#section-4.4.6">Section 4.4.6</a> +<br> +<code><nobr>.text</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a>, +<a href="nasmdoc7.html#section-7.10">Section 7.10</a>, +<a href="nasmdoc7.html#section-7.11">Section 7.11</a>, +<a href="nasmdoc7.html#section-7.12">Section 7.12</a>, +<a href="nasmdoc7.html#section-7.13">Section 7.13</a> +<br> +<code><nobr>_TEXT</nobr></code>: +<a href="nasmdoc8.html#section-8.4.2">Section 8.4.2</a> +<br> +thread local storage: +<a href="nasmdoc7.html#section-7.9.4">Section 7.9.4</a> +<br> +<code><nobr>__TIME__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.7">Section 4.11.7</a> +<br> +<code><nobr>__TIME_NUM__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.7">Section 4.11.7</a> +<br> +<code><nobr>TIMES</nobr></code>: +<a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.5">Section 3.2.5</a>, +<a href="nasmdoc3.html#section-3.8">Section 3.8</a>, +<a href="nasmdo12.html#section-12.1.3">Section 12.1.3</a>, +<a href="nasmdo12.html#section-12.1.4">Section 12.1.4</a> +<br> +<code><nobr>TLINK</nobr></code>: +<a href="nasmdoc8.html#section-8.2.2">Section 8.2.2</a> +<br> +<code><nobr>tls</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a>, +<a href="nasmdoc7.html#section-7.9.4">Section 7.9.4</a> +<br> +<code><nobr>..tlsie</nobr></code>: +<a href="nasmdoc7.html#section-7.9.4">Section 7.9.4</a> +<br> +trailing colon: <a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +<code><nobr>TWORD</nobr></code>: +<a href="nasmdoc2.html#section-2.2.7">Section 2.2.7</a>, +<a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +type, of symbols: <a href="nasmdoc7.html#section-7.9.5">Section 7.9.5</a> +<br> +<code><nobr>-U</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.19">Section 2.1.19</a> +<br> +<code><nobr>-u</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.19">Section 2.1.19</a>, +<a href="nasmdoca.html#section-A.3">Section A.3</a> +<br> +unary operators: <a href="nasmdoc3.html#section-3.5.7">Section 3.5.7</a> +<br> +<code><nobr>%undef</nobr></code>: +<a href="nasmdoc2.html#section-2.1.19">Section 2.1.19</a>, +<a href="nasmdoc4.html#section-4.1.6">Section 4.1.6</a> +<br> +undefining macros: +<a href="nasmdoc2.html#section-2.1.19">Section 2.1.19</a> +<br> +underscore, in C symbols: +<a href="nasmdoc8.html#section-8.4.1">Section 8.4.1</a> +<br> +Unicode: <a href="nasmdoc3.html#section-3.4.2">Section 3.4.2</a>, +<a href="nasmdoc3.html#section-3.4.5">Section 3.4.5</a> +<br> +uninitialized: <a href="nasmdoc3.html#section-3.2">Section 3.2</a>, +<a href="nasmdoc3.html#section-3.2.2">Section 3.2.2</a> +<br> +uninitialized storage: +<a href="nasmdoc2.html#section-2.2.7">Section 2.2.7</a> +<br> +Unix: <a href="nasmdoc1.html#section-1.3.2">Section 1.3.2</a> +<br> +Unix, SCO: <a href="nasmdoc7.html#section-7.9">Section 7.9</a> +<br> +Unix, source archive: +<a href="nasmdoc1.html#section-1.3.2">Section 1.3.2</a> +<br> +Unix, System V: <a href="nasmdoc7.html#section-7.9">Section 7.9</a> +<br> +UnixWare: <a href="nasmdoc7.html#section-7.9">Section 7.9</a> +<br> +<code><nobr>%unmacro</nobr></code>: +<a href="nasmdoc4.html#section-4.3.11">Section 4.3.11</a> +<br> +unrolled loops: <a href="nasmdoc3.html#section-3.2.5">Section 3.2.5</a> +<br> +unsigned division: <a href="nasmdoc3.html#section-3.5.6">Section 3.5.6</a> +<br> +unsigned modulo: <a href="nasmdoc3.html#section-3.5.6">Section 3.5.6</a> +<br> +<code><nobr>UPPERCASE</nobr></code>: +<a href="nasmdoc2.html#section-2.2.1">Section 2.2.1</a>, +<a href="nasmdoc7.html#section-7.4.3">Section 7.4.3</a> +<br> +<code><nobr>%use</nobr></code>: +<a href="nasmdoc4.html#section-4.6.4">Section 4.6.4</a>, +<a href="nasmdoc5.html">Chapter 5</a> +<br> +<code><nobr>__USE_*__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.8">Section 4.11.8</a> +<br> +<code><nobr>USE16</nobr></code>: +<a href="nasmdoc6.html#section-6.1.1">Section 6.1.1</a>, +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +<code><nobr>USE32</nobr></code>: +<a href="nasmdoc6.html#section-6.1.1">Section 6.1.1</a>, +<a href="nasmdoc7.html#section-7.4.1">Section 7.4.1</a> +<br> +<code><nobr>user</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +user-defined errors: <a href="nasmdoc4.html#section-4.9">Section 4.9</a> +<br> +user-level assembler directives: +<a href="nasmdoc4.html#section-4.11">Section 4.11</a> +<br> +user-level directives: <a href="nasmdoc6.html">Chapter 6</a> +<br> +<code><nobr>__UTC_DATE__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.7">Section 4.11.7</a> +<br> +<code><nobr>__UTC_DATE_NUM__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.7">Section 4.11.7</a> +<br> +<code><nobr>__UTC_TIME__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.7">Section 4.11.7</a> +<br> +<code><nobr>__UTC_TIME_NUM__</nobr></code>: +<a href="nasmdoc4.html#section-4.11.7">Section 4.11.7</a> +<br> +UTF-16: <a href="nasmdoc3.html#section-3.4.5">Section 3.4.5</a> +<br> +UTF-32: <a href="nasmdoc3.html#section-3.4.5">Section 3.4.5</a> +<br> +UTF-8: <a href="nasmdoc3.html#section-3.4.2">Section 3.4.2</a> +<br> +<code><nobr>__utf16__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.5">Section 3.4.5</a> +<br> +<code><nobr>__utf32__</nobr></code>: +<a href="nasmdoc3.html#section-3.4.5">Section 3.4.5</a> +<br> +<code><nobr>-v</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.25">Section 2.1.25</a> +<br> +VAL: <a href="nasmdoc8.html#section-8.1.1">Section 8.1.1</a> +<br> +valid characters: <a href="nasmdoc3.html#section-3.1">Section 3.1</a> +<br> +variable types: <a href="nasmdoc2.html#section-2.2.3">Section 2.2.3</a> +<br> +version: <a href="nasmdoc2.html#section-2.1.25">Section 2.1.25</a> +<br> +version number of NASM: +<a href="nasmdoc4.html#section-4.11.1">Section 4.11.1</a> +<br> +<code><nobr>vfollows=</nobr></code>: +<a href="nasmdoc7.html#section-7.1.3">Section 7.1.3</a> +<br> +Visual C++: <a href="nasmdoc7.html#section-7.5">Section 7.5</a> +<br> +<code><nobr>vstart=</nobr></code>: +<a href="nasmdoc7.html#section-7.1.3">Section 7.1.3</a> +<br> +<code><nobr>-W</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +<code><nobr>-w</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +<code><nobr>%warning</nobr></code>: +<a href="nasmdoc4.html#section-4.9">Section 4.9</a> +<br> +warnings: <a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +<code><nobr>[warning *warning-name]</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +<code><nobr>[warning +warning-name]</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +<code><nobr>[warning -warning-name]</nobr></code>: +<a href="nasmdoc2.html#section-2.1.24">Section 2.1.24</a> +<br> +website: <a href="nasmdoc1.html#section-1.2">Section 1.2</a> +<br> +<code><nobr>win64</nobr></code>: +<a href="nasmdoc7.html#section-7.6">Section 7.6</a>, +<a href="nasmdo11.html">Chapter 11</a> +<br> +Win64: <a href="nasmdoc7.html#section-7.4">Section 7.4</a>, +<a href="nasmdoc7.html#section-7.5">Section 7.5</a>, +<a href="nasmdoc9.html">Chapter 9</a> +<br> +Windows: <a href="nasmdoc8.html#section-8.1">Section 8.1</a> +<br> +Windows 95: +<br> +Windows NT: +<br> +<code><nobr>write</nobr></code>: +<a href="nasmdoc7.html#section-7.9.2">Section 7.9.2</a> +<br> +writing operating systems: +<a href="nasmdo10.html#section-10.1">Section 10.1</a> +<br> +<code><nobr>WRT</nobr></code>: +<a href="nasmdoc3.html#section-3.6">Section 3.6</a>, +<a href="nasmdoc7.html#section-7.4">Section 7.4</a>, +<a href="nasmdoc7.html#section-7.9.3">Section 7.9.3</a>, +<a href="nasmdoc7.html#section-7.9.4">Section 7.9.4</a>, +<a href="nasmdoc7.html#section-7.11">Section 7.11</a> +<br> +<code><nobr>WRT ..got</nobr></code>: +<a href="nasmdoc9.html#section-9.2.3">Section 9.2.3</a> +<br> +<code><nobr>WRT ..gotoff</nobr></code>: +<a href="nasmdoc9.html#section-9.2.2">Section 9.2.2</a> +<br> +<code><nobr>WRT ..gotpc</nobr></code>: +<a href="nasmdoc9.html#section-9.2.1">Section 9.2.1</a> +<br> +<code><nobr>WRT ..plt</nobr></code>: +<a href="nasmdoc9.html#section-9.2.5">Section 9.2.5</a> +<br> +<code><nobr>WRT ..sym</nobr></code>: +<a href="nasmdoc9.html#section-9.2.4">Section 9.2.4</a> +<br> +WWW page: +<br> +<code><nobr>www.cpan.org</nobr></code>: +<a href="nasmdoc1.html#section-1.3.1">Section 1.3.1</a> +<br> +<code><nobr>www.delorie.com</nobr></code>: +<a href="nasmdoc8.html#section-8.1.1">Section 8.1.1</a> +<br> +<code><nobr>www.pcorner.com</nobr></code>: +<a href="nasmdoc8.html#section-8.1.1">Section 8.1.1</a> +<br> +<code><nobr>-X</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.13">Section 2.1.13</a> +<br> +<code><nobr>x2ftp.oulu.fi</nobr></code>: +<a href="nasmdoc8.html#section-8.1.1">Section 8.1.1</a> +<br> +<code><nobr>%xdefine</nobr></code>: +<a href="nasmdoc4.html#section-4.1.2">Section 4.1.2</a> +<br> +<code><nobr>-y</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.26">Section 2.1.26</a> +<br> +<code><nobr>-Z</nobr></code> option: +<a href="nasmdoc2.html#section-2.1.14">Section 2.1.14</a> +<br> +<p align=center><a href="nasmdoc0.html">Contents</a> +</body></html> |