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 6) 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 uses backslash (\) as the line continuation character; if a line ends with backslash, the next line is considered to be a part of the backslash-ended line.
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 alone
on a line, and type by accident, then
that's still a valid source line which does nothing but define a label.
Running NASM with the command-line option
will cause it to warn you if you
define a label alone on a line without a trailing colon.)
Valid characters in labels are letters, numbers,
, ,
, ,
, , and
. The only characters which may be used as the
first character of an identifier are letters,
(with special meaning: see
section 3.9), and
. An identifier may also be prefixed with a
to indicate that it is intended to be read as
an identifier and not a reserved word; thus, if some other module you are
linking with defines a symbol called , you can
refer to in NASM code to distinguish the
symbol from the register. Maximum length of an identifier is 4095
characters.
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
, ,
/,
/,
/ or
/, in the usual
way. Explicit address-size and operand-size prefixes
, ,
, and
, are provided -
one example of their use is given in chapter
10. You can also use the name of a segment register as an instruction
prefix: coding is equivalent to
coding . We recommend the latter
syntax, since it is consistent with other syntactic features of the
language, but for instructions such as ,
which has no operands and yet can require a segment override, there is no
clean syntactic way to proceed apart from
.
An instruction is not required to use a prefix: prefixes such as
, ,
or can appear
on a line by themselves, and NASM will just generate the prefix bytes.
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. ,
, ,
: NASM does not use the
-style syntax in which register names must be
prefixed by a sign), or they can be effective
addresses (see section 3.3), constants
(section 3.4) or expressions
(section 3.5).
For x87 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. 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 x87 floating-point instruction that references memory must
use one of the prefixes ,
or to
indicate what size of memory operand it refers to.
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
, ,
, ,
, ,
and ; their
uninitialized counterparts ,
, ,
, ,
, and
; the
command, the command, and the
prefix.
DB and Friends: Declaring Initialized Data, ,
, ,
, ,
and are used,
much as in MASM, to declare initialized data in the output file. They can
be invoked in a wide range of ways:
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' ; 0x61 0x00 (it's just a number)
dw 'ab' ; 0x61 0x62 (character constant)
dw 'abc' ; 0x61 0x62 0x63 0x00 (string)
dd 0x12345678 ; 0x78 0x56 0x34 0x12
dd 1.234567e20 ; floating-point constant
dq 0x123456789abcdef0 ; eight byte constant
dq 1.234567e20 ; double-precision float
dt 1.234567e20 ; extended-precision float
, ,
and do not accept
numeric constants as operands.
RESB and Friends: Declaring Uninitialized Data, ,
, ,
, ,
and are
designed to be used in the BSS section of a module: they declare
uninitialized storage space. Each takes a single operand, which is
the number of bytes, words, doublewords or whatever to reserve. As stated
in section 2.2.7, NASM does not
support the MASM/TASM syntax of reserving uninitialized space by writing
or similar things: this is what it does
instead. The operand to a -type
pseudo-instruction is a critical expression: see
section 3.8.
For example:
buffer: resb 64 ; reserve 64 bytes wordvar: resw 1 ; reserve a word realarray resq 10 ; array of ten reals ymmval: resy 1 ; one YMM register zmmvals: resz 32 ; 32 ZMM registers
INCBIN : Including External Binary Files is borrowed from the old Amiga
assembler DevPac: it includes a binary file verbatim into the output file.
This can be handy for (for example) including graphics and sound data
directly into a game executable file. It can be called in one of these
three ways:
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
is both a directive and a standard
macro; the standard macro version searches for the file in the include file
search path and adds the file to the dependency lists. This macro can be
overridden if desired.
EQU : Defining Constants defines a symbol to a given constant
value: when is used, the source line must
contain a label. The action of is to define
the given label name to the value of its (only) operand. This definition is
absolute, and cannot change later. So, for example,
message db 'hello, world' msglen equ $-message
defines to be the constant 12.
may not then be redefined later. This is
not a preprocessor definition either: the value of
is evaluated once, using the
value of (see section
3.5 for an explanation of ) at the point of
definition, rather than being evaluated wherever it is referenced and using
the value of at the point of reference.
TIMES : Repeating Instructions or DataThe prefix causes the instruction to be
assembled multiple times. This is partly present as NASM's equivalent of
the syntax supported by MASM-compatible
assemblers, in that you can code
zerobuf: times 64 db 0
or similar things; but is more versatile
than that. The argument to is not just a
numeric constant, but a numeric expression, so you can do things
like
buffer: db 'hello, world'
times 64-$+buffer db ' '
which will store exactly enough spaces to make the total length of
up to 64. Finally,
can be applied to ordinary instructions, so
you can code trivial unrolled loops in it:
times 100 movsb
Note that there is no effective difference between
and
, except that the latter will be
assembled about 100 times faster due to the internal structure of the
assembler.
The operand to is a critical expression
(section 3.8).
Note also that can't be applied to
macros: the reason for this is that is
processed after the macro phase, which allows the argument to
to contain expressions such as
as above. To repeat more than one
line of code, or a complex macro, use the preprocessor
directive.
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
and
, and NASM will generally generate the
latter on the grounds that the former requires four bytes to store a zero
offset.
NASM has a hinting mechanism which will cause
and
to generate different opcodes; this is occasionally useful because
and
have different default segment registers.
However, you can force NASM to generate an effective address in a
particular form by the use of the keywords ,
, and
. If you need
to be assembled using a double-word
offset field instead of the one byte NASM will normally generate, you can
code . Similarly, you can force NASM
to use a byte offset for a small value which it hasn't seen on the first
pass (see section 3.8 for an example of such a
code fragment) by using . As
special cases, will code
with a byte offset of zero, and
will code it with a double-word
offset of zero. The normal form, , will be
coded with no offset field.
The form described in the previous paragraph is also useful if you are trying to access data in a 32-bit segment from within 16 bit code. For more information on this see the section on mixed-size addressing (section 10.2). In particular, if you need to access data with a known offset that is larger than will fit in a 16-bit value, if you don't specify that it is a dword offset, nasm will cause the high word of the offset to be lost.
Similarly, NASM will split into
because that allows the offset field to
be absent and space to be saved; in fact, it will also split
into
. You can combat this behaviour
by the use of the keyword:
will force
to be generated literally.
also has the same effect. In
another way, a split EA form can be
used, too. However, in
will be ignored because user's
intention here is considered as .
In 64-bit mode, NASM will by default generate absolute addresses. The
keyword makes it produce
-relative addresses. Since this is frequently
the normally desired behaviour, see the
directive (section 6.2). The
keyword overrides
.
A new form of split effective addres syntax is also supported. This is mainly intended for mib operands as used by MPX instructions, but can be used for any memory reference. The basic concept of this form is splitting base and index.
mov eax,[ebx+8,ecx*4] ; ebx=base, ecx=index, 4=scale, 8=disp
For mib operands, there are several ways of writing effective address depending on the tools. NASM supports all currently possible ways of mib syntax:
; bndstx
; next 5 lines are parsed same
; base=rax, index=rbx, scale=1, displacement=3
bndstx [rax+0x3,rbx], bnd0 ; NASM - split EA
bndstx [rbx*1+rax+0x3], bnd0 ; GAS - '*1' indecates an index reg
bndstx [rax+rbx+3], bnd0 ; GAS - without hints
bndstx [rax+0x3], bnd0, rbx ; ICC-1
bndstx [rax+0x3], rbx, bnd0 ; ICC-2
When broadcasting decorator is used, the opsize keyword should match the size of each element.
VDIVPS zmm4, zmm5, dword [rbx]{1to16} ; single-precision float
VDIVPS zmm4, zmm5, zword [rbx] ; packed 512 bit memory
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
or ,
or ,
or , and
or for hexadecimal,
decimal, octal and binary respectively, or you can prefix
, for hexadecimal in the style of C, or you can
prefix for hexadecimal in the style of Borland
Pascal or Motorola Assemblers. Note, though, that the
prefix does double duty as a prefix on
identifiers (see section 3.1), so a hex number
prefixed with a sign must have a digit after
the rather than a letter. In addition, current
versions of NASM accept the prefix for
hexadecimal, or
for decimal, or
for octal, and or
for binary. Please note that unlike C, a prefix
by itself does not imply an octal constant!
Numeric constants can have underscores ()
interspersed to break up long strings.
Some examples (all producing exactly the same code):
mov ax,200 ; decimal
mov ax,0200 ; still decimal
mov ax,0200d ; explicitly decimal
mov ax,0d200 ; also decimal
mov ax,0c8h ; hex
mov ax,$0c8 ; hex again: the 0 is required
mov ax,0xc8 ; hex yet again
mov ax,0hc8 ; still hex
mov ax,310q ; octal
mov ax,310o ; octal again
mov ax,0o310 ; octal yet again
mov ax,0q310 ; octal yet again
mov ax,11001000b ; binary
mov ax,1100_1000b ; same binary constant
mov ax,1100_1000y ; same binary constant once more
mov ax,0b1100_1000 ; same binary constant yet again
mov ax,0y1100_1000 ; same binary constant yet again
A character string consists of up to eight characters enclosed in either
single quotes (), double quotes
() or backquotes
(). Single or double quotes are equivalent
to NASM (except of course that surrounding the constant with single quotes
allows double quotes to appear within it and vice versa); the contents of
those are represented verbatim. Strings enclosed in backquotes support
C-style -escapes for special characters.
The following escape sequences are recognized by backquoted strings:
\' single quote (')
\" double quote (")
\` backquote (`)
\\ backslash (\)
\? question mark (?)
\a BEL (ASCII 7)
\b BS (ASCII 8)
\t TAB (ASCII 9)
\n LF (ASCII 10)
\v VT (ASCII 11)
\f FF (ASCII 12)
\r CR (ASCII 13)
\e ESC (ASCII 27)
\377 Up to 3 octal digits - literal byte
\xFF Up to 2 hexadecimal digits - literal byte
\u1234 4 hexadecimal digits - Unicode character
\U12345678 8 hexadecimal digits - Unicode character
All other escape sequences are reserved. Note that
, meaning a
character (ASCII 0), is a special case of the octal escape sequence.
Unicode characters specified with or
are converted to UTF-8. For example, the
following lines are all equivalent:
db `\u263a` ; UTF-8 smiley face
db `\xe2\x98\xba` ; UTF-8 smiley face
db 0E2h, 098h, 0BAh ; UTF-8 smiley face
A character constant consists of a string up to eight bytes long, used in an expression context. It is treated as if it was an integer.
A character constant with more than one byte will be arranged with little-endian order in mind: if you code
mov eax,'abcd'
then the constant generated is not ,
but , so that if you were then to store
the value into memory, it would read rather
than . This is also the sense of character
constants understood by the Pentium's
instruction.
String constants are character strings used in the context of some
pseudo-instructions, namely the family and
(where it represents a filename.) They are
also used in certain preprocessor directives.
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 in a string-supporting context, quoted strings are
treated as a string constants even if they are short enough to be a
character constant, because otherwise
would have the same effect as , which would
be silly. Similarly, three-character or four-character constants are
treated as strings when they are operands to ,
and so forth.
The special operators ,
,
, ,
and
allows definition of Unicode strings.
They take a string in UTF-8 format and converts it to UTF-16 or UTF-32,
respectively. Unless the forms are specified,
the output is littleendian.
For example:
%define u(x) __utf16__(x)
%define w(x) __utf32__(x)
dw u('C:\WINDOWS'), 0 ; Pathname in UTF-16
dd w(`A + B = \u206a`), 0 ; String in UTF-32
The UTF operators can be applied either to strings passed to the
family instructions, or to character constants
in an expression context.
Floating-point constants are acceptable only as arguments to
, ,
, ,
, and , or as
arguments to the special operators ,
,
,
,
,
,
, and
.
Floating-point constants are expressed in the traditional form: digits,
then a period, then optionally more digits, then optionally an
followed by an exponent. The period is
mandatory, so that NASM can distinguish between
, which declares an integer constant, and
which declares a floating-point constant.
NASM also support C99-style hexadecimal floating-point:
, hexadecimal digits, period, optionally more
hexadeximal digits, then optionally a followed
by a binary (not hexadecimal) exponent in decimal notation. As an
extension, NASM additionally supports the and
prefixes for hexadecimal, as well binary and
octal floating-point, using the or
and or
prefixes, respectively.
Underscores to break up groups of digits are permitted in floating-point constants as well.
Some examples:
db -0.2 ; "Quarter precision"
dw -0.5 ; IEEE 754r/SSE5 half precision
dd 1.2 ; an easy one
dd 1.222_222_222 ; underscores are permitted
dd 0x1p+2 ; 1.0x2^2 = 4.0
dq 0x1p+32 ; 1.0x2^32 = 4 294 967 296.0
dq 1.e10 ; 10 000 000 000.0
dq 1.e+10 ; synonymous with 1.e10
dq 1.e-10 ; 0.000 000 000 1
dt 3.141592653589793238462 ; pi
do 1.e+4000 ; IEEE 754r quad precision
The 8-bit "quarter-precision" floating-point format is sign:exponent:mantissa = 1:4:3 with an exponent bias of 7. This appears to be the most frequently used 8-bit floating-point format, although it is not covered by any formal standard. This is sometimes called a "minifloat."
The special operators are used to produce floating-point numbers in
other contexts. They produce the binary representation of a specific
floating-point number as an integer, and can use anywhere integer constants
are used in an expression. and
produce the 64-bit mantissa and
16-bit exponent of an 80-bit floating-point number, and
and
produce the lower and upper 64-bit
halves of a 128-bit floating-point number, respectively.
For example:
mov rax,__float64__(3.141592653589793238462)
... would assign the binary representation of pi as a 64-bit floating
point number into . This is exactly equivalent
to:
mov rax,0x400921fb54442d18
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.
The special tokens ,
(or )
and can be used to generate infinities,
quiet NaNs, and signalling NaNs, respectively. These are normally used as
macros:
%define Inf __Infinity__
%define NaN __QNaN__
dq +1.5, -Inf, NaN ; Double-precision constants
The standard macro package contains a
set of convenience macros. See section
5.3.
x87-style packed BCD constants can be used in the same contexts as
80-bit floating-point numbers. They are suffixed with
or prefixed with ,
and can include up to 18 decimal digits.
As with other numeric constants, underscores can be used to separate digits.
For example:
dt 12_345_678_901_245_678p
dt -12_345_67