nasmdoc2.htm

nasm手册 大家可以看看 对要写汇编程序的帮助很大

why you might want it to.
<li><code><nobr>number-overflow</nobr></code> covers warnings about numeric
constants which don't fit in 32 bits (for example, it's easy to type one
too many Fs and produce <code><nobr>0x7ffffffff</nobr></code> by mistake).
This warning class is enabled by default.
<li><code><nobr>gnu-elf-extensions</nobr></code> warns if 8-bit or 16-bit
relocations are used in <code><nobr>-f elf</nobr></code> format. The GNU
extensions allow this. This warning class is enabled by default.
<li>In addition, warning classes may be enabled or disabled across sections
of source code with <code><nobr>[warning +warning-name]</nobr></code> or
<code><nobr>[warning -warning-name]</nobr></code>. No "user form" (without
the brackets) exists.
</ul>
<h4><a name="section-2.1.19">2.1.19 The <code><nobr>-v</nobr></code> Option: Display Version Info</a></h4>
<p>Typing <code><nobr>NASM -v</nobr></code> will display the version of
NASM which you are using, and the date on which it was compiled. This
replaces the deprecated <code><nobr>-r</nobr></code>.
<p>You will need the version number if you report a bug.
<h4><a name="section-2.1.20">2.1.20 The <code><nobr>-y</nobr></code> Option: Display Available Debug Info Formats</a></h4>
<p>Typing <code><nobr>nasm -f &lt;option&gt; -y</nobr></code> will display
a list of the available debug info formats for the given output format. The
default format is indicated by an asterisk. E.g.
<code><nobr>nasm -f obj -y</nobr></code> yields
<code><nobr>* borland</nobr></code>. (as of 0.98.35, the <em>only</em>
debug info format implemented).
<h4><a name="section-2.1.21">2.1.21 The <code><nobr>--prefix</nobr></code> and <code><nobr>--postfix</nobr></code> Options.</a></h4>
<p>The <code><nobr>--prefix</nobr></code> and
<code><nobr>--postfix</nobr></code> options prepend or append
(respectively) the given argument to all <code><nobr>global</nobr></code>
or <code><nobr>extern</nobr></code> variables. E.g.
<code><nobr>--prefix_</nobr></code> will prepend the underscore to all
global and external variables, as C sometimes (but not always) likes it.
<h4><a name="section-2.1.22">2.1.22 The <code><nobr>NASMENV</nobr></code> Environment Variable</a></h4>
<p>If you define an environment variable called
<code><nobr>NASMENV</nobr></code>, the program will interpret it as a list
of extra command-line options, which are processed before the real command
line. You can use this to define standard search directories for include
files, by putting <code><nobr>-i</nobr></code> options in the
<code><nobr>NASMENV</nobr></code> variable.
<p>The value of the variable is split up at white space, so that the value
<code><nobr>-s -ic:\nasmlib</nobr></code> will be treated as two separate
options. However, that means that the value
<code><nobr>-dNAME="my name"</nobr></code> won't do what you might want,
because it will be split at the space and the NASM command-line processing
will get confused by the two nonsensical words
<code><nobr>-dNAME="my</nobr></code> and <code><nobr>name"</nobr></code>.
<p>To get round this, NASM provides a feature whereby, if you begin the
<code><nobr>NASMENV</nobr></code> environment variable with some character
that isn't a minus sign, then NASM will treat this character as the
separator character for options. So setting the
<code><nobr>NASMENV</nobr></code> variable to the value
<code><nobr>!-s!-ic:\nasmlib</nobr></code> is equivalent to setting it to
<code><nobr>-s -ic:\nasmlib</nobr></code>, but
<code><nobr>!-dNAME="my name"</nobr></code> will work.
<p>This environment variable was previously called
<code><nobr>NASM</nobr></code>. This was changed with version 0.98.31.
<h3><a name="section-2.2">2.2 Quick Start for MASM Users</a></h3>
<p>If you're used to writing programs with MASM, or with TASM in
MASM-compatible (non-Ideal) mode, or with <code><nobr>a86</nobr></code>,
this section attempts to outline the major differences between MASM's
syntax and NASM's. If you're not already used to MASM, it's probably worth
skipping this section.
<h4><a name="section-2.2.1">2.2.1 NASM Is Case-Sensitive</a></h4>
<p>One simple difference is that NASM is case-sensitive. It makes a
difference whether you call your label <code><nobr>foo</nobr></code>,
<code><nobr>Foo</nobr></code> or <code><nobr>FOO</nobr></code>. If you're
assembling to <code><nobr>DOS</nobr></code> or
<code><nobr>OS/2</nobr></code> <code><nobr>.OBJ</nobr></code> files, you
can invoke the <code><nobr>UPPERCASE</nobr></code> directive (documented in
<a href="nasmdoc6.html#section-6.2">section 6.2</a>) to ensure that all
symbols exported to other code modules are forced to be upper case; but
even then, <em>within</em> a single module, NASM will distinguish between
labels differing only in case.
<h4><a name="section-2.2.2">2.2.2 NASM Requires Square Brackets For Memory References</a></h4>
<p>NASM was designed with simplicity of syntax in mind. One of the design
goals of NASM is that it should be possible, as far as is practical, for
the user to look at a single line of NASM code and tell what opcode is
generated by it. You can't do this in MASM: if you declare, for example,
<p><pre>
foo     equ     1 
bar     dw      2
</pre>
<p>then the two lines of code
<p><pre>
        mov     ax,foo 
        mov     ax,bar
