"Fossies" - the Fresh Open Source Software Archive

Member "nasm-2.15.05/doc/html/nasmdoc7.html" (28 Aug 2020, 24055 Bytes) of package /linux/misc/nasm-2.15.05-xdoc.tar.xz:


As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) HTML source code syntax highlighting (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
    2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
    3 <html xmlns="http://www.w3.org/1999/xhtml">
    4 <head>
    5 <title>NASM - The Netwide Assembler</title>
    6 <link href="nasmdoc.css" rel="stylesheet" type="text/css" />
    7 <link href="local.css" rel="stylesheet" type="text/css" />
    8 </head>
    9 <body>
   10 <ul class="navbar">
   11 <li class="first"><a class="prev" href="nasmdoc6.html">Chapter 6</a></li>
   12 <li><a class="next" href="nasmdoc8.html">Chapter 8</a></li>
   13 <li><a class="toc" href="nasmdoc0.html">Contents</a></li>
   14 <li class="last"><a class="index" href="nasmdoci.html">Index</a></li>
   15 </ul>
   16 <div class="title">
   17 <h1>NASM - The Netwide Assembler</h1>
   18 <span class="subtitle">version 2.15.05</span>
   19 </div>
   20 <div class="contents"
   21 >
   22 <h2 id="chapter-7">Chapter 7: Assembler Directives</h2>
   23 <p>NASM, though it attempts to avoid the bureaucracy of assemblers like
   24 MASM and TASM, is nevertheless forced to support a <em>few</em> directives.
   25 These are described in this chapter.</p>
   26 <p>NASM's directives come in two types: <em>user-level</em> directives and
   27 <em>primitive</em> directives. Typically, each directive has a user-level
   28 form and a primitive form. In almost all cases, we recommend that users use
   29 the user-level forms of the directives, which are implemented as macros
   30 which call the primitive forms.</p>
   31 <p>Primitive directives are enclosed in square brackets; user-level
   32 directives are not.</p>
   33 <p>In addition to the universal directives described in this chapter, each
   34 object file format can optionally supply extra directives in order to
   35 control particular features of that file format. These
   36 <em>format-specific</em> directives are documented along with the formats
   37 that implement them, in <a href="nasmdoc8.html">chapter 8</a>.</p>
   38 <h3 id="section-7.1">7.1 <code>BITS</code>: Specifying Target Processor Mode</h3>
   39 <p>The <code>BITS</code> directive specifies whether NASM should generate
   40 code designed to run on a processor operating in 16-bit mode, 32-bit mode
   41 or 64-bit mode. The syntax is <code>BITS XX</code>, where XX is 16, 32 or
   42 64.</p>
   43 <p>In most cases, you should not need to use <code>BITS</code> explicitly.
   44 The <code>aout</code>, <code>coff</code>, <code>elf*</code>,
   45 <code>macho</code>, <code>win32</code> and <code>win64</code> object
   46 formats, which are designed for use in 32-bit or 64-bit operating systems,
   47 all cause NASM to select 32-bit or 64-bit mode, respectively, by default.
   48 The <code>obj</code> object format allows you to specify each segment you
   49 define as either <code>USE16</code> or <code>USE32</code>, and NASM will
   50 set its operating mode accordingly, so the use of the <code>BITS</code>
   51 directive is once again unnecessary.</p>
   52 <p>The most likely reason for using the <code>BITS</code> directive is to
   53 write 32-bit or 64-bit code in a flat binary file; this is because the
   54 <code>bin</code> output format defaults to 16-bit mode in anticipation of
   55 it being used most frequently to write DOS <code>.COM</code> programs, DOS
   56 <code>.SYS</code> device drivers and boot loader software.</p>
   57 <p>The <code>BITS</code> directive can also be used to generate code for a
   58 different mode than the standard one for the output format.</p>
   59 <p>You do <em>not</em> need to specify <code>BITS 32</code> merely in order
   60 to use 32-bit instructions in a 16-bit DOS program; if you do, the
   61 assembler will generate incorrect code because it will be writing code
   62 targeted at a 32-bit platform, to be run on a 16-bit one.</p>
   63 <p>When NASM is in <code>BITS 16</code> mode, instructions which use 32-bit
   64 data are prefixed with an 0x66 byte, and those referring to 32-bit
   65 addresses have an 0x67 prefix. In <code>BITS 32</code> mode, the reverse is
   66 true: 32-bit instructions require no prefixes, whereas instructions using
   67 16-bit data need an 0x66 and those working on 16-bit addresses need an
   68 0x67.</p>
   69 <p>When NASM is in <code>BITS 64</code> mode, most instructions operate the
   70 same as they do for <code>BITS 32</code> mode. However, there are 8 more
   71 general and SSE registers, and 16-bit addressing is no longer supported.</p>
   72 <p>The default address size is 64 bits; 32-bit addressing can be selected
   73 with the 0x67 prefix. The default operand size is still 32 bits, however,
   74 and the 0x66 prefix selects 16-bit operand size. The <code>REX</code>
   75 prefix is used both to select 64-bit operand size, and to access the new
   76 registers. NASM automatically inserts REX prefixes when necessary.</p>
   77 <p>When the <code>REX</code> prefix is used, the processor does not know
   78 how to address the AH, BH, CH or DH (high 8-bit legacy) registers. Instead,
   79 it is possible to access the the low 8-bits of the SP, BP SI and DI
   80 registers as SPL, BPL, SIL and DIL, respectively; but only when the REX
   81 prefix is used.</p>
   82 <p>The <code>BITS</code> directive has an exactly equivalent primitive
   83 form, <code>[BITS 16]</code>, <code>[BITS 32]</code> and
   84 <code>[BITS 64]</code>. The user-level form is a macro which has no
   85 function other than to call the primitive form.</p>
   86 <p>Note that the space is neccessary, e.g. <code>BITS32</code> will
   87 <em>not</em> work!</p>
   88 <h4 id="section-7.1.1">7.1.1 <code>USE16</code> &amp; <code>USE32</code>: Aliases for BITS</h4>
   89 <p>The `<code>USE16</code>' and `<code>USE32</code>' directives can be used
   90 in place of `<code>BITS 16</code>' and `<code>BITS 32</code>', for
   91 compatibility with other assemblers.</p>
   92 <h3 id="section-7.2">7.2 <code>DEFAULT</code>: Change the assembler defaults</h3>
   93 <p>The <code>DEFAULT</code> directive changes the assembler defaults.
   94 Normally, NASM defaults to a mode where the programmer is expected to
   95 explicitly specify most features directly. However, this is occasionally
   96 obnoxious, as the explicit form is pretty much the only one one wishes to
   97 use.</p>
   98 <p>Currently, <code>DEFAULT</code> can set <code>REL</code> &amp;
   99 <code>ABS</code> and <code>BND</code> &amp; <code>NOBND</code>.</p>
  100 <h4 id="section-7.2.1">7.2.1 <code>REL</code> &amp; <code>ABS</code>: RIP-relative addressing</h4>
  101 <p>This sets whether registerless instructions in 64-bit mode are
  102 <code>RIP</code>&ndash;relative or not. By default, they are absolute
  103 unless overridden with the <code>REL</code> specifier (see
  104 <a href="nasmdoc3.html#section-3.3">section 3.3</a>). However, if
  105 <code>DEFAULT REL</code> is specified, <code>REL</code> is default, unless
  106 overridden with the <code>ABS</code> specifier, <em>except when used with
  107 an FS or GS segment override</em>.</p>
  108 <p>The special handling of <code>FS</code> and <code>GS</code> overrides
  109 are due to the fact that these registers are generally used as thread
  110 pointers or other special functions in 64-bit mode, and generating
  111 <code>RIP</code>&ndash;relative addresses would be extremely confusing.</p>
  112 <p><code>DEFAULT REL</code> is disabled with <code>DEFAULT ABS</code>.</p>
  113 <h4 id="section-7.2.2">7.2.2 <code>BND</code> &amp; <code>NOBND</code>: <code>BND</code> prefix</h4>
  114 <p>If <code>DEFAULT BND</code> is set, all bnd-prefix available
  115 instructions following this directive are prefixed with bnd. To override
  116 it, <code>NOBND</code> prefix can be used.</p>
  117 <pre>
  118  DEFAULT BND 
  119      call foo            ; BND will be prefixed 
  120      nobnd call foo      ; BND will NOT be prefixed
  121 </pre>
  122 <p><code>DEFAULT NOBND</code> can disable <code>DEFAULT BND</code> and then
  123 <code>BND</code> prefix will be added only when explicitly specified in
  124 code.</p>
  125 <p><code>DEFAULT BND</code> is expected to be the normal configuration for
  126 writing MPX-enabled code.</p>
  127 <h3 id="section-7.3">7.3 <code>SECTION</code> or <code>SEGMENT</code>: Changing and Defining Sections</h3>
  128 <p>The <code>SECTION</code> directive (<code>SEGMENT</code> is an exactly
  129 equivalent synonym) changes which section of the output file the code you
  130 write will be assembled into. In some object file formats, the number and
  131 names of sections are fixed; in others, the user may make up as many as
  132 they wish. Hence <code>SECTION</code> may sometimes give an error message,
  133 or may define a new section, if you try to switch to a section that does
  134 not (yet) exist.</p>
  135 <p>The Unix object formats, and the <code>bin</code> object format (but see
  136 <a href="nasmdoc8.html#section-8.1.3">section 8.1.3</a>), all support the
  137 standardized section names <code>.text</code>, <code>.data</code> and
  138 <code>.bss</code> for the code, data and uninitialized-data sections. The
  139 <code>obj</code> format, by contrast, does not recognize these section
  140 names as being special, and indeed will strip off the leading period of any
  141 section name that has one.</p>
  142 <h4 id="section-7.3.1">7.3.1 The <code>__?SECT?__</code> Macro</h4>
  143 <p>The <code>SECTION</code> directive is unusual in that its user-level
  144 form functions differently from its primitive form. The primitive form,
  145 <code>[SECTION xyz]</code>, simply switches the current target section to
  146 the one given. The user-level form, <code>SECTION xyz</code>, however,
  147 first defines the single-line macro <code>__?SECT?__</code> to be the
  148 primitive <code>[SECTION]</code> directive which it is about to issue, and
  149 then issues it. So the user-level directive</p>
  150 <pre>
  151         SECTION .text
  152 </pre>
  153 <p>expands to the two lines</p>
  154 <pre>
  155 %define __?SECT?__        [SECTION .text] 
  156         [SECTION .text]
  157 </pre>
  158 <p>Users may find it useful to make use of this in their own macros. For
  159 example, the <code>writefile</code> macro defined in
  160 <a href="nasmdoc4.html#section-4.3.3">section 4.3.3</a> can be usefully
  161 rewritten in the following more sophisticated form:</p>
  162 <pre>
  163 %macro  writefile 2+ 
  164 
  165         [section .data] 
  166 
  167   %%str:        db      %2 
  168   %%endstr: 
  169 
  170         __?SECT?__ 
  171 
  172         mov     dx,%%str 
  173         mov     cx,%%endstr-%%str 
  174         mov     bx,%1 
  175         mov     ah,0x40 
  176         int     0x21 
  177 
  178 %endmacro
  179 </pre>
  180 <p>This form of the macro, once passed a string to output, first switches
  181 temporarily to the data section of the file, using the primitive form of
  182 the <code>SECTION</code> directive so as not to modify
  183 <code>__?SECT?__</code>. It then declares its string in the data section,
  184 and then invokes <code>__?SECT?__</code> to switch back to
  185 <em>whichever</em> section the user was previously working in. It thus
  186 avoids the need, in the previous version of the macro, to include a
  187 <code>JMP</code> instruction to jump over the data, and also does not fail
  188 if, in a complicated <code>OBJ</code> format module, the user could
  189 potentially be assembling the code in any of several separate code
  190 sections.</p>
  191 <h3 id="section-7.4">7.4 <code>ABSOLUTE</code>: Defining Absolute Labels</h3>
  192 <p>The <code>ABSOLUTE</code> directive can be thought of as an alternative
  193 form of <code>SECTION</code>: it causes the subsequent code to be directed
  194 at no physical section, but at the hypothetical section starting at the
  195 given absolute address. The only instructions you can use in this mode are
  196 the <code>RESB</code> family.</p>
  197 <p><code>ABSOLUTE</code> is used as follows:</p>
  198 <pre>
  199 absolute 0x1A 
  200 
  201     kbuf_chr    resw    1 
  202     kbuf_free   resw    1 
  203     kbuf        resw    16
  204 </pre>
  205 <p>This example describes a section of the PC BIOS data area, at segment
  206 address 0x40: the above code defines <code>kbuf_chr</code> to be 0x1A,
  207 <code>kbuf_free</code> to be 0x1C, and <code>kbuf</code> to be 0x1E.</p>
  208 <p>The user-level form of <code>ABSOLUTE</code>, like that of
  209 <code>SECTION</code>, redefines the <code>__?SECT?__</code> macro when it
  210 is invoked.</p>
  211 <p><code>STRUC</code> and <code>ENDSTRUC</code> are defined as macros which
  212 use <code>ABSOLUTE</code> (and also <code>__?SECT?__</code>).</p>
  213 <p><code>ABSOLUTE</code> doesn't have to take an absolute constant as an
  214 argument: it can take an expression (actually, a critical expression: see
  215 <a href="nasmdoc3.html#section-3.8">section 3.8</a>) and it can be a value
  216 in a segment. For example, a TSR can re-use its setup code as run-time BSS
  217 like this:</p>
  218 <pre>
  219         org     100h               ; it's a .COM program 
  220 
  221         jmp     setup              ; setup code comes last 
  222 
  223         ; the resident part of the TSR goes here 
  224 setup: 
  225         ; now write the code that installs the TSR here 
  226 
  227 absolute setup 
  228 
  229 runtimevar1     resw    1 
  230 runtimevar2     resd    20 
  231 
  232 tsr_end:
  233 </pre>
  234 <p>This defines some variables `on top of' the setup code, so that after
  235 the setup has finished running, the space it took up can be re-used as data
  236 storage for the running TSR. The symbol `tsr_end' can be used to calculate
  237 the total size of the part of the TSR that needs to be made resident.</p>
  238 <h3 id="section-7.5">7.5 <code>EXTERN</code>: Importing Symbols from Other Modules</h3>
  239 <p><code>EXTERN</code> is similar to the MASM directive <code>EXTRN</code>
  240 and the C keyword <code>extern</code>: it is used to declare a symbol which
  241 is not defined anywhere in the module being assembled, but is assumed to be
  242 defined in some other module and needs to be referred to by this one. Not
  243 every object-file format can support external variables: the
  244 <code>bin</code> format cannot.</p>
  245 <p>The <code>EXTERN</code> directive takes as many arguments as you like.
  246 Each argument is the name of a symbol:</p>
  247 <pre>
  248 extern  _printf 
  249 extern  _sscanf,_fscanf
  250 </pre>
  251 <p>Some object-file formats provide extra features to the
  252 <code>EXTERN</code> directive. In all cases, the extra features are used by
  253 suffixing a colon to the symbol name followed by object-format specific
  254 text. For example, the <code>obj</code> format allows you to declare that
  255 the default segment base of an external should be the group
  256 <code>dgroup</code> by means of the directive</p>
  257 <pre>
  258 extern  _variable:wrt dgroup
  259 </pre>
  260 <p>The primitive form of <code>EXTERN</code> differs from the user-level
  261 form only in that it can take only one argument at a time: the support for
  262 multiple arguments is implemented at the preprocessor level.</p>
  263 <p>You can declare the same variable as <code>EXTERN</code> more than once:
  264 NASM will quietly ignore the second and later redeclarations.</p>
  265 <p>If a variable is declared both <code>GLOBAL</code> and
  266 <code>EXTERN</code>, or if it is declared as <code>EXTERN</code> and then
  267 defined, it will be treated as <code>GLOBAL</code>. If a variable is
  268 declared both as <code>COMMON</code> and <code>EXTERN</code>, it will be
  269 treated as <code>COMMON</code>.</p>
  270 <h3 id="section-7.6">7.6 <code>REQUIRED</code>: Unconditionally Importing Symbols from Other Modules</h3>
  271 <p>The <code>REQUIRED</code> keyword is similar to <code>EXTERN</code> one.
  272 The difference is that the <code>EXTERN</code> keyword as of version 2.15
  273 does not generate unknown symbols as that prevents using common header
  274 files, as it might cause the linker to pull in a bunch of unnecessary
  275 modules.</p>
  276 <p>If the old behavior is required, use <code>REQUIRED</code> keyword
  277 instead.</p>
  278 <h3 id="section-7.7">7.7 <code>GLOBAL</code>: Exporting Symbols to Other Modules</h3>
  279 <p><code>GLOBAL</code> is the other end of <code>EXTERN</code>: if one
  280 module declares a symbol as <code>EXTERN</code> and refers to it, then in
  281 order to prevent linker errors, some other module must actually
  282 <em>define</em> the symbol and declare it as <code>GLOBAL</code>. Some
  283 assemblers use the name <code>PUBLIC</code> for this purpose.</p>
  284 <p><code>GLOBAL</code> uses the same syntax as <code>EXTERN</code>, except
  285 that it must refer to symbols which <em>are</em> defined in the same module
  286 as the <code>GLOBAL</code> directive. For example:</p>
  287 <pre>
  288 global _main 
  289 _main: 
  290         ; some code
  291 </pre>
  292 <p><code>GLOBAL</code>, like <code>EXTERN</code>, allows object formats to
  293 define private extensions by means of a colon. The ELF object format, for
  294 example, lets you specify whether global data items are functions or data:</p>
  295 <pre>
  296 global  hashlookup:function, hashtable:data
  297 </pre>
  298 <p>Like <code>EXTERN</code>, the primitive form of <code>GLOBAL</code>
  299 differs from the user-level form only in that it can take only one argument
  300 at a time.</p>
  301 <h3 id="section-7.8">7.8 <code>COMMON</code>: Defining Common Data Areas</h3>
  302 <p>The <code>COMMON</code> directive is used to declare <em>common
  303 variables</em>. A common variable is much like a global variable declared
  304 in the uninitialized data section, so that</p>
  305 <pre>
  306 common  intvar  4
  307 </pre>
  308 <p>is similar in function to</p>
  309 <pre>
  310 global  intvar 
  311 section .bss 
  312 
  313 intvar  resd    1
  314 </pre>
  315 <p>The difference is that if more than one module defines the same common
  316 variable, then at link time those variables will be <em>merged</em>, and
  317 references to <code>intvar</code> in all modules will point at the same
  318 piece of memory.</p>
  319 <p>Like <code>GLOBAL</code> and <code>EXTERN</code>, <code>COMMON</code>
  320 supports object-format specific extensions. For example, the
  321 <code>obj</code> format allows common variables to be NEAR or FAR, and the
  322 ELF format allows you to specify the alignment requirements of a common
  323 variable:</p>
  324 <pre>
  325 common  commvar  4:near  ; works in OBJ 
  326 common  intarray 100:4   ; works in ELF: 4 byte aligned
  327 </pre>
  328 <p>Once again, like <code>EXTERN</code> and <code>GLOBAL</code>, the
  329 primitive form of <code>COMMON</code> differs from the user-level form only
  330 in that it can take only one argument at a time.</p>
  331 <h3 id="section-7.9">7.9 <code>STATIC</code>: Local Symbols within Modules</h3>
  332 <p>Opposite to <code>EXTERN</code> and <code>GLOBAL</code>,
  333 <code>STATIC</code> is local symbol, but should be named according to the
  334 global mangling rules (named by analogy with the C keyword
  335 <code>static</code> as applied to functions or global variables).</p>
  336 <pre>
  337 static foo 
  338 foo: 
  339          ; codes
  340 </pre>
  341 <p>Unlike <code>GLOBAL</code>, <code>STATIC</code> does not allow object
  342 formats to accept private extensions mentioned in
  343 <a href="#section-7.7">section 7.7</a>.</p>
  344 <h3 id="section-7.10">7.10 <code>(G|L)PREFIX</code>, <code>(G|L)POSTFIX</code>: Mangling Symbols</h3>
  345 <p><code>PREFIX</code>, <code>GPREFIX</code>, <code>LPREFIX</code>,
  346 <code>POSTFIX</code>, <code>GPOSTFIX</code>, and <code>LPOSTFIX</code>
  347 directives can prepend or append a string to a certain type of symbols,
  348 normally to fit specific ABI conventions</p>
  349 <ul>
  350 <li>
  351 <p><code>PREFIX</code>|<code>GPREFIX</code>: Prepend the argument to all
  352 <code>EXTERN</code> <code>COMMON</code>, <code>STATIC</code>, and
  353 <code>GLOBAL</code> symbols.</p>
  354 </li>
  355 <li>
  356 <p><code>LPREFIX</code>: Prepend the argument to all other symbols such as
  357 local labels and backend defined symbols.</p>
  358 </li>
  359 <li>
  360 <p><code>POSTFIX</code>|<code>GPOSTFIX</code>: Append the argument to all
  361 <code>EXTERN</code> <code>COMMON</code>, <code>STATIC</code>, and
  362 <code>GLOBAL</code> symbols.</p>
  363 </li>
  364 <li>
  365 <p><code>LPOSTFIX</code>: Append the argument to all other symbols such as
  366 local labels and backend defined symbols.</p>
  367 </li>
  368 </ul>
  369 <p>These a macros implemented as pragmas, and using <code>%pragma</code>
  370 syntax can be restricted to specific backends (see
  371 <a href="nasmdoc4.html#section-4.10">section 4.10</a>):</p>
  372 <pre>
  373 %pragma macho lprefix L_
  374 </pre>
  375 <p>Command line options are also available. See also
  376 <a href="nasmdoc2.html#section-2.1.28">section 2.1.28</a>.</p>
  377 <p>One example which supports many ABIs:</p>
  378 <pre>
  379 ; The most common conventions 
  380 %pragma output gprefix _ 
  381 %pragma output lprefix L_ 
  382 ; ELF uses a different convention 
  383 %pragma elf    gprefix                       ; empty 
  384 %pragma elf    lprefix .L
  385 </pre>
  386 <p>Some toolchains is aware of a particular prefix for its own optimization
  387 options, such as code elimination. For instance, Mach-O backend has a
  388 linker that uses a simplistic naming scheme to chunk up sections into a
  389 meta section. When the <code>subsections_via_symbols</code> directive
  390 (<a href="nasmdoc8.html#section-8.8.4">section 8.8.4</a>) is declared, each
  391 symbol is the start of a separate block. The meta section is, then, defined
  392 to include sections before the one that starts with a 'L'.
  393 <code>LPREFIX</code> is useful here to mark all local symbols with the 'L'
  394 prefix to be excluded to the meta section. It converts local symbols
  395 compatible with the particular toolchain. Note that local symbols declared
  396 with <code>STATIC</code> (<a href="#section-7.9">section 7.9</a>) are
  397 excluded from the symbol mangling and also not marked as global.</p>
  398 <h3 id="section-7.11">7.11 <code>CPU</code>: Defining CPU Dependencies</h3>
  399 <p>The <code>CPU</code> directive restricts assembly to those instructions
  400 which are available on the specified CPU.</p>
  401 <p>Options are:</p>
  402 <ul>
  403 <li>
  404 <p><code>CPU 8086</code> Assemble only 8086 instruction set</p>
  405 </li>
  406 <li>
  407 <p><code>CPU 186</code> Assemble instructions up to the 80186 instruction
  408 set</p>
  409 </li>
  410 <li>
  411 <p><code>CPU 286</code> Assemble instructions up to the 286 instruction set</p>
  412 </li>
  413 <li>
  414 <p><code>CPU 386</code> Assemble instructions up to the 386 instruction set</p>
  415 </li>
  416 <li>
  417 <p><code>CPU 486</code> 486 instruction set</p>
  418 </li>
  419 <li>
  420 <p><code>CPU 586</code> Pentium instruction set</p>
  421 </li>
  422 <li>
  423 <p><code>CPU PENTIUM</code> Same as 586</p>
  424 </li>
  425 <li>
  426 <p><code>CPU 686</code> P6 instruction set</p>
  427 </li>
  428 <li>
  429 <p><code>CPU PPRO</code> Same as 686</p>
  430 </li>
  431 <li>
  432 <p><code>CPU P2</code> Same as 686</p>
  433 </li>
  434 <li>
  435 <p><code>CPU P3</code> Pentium III (Katmai) instruction sets</p>
  436 </li>
  437 <li>
  438 <p><code>CPU KATMAI</code> Same as P3</p>
  439 </li>
  440 <li>
  441 <p><code>CPU P4</code> Pentium 4 (Willamette) instruction set</p>
  442 </li>
  443 <li>
  444 <p><code>CPU WILLAMETTE</code> Same as P4</p>
  445 </li>
  446 <li>
  447 <p><code>CPU PRESCOTT</code> Prescott instruction set</p>
  448 </li>
  449 <li>
  450 <p><code>CPU X64</code> x86-64 (x64/AMD64/Intel 64) instruction set</p>
  451 </li>
  452 <li>
  453 <p><code>CPU IA64</code> IA64 CPU (in x86 mode) instruction set</p>
  454 </li>
  455 </ul>
  456 <p>All options are case insensitive. All instructions will be selected only
  457 if they apply to the selected CPU or lower. By default, all instructions
  458 are available.</p>
  459 <h3 id="section-7.12">7.12 <code>FLOAT</code>: Handling of floating-point constants</h3>
  460 <p>By default, floating-point constants are rounded to nearest, and IEEE
  461 denormals are supported. The following options can be set to alter this
  462 behaviour:</p>
  463 <ul>
  464 <li>
  465 <p><code>FLOAT DAZ</code> Flush denormals to zero</p>
  466 </li>
  467 <li>
  468 <p><code>FLOAT NODAZ</code> Do not flush denormals to zero (default)</p>
  469 </li>
  470 <li>
  471 <p><code>FLOAT NEAR</code> Round to nearest (default)</p>
  472 </li>
  473 <li>
  474 <p><code>FLOAT UP</code> Round up (toward +Infinity)</p>
  475 </li>
  476 <li>
  477 <p><code>FLOAT DOWN</code> Round down (toward &ndash;Infinity)</p>
  478 </li>
  479 <li>
  480 <p><code>FLOAT ZERO</code> Round toward zero</p>
  481 </li>
  482 <li>
  483 <p><code>FLOAT DEFAULT</code> Restore default settings</p>
  484 </li>
  485 </ul>
  486 <p>The standard macros <code>__?FLOAT_DAZ?__</code>,
  487 <code>__?FLOAT_ROUND?__</code>, and <code>__?FLOAT?__</code> contain the
  488 current state, as long as the programmer has avoided the use of the
  489 brackeded primitive form, (<code>[FLOAT]</code>).</p>
  490 <p><code>__?FLOAT?__</code> contains the full set of floating-point
  491 settings; this value can be saved away and invoked later to restore the
  492 setting.</p>
  493 <h3 id="section-7.13">7.13 <code>[WARNING]</code>: Enable or disable warnings</h3>
  494 <p>The <code>[WARNING]</code> directive can be used to enable or disable
  495 classes of warnings in the same way as the <code>-w</code> option, see
  496 <a href="nasmdoc2.html#section-2.1.26">section 2.1.26</a> for more details
  497 about warning classes.</p>
  498 <ul>
  499 <li>
  500 <p><code>[warning +</code><em>warning-class</em><code>]</code> enables
  501 warnings for <em>warning-class</em>.</p>
  502 </li>
  503 <li>
  504 <p><code>[warning -</code><em>warning-class</em><code>]</code> disables
  505 warnings for <em>warning-class</em>.</p>
  506 </li>
  507 <li>
  508 <p><code>[warning *</code><em>warning-class</em><code>]</code> restores
  509 <em>warning-class</em> to the original value, either the default value or
  510 as specified on the command line.</p>
  511 </li>
  512 <li>
  513 <p><code>[warning push]</code> saves the current warning state on a stack.</p>
  514 </li>
  515 <li>
  516 <p><code>[warning pop]</code> restores the current warning state from the
  517 stack.</p>
  518 </li>
  519 </ul>
  520 <p>The <code>[WARNING]</code> directive also accepts the <code>all</code>,
  521 <code>error</code> and <code>error=</code><em>warning-class</em>
  522 specifiers.</p>
  523 <p>No "user form" (without the brackets) currently exists.</p>
  524 </div>
  525 </body>
  526 </html>