nasmdoc6.htm

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

rounded up to 256, and so on. Note that alignment to 4096-byte boundaries
is a PharLap extension to the format and may not be supported by all
linkers.
<li><code><nobr>CLASS</nobr></code> can be used to specify the segment
class; this feature indicates to the linker that segments of the same class
should be placed near each other in the output file. The class name can be
any word, e.g. <code><nobr>CLASS=CODE</nobr></code>.
<li><code><nobr>OVERLAY</nobr></code>, like
<code><nobr>CLASS</nobr></code>, is specified with an arbitrary word as an
argument, and provides overlay information to an overlay-capable linker.
<li>Segments can be declared as <code><nobr>USE16</nobr></code> or
<code><nobr>USE32</nobr></code>, which has the effect of recording the
choice in the object file and also ensuring that NASM's default assembly
mode when assembling in that segment is 16-bit or 32-bit respectively.
<li>When writing OS/2 object files, you should declare 32-bit segments as
<code><nobr>FLAT</nobr></code>, which causes the default segment base for
anything in the segment to be the special group
<code><nobr>FLAT</nobr></code>, and also defines the group if it is not
already defined.
<li>The <code><nobr>obj</nobr></code> file format also allows segments to
be declared as having a pre-defined absolute segment address, although no
linkers are currently known to make sensible use of this feature;
nevertheless, NASM allows you to declare a segment such as
<code><nobr>SEGMENT SCREEN ABSOLUTE=0xB800</nobr></code> if you need to.
The <code><nobr>ABSOLUTE</nobr></code> and <code><nobr>ALIGN</nobr></code>
keywords are mutually exclusive.
</ul>
<p>NASM's default segment attributes are <code><nobr>PUBLIC</nobr></code>,
<code><nobr>ALIGN=1</nobr></code>, no class, no overlay, and
<code><nobr>USE16</nobr></code>.
<h4><a name="section-6.2.2">6.2.2 <code><nobr>GROUP</nobr></code>: Defining Groups of Segments</a></h4>
<p>The <code><nobr>obj</nobr></code> format also allows segments to be
grouped, so that a single segment register can be used to refer to all the
segments in a group. NASM therefore supplies the
<code><nobr>GROUP</nobr></code> directive, whereby you can code
<p><pre>
segment data 

        ; some data 

segment bss 

        ; some uninitialised data 

group dgroup data bss
</pre>
<p>which will define a group called <code><nobr>dgroup</nobr></code> to
contain the segments <code><nobr>data</nobr></code> and
<code><nobr>bss</nobr></code>. Like <code><nobr>SEGMENT</nobr></code>,
<code><nobr>GROUP</nobr></code> causes the group name to be defined as a
symbol, so that you can refer to a variable <code><nobr>var</nobr></code>
in the <code><nobr>data</nobr></code> segment as
<code><nobr>var wrt data</nobr></code> or as
<code><nobr>var wrt dgroup</nobr></code>, depending on which segment value
is currently in your segment register.
<p>If you just refer to <code><nobr>var</nobr></code>, however, and
<code><nobr>var</nobr></code> is declared in a segment which is part of a
group, then NASM will default to giving you the offset of
<code><nobr>var</nobr></code> from the beginning of the <em>group</em>, not
the <em>segment</em>. Therefore <code><nobr>SEG var</nobr></code>, also,
will return the group base rather than the segment base.
<p>NASM will allow a segment to be part of more than one group, but will
generate a warning if you do this. Variables declared in a segment which is
part of more than one group will default to being relative to the first
group that was defined to contain the segment.
<p>A group does not have to contain any segments; you can still make
<code><nobr>WRT</nobr></code> references to a group which does not contain
the variable you are referring to. OS/2, for example, defines the special
group <code><nobr>FLAT</nobr></code> with no segments in it.
<h4><a name="section-6.2.3">6.2.3 <code><nobr>UPPERCASE</nobr></code>: Disabling Case Sensitivity in Output</a></h4>
<p>Although NASM itself is case sensitive, some OMF linkers are not;
therefore it can be useful for NASM to output single-case object files. The
<code><nobr>UPPERCASE</nobr></code> format-specific directive causes all
segment, group and symbol names that are written to the object file to be
forced to upper case just before being written. Within a source file, NASM
is still case-sensitive; but the object file can be written entirely in
upper case if desired.
<p><code><nobr>UPPERCASE</nobr></code> is used alone on a line; it requires
no parameters.
<h4><a name="section-6.2.4">6.2.4 <code><nobr>IMPORT</nobr></code>: Importing DLL Symbols</a></h4>
<p>The <code><nobr>IMPORT</nobr></code> format-specific directive defines a
symbol to be imported from a DLL, for use if you are writing a DLL's import
library in NASM. You still need to declare the symbol as
<code><nobr>EXTERN</nobr></code> as well as using the
<code><nobr>IMPORT</nobr></code> directive.
<p>The <code><nobr>IMPORT</nobr></code> directive takes two required
parameters, separated by white space, which are (respectively) the name of
the symbol you wish to import and the name of the library you wish to
import it from. For example:
<p><pre>
    import  WSAStartup wsock32.dll
</pre>
<p>A third optional parameter gives the name by which the symbol is known
in the library you are importing it from, in case this is not the same as
the name you wish the symbol to be known by to your code once you have
imported it. For example:
<p><pre>
    import  asyncsel wsock32.dll WSAAsyncSelect