</pre>
<p>generate completely different opcodes, despite having identical-looking
syntaxes.
<p>NASM avoids this undesirable situation by having a much simpler syntax
for memory references. The rule is simply that any access to the
<em>contents</em> of a memory location requires square brackets around the
address, and any access to the <em>address</em> of a variable doesn't. So
an instruction of the form <code><nobr>mov ax,foo</nobr></code> will
<em>always</em> refer to a compile-time constant, whether it's an
<code><nobr>EQU</nobr></code> or the address of a variable; and to access
the <em>contents</em> of the variable <code><nobr>bar</nobr></code>, you
must code <code><nobr>mov ax,[bar]</nobr></code>.
<p>This also means that NASM has no need for MASM's
<code><nobr>OFFSET</nobr></code> keyword, since the MASM code
<code><nobr>mov ax,offset bar</nobr></code> means exactly the same thing as
NASM's <code><nobr>mov ax,bar</nobr></code>. If you're trying to get large
amounts of MASM code to assemble sensibly under NASM, you can always code
<code><nobr>%idefine offset</nobr></code> to make the preprocessor treat
the <code><nobr>OFFSET</nobr></code> keyword as a no-op.
<p>This issue is even more confusing in <code><nobr>a86</nobr></code>,
where declaring a label with a trailing colon defines it to be a `label' as
opposed to a `variable' and causes <code><nobr>a86</nobr></code> to adopt
NASM-style semantics; so in <code><nobr>a86</nobr></code>,
<code><nobr>mov ax,var</nobr></code> has different behaviour depending on
whether <code><nobr>var</nobr></code> was declared as
<code><nobr>var: dw 0</nobr></code> (a label) or
<code><nobr>var dw 0</nobr></code> (a word-size variable). NASM is very
simple by comparison: <em>everything</em> is a label.
<p>NASM, in the interests of simplicity, also does not support the hybrid
syntaxes supported by MASM and its clones, such as
<code><nobr>mov ax,table[bx]</nobr></code>, where a memory reference is
denoted by one portion outside square brackets and another portion inside.
The correct syntax for the above is
<code><nobr>mov ax,[table+bx]</nobr></code>. Likewise,
<code><nobr>mov ax,es:[di]</nobr></code> is wrong and
<code><nobr>mov ax,[es:di]</nobr></code> is right.
<h4><a name="section-2.2.3">2.2.3 NASM Doesn't Store Variable Types</a></h4>
<p>NASM, by design, chooses not to remember the types of variables you
declare. Whereas MASM will remember, on seeing
<code><nobr>var dw 0</nobr></code>, that you declared
<code><nobr>var</nobr></code> as a word-size variable, and will then be
able to fill in the ambiguity in the size of the instruction
<code><nobr>mov var,2</nobr></code>, NASM will deliberately remember
nothing about the symbol <code><nobr>var</nobr></code> except where it
begins, and so you must explicitly code
<code><nobr>mov word [var],2</nobr></code>.
<p>For this reason, NASM doesn't support the
<code><nobr>LODS</nobr></code>, <code><nobr>MOVS</nobr></code>,
<code><nobr>STOS</nobr></code>, <code><nobr>SCAS</nobr></code>,
<code><nobr>CMPS</nobr></code>, <code><nobr>INS</nobr></code>, or
<code><nobr>OUTS</nobr></code> instructions, but only supports the forms
such as <code><nobr>LODSB</nobr></code>, <code><nobr>MOVSW</nobr></code>,
and <code><nobr>SCASD</nobr></code>, which explicitly specify the size of
the components of the strings being manipulated.
<h4><a name="section-2.2.4">2.2.4 NASM Doesn't <code><nobr>ASSUME</nobr></code></a></h4>
<p>As part of NASM's drive for simplicity, it also does not support the
<code><nobr>ASSUME</nobr></code> directive. NASM will not keep track of
what values you choose to put in your segment registers, and will never
<em>automatically</em> generate a segment override prefix.
<h4><a name="section-2.2.5">2.2.5 NASM Doesn't Support Memory Models</a></h4>
<p>NASM also does not have any directives to support different 16-bit
memory models. The programmer has to keep track of which functions are
supposed to be called with a far call and which with a near call, and is
responsible for putting the correct form of <code><nobr>RET</nobr></code>
instruction (<code><nobr>RETN</nobr></code> or
<code><nobr>RETF</nobr></code>; NASM accepts <code><nobr>RET</nobr></code>
itself as an alternate form for <code><nobr>RETN</nobr></code>); in
addition, the programmer is responsible for coding CALL FAR instructions
where necessary when calling <em>external</em> functions, and must also
keep track of which external variable definitions are far and which are
near.
<h4><a name="section-2.2.6">2.2.6 Floating-Point Differences</a></h4>
<p>NASM uses different names to refer to floating-point registers from
MASM: where MASM would call them <code><nobr>ST(0)</nobr></code>,
<code><nobr>ST(1)</nobr></code> and so on, and
<code><nobr>a86</nobr></code> would call them simply
<code><nobr>0</nobr></code>, <code><nobr>1</nobr></code> and so on, NASM
chooses to call them <code><nobr>st0</nobr></code>,
<code><nobr>st1</nobr></code> etc.
<p>As of version 0.96, NASM now treats the instructions with `nowait' forms
in the same way as MASM-compatible assemblers. The idiosyncratic treatment
employed by 0.95 and earlier was based on a misunderstanding by the
authors.
<h4><a name="section-2.2.7">2.2.7 Other Differences</a></h4>
<p>For historical reasons, NASM uses the keyword
<code><nobr>TWORD</nobr></code> where MASM and compatible assemblers use
<code><nobr>TBYTE</nobr></code>.
<p>NASM does not declare uninitialised storage in the same way as MASM:
where a MASM programmer might use
<code><nobr>stack db 64 dup (?)</nobr></code>, NASM requires
<code><nobr>stack resb 64</nobr></code>, intended to be read as `reserve 64
bytes'. For a limited amount of compatibility, since NASM treats
<code><nobr>?</nobr></code> as a valid character in symbol names, you can
code <code><nobr>? equ 0</nobr></code> and then writing
<code><nobr>dw ?</nobr></code> will at least do something vaguely useful.
<code><nobr>DUP</nobr></code> is still not a supported syntax, however.
<p>In addition to all of this, macros and directives work completely
differently to MASM. See <a href="nasmdoc4.html">chapter 4</a> and
<a href="nasmdoc5.html">chapter 5</a> for further details.
<p align=center><a href="nasmdoc3.html">Next Chapter</a> |
<a href="nasmdoc1.html">Previous Chapter</a> |
<a href="nasmdoc0.html">Contents</a> |
<a href="nasmdoci.html">Index</a>
</body></html>