The Netwide Assembler: NASM

Next Chapter | Previous Chapter | Contents | Index

Chapter 2: Running NASM

2.1 NASM Command-Line Syntax

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 myfile.asm into an ELF object file myfile.o. And 

nasm -f bin myfile.asm -o myfile.com

will assemble myfile.asm into a raw binary file myfile.com.

To produce a listing file, with the hex codes output from NASM displayed on the left of the original sources, use the -l 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

As -hf, 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 a.out 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 -f elf 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 a.out, and you should use -f aout instead (Linux a.out systems have long been 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.

2.1.1 -o オプション: 出力ファイル名の指定

-oオプションを指定しない場合、出力ファイル名は出力ファイル形式により決まります。
入力ファイル名が"filename.asm"の場合、出力ファイル名は
filename.obj (マイクロソフトオブジェクト形式(obj,win32)の場合)
filename.o (Unixオブジェクト形式(aout, coff, elf, macho, as86)の場合)
filename.rdf (rdfの場合)
filename (バイナリ形式(bin)の場合)
となります。

出力ファイルがすでに存在している場合、すでにあるファイルは上書きされます。 (同じ名前の入力ファイルがあり、警告があり、代わりとしてnasm.outを使用しない場合)

この動作が容認できない状況の場合、-oオプションを使用します。
-oオプションの後に指定した文字列が出力ファイル名となります。
-oオプションと出力ファイル名の間にはスペースを入れても入れなくてもかまいません。
使用例 

nasm -f bin program.asm -o program.com 
nasm -f bin driver.asm -odriver.sys

注：このオプションで使用するのは小文字の'o'です。大文字の'O'は最適化の指示に使用されます。 section 2.1.22.

2.1.2 -f オプション: 出力フォーマットの指定

-fオプションを省略した場合、デフォルトでbin形式ファイルが生成されます。
自身でnasmをコンパイルする場合、OF_DEFAULT定義を変更することでデフォルトのフォーマット形式を選ぶことができます。
-oのように、-fと出力ファイル形式の間のスペースは任意です。
コマンド nasm -hf を発行することによって、出力フォーマットで指定可能なリストが取得できます。

2.1.3 -l オプション: リストファイルの生成

-lオプションを指定することで、リストファイルを生成できます。
マルチラインマクロも、リスト展開を無効に指定しない限り、リスト上では展開されて表示します。 (see section 4.3.9)

ソース上に[list +]、[list -]、を記述することで、リストファイルに生成するかしないかを選択できます。
[list +]の次の行からがリストファイル上に生成され、[list -]の次の行からはリストファイル上に生成されません。

2.1.4 The -M Option: Generate Makefile Dependencies

This option can be used to generate makefile dependencies on stdout. This can be redirected to a file for further processing. For example: 

nasm -M myfile.asm > myfile.dep

2.1.5 The -MG Option: Generate Makefile Dependencies

This option can be used to generate makefile dependencies on stdout. This differs from the -M 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.

2.1.6 The -MF Option: Set Makefile Dependency File

This option can be used with the -M or -MG options to send the output to a file, rather than to stdout. For example: 

nasm -M -MF myfile.dep myfile.asm

2.1.7 The -MD Option: Assemble and Generate Dependencies

The -MD option acts as the combination of the -M and -MF options (i.e. a filename has to be specified.) However, unlike the -M or -MG options, -MD does not inhibit the normal operation of the assembler. Use this to automatically generate updated dependencies with every assembly session. For example: 

nasm -f elf -o myfile.o -MD myfile.dep myfile.asm

2.1.8 The -MT Option: Dependency Target Name

The -MT 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 -o option.

2.1.9 The -MQ Option: Dependency Target Name (Quoted)

The -MQ option acts as the -MT 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.

2.1.10 The -MP Option: Emit phony targets

When used with any of the dependency generation options, the -MP 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.

2.1.11 The -F Option: Selecting a Debug Information Format

This option is used to select the format of the debug information emitted into the output file, to be used by a debugger (or will be). Use of this switch does not enable output of the selected debug info format. Use -g, see section 2.1.12, to enable output.

A complete list of the available debug file formats for an output format can be seen by issuing the command nasm -f <format> -y. (As of 2.00, only "-f elf32", "-f elf64", "-f ieee", and "-f obj" provide debug information.) See section 2.1.26.

This should not be confused with the "-f dbg" output format option which is not built into NASM by default. For information on how to enable it when building from the sources, see section 6.12

2.1.12 The -g Option: Enabling Debug Information.

This option can be used to generate debugging information in the specified format. See section 2.1.11. Using -g without -F 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, -g is silently ignored.

2.1.13 The -X Option: Selecting an Error Reporting Format

This option can be used to select an error reporting format for any error messages that might be produced by NASM.

Currently, two error reporting formats may be selected. They are the -Xvc option and the -Xgnu option. The GNU format is the default and looks like this: 

filename.asm:65: error: specific error message

where filename.asm is the name of the source file in which the error was detected, 65 is the source file line number on which the error was detected, error is the severity of the error (this could be warning), and specific error message is a more detailed text message which should help pinpoint the exact problem.

The other format, specified by -Xvc is the style used by Microsoft Visual C++ and some other programs. It looks like this: 

filename.asm(65) : error: specific error message

where the only difference is that the line number is in parentheses instead of being delimited by colons.

See also the Visual C++ output format, section 6.3.

2.1.14 The -Z Option: Send Errors to a File

Under 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 stderr, this can make it hard to capture the errors if (for example) you want to load them into an editor.

NASM therefore provides the -Z 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 -Z myfile.err -f obj myfile.asm

In earlier versions of NASM, this option was called -E, but it was changed since -E is an option conventionally used for preprocessing only, with disastrous results. See section 2.1.20.

2.1.15 The -s Option: Send Errors to stdout

The -s option redirects error messages to stdout rather than stderr, so it can be redirected under MS-DOS. To assemble the file myfile.asm and pipe its output to the more program, you can type: 

nasm -s -f obj myfile.asm | more

See also the -Z option, section 2.1.14.

2.1.16 The -i Option: Include File Search Directories

When NASM sees the %include or %pathsearch directive in a source file (see section 4.6.1, section 4.6.2 or section 3.2.3), 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 -i 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 -i 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 -i 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 -ifoo will cause %include "bar.i" to search for the file foobar.i...)