</pre>
<h4><a name="section-6.2.5">6.2.5 <code><nobr>EXPORT</nobr></code>: Exporting DLL Symbols</a></h4>
<p>The <code><nobr>EXPORT</nobr></code> format-specific directive defines a
global symbol to be exported as a DLL symbol, for use if you are writing a
DLL in NASM. You still need to declare the symbol as
<code><nobr>GLOBAL</nobr></code> as well as using the
<code><nobr>EXPORT</nobr></code> directive.
<p><code><nobr>EXPORT</nobr></code> takes one required parameter, which is
the name of the symbol you wish to export, as it was defined in your source
file. An optional second parameter (separated by white space from the
first) gives the <em>external</em> name of the symbol: the name by which
you wish the symbol to be known to programs using the DLL. If this name is
the same as the internal name, you may leave the second parameter off.
<p>Further parameters can be given to define attributes of the exported
symbol. These parameters, like the second, are separated by white space. If
further parameters are given, the external name must also be specified,
even if it is the same as the internal name. The available attributes are:
<ul>
<li><code><nobr>resident</nobr></code> indicates that the exported name is
to be kept resident by the system loader. This is an optimisation for
frequently used symbols imported by name.
<li><code><nobr>nodata</nobr></code> indicates that the exported symbol is
a function which does not make use of any initialised data.
<li><code><nobr>parm=NNN</nobr></code>, where <code><nobr>NNN</nobr></code>
is an integer, sets the number of parameter words for the case in which the
symbol is a call gate between 32-bit and 16-bit segments.
<li>An attribute which is just a number indicates that the symbol should be
exported with an identifying number (ordinal), and gives the desired
number.
</ul>
<p>For example:
<p><pre>
    export  myfunc 
    export  myfunc TheRealMoreFormalLookingFunctionName 
    export  myfunc myfunc 1234  ; export by ordinal 
    export  myfunc myfunc resident parm=23 nodata
</pre>
<h4><a name="section-6.2.6">6.2.6 <code><nobr>..start</nobr></code>: Defining the Program Entry Point</a></h4>
<p><code><nobr>OMF</nobr></code> linkers require exactly one of the object
files being linked to define the program entry point, where execution will
begin when the program is run. If the object file that defines the entry
point is assembled using NASM, you specify the entry point by declaring the
special symbol <code><nobr>..start</nobr></code> at the point where you
wish execution to begin.
<h4><a name="section-6.2.7">6.2.7 <code><nobr>obj</nobr></code> Extensions to the <code><nobr>EXTERN</nobr></code> Directive</a></h4>
<p>If you declare an external symbol with the directive
<p><pre>
    extern  foo
</pre>
<p>then references such as <code><nobr>mov ax,foo</nobr></code> will give
you the offset of <code><nobr>foo</nobr></code> from its preferred segment
base (as specified in whichever module <code><nobr>foo</nobr></code> is
actually defined in). So to access the contents of
<code><nobr>foo</nobr></code> you will usually need to do something like
<p><pre>
        mov     ax,seg foo      ; get preferred segment base 
        mov     es,ax           ; move it into ES 
        mov     ax,[es:foo]     ; and use offset `foo' from it
</pre>
<p>This is a little unwieldy, particularly if you know that an external is
going to be accessible from a given segment or group, say
<code><nobr>dgroup</nobr></code>. So if <code><nobr>DS</nobr></code>
already contained <code><nobr>dgroup</nobr></code>, you could simply code
<p><pre>
        mov     ax,[foo wrt dgroup]
</pre>
<p>However, having to type this every time you want to access
<code><nobr>foo</nobr></code> can be a pain; so NASM allows you to declare
<code><nobr>foo</nobr></code> in the alternative form
<p><pre>
    extern  foo:wrt dgroup
</pre>
<p>This form causes NASM to pretend that the preferred segment base of
<code><nobr>foo</nobr></code> is in fact <code><nobr>dgroup</nobr></code>;
so the expression <code><nobr>seg foo</nobr></code> will now return
<code><nobr>dgroup</nobr></code>, and the expression
<code><nobr>foo</nobr></code> is equivalent to
<code><nobr>foo wrt dgroup</nobr></code>.
<p>This default-<code><nobr>WRT</nobr></code> mechanism can be used to make
externals appear to be relative to any group or segment in your program. It
can also be applied to common variables: see
<a href="#section-6.2.8">section 6.2.8</a>.
<h4><a name="section-6.2.8">6.2.8 <code><nobr>obj</nobr></code> Extensions to the <code><nobr>COMMON</nobr></code> Directive</a></h4>
<p>The <code><nobr>obj</nobr></code> format allows common variables to be
either near or far; NASM allows you to specify which your variables should
be by the use of the syntax
<p><pre>
common  nearvar 2:near   ; `nearvar' is a near common 
common  farvar  10:far   ; and `farvar' is far
</pre>
<p>Far common variables may be greater in size than 64Kb, and so the OMF
specification says that they are declared as a number of <em>elements</em>
of a given size. So a 10-byte far common variable could be declared as ten
one-byte elements, five two-byte elements, two five-byte elements or one
ten-byte element.
<p>Some <code><nobr>OMF</nobr></code> linkers require the element size, as
well as the variable size, to match when resolving common variables
declared in more than one module. Therefore NASM must allow you to specify
the element size on your far common variables. This is done by the
following syntax:
<p><pre>
common  c_5by2  10:far 5        ; two five-byte elements 
common  c_2by5  10:far 2        ; five two-byte elements
</pre>
<p>If no element size is specified, the default is 1. Also, the
<code><nobr>FAR</nobr></code> keyword is not required when an element size
is specified, since only far commons may have element sizes at all. So the
above declarations could equivalently be
<p><pre>
common  c_5by2  10:5            ; two five-byte elements 
common  c_2by5  10:2            ; five two-byte elements
</pre>