Next Chapter | Previous Chapter | Contents | Index
To assemble a file, you issue a command of the form
nasm -f <format> <filename> [-o <output>]
For example,
nasm -f elf myfile.asm
will assemble
into an ELF object
file
. And
nasm -f bin myfile.asm -o myfile.com
will assemble
into a raw binary
file
.
To produce a listing file, with the hex codes output from NASM displayed
on the left of the original sources, use the
option to give a listing file name, for example:
nasm -f coff myfile.asm -l myfile.lst
To get further usage instructions from NASM, try typing
nasm -h
This will also list the available output file formats, and what they are.
If you use Linux but aren't sure whether your system is
or ELF, type
file nasm
(in the directory in which you put the NASM binary when you installed it). If it says something like
nasm: ELF 32-bit LSB executable i386 (386 and up) Version 1
then your system is ELF, and you should use the option
when you want NASM to produce Linux object
files. If it says
nasm: Linux/i386 demand-paged executable (QMAGIC)
or something similar, your system is
,
and you should use
instead (Linux
systems are considered obsolete, and are
rare these days.)
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.
-o
Option: Specifying the Output File NameNASM 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 (
and
), it will remove the
extension (or whatever extension you like to
use - NASM doesn't care) from your source file name and substitute
. For Unix object file formats
(
,
,
and
) it will
substitute
. For
,
it will use
, and for the
format it will simply remove the extension,
so that
produces the output file
.
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
as the output file name instead.
For situations in which this behaviour is unacceptable, NASM provides
the
command-line option, which allows you to
specify your desired output file name. You invoke
by following it with the name you wish for the
output file, either with or without an intervening space. For example:
nasm -f bin program.asm -o program.com nasm -f bin driver.asm -odriver.sys
-f
Option: Specifying the Output File FormatIf you do not supply the
option to NASM, it
will choose an output file format for you itself. In the distribution
versions of NASM, the default is always
; if
you've compiled your own copy of NASM, you can redefine
at compile time and choose what you
want the default to be.
Like
, the intervening space between
and the output file format is optional; so
and
are
both valid.
A complete list of the available output file formats can be given by
issuing the command
.
-l
Option: Generating a Listing FileIf you supply the
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 section
4.2.9) on the right. For example:
nasm -f elf myfile.asm -l myfile.lst
-E
Option: Send Errors to a FileUnder MS-DOS 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
, this
can make it hard to capture the errors if (for example) you want to load
them into an editor.
NASM therefore provides the
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
nasm -E myfile.err -f obj myfile.asm
-s
Option: Send Errors to stdout
The
option redirects error messages to
rather than
, so it can be redirected under MS-DOS. To
assemble the file
and pipe its output
to the
program, you can type:
nasm -s -f obj myfile.asm | more
See also the
option,
section 2.1.4.
-i
Option: Include File Search DirectoriesWhen NASM sees the
directive in a
source file (see section 4.5), 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
option. Therefore you can include files from a
macro library, for example, by typing
nasm -ic:\macrolib\ -f obj myfile.asm
(As usual, a space between
and the path
name is allowed, and optional).
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
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.
(You can use this to your advantage, if you're really perverse, by
noting that the option
will cause
to search for the file
...)
If you want to define a standard include search path, similar
to
on Unix systems, you should place
one or more
directives in the
environment variable (see
section 2.1.13).
For Makefile compatibility with many C compilers, this option can also
be specified as
.
-p
Option: Pre-Include a FileNASM allows you to specify files to be pre-included into your
source file, by the use of the
option. So
running
nasm myfile.asm -p myinc.inc
is equivalent to running
and
placing the directive
at the
start of the file.
For consistency with the
,
and
options, this
option can also be specified as
.
-d
Option: Pre-Define a MacroJust as the
option gives an alternative to
placing
directives at the start of a
source file, the
option gives an alternative
to placing a
directive. You could code
nasm myfile.asm -dFOO=100
as an alternative to placing the directive
%define FOO 100
at the start of the file. You can miss off the macro value, as well: the
option
is equivalent to coding
. This form of the directive may be
useful for selecting assembly-time options which are then tested using
, for example
.
For Makefile compatibility with many C compilers, this option can also
be specified as
.
-u
Option: Undefine a MacroThe
option undefines a macro that would
otherwise have been pre-defined, either automatically or by a
or
option
specified earlier on the command lines.
For example, the following command line:
nasm myfile.asm -dFOO=100 -uFOO
would result in
not being a
predefined macro in the program. This is useful to override options
specified at a different point in a Makefile.
For Makefile compatibility with many C compilers, this option can also
be specified as
.
-e
Option: Preprocess OnlyNASM allows the preprocessor to be run on its own, up to a point. Using
the
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
option is also used).
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
%assign tablesize ($-tablestart)
will cause an error in preprocess-only mode.
-a
Option: Don't Preprocess At AllIf 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
option, requiring no argument, instructs NASM
to replace its powerful preprocessor with a stub preprocessor which does
nothing.
-w
Option: Enable or Disable Assembly WarningsNASM 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.
Some conditions are even less severe than that: they are only sometimes
worth mentioning to the user. Therefore NASM supports the
command-line option, which enables or disables
certain classes of assembly warning. Such warning classes are described by
a name, for example
; you can enable
warnings of this class by the command-line option
and disable it by
.
The suppressible warning classes are:
macro-params
covers warnings about multi-line
macros being invoked with the wrong number of parameters. This warning
class is enabled by default; see
section 4.2.1 for an example of
why you might want to disable it.
orphan-labels
covers warnings about source
lines which contain no instruction but define a label without a trailing
colon. NASM does not warn about this somewhat obscure condition by default;
see section 3.1 for an example of
why you might want it to.
number-overflow
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 0x7ffffffff
by mistake).
This warning class is enabled by default.
NASM
Environment VariableIf you define an environment variable called
, 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
options in the
variable.
The value of the variable is split up at white space, so that the value
will be treated as two separate
options. However, that means that the value
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
and
.
To get round this, NASM provides a feature whereby, if you begin the
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
variable to the value
is equivalent to setting it to
, but
will work.
If you're used to writing programs with MASM, or with TASM in
MASM-compatible (non-Ideal) mode, or with
,
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.
One simple difference is that NASM is case-sensitive. It makes a
difference whether you call your label
,
or
. If you're
assembling to DOS or OS/2
files, you can
invoke the
directive (documented in
section 6.2) to ensure that all
symbols exported to other code modules are forced to be upper case; but
even then, within a single module, NASM will distinguish between
labels differing only in case.
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,
foo equ 1 bar dw 2
then the two lines of code
mov ax,foo mov ax,bar
generate completely different opcodes, despite having identical-looking syntaxes.
NASM avoids this undesirable situation by having a much simpler syntax
for memory references. The rule is simply that any access to the
contents of a memory location requires square brackets around the
address, and any access to the address of a variable doesn't. So
an instruction of the form
will
always refer to a compile-time constant, whether it's an
or the address of a variable; and to access
the contents of the variable
, you
must code
.
This also means that NASM has no need for MASM's
keyword, since the MASM code
means exactly the same thing as
NASM's
. If you're trying to get large
amounts of MASM code to assemble sensibly under NASM, you can always code
to make the preprocessor treat
the
keyword as a no-op.
This issue is even more confusing in
,
where declaring a label with a trailing colon defines it to be a `label' as
opposed to a `variable' and causes
to adopt
NASM-style semantics; so in
,
has different behaviour depending on
whether
was declared as
(a label) or
(a word-size variable). NASM is very
simple by comparison: everything is a label.
NASM, in the interests of simplicity, also does not support the hybrid
syntaxes supported by MASM and its clones, such as
, where a memory reference is
denoted by one portion outside square brackets and another portion inside.
The correct syntax for the above is
. Likewise,
is wrong and
is right.
NASM, by design, chooses not to remember the types of variables you
declare. Whereas MASM will remember, on seeing
, that you declared
as a word-size variable, and will then be
able to fill in the ambiguity in the size of the instruction
, NASM will deliberately remember
nothing about the symbol
except where it
begins, and so you must explicitly code
.
For this reason, NASM doesn't support the
,
,
,
,
,
, or
instructions, but only supports the forms
such as
,
,
and
, which explicitly specify the size of
the components of the strings being manipulated.
ASSUME
As part of NASM's drive for simplicity, it also does not support the
directive. NASM will not keep track of
what values you choose to put in your segment registers, and will never
automatically generate a segment override prefix.
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
instruction (
or
; NASM accepts
itself as an alternate form for
); in
addition, the programmer is responsible for coding CALL FAR instructions
where necessary when calling external functions, and must also
keep track of which external variable definitions are far and which are
near.
NASM uses different names to refer to floating-point registers from
MASM: where MASM would call them
,
and so on, and
would call them simply
,
and so on, NASM
chooses to call them
,
etc.
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.
For historical reasons, NASM uses the keyword
where MASM and compatible assemblers use
.
NASM does not declare uninitialised storage in the same way as MASM:
where a MASM programmer might use
, NASM requires
, intended to be read as `reserve 64
bytes'. For a limited amount of compatibility, since NASM treats
as a valid character in symbol names, you can
code
and then writing
will at least do something vaguely useful.
is still not a supported syntax, however.
In addition to all of this, macros and directives work completely differently to MASM. See chapter 4 and chapter 5 for further details.