| What is it? | Who wrote it? | Where is it? | Latest version | Known bugs | |||||
| Link to this site | Manual | Other documents | Chat forum | Tools and Libs |  | ||||
Next Chapter | Previous Chapter | Contents | Index
Like most assemblers, each NASM source line contains (unless it is a macro, a preprocessor directive or an assembler directive: see chapter 4 and chapter 5) some combination of the four fields
label: instruction operands ; comment
As usual, most of these fields are optional; the presence or absence of any combination of a label, an instruction and a comment is allowed. Of course, the operand field is either required or forbidden by the presence and nature of the instruction field.
NASM places no restrictions on white space within a line: labels may have
white space before them, or instructions may have no space before them, or
anything. The colon after a label is also optional. (Note that this means that
if you intend to code
Valid characters in labels are letters, numbers,
The instruction field may contain any machine instruction: Pentium and P6
instructions, FPU instructions, MMX instructions and even undocumented
instructions are all supported. The instruction may be prefixed by
An instruction is not required to use a prefix: prefixes such as
In addition to actual machine instructions, NASM also supports a number of pseudo-instructions, described in section 3.2.
Instruction operands may take a number of forms: they can be registers,
described simply by the register name (e.g.
For floating-point instructions, NASM accepts a wide range of syntaxes: you can use two-operand forms like MASM supports, or you can use NASM's native single-operand forms in most cases. Details of all forms of each supported instruction are given in appendix A. For example, you can code:
fadd st1 ; this sets st0 := st0 + st1
fadd st0,st1 ; so does this
fadd st1,st0 ; this sets st1 := st1 + st0
fadd to st1 ; so does this
Almost any floating-point instruction that references memory must use one of
the prefixes
Pseudo-instructions are things which, though not real x86 machine
instructions, are used in the instruction field anyway because that's the most
convenient place to put them. The current pseudo-instructions are
DB
db 0x55 ; just the byte 0x55
db 0x55,0x56,0x57 ; three bytes in succession
db 'a',0x55 ; character constants are OK
db 'hello',13,10,'$' ; so are string constants
dw 0x1234 ; 0x34 0x12
dw 'a' ; 0x41 0x00 (it's just a number)
dw 'ab' ; 0x41 0x42 (character constant)
dw 'abc' ; 0x41 0x42 0x43 0x00 (string)
dd 0x12345678 ; 0x78 0x56 0x34 0x12
dd 1.234567e20 ; floating-point constant
dq 1.234567e20 ; double-precision float
dt 1.234567e20 ; extended-precision float
RESB
For example:
buffer: resb 64 ; reserve 64 bytes wordvar: resw 1 ; reserve a word realarray resq 10 ; array of ten reals
INCBIN
incbin "file.dat" ; include the whole file
incbin "file.dat",1024 ; skip the first 1024 bytes
incbin "file.dat",1024,512 ; skip the first 1024, and
; actually include at most 512
EQU
message db 'hello, world' msglen equ $-message
defines
TIMES The
zerobuf: times 64 db 0
or similar things; but
buffer: db 'hello, world'
times 64-$+buffer db ' '
which will store exactly enough spaces to make the total length of
times 100 movsb
Note that there is no effective difference between
The operand to
Note also that
An effective address is any operand to an instruction which references memory. Effective addresses, in NASM, have a very simple syntax: they consist of an expression evaluating to the desired address, enclosed in square brackets. For example:
wordvar dw 123
mov ax,[wordvar]
mov ax,[wordvar+1]
mov ax,[es:wordvar+bx]
Anything not conforming to this simple system is not a valid memory reference
in NASM, for example
More complicated effective addresses, such as those involving more than one register, work in exactly the same way:
mov eax,[ebx*2+ecx+offset]
mov ax,[bp+di+8]
NASM is capable of doing algebra on these effective addresses, so that things which don't necessarily look legal are perfectly all right:
mov eax,[ebx*5] ; assembles as [ebx*4+ebx]
mov eax,[label1*2-label2] ; ie [label1+(label1-label2)]
Some forms of effective address have more than one assembled form; in most
such cases NASM will generate the smallest form it can. For example, there are
distinct assembled forms for the 32-bit effective addresses
NASM has a hinting mechanism which will cause
However, you can force NASM to generate an effective address in a particular
form by the use of the keywords
Similarly, NASM will split
NASM understands four different types of constant: numeric, character, string and floating-point.
A numeric constant is simply a number. NASM allows you to specify numbers in
a variety of number bases, in a variety of ways: you can suffix
Some examples:
mov ax,100 ; decimal
mov ax,0a2h ; hex
mov ax,$0a2 ; hex again: the 0 is required
mov ax,0xa2 ; hex yet again
mov ax,777q ; octal
mov ax,10010011b ; binary
A character constant consists of up to four characters enclosed in either single or double quotes. The type of quote makes no difference to NASM, except of course that surrounding the constant with single quotes allows double quotes to appear within it and vice versa.
A character constant with more than one character will be arranged with little-endian order in mind: if you code
mov eax,'abcd'
then the constant generated is not
String constants are only acceptable to some pseudo-instructions, namely the
A string constant looks like a character constant, only longer. It is treated as a concatenation of maximum-size character constants for the conditions. So the following are equivalent:
db 'hello' ; string constant
db 'h','e','l','l','o' ; equivalent character constants
And the following are also equivalent:
dd 'ninechars' ; doubleword string constant
dd 'nine','char','s' ; becomes three doublewords
db 'ninechars',0,0,0 ; and really looks like this
Note that when used as an operand to
Floating-point constants are acceptable only as arguments to
Some examples:
dd 1.2 ; an easy one
dq 1.e10 ; 10,000,000,000
dq 1.e+10 ; synonymous with 1.e10
dq 1.e-10 ; 0.000 000 000 1
dt 3.141592653589793238462 ; pi
NASM cannot do compile-time arithmetic on floating-point constants. This is because NASM is designed to be portable - although it always generates code to run on x86 processors, the assembler itself can run on any system with an ANSI C compiler. Therefore, the assembler cannot guarantee the presence of a floating-point unit capable of handling the Intel number formats, and so for NASM to be able to do floating arithmetic it would have to include its own complete set of floating-point routines, which would significantly increase the size of the assembler for very little benefit.
Expressions in NASM are similar in syntax to those in C.
NASM does not guarantee the size of the integers used to evaluate expressions at compile time: since NASM can compile and run on 64-bit systems quite happily, don't assume that expressions are evaluated in 32-bit registers and so try to make deliberate use of integer overflow. It might not always work. The only thing NASM will guarantee is what's guaranteed by ANSI C: you always have at least 32 bits to work in.
NASM supports two special tokens in expressions, allowing calculations to
involve the current assembly position: the
The arithmetic operators provided by NASM are listed here, in increasing order of precedence.
| The
^
&
<< >>
+ - The
* / // % %%
NASM, like ANSI C, provides no guarantees about the sensible operation of the signed modulo operator.
Since the
+ - ~ SEG The highest-priority operators in NASM's expression grammar are those which
only apply to one argument.
SEG WRT When writing large 16-bit programs, which must be split into multiple
segments, it is often necessary to be able to refer to the segment part of the
address of a symbol. NASM supports the
The
mov ax,seg symbol
mov es,ax
mov bx,symbol
will load
Things can be more complex than this: since 16-bit segments and groups may
overlap, you might occasionally want to refer to some symbol using a different
segment base from the preferred one. NASM lets you do this, by the use of the
mov ax,weird_seg ; weird_seg is a segment base
mov es,ax
mov bx,symbol wrt weird_seg
to load
NASM supports far (inter-segment) calls and jumps by means of the syntax
call (seg procedure):procedure
call weird_seg:(procedure wrt weird_seg)
(The parentheses are included for clarity, to show the intended parsing of the above instructions. They are not necessary in practice.)
NASM supports the syntax
To declare a far pointer to a data item in a data segment, you must code
dw symbol, seg symbol
NASM supports no convenient synonym for this, though you can always invent one using the macro processor.
A limitation of NASM is that it is a two-pass assembler; unlike TASM and others, it will always do exactly two assembly passes. Therefore it is unable to cope with source files that are complex enough to require three or more passes.
The first pass is used to determine the size of all the assembled code and data, so that the second pass, when generating all the code, knows all the symbol addresses the code refers to. So one thing NASM can't handle is code whose size depends on the value of a symbol declared after the code in question. For example,
times (label-$) db 0 label: db 'Where am I?'
The argument to
times (label-$+1) db 0 label: db 'NOW where am I?'
in which any value for the
NASM rejects these examples by means of a concept called a critical
expression, which is defined to be an expression whose value is required to
be computable in the first pass, and which must therefore depend only on symbols
defined before it. The argument to the
Critical expressions can crop up in other contexts as well: consider the following code.
mov ax,symbol1 symbol1 equ symbol2 symbol2:
On the first pass, NASM cannot determine the value of
NASM avoids this problem by defining the right-hand side of an
There is a related issue involving forward references: consider this code fragment.
mov eax,[ebx+offset] offset equ 10
NASM, on pass one, must calculate the size of the instruction
NASM gives special treatment to symbols beginning with a period. A label beginning with a single period is treated as a local label, which means that it is associated with the previous non-local label. So, for example:
label1 ; some code
.loop ; some more code
jne .loop
ret
label2 ; some code
.loop ; some more code
jne .loop
ret
In the above code fragment, each
This form of local label handling is borrowed from the old Amiga assembler
DevPac; however, NASM goes one step further, in allowing access to local labels
from other parts of the code. This is achieved by means of defining a
local label in terms of the previous non-local label: the first definition of
label3 ; some more code
; and some more
jmp label1.loop
Sometimes it is useful - in a macro, for instance - to be able to define a
label which can be referenced from anywhere but which doesn't interfere with the
normal local-label mechanism. Such a label can't be non-local because it would
interfere with subsequent definitions of, and references to, local labels; and
it can't be local because the macro that defined it wouldn't know the label's
full name. NASM therefore introduces a third type of label, which is probably
only useful in macro definitions: if a label begins with the special prefix
label1: ; a non-local label
.local: ; this is really label1.local
..@foo: ; this is a special symbol
label2: ; another non-local label
.local: ; this is really label2.local
jmp ..@foo ; this will jump three lines up
NASM has the capacity to define other special symbols beginning with a double
period: for example,