If you want to define a standard include search path, similar to /usr/include on Unix systems, you should place one or more -i directives in the NASMENV environment variable (see section 2.1.28).

For Makefile compatibility with many C compilers, this option can also be specified as -I.

2.1.17 The -p Option: Pre-Include a File

NASM allows you to specify files to be pre-included into your source file, by the use of the -p option. So running 

nasm myfile.asm -p myinc.inc

is equivalent to running nasm myfile.asm and placing the directive %include "myinc.inc" at the start of the file.

For consistency with the -I, -D and -U options, this option can also be specified as -P.

2.1.18 The -d Option: Pre-Define a Macro

Just as the -p option gives an alternative to placing %include directives at the start of a source file, the -d option gives an alternative to placing a %define 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 -dFOO is equivalent to coding %define FOO. This form of the directive may be useful for selecting assembly-time options which are then tested using %ifdef, for example -dDEBUG.

For Makefile compatibility with many C compilers, this option can also be specified as -D.

2.1.19 The -u Option: Undefine a Macro

The -u option undefines a macro that would otherwise have been pre-defined, either automatically or by a -p or -d option specified earlier on the command lines.

For example, the following command line: 

nasm myfile.asm -dFOO=100 -uFOO

would result in FOO 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 -U.

2.1.20 The -E Option: Preprocess Only

NASM allows the preprocessor to be run on its own, up to a point. Using the -E 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 -o 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.

For compatiblity with older version of NASM, this option can also be written -e. -E in older versions of NASM was the equivalent of the current -Z option, section 2.1.14.

2.1.21 The -a Option: Don't Preprocess At All

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 -a option, requiring no argument, instructs NASM to replace its powerful preprocessor with a stub preprocessor which does nothing.

2.1.22 The -On Option: Specifying Multipass Optimization.

NASM defaults to being a two pass assembler. This means that if you have a complex source file which needs more than 2 passes to assemble optimally, you have to enable extra passes.

Using the -O option, you can tell NASM to carry out multiple passes. The syntax is:

Note that this is a capital O, and is different from a small o, which is used to specify the output file name. See section 2.1.1.

2.1.23 The -t option: Enable TASM Compatibility Mode

NASM includes a limited form of compatibility with Borland's TASM. When NASM's -t option is used, the following changes are made:

2.1.24 The -w Option: Enable or Disable Assembly Warnings

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.

Some conditions are even less severe than that: they are only sometimes worth mentioning to the user. Therefore NASM supports the -w command-line option, which enables or disables certain classes of assembly warning. Such warning classes are described by a name, for example orphan-labels; you can enable warnings of this class by the command-line option -w+orphan-labels and disable it by -w-orphan-labels.

The suppressible warning classes are:

2.1.25 The -v Option: Display Version Info

Typing NASM -v will display the version of NASM which you are using, and the date on which it was compiled.

You will need the version number if you report a bug.

2.1.26 The -y Option: Display Available Debug Info Formats

Typing nasm -f <option> -y 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: 

nasm -f elf -y


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

2.1.27 --prefix , --postfix オプション.

--prefixオプションを指定した場合、exrernまたはglobal宣言を行った宣言名の先頭に、
--postfixオプションを指定した場合は、宣言名の末尾に、オプションで指定した文字列が付加されます。
例：--prefix _ --postfix _dbgとした場合
extern MessageBoxA は
extern _MessageBoxA_dbg
として扱われます。

2.1.28 The NASMENV Environment Variable

If you define an environment variable called NASMENV, 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 -i options in the NASMENV variable.

The value of the variable is split up at white space, so that the value -s -ic:\nasmlib will be treated as two separate options. However, that means that the value -dNAME="my name" 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 -dNAME="my and name".

To get round this, NASM provides a feature whereby, if you begin the NASMENV 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 NASMENV variable to the value !-s!-ic:\nasmlib is equivalent to setting it to -s -ic:\nasmlib, but !-dNAME="my name" will work.

This environment variable was previously called NASM. This was changed with version 0.98.31.

2.2 Quick Start for MASM Users

If you're used to writing programs with MASM, or with TASM in MASM-compatible (non-Ideal) mode, or with a86, 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.

2.2.1 NASM Is Case-Sensitive

One simple difference is that NASM is case-sensitive. It makes a difference whether you call your label foo, Foo or FOO. If you're assembling to DOS or OS/2 .OBJ files, you can invoke the UPPERCASE 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.

2.2.2 NASM Requires Square Brackets For Memory References

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 mov ax,foo will always refer to a compile-time constant, whether it's an EQU or the address of a variable; and to access the contents of the variable bar, you must code mov ax,[bar].

This also means that NASM has no need for MASM's OFFSET keyword, since the MASM code mov ax,offset bar means exactly the same thing as NASM's mov ax,bar. If you're trying to get large amounts of MASM code to assemble sensibly under NASM, you can always code %idefine offset to make the preprocessor treat the OFFSET keyword as a no-op.

This issue is even more confusing in a86, where declaring a label with a trailing colon defines it to be a `label' as opposed to a `variable' and causes a86 to adopt NASM-style semantics; so in a86, mov ax,var has different behaviour depending on whether var was declared as var: dw 0 (a label) or var dw 0 (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 mov ax,table[bx], where a memory reference is denoted by one portion outside square brackets and another portion inside. The correct syntax for the above is mov ax,[table+bx]. Likewise, mov ax,es:[di] is wrong and mov ax,[es:di] is right.

2.2.3 NASM Doesn't Store Variable Types

NASM, by design, chooses not to remember the types of variables you declare. Whereas MASM will remember, on seeing var dw 0, that you declared var as a word-size variable, and will then be able to fill in the ambiguity in the size of the instruction mov var,2, NASM will deliberately remember nothing about the symbol var except where it begins, and so you must explicitly code mov word [var],2.

For this reason, NASM doesn't support the LODS, MOVS, STOS, SCAS, CMPS, INS, or OUTS instructions, but only supports the forms such as LODSB, MOVSW, and SCASD, which explicitly specify the size of the components of the strings being manipulated.

2.2.4 NASM Doesn't ASSUME

As part of NASM's drive for simplicity, it also does not support the ASSUME 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.

2.2.5 NASM Doesn't Support Memory Models

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 RET instruction (RETN or RETF; NASM accepts RET itself as an alternate form for RETN); 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.

2.2.6 Floating-Point Differences

NASM uses different names to refer to floating-point registers from MASM: where MASM would call them ST(0), ST(1) and so on, and a86 would call them simply 0, 1 and so on, NASM chooses to call them st0, st1 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.

2.2.7 Other Differences

For historical reasons, NASM uses the keyword TWORD where MASM and compatible assemblers use TBYTE.

NASM does not declare uninitialized storage in the same way as MASM: where a MASM programmer might use stack db 64 dup (?), NASM requires stack resb 64, 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 ? equ 0 and then writing dw ? will at least do something vaguely useful. DUP 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.

Next Chapter | Previous Chapter | Contents | Index