The Netwide Assembler: NASM

Previous Chapter | Contents | Index

Appendix B: Instruction List

6.11.3 rdf Extensions to the GLOBAL directive

RDOFF global symbols can contain additional information needed by the static linker. You can mark a global symbol as exported, thus telling the linker do not strip it from target executable or library file. Like in ELF, you can also specify whether an exported symbol is a procedure (function) or data object.

Suffixing the name with a colon and the word export you make the symbol exported: 

    global  sys_open:export

To specify that exported symbol is a procedure (function), you add the word proc or function after declaration: 

    global  sys_open:export proc

Similarly, to specify exported data object, add the word data or object to the directive: 

    global  kernel_ticks:export data

6.11.4 rdf Extensions to the EXTERN directive

By default the EXTERN directive in RDOFF declares a "pure external" symbol (i.e. the static linker will complain if such a symbol is not resolved). To declare an "imported" symbol, which must be resolved later during a dynamic linking phase, RDOFF offers an additional import modifier. As in GLOBAL, you can also specify whether an imported symbol is a procedure (function) or data object. For example: 

    library $libc 
    extern  _open:import 
    extern  _printf:import proc 
    extern  _errno:import data

Here the directive LIBRARY is also included, which gives the dynamic linker a hint as to where to find requested symbols.

6.12 dbg: Debugging Format

The dbg output format is not built into NASM in the default configuration. If you are building your own NASM executable from the sources, you can define OF_DBG in outform.h or on the compiler command line, and obtain the dbg output format.

The dbg format does not output an object file as such; instead, it outputs a text file which contains a complete list of all the transactions between the main body of NASM and the output-format back end module. It is primarily intended to aid people who want to write their own output drivers, so that they can get a clearer idea of the various requests the main program makes of the output driver, and in what order they happen.

For simple files, one can easily use the dbg format like this: 

nasm -f dbg filename.asm

which will generate a diagnostic file called filename.dbg. However, this will not work well on files which were designed for a different object format, because each object format defines its own macros (usually user-level forms of directives), and those macros will not be defined in the dbg format. Therefore it can be useful to run NASM twice, in order to do the preprocessing with the native object format selected: 

nasm -e -f rdf -o rdfprog.i rdfprog.asm 
nasm -a -f dbg rdfprog.i

This preprocesses rdfprog.asm into rdfprog.i, keeping the rdf object format selected in order to make sure RDF special directives are converted into primitive form correctly. Then the preprocessed source is fed through the dbg format to generate the final diagnostic output.

This workaround will still typically not work for programs intended for obj format, because the obj SEGMENT and GROUP directives have side effects of defining the segment and group names as symbols; dbg will not do this, so the program will not assemble. You will have to work around that by defining the symbols yourself (using EXTERN, for example) if you really need to get a dbg trace of an obj-specific source file.

dbg accepts any section name and any directives at all, and logs them all to its output file.

Next Chapter | Previous Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdoc1.html0000644000000000000000000002166211026031754016674 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Next Chapter | Contents | Index

Chapter 1: Introduction

1.1 What Is NASM?

The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. It supports a range of object file formats, including Linux and *BSD a.out, ELF, COFF, Mach-O, Microsoft 16-bit OBJ, Win32 and Win64. It will also output plain binary files. Its syntax is designed to be simple and easy to understand, similar to Intel's but less complex. It supports all currently known x86 architectural extensions, and has strong support for macros.

1.1.1 Why Yet Another Assembler?

The Netwide Assembler grew out of an idea on comp.lang.asm.x86 (or possibly alt.lang.asm - I forget which), which was essentially that there didn't seem to be a good free x86-series assembler around, and that maybe someone ought to write one.

So here, for your coding pleasure, is NASM. At present it's still in prototype stage - we don't promise that it can outperform any of these assemblers. But please, please send us bug reports, fixes, helpful information, and anything else you can get your hands on (and thanks to the many people who've done this already! You all know who you are), and we'll improve it out of all recognition. Again.

1.1.2 License Conditions

Please see the file COPYING, supplied as part of any NASM distribution archive, for the license conditions under which you may use NASM. NASM is now under the so-called GNU Lesser General Public License, LGPL.

1.2 Contact Information

The current version of NASM (since about 0.98.08) is maintained by a team of developers, accessible through the nasm-devel mailing list (see below for the link). If you want to report a bug, please read section 11.2 first.

NASM has a WWW page at http://nasm.sourceforge.net. If it's not there, google for us!

The original authors are e-mailable as jules@dsf.org.uk and anakin@pobox.com. The latter is no longer involved in the development team.

New releases of NASM are uploaded to the official sites http://nasm.sourceforge.net and to ftp.kernel.org and ibiblio.org.

Announcements are posted to comp.lang.asm.x86, alt.lang.asm and comp.os.linux.announce

If you want information about NASM beta releases, and the current development status, please subscribe to the nasm-devel email list by registering at http://sourceforge.net/projects/nasm.

1.3 Installation

1.3.1 Installing NASM under MS-DOS or Windows

Once you've obtained the appropriate archive for NASM, nasm-XXX-dos.zip or nasm-XXX-win32.zip (where XXX denotes the version number of NASM contained in the archive), unpack it into its own directory (for example c:\nasm).

The archive will contain a set of executable files: the NASM executable file nasm.exe, the NDISASM executable file ndisasm.exe, and possibly additional utilities to handle the RDOFF file format.

The only file NASM needs to run is its own executable, so copy nasm.exe to a directory on your PATH, or alternatively edit autoexec.bat to add the nasm directory to your PATH (to do that under Windows XP, go to Start > Control Panel > System > Advanced > Environment Variables; these instructions may work under other versions of Windows as well.)

That's it - NASM is installed. You don't need the nasm directory to be present to run NASM (unless you've added it to your PATH), so you can delete it if you need to save space; however, you may want to keep the documentation or test programs.

If you've downloaded the DOS source archive, nasm-XXX.zip, the nasm directory will also contain the full NASM source code, and a selection of Makefiles you can (hopefully) use to rebuild your copy of NASM from scratch. See the file INSTALL in the source archive.

Note that a number of files are generated from other files by Perl scripts. Although the NASM source distribution includes these generated files, you will need to rebuild them (and hence, will need a Perl interpreter) if you change insns.dat, standard.mac or the documentation. It is possible future source distributions may not include these files at all. Ports of Perl for a variety of platforms, including DOS and Windows, are available from www.cpan.org.

1.3.2 Installing NASM under Unix

Once you've obtained the Unix source archive for NASM, nasm-XXX.tar.gz (where XXX denotes the version number of NASM contained in the archive), unpack it into a directory such as /usr/local/src. The archive, when unpacked, will create its own subdirectory nasm-XXX.

NASM is an auto-configuring package: once you've unpacked it, cd to the directory it's been unpacked into and type ./configure. This shell script will find the best C compiler to use for building NASM and set up Makefiles accordingly.

Once NASM has auto-configured, you can type make to build the nasm and ndisasm binaries, and then make install to install them in /usr/local/bin and install the man pages nasm.1 and ndisasm.1 in /usr/local/man/man1. Alternatively, you can give options such as --prefix to the configure script (see the file INSTALL for more details), or install the programs yourself.

NASM also comes with a set of utilities for handling the RDOFF custom object-file format, which are in the rdoff subdirectory of the NASM archive. You can build these with make rdf and install them with make rdf_install, if you want them.

Next Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdocb.html0000644000000000000000000056307711026031755016771 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Previous Chapter | Contents | Index

Appendix B: Instruction List

6.11.3 rdf Extensions to the GLOBAL directive

RDOFF global symbols can contain additional information needed by the static linker. You can mark a global symbol as exported, thus telling the linker do not strip it from target executable or library file. Like in ELF, you can also specify whether an exported symbol is a procedure (function) or data object.

Suffixing the name with a colon and the word export you make the symbol exported: 

    global  sys_open:export

To specify that exported symbol is a procedure (function), you add the word proc or function after declaration: 

    global  sys_open:export proc

Similarly, to specify exported data object, add the word data or object to the directive: 

    global  kernel_ticks:export data

6.11.4 rdf Extensions to the EXTERN directive

By default the EXTERN directive in RDOFF declares a "pure external" symbol (i.e. the static linker will complain if such a symbol is not resolved). To declare an "imported" symbol, which must be resolved later during a dynamic linking phase, RDOFF offers an additional import modifier. As in GLOBAL, you can also specify whether an imported symbol is a procedure (function) or data object. For example: 

    library $libc 
    extern  _open:import 
    extern  _printf:import proc 
    extern  _errno:import data

Here the directive LIBRARY is also included, which gives the dynamic linker a hint as to where to find requested symbols.

6.12 dbg: Debugging Format

The dbg output format is not built into NASM in the default configuration. If you are building your own NASM executable from the sources, you can define OF_DBG in outform.h or on the compiler command line, and obtain the dbg output format.

The dbg format does not output an object file as such; instead, it outputs a text file which contains a complete list of all the transactions between the main body of NASM and the output-format back end module. It is primarily intended to aid people who want to write their own output drivers, so that they can get a clearer idea of the various requests the main program makes of the output driver, and in what order they happen.

For simple files, one can easily use the dbg format like this: 

nasm -f dbg filename.asm

which will generate a diagnostic file called filename.dbg. However, this will not work well on files which were designed for a different object format, because each object format defines its own macros (usually user-level forms of directives), and those macros will not be defined in the dbg format. Therefore it can be useful to run NASM twice, in order to do the preprocessing with the native object format selected: 

nasm -e -f rdf -o rdfprog.i rdfprog.asm 
nasm -a -f dbg rdfprog.i

This preprocesses rdfprog.asm into rdfprog.i, keeping the rdf object format selected in order to make sure RDF special directives are converted into primitive form correctly. Then the preprocessed source is fed through the dbg format to generate the final diagnostic output.

This workaround will still typically not work for programs intended for obj format, because the obj SEGMENT and GROUP directives have side effects of defining the segment and group names as symbols; dbg will not do this, so the program will not assemble. You will have to work around that by defining the symbols yourself (using EXTERN, for example) if you really need to get a dbg trace of an obj-specific source file.

dbg accepts any section name and any directives at all, and logs them all to its output file.

Next Chapter | Previous Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdoc1.html0000644000000000000000000002166211026031754016674 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Next Chapter | Contents | Index

Chapter 1: Introduction

1.1 What Is NASM?

The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. It supports a range of object file formats, including Linux and *BSD a.out, ELF, COFF, Mach-O, Microsoft 16-bit OBJ, Win32 and Win64. It will also output plain binary files. Its syntax is designed to be simple and easy to understand, similar to Intel's but less complex. It supports all currently known x86 architectural extensions, and has strong support for macros.

1.1.1 Why Yet Another Assembler?

The Netwide Assembler grew out of an idea on comp.lang.asm.x86 (or possibly alt.lang.asm - I forget which), which was essentially that there didn't seem to be a good free x86-series assembler around, and that maybe someone ought to write one.

So here, for your coding pleasure, is NASM. At present it's still in prototype stage - we don't promise that it can outperform any of these assemblers. But please, please send us bug reports, fixes, helpful information, and anything else you can get your hands on (and thanks to the many people who've done this already! You all know who you are), and we'll improve it out of all recognition. Again.

1.1.2 License Conditions

Please see the file COPYING, supplied as part of any NASM distribution archive, for the license conditions under which you may use NASM. NASM is now under the so-called GNU Lesser General Public License, LGPL.

1.2 Contact Information

The current version of NASM (since about 0.98.08) is maintained by a team of developers, accessible through the nasm-devel mailing list (see below for the link). If you want to report a bug, please read section 11.2 first.

NASM has a WWW page at http://nasm.sourceforge.net. If it's not there, google for us!

The original authors are e-mailable as jules@dsf.org.uk and anakin@pobox.com. The latter is no longer involved in the development team.

New releases of NASM are uploaded to the official sites http://nasm.sourceforge.net and to ftp.kernel.org and ibiblio.org.

Announcements are posted to comp.lang.asm.x86, alt.lang.asm and comp.os.linux.announce

If you want information about NASM beta releases, and the current development status, please subscribe to the nasm-devel email list by registering at http://sourceforge.net/projects/nasm.

1.3 Installation

1.3.1 Installing NASM under MS-DOS or Windows

Once you've obtained the appropriate archive for NASM, nasm-XXX-dos.zip or nasm-XXX-win32.zip (where XXX denotes the version number of NASM contained in the archive), unpack it into its own directory (for example c:\nasm).

The archive will contain a set of executable files: the NASM executable file nasm.exe, the NDISASM executable file ndisasm.exe, and possibly additional utilities to handle the RDOFF file format.

The only file NASM needs to run is its own executable, so copy nasm.exe to a directory on your PATH, or alternatively edit autoexec.bat to add the nasm directory to your PATH (to do that under Windows XP, go to Start > Control Panel > System > Advanced > Environment Variables; these instructions may work under other versions of Windows as well.)

That's it - NASM is installed. You don't need the nasm directory to be present to run NASM (unless you've added it to your PATH), so you can delete it if you need to save space; however, you may want to keep the documentation or test programs.

If you've downloaded the DOS source archive, nasm-XXX.zip, the nasm directory will also contain the full NASM source code, and a selection of Makefiles you can (hopefully) use to rebuild your copy of NASM from scratch. See the file INSTALL in the source archive.

Note that a number of files are generated from other files by Perl scripts. Although the NASM source distribution includes these generated files, you will need to rebuild them (and hence, will need a Perl interpreter) if you change insns.dat, standard.mac or the documentation. It is possible future source distributions may not include these files at all. Ports of Perl for a variety of platforms, including DOS and Windows, are available from www.cpan.org.

1.3.2 Installing NASM under Unix

Once you've obtained the Unix source archive for NASM, nasm-XXX.tar.gz (where XXX denotes the version number of NASM contained in the archive), unpack it into a directory such as /usr/local/src. The archive, when unpacked, will create its own subdirectory nasm-XXX.

NASM is an auto-configuring package: once you've unpacked it, cd to the directory it's been unpacked into and type ./configure. This shell script will find the best C compiler to use for building NASM and set up Makefiles accordingly.

Once NASM has auto-configured, you can type make to build the nasm and ndisasm binaries, and then make install to install them in /usr/local/bin and install the man pages nasm.1 and ndisasm.1 in /usr/local/man/man1. Alternatively, you can give options such as --prefix to the configure script (see the file INSTALL for more details), or install the programs yourself.

NASM also comes with a set of utilities for handling the RDOFF custom object-file format, which are in the rdoff subdirectory of the NASM archive. You can build these with make rdf and install them with make rdf_install, if you want them.

Next Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdocb.html0000644000000000000000000056307711026031755016771 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Previous Chapter | Contents | Index

Appendix B: Instruction List

6.11.3 rdf Extensions to the GLOBAL directive

RDOFF global symbols can contain additional information needed by the static linker. You can mark a global symbol as exported, thus telling the linker do not strip it from target executable or library file. Like in ELF, you can also specify whether an exported symbol is a procedure (function) or data object.

Suffixing the name with a colon and the word export you make the symbol exported: 

    global  sys_open:export

To specify that exported symbol is a procedure (function), you add the word proc or function after declaration: 

    global  sys_open:export proc

Similarly, to specify exported data object, add the word data or object to the directive: 

    global  kernel_ticks:export data

6.11.4 rdf Extensions to the EXTERN directive

By default the EXTERN directive in RDOFF declares a "pure external" symbol (i.e. the static linker will complain if such a symbol is not resolved). To declare an "imported" symbol, which must be resolved later during a dynamic linking phase, RDOFF offers an additional import modifier. As in GLOBAL, you can also specify whether an imported symbol is a procedure (function) or data object. For example: 

    library $libc 
    extern  _open:import 
    extern  _printf:import proc 
    extern  _errno:import data

Here the directive LIBRARY is also included, which gives the dynamic linker a hint as to where to find requested symbols.

6.12 dbg: Debugging Format

The dbg output format is not built into NASM in the default configuration. If you are building your own NASM executable from the sources, you can define OF_DBG in outform.h or on the compiler command line, and obtain the dbg output format.

The dbg format does not output an object file as such; instead, it outputs a text file which contains a complete list of all the transactions between the main body of NASM and the output-format back end module. It is primarily intended to aid people who want to write their own output drivers, so that they can get a clearer idea of the various requests the main program makes of the output driver, and in what order they happen.

For simple files, one can easily use the dbg format like this: 

nasm -f dbg filename.asm

which will generate a diagnostic file called filename.dbg. However, this will not work well on files which were designed for a different object format, because each object format defines its own macros (usually user-level forms of directives), and those macros will not be defined in the dbg format. Therefore it can be useful to run NASM twice, in order to do the preprocessing with the native object format selected: 

nasm -e -f rdf -o rdfprog.i rdfprog.asm 
nasm -a -f dbg rdfprog.i

This preprocesses rdfprog.asm into rdfprog.i, keeping the rdf object format selected in order to make sure RDF special directives are converted into primitive form correctly. Then the preprocessed source is fed through the dbg format to generate the final diagnostic output.

This workaround will still typically not work for programs intended for obj format, because the obj SEGMENT and GROUP directives have side effects of defining the segment and group names as symbols; dbg will not do this, so the program will not assemble. You will have to work around that by defining the symbols yourself (using EXTERN, for example) if you really need to get a dbg trace of an obj-specific source file.

dbg accepts any section name and any directives at all, and logs them all to its output file.

Next Chapter | Previous Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdoc1.html0000644000000000000000000002166211026031754016674 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Next Chapter | Contents | Index

Chapter 1: Introduction

1.1 What Is NASM?

The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. It supports a range of object file formats, including Linux and *BSD a.out, ELF, COFF, Mach-O, Microsoft 16-bit OBJ, Win32 and Win64. It will also output plain binary files. Its syntax is designed to be simple and easy to understand, similar to Intel's but less complex. It supports all currently known x86 architectural extensions, and has strong support for macros.

1.1.1 Why Yet Another Assembler?

The Netwide Assembler grew out of an idea on comp.lang.asm.x86 (or possibly alt.lang.asm - I forget which), which was essentially that there didn't seem to be a good free x86-series assembler around, and that maybe someone ought to write one.

So here, for your coding pleasure, is NASM. At present it's still in prototype stage - we don't promise that it can outperform any of these assemblers. But please, please send us bug reports, fixes, helpful information, and anything else you can get your hands on (and thanks to the many people who've done this already! You all know who you are), and we'll improve it out of all recognition. Again.

1.1.2 License Conditions

Please see the file COPYING, supplied as part of any NASM distribution archive, for the license conditions under which you may use NASM. NASM is now under the so-called GNU Lesser General Public License, LGPL.

1.2 Contact Information

The current version of NASM (since about 0.98.08) is maintained by a team of developers, accessible through the nasm-devel mailing list (see below for the link). If you want to report a bug, please read section 11.2 first.

NASM has a WWW page at http://nasm.sourceforge.net. If it's not there, google for us!

The original authors are e-mailable as jules@dsf.org.uk and anakin@pobox.com. The latter is no longer involved in the development team.

New releases of NASM are uploaded to the official sites http://nasm.sourceforge.net and to ftp.kernel.org and ibiblio.org.

Announcements are posted to comp.lang.asm.x86, alt.lang.asm and comp.os.linux.announce

If you want information about NASM beta releases, and the current development status, please subscribe to the nasm-devel email list by registering at http://sourceforge.net/projects/nasm.

1.3 Installation

1.3.1 Installing NASM under MS-DOS or Windows

Once you've obtained the appropriate archive for NASM, nasm-XXX-dos.zip or nasm-XXX-win32.zip (where XXX denotes the version number of NASM contained in the archive), unpack it into its own directory (for example c:\nasm).

The archive will contain a set of executable files: the NASM executable file nasm.exe, the NDISASM executable file ndisasm.exe, and possibly additional utilities to handle the RDOFF file format.

The only file NASM needs to run is its own executable, so copy nasm.exe to a directory on your PATH, or alternatively edit autoexec.bat to add the nasm directory to your PATH (to do that under Windows XP, go to Start > Control Panel > System > Advanced > Environment Variables; these instructions may work under other versions of Windows as well.)

That's it - NASM is installed. You don't need the nasm directory to be present to run NASM (unless you've added it to your PATH), so you can delete it if you need to save space; however, you may want to keep the documentation or test programs.

If you've downloaded the DOS source archive, nasm-XXX.zip, the nasm directory will also contain the full NASM source code, and a selection of Makefiles you can (hopefully) use to rebuild your copy of NASM from scratch. See the file INSTALL in the source archive.

Note that a number of files are generated from other files by Perl scripts. Although the NASM source distribution includes these generated files, you will need to rebuild them (and hence, will need a Perl interpreter) if you change insns.dat, standard.mac or the documentation. It is possible future source distributions may not include these files at all. Ports of Perl for a variety of platforms, including DOS and Windows, are available from www.cpan.org.

1.3.2 Installing NASM under Unix

Once you've obtained the Unix source archive for NASM, nasm-XXX.tar.gz (where XXX denotes the version number of NASM contained in the archive), unpack it into a directory such as /usr/local/src. The archive, when unpacked, will create its own subdirectory nasm-XXX.

NASM is an auto-configuring package: once you've unpacked it, cd to the directory it's been unpacked into and type ./configure. This shell script will find the best C compiler to use for building NASM and set up Makefiles accordingly.

Once NASM has auto-configured, you can type make to build the nasm and ndisasm binaries, and then make install to install them in /usr/local/bin and install the man pages nasm.1 and ndisasm.1 in /usr/local/man/man1. Alternatively, you can give options such as --prefix to the configure script (see the file INSTALL for more details), or install the programs yourself.

NASM also comes with a set of utilities for handling the RDOFF custom object-file format, which are in the rdoff subdirectory of the NASM archive. You can build these with make rdf and install them with make rdf_install, if you want them.

Next Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdocb.html0000644000000000000000000056307711026031755016771 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Previous Chapter | Contents | Index

Appendix B: Instruction List

6.11.3 rdf Extensions to the GLOBAL directive

RDOFF global symbols can contain additional information needed by the static linker. You can mark a global symbol as exported, thus telling the linker do not strip it from target executable or library file. Like in ELF, you can also specify whether an exported symbol is a procedure (function) or data object.

Suffixing the name with a colon and the word export you make the symbol exported: 

    global  sys_open:export

To specify that exported symbol is a procedure (function), you add the word proc or function after declaration: 

    global  sys_open:export proc

Similarly, to specify exported data object, add the word data or object to the directive: 

    global  kernel_ticks:export data

6.11.4 rdf Extensions to the EXTERN directive

By default the EXTERN directive in RDOFF declares a "pure external" symbol (i.e. the static linker will complain if such a symbol is not resolved). To declare an "imported" symbol, which must be resolved later during a dynamic linking phase, RDOFF offers an additional import modifier. As in GLOBAL, you can also specify whether an imported symbol is a procedure (function) or data object. For example: 

    library $libc 
    extern  _open:import 
    extern  _printf:import proc 
    extern  _errno:import data

Here the directive LIBRARY is also included, which gives the dynamic linker a hint as to where to find requested symbols.

6.12 dbg: Debugging Format

The dbg output format is not built into NASM in the default configuration. If you are building your own NASM executable from the sources, you can define OF_DBG in outform.h or on the compiler command line, and obtain the dbg output format.

The dbg format does not output an object file as such; instead, it outputs a text file which contains a complete list of all the transactions between the main body of NASM and the output-format back end module. It is primarily intended to aid people who want to write their own output drivers, so that they can get a clearer idea of the various requests the main program makes of the output driver, and in what order they happen.

For simple files, one can easily use the dbg format like this: 

nasm -f dbg filename.asm

which will generate a diagnostic file called filename.dbg. However, this will not work well on files which were designed for a different object format, because each object format defines its own macros (usually user-level forms of directives), and those macros will not be defined in the dbg format. Therefore it can be useful to run NASM twice, in order to do the preprocessing with the native object format selected: 

nasm -e -f rdf -o rdfprog.i rdfprog.asm 
nasm -a -f dbg rdfprog.i

This preprocesses rdfprog.asm into rdfprog.i, keeping the rdf object format selected in order to make sure RDF special directives are converted into primitive form correctly. Then the preprocessed source is fed through the dbg format to generate the final diagnostic output.

This workaround will still typically not work for programs intended for obj format, because the obj SEGMENT and GROUP directives have side effects of defining the segment and group names as symbols; dbg will not do this, so the program will not assemble. You will have to work around that by defining the symbols yourself (using EXTERN, for example) if you really need to get a dbg trace of an obj-specific source file.

dbg accepts any section name and any directives at all, and logs them all to its output file.

Next Chapter | Previous Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdoc1.html0000644000000000000000000002166211026031754016674 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Next Chapter | Contents | Index

Chapter 1: Introduction

1.1 What Is NASM?

The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. It supports a range of object file formats, including Linux and *BSD a.out, ELF, COFF, Mach-O, Microsoft 16-bit OBJ, Win32 and Win64. It will also output plain binary files. Its syntax is designed to be simple and easy to understand, similar to Intel's but less complex. It supports all currently known x86 architectural extensions, and has strong support for macros.

1.1.1 Why Yet Another Assembler?

The Netwide Assembler grew out of an idea on comp.lang.asm.x86 (or possibly alt.lang.asm - I forget which), which was essentially that there didn't seem to be a good free x86-series assembler around, and that maybe someone ought to write one.

So here, for your coding pleasure, is NASM. At present it's still in prototype stage - we don't promise that it can outperform any of these assemblers. But please, please send us bug reports, fixes, helpful information, and anything else you can get your hands on (and thanks to the many people who've done this already! You all know who you are), and we'll improve it out of all recognition. Again.

1.1.2 License Conditions

Please see the file COPYING, supplied as part of any NASM distribution archive, for the license conditions under which you may use NASM. NASM is now under the so-called GNU Lesser General Public License, LGPL.

1.2 Contact Information

The current version of NASM (since about 0.98.08) is maintained by a team of developers, accessible through the nasm-devel mailing list (see below for the link). If you want to report a bug, please read section 11.2 first.

NASM has a WWW page at http://nasm.sourceforge.net. If it's not there, google for us!

The original authors are e-mailable as jules@dsf.org.uk and anakin@pobox.com. The latter is no longer involved in the development team.

New releases of NASM are uploaded to the official sites http://nasm.sourceforge.net and to ftp.kernel.org and ibiblio.org.

Announcements are posted to comp.lang.asm.x86, alt.lang.asm and comp.os.linux.announce

If you want information about NASM beta releases, and the current development status, please subscribe to the nasm-devel email list by registering at http://sourceforge.net/projects/nasm.

1.3 Installation

1.3.1 Installing NASM under MS-DOS or Windows

Once you've obtained the appropriate archive for NASM, nasm-XXX-dos.zip or nasm-XXX-win32.zip (where XXX denotes the version number of NASM contained in the archive), unpack it into its own directory (for example c:\nasm).

The archive will contain a set of executable files: the NASM executable file nasm.exe, the NDISASM executable file ndisasm.exe, and possibly additional utilities to handle the RDOFF file format.

The only file NASM needs to run is its own executable, so copy nasm.exe to a directory on your PATH, or alternatively edit autoexec.bat to add the nasm directory to your PATH (to do that under Windows XP, go to Start > Control Panel > System > Advanced > Environment Variables; these instructions may work under other versions of Windows as well.)

That's it - NASM is installed. You don't need the nasm directory to be present to run NASM (unless you've added it to your PATH), so you can delete it if you need to save space; however, you may want to keep the documentation or test programs.

If you've downloaded the DOS source archive, nasm-XXX.zip, the nasm directory will also contain the full NASM source code, and a selection of Makefiles you can (hopefully) use to rebuild your copy of NASM from scratch. See the file INSTALL in the source archive.

Note that a number of files are generated from other files by Perl scripts. Although the NASM source distribution includes these generated files, you will need to rebuild them (and hence, will need a Perl interpreter) if you change insns.dat, standard.mac or the documentation. It is possible future source distributions may not include these files at all. Ports of Perl for a variety of platforms, including DOS and Windows, are available from www.cpan.org.

1.3.2 Installing NASM under Unix

Once you've obtained the Unix source archive for NASM, nasm-XXX.tar.gz (where XXX denotes the version number of NASM contained in the archive), unpack it into a directory such as /usr/local/src. The archive, when unpacked, will create its own subdirectory nasm-XXX.

NASM is an auto-configuring package: once you've unpacked it, cd to the directory it's been unpacked into and type ./configure. This shell script will find the best C compiler to use for building NASM and set up Makefiles accordingly.

Once NASM has auto-configured, you can type make to build the nasm and ndisasm binaries, and then make install to install them in /usr/local/bin and install the man pages nasm.1 and ndisasm.1 in /usr/local/man/man1. Alternatively, you can give options such as --prefix to the configure script (see the file INSTALL for more details), or install the programs yourself.

NASM also comes with a set of utilities for handling the RDOFF custom object-file format, which are in the rdoff subdirectory of the NASM archive. You can build these with make rdf and install them with make rdf_install, if you want them.

Next Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdocb.html0000644000000000000000000056307711026031755016771 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Previous Chapter | Contents | Index

Appendix B: Instruction List

6.11.3 rdf Extensions to the GLOBAL directive

RDOFF global symbols can contain additional information needed by the static linker. You can mark a global symbol as exported, thus telling the linker do not strip it from target executable or library file. Like in ELF, you can also specify whether an exported symbol is a procedure (function) or data object.

Suffixing the name with a colon and the word export you make the symbol exported: 

    global  sys_open:export

To specify that exported symbol is a procedure (function), you add the word proc or function after declaration: 

    global  sys_open:export proc

Similarly, to specify exported data object, add the word data or object to the directive: 

    global  kernel_ticks:export data

6.11.4 rdf Extensions to the EXTERN directive

By default the EXTERN directive in RDOFF declares a "pure external" symbol (i.e. the static linker will complain if such a symbol is not resolved). To declare an "imported" symbol, which must be resolved later during a dynamic linking phase, RDOFF offers an additional import modifier. As in GLOBAL, you can also specify whether an imported symbol is a procedure (function) or data object. For example: 

    library $libc 
    extern  _open:import 
    extern  _printf:import proc 
    extern  _errno:import data

Here the directive LIBRARY is also included, which gives the dynamic linker a hint as to where to find requested symbols.

6.12 dbg: Debugging Format

The dbg output format is not built into NASM in the default configuration. If you are building your own NASM executable from the sources, you can define OF_DBG in outform.h or on the compiler command line, and obtain the dbg output format.

The dbg format does not output an object file as such; instead, it outputs a text file which contains a complete list of all the transactions between the main body of NASM and the output-format back end module. It is primarily intended to aid people who want to write their own output drivers, so that they can get a clearer idea of the various requests the main program makes of the output driver, and in what order they happen.

For simple files, one can easily use the dbg format like this: 

nasm -f dbg filename.asm

which will generate a diagnostic file called filename.dbg. However, this will not work well on files which were designed for a different object format, because each object format defines its own macros (usually user-level forms of directives), and those macros will not be defined in the dbg format. Therefore it can be useful to run NASM twice, in order to do the preprocessing with the native object format selected: 

nasm -e -f rdf -o rdfprog.i rdfprog.asm 
nasm -a -f dbg rdfprog.i

This preprocesses rdfprog.asm into rdfprog.i, keeping the rdf object format selected in order to make sure RDF special directives are converted into primitive form correctly. Then the preprocessed source is fed through the dbg format to generate the final diagnostic output.

This workaround will still typically not work for programs intended for obj format, because the obj SEGMENT and GROUP directives have side effects of defining the segment and group names as symbols; dbg will not do this, so the program will not assemble. You will have to work around that by defining the symbols yourself (using EXTERN, for example) if you really need to get a dbg trace of an obj-specific source file.

dbg accepts any section name and any directives at all, and logs them all to its output file.

Next Chapter | Previous Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdoc1.html0000644000000000000000000002166211026031754016674 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Next Chapter | Contents | Index

Chapter 1: Introduction

1.1 What Is NASM?

The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. It supports a range of object file formats, including Linux and *BSD a.out, ELF, COFF, Mach-O, Microsoft 16-bit OBJ, Win32 and Win64. It will also output plain binary files. Its syntax is designed to be simple and easy to understand, similar to Intel's but less complex. It supports all currently known x86 architectural extensions, and has strong support for macros.

1.1.1 Why Yet Another Assembler?

The Netwide Assembler grew out of an idea on comp.lang.asm.x86 (or possibly alt.lang.asm - I forget which), which was essentially that there didn't seem to be a good free x86-series assembler around, and that maybe someone ought to write one.

So here, for your coding pleasure, is NASM. At present it's still in prototype stage - we don't promise that it can outperform any of these assemblers. But please, please send us bug reports, fixes, helpful information, and anything else you can get your hands on (and thanks to the many people who've done this already! You all know who you are), and we'll improve it out of all recognition. Again.

1.1.2 License Conditions

Please see the file COPYING, supplied as part of any NASM distribution archive, for the license conditions under which you may use NASM. NASM is now under the so-called GNU Lesser General Public License, LGPL.

1.2 Contact Information

The current version of NASM (since about 0.98.08) is maintained by a team of developers, accessible through the nasm-devel mailing list (see below for the link). If you want to report a bug, please read section 11.2 first.

NASM has a WWW page at http://nasm.sourceforge.net. If it's not there, google for us!

The original authors are e-mailable as jules@dsf.org.uk and anakin@pobox.com. The latter is no longer involved in the development team.

New releases of NASM are uploaded to the official sites http://nasm.sourceforge.net and to ftp.kernel.org and ibiblio.org.

Announcements are posted to comp.lang.asm.x86, alt.lang.asm and comp.os.linux.announce

If you want information about NASM beta releases, and the current development status, please subscribe to the nasm-devel email list by registering at http://sourceforge.net/projects/nasm.

1.3 Installation

1.3.1 Installing NASM under MS-DOS or Windows

Once you've obtained the appropriate archive for NASM, nasm-XXX-dos.zip or nasm-XXX-win32.zip (where XXX denotes the version number of NASM contained in the archive), unpack it into its own directory (for example c:\nasm).

The archive will contain a set of executable files: the NASM executable file nasm.exe, the NDISASM executable file ndisasm.exe, and possibly additional utilities to handle the RDOFF file format.

The only file NASM needs to run is its own executable, so copy nasm.exe to a directory on your PATH, or alternatively edit autoexec.bat to add the nasm directory to your PATH (to do that under Windows XP, go to Start > Control Panel > System > Advanced > Environment Variables; these instructions may work under other versions of Windows as well.)

That's it - NASM is installed. You don't need the nasm directory to be present to run NASM (unless you've added it to your PATH), so you can delete it if you need to save space; however, you may want to keep the documentation or test programs.

If you've downloaded the DOS source archive, nasm-XXX.zip, the nasm directory will also contain the full NASM source code, and a selection of Makefiles you can (hopefully) use to rebuild your copy of NASM from scratch. See the file INSTALL in the source archive.

Note that a number of files are generated from other files by Perl scripts. Although the NASM source distribution includes these generated files, you will need to rebuild them (and hence, will need a Perl interpreter) if you change insns.dat, standard.mac or the documentation. It is possible future source distributions may not include these files at all. Ports of Perl for a variety of platforms, including DOS and Windows, are available from www.cpan.org.

1.3.2 Installing NASM under Unix

Once you've obtained the Unix source archive for NASM, nasm-XXX.tar.gz (where XXX denotes the version number of NASM contained in the archive), unpack it into a directory such as /usr/local/src. The archive, when unpacked, will create its own subdirectory nasm-XXX.

NASM is an auto-configuring package: once you've unpacked it, cd to the directory it's been unpacked into and type ./configure. This shell script will find the best C compiler to use for building NASM and set up Makefiles accordingly.

Once NASM has auto-configured, you can type make to build the nasm and ndisasm binaries, and then make install to install them in /usr/local/bin and install the man pages nasm.1 and ndisasm.1 in /usr/local/man/man1. Alternatively, you can give options such as --prefix to the configure script (see the file INSTALL for more details), or install the programs yourself.

NASM also comes with a set of utilities for handling the RDOFF custom object-file format, which are in the rdoff subdirectory of the NASM archive. You can build these with make rdf and install them with make rdf_install, if you want them.

Next Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdocb.html0000644000000000000000000056307711026031755016771 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Previous Chapter | Contents | Index

Appendix B: Instruction List

6.11.3 rdf Extensions to the GLOBAL directive

RDOFF global symbols can contain additional information needed by the static linker. You can mark a global symbol as exported, thus telling the linker do not strip it from target executable or library file. Like in ELF, you can also specify whether an exported symbol is a procedure (function) or data object.

Suffixing the name with a colon and the word export you make the symbol exported: 

    global  sys_open:export

To specify that exported symbol is a procedure (function), you add the word proc or function after declaration: 

    global  sys_open:export proc

Similarly, to specify exported data object, add the word data or object to the directive: 

    global  kernel_ticks:export data

6.11.4 rdf Extensions to the EXTERN directive

By default the EXTERN directive in RDOFF declares a "pure external" symbol (i.e. the static linker will complain if such a symbol is not resolved). To declare an "imported" symbol, which must be resolved later during a dynamic linking phase, RDOFF offers an additional import modifier. As in GLOBAL, you can also specify whether an imported symbol is a procedure (function) or data object. For example: 

    library $libc 
    extern  _open:import 
    extern  _printf:import proc 
    extern  _errno:import data

Here the directive LIBRARY is also included, which gives the dynamic linker a hint as to where to find requested symbols.

6.12 dbg: Debugging Format

The dbg output format is not built into NASM in the default configuration. If you are building your own NASM executable from the sources, you can define OF_DBG in outform.h or on the compiler command line, and obtain the dbg output format.

The dbg format does not output an object file as such; instead, it outputs a text file which contains a complete list of all the transactions between the main body of NASM and the output-format back end module. It is primarily intended to aid people who want to write their own output drivers, so that they can get a clearer idea of the various requests the main program makes of the output driver, and in what order they happen.

For simple files, one can easily use the dbg format like this: 

nasm -f dbg filename.asm

which will generate a diagnostic file called filename.dbg. However, this will not work well on files which were designed for a different object format, because each object format defines its own macros (usually user-level forms of directives), and those macros will not be defined in the dbg format. Therefore it can be useful to run NASM twice, in order to do the preprocessing with the native object format selected: 

nasm -e -f rdf -o rdfprog.i rdfprog.asm 
nasm -a -f dbg rdfprog.i

This preprocesses rdfprog.asm into rdfprog.i, keeping the rdf object format selected in order to make sure RDF special directives are converted into primitive form correctly. Then the preprocessed source is fed through the dbg format to generate the final diagnostic output.

This workaround will still typically not work for programs intended for obj format, because the obj SEGMENT and GROUP directives have side effects of defining the segment and group names as symbols; dbg will not do this, so the program will not assemble. You will have to work around that by defining the symbols yourself (using EXTERN, for example) if you really need to get a dbg trace of an obj-specific source file.

dbg accepts any section name and any directives at all, and logs them all to its output file.

Next Chapter | Previous Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdoc1.html0000644000000000000000000002166211026031754016674 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Next Chapter | Contents | Index

Chapter 1: Introduction

1.1 What Is NASM?

The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. It supports a range of object file formats, including Linux and *BSD a.out, ELF, COFF, Mach-O, Microsoft 16-bit OBJ, Win32 and Win64. It will also output plain binary files. Its syntax is designed to be simple and easy to understand, similar to Intel's but less complex. It supports all currently known x86 architectural extensions, and has strong support for macros.

1.1.1 Why Yet Another Assembler?

The Netwide Assembler grew out of an idea on comp.lang.asm.x86 (or possibly alt.lang.asm - I forget which), which was essentially that there didn't seem to be a good free x86-series assembler around, and that maybe someone ought to write one.

So here, for your coding pleasure, is NASM. At present it's still in prototype stage - we don't promise that it can outperform any of these assemblers. But please, please send us bug reports, fixes, helpful information, and anything else you can get your hands on (and thanks to the many people who've done this already! You all know who you are), and we'll improve it out of all recognition. Again.

1.1.2 License Conditions

Please see the file COPYING, supplied as part of any NASM distribution archive, for the license conditions under which you may use NASM. NASM is now under the so-called GNU Lesser General Public License, LGPL.

1.2 Contact Information

The current version of NASM (since about 0.98.08) is maintained by a team of developers, accessible through the nasm-devel mailing list (see below for the link). If you want to report a bug, please read section 11.2 first.

NASM has a WWW page at http://nasm.sourceforge.net. If it's not there, google for us!

The original authors are e-mailable as jules@dsf.org.uk and anakin@pobox.com. The latter is no longer involved in the development team.

New releases of NASM are uploaded to the official sites http://nasm.sourceforge.net and to ftp.kernel.org and ibiblio.org.

Announcements are posted to comp.lang.asm.x86, alt.lang.asm and comp.os.linux.announce

If you want information about NASM beta releases, and the current development status, please subscribe to the nasm-devel email list by registering at http://sourceforge.net/projects/nasm.

1.3 Installation

1.3.1 Installing NASM under MS-DOS or Windows

Once you've obtained the appropriate archive for NASM, nasm-XXX-dos.zip or nasm-XXX-win32.zip (where XXX denotes the version number of NASM contained in the archive), unpack it into its own directory (for example c:\nasm).

The archive will contain a set of executable files: the NASM executable file nasm.exe, the NDISASM executable file ndisasm.exe, and possibly additional utilities to handle the RDOFF file format.

The only file NASM needs to run is its own executable, so copy nasm.exe to a directory on your PATH, or alternatively edit autoexec.bat to add the nasm directory to your PATH (to do that under Windows XP, go to Start > Control Panel > System > Advanced > Environment Variables; these instructions may work under other versions of Windows as well.)

That's it - NASM is installed. You don't need the nasm directory to be present to run NASM (unless you've added it to your PATH), so you can delete it if you need to save space; however, you may want to keep the documentation or test programs.

If you've downloaded the DOS source archive, nasm-XXX.zip, the nasm directory will also contain the full NASM source code, and a selection of Makefiles you can (hopefully) use to rebuild your copy of NASM from scratch. See the file INSTALL in the source archive.

Note that a number of files are generated from other files by Perl scripts. Although the NASM source distribution includes these generated files, you will need to rebuild them (and hence, will need a Perl interpreter) if you change insns.dat, standard.mac or the documentation. It is possible future source distributions may not include these files at all. Ports of Perl for a variety of platforms, including DOS and Windows, are available from www.cpan.org.

1.3.2 Installing NASM under Unix

Once you've obtained the Unix source archive for NASM, nasm-XXX.tar.gz (where XXX denotes the version number of NASM contained in the archive), unpack it into a directory such as /usr/local/src. The archive, when unpacked, will create its own subdirectory nasm-XXX.

NASM is an auto-configuring package: once you've unpacked it, cd to the directory it's been unpacked into and type ./configure. This shell script will find the best C compiler to use for building NASM and set up Makefiles accordingly.

Once NASM has auto-configured, you can type make to build the nasm and ndisasm binaries, and then make install to install them in /usr/local/bin and install the man pages nasm.1 and ndisasm.1 in /usr/local/man/man1. Alternatively, you can give options such as --prefix to the configure script (see the file INSTALL for more details), or install the programs yourself.

NASM also comes with a set of utilities for handling the RDOFF custom object-file format, which are in the rdoff subdirectory of the NASM archive. You can build these with make rdf and install them with make rdf_install, if you want them.

Next Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdocb.html0000644000000000000000000056307711026031755016771 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Previous Chapter | Contents | Index

Appendix B: Instruction List

6.11.3 rdf Extensions to the GLOBAL directive

RDOFF global symbols can contain additional information needed by the static linker. You can mark a global symbol as exported, thus telling the linker do not strip it from target executable or library file. Like in ELF, you can also specify whether an exported symbol is a procedure (function) or data object.

Suffixing the name with a colon and the word export you make the symbol exported: 

    global  sys_open:export

To specify that exported symbol is a procedure (function), you add the word proc or function after declaration: 

    global  sys_open:export proc

Similarly, to specify exported data object, add the word data or object to the directive: 

    global  kernel_ticks:export data

6.11.4 rdf Extensions to the EXTERN directive

By default the EXTERN directive in RDOFF declares a "pure external" symbol (i.e. the static linker will complain if such a symbol is not resolved). To declare an "imported" symbol, which must be resolved later during a dynamic linking phase, RDOFF offers an additional import modifier. As in GLOBAL, you can also specify whether an imported symbol is a procedure (function) or data object. For example: 

    library $libc 
    extern  _open:import 
    extern  _printf:import proc 
    extern  _errno:import data

Here the directive LIBRARY is also included, which gives the dynamic linker a hint as to where to find requested symbols.

6.12 dbg: Debugging Format

The dbg output format is not built into NASM in the default configuration. If you are building your own NASM executable from the sources, you can define OF_DBG in outform.h or on the compiler command line, and obtain the dbg output format.

The dbg format does not output an object file as such; instead, it outputs a text file which contains a complete list of all the transactions between the main body of NASM and the output-format back end module. It is primarily intended to aid people who want to write their own output drivers, so that they can get a clearer idea of the various requests the main program makes of the output driver, and in what order they happen.

For simple files, one can easily use the dbg format like this: 

nasm -f dbg filename.asm

which will generate a diagnostic file called filename.dbg. However, this will not work well on files which were designed for a different object format, because each object format defines its own macros (usually user-level forms of directives), and those macros will not be defined in the dbg format. Therefore it can be useful to run NASM twice, in order to do the preprocessing with the native object format selected: 

nasm -e -f rdf -o rdfprog.i rdfprog.asm 
nasm -a -f dbg rdfprog.i

This preprocesses rdfprog.asm into rdfprog.i, keeping the rdf object format selected in order to make sure RDF special directives are converted into primitive form correctly. Then the preprocessed source is fed through the dbg format to generate the final diagnostic output.

This workaround will still typically not work for programs intended for obj format, because the obj SEGMENT and GROUP directives have side effects of defining the segment and group names as symbols; dbg will not do this, so the program will not assemble. You will have to work around that by defining the symbols yourself (using EXTERN, for example) if you really need to get a dbg trace of an obj-specific source file.

dbg accepts any section name and any directives at all, and logs them all to its output file.

Next Chapter | Previous Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdoc1.html0000644000000000000000000002166211026031754016674 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Next Chapter | Contents | Index

Chapter 1: Introduction

1.1 What Is NASM?

The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. It supports a range of object file formats, including Linux and *BSD a.out, ELF, COFF, Mach-O, Microsoft 16-bit OBJ, Win32 and Win64. It will also output plain binary files. Its syntax is designed to be simple and easy to understand, similar to Intel's but less complex. It supports all currently known x86 architectural extensions, and has strong support for macros.

1.1.1 Why Yet Another Assembler?

The Netwide Assembler grew out of an idea on comp.lang.asm.x86 (or possibly alt.lang.asm - I forget which), which was essentially that there didn't seem to be a good free x86-series assembler around, and that maybe someone ought to write one.

So here, for your coding pleasure, is NASM. At present it's still in prototype stage - we don't promise that it can outperform any of these assemblers. But please, please send us bug reports, fixes, helpful information, and anything else you can get your hands on (and thanks to the many people who've done this already! You all know who you are), and we'll improve it out of all recognition. Again.

1.1.2 License Conditions

Please see the file COPYING, supplied as part of any NASM distribution archive, for the license conditions under which you may use NASM. NASM is now under the so-called GNU Lesser General Public License, LGPL.

1.2 Contact Information

The current version of NASM (since about 0.98.08) is maintained by a team of developers, accessible through the nasm-devel mailing list (see below for the link). If you want to report a bug, please read section 11.2 first.

NASM has a WWW page at http://nasm.sourceforge.net. If it's not there, google for us!

The original authors are e-mailable as jules@dsf.org.uk and anakin@pobox.com. The latter is no longer involved in the development team.

New releases of NASM are uploaded to the official sites http://nasm.sourceforge.net and to ftp.kernel.org and ibiblio.org.

Announcements are posted to comp.lang.asm.x86, alt.lang.asm and comp.os.linux.announce

If you want information about NASM beta releases, and the current development status, please subscribe to the nasm-devel email list by registering at http://sourceforge.net/projects/nasm.

1.3 Installation

1.3.1 Installing NASM under MS-DOS or Windows

Once you've obtained the appropriate archive for NASM, nasm-XXX-dos.zip or nasm-XXX-win32.zip (where XXX denotes the version number of NASM contained in the archive), unpack it into its own directory (for example c:\nasm).

The archive will contain a set of executable files: the NASM executable file nasm.exe, the NDISASM executable file ndisasm.exe, and possibly additional utilities to handle the RDOFF file format.

The only file NASM needs to run is its own executable, so copy nasm.exe to a directory on your PATH, or alternatively edit autoexec.bat to add the nasm directory to your PATH (to do that under Windows XP, go to Start > Control Panel > System > Advanced > Environment Variables; these instructions may work under other versions of Windows as well.)

That's it - NASM is installed. You don't need the nasm directory to be present to run NASM (unless you've added it to your PATH), so you can delete it if you need to save space; however, you may want to keep the documentation or test programs.

If you've downloaded the DOS source archive, nasm-XXX.zip, the nasm directory will also contain the full NASM source code, and a selection of Makefiles you can (hopefully) use to rebuild your copy of NASM from scratch. See the file INSTALL in the source archive.

Note that a number of files are generated from other files by Perl scripts. Although the NASM source distribution includes these generated files, you will need to rebuild them (and hence, will need a Perl interpreter) if you change insns.dat, standard.mac or the documentation. It is possible future source distributions may not include these files at all. Ports of Perl for a variety of platforms, including DOS and Windows, are available from www.cpan.org.

1.3.2 Installing NASM under Unix

Once you've obtained the Unix source archive for NASM, nasm-XXX.tar.gz (where XXX denotes the version number of NASM contained in the archive), unpack it into a directory such as /usr/local/src. The archive, when unpacked, will create its own subdirectory nasm-XXX.

NASM is an auto-configuring package: once you've unpacked it, cd to the directory it's been unpacked into and type ./configure. This shell script will find the best C compiler to use for building NASM and set up Makefiles accordingly.

Once NASM has auto-configured, you can type make to build the nasm and ndisasm binaries, and then make install to install them in /usr/local/bin and install the man pages nasm.1 and ndisasm.1 in /usr/local/man/man1. Alternatively, you can give options such as --prefix to the configure script (see the file INSTALL for more details), or install the programs yourself.

NASM also comes with a set of utilities for handling the RDOFF custom object-file format, which are in the rdoff subdirectory of the NASM archive. You can build these with make rdf and install them with make rdf_install, if you want them.

Next Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdocb.html0000644000000000000000000056307711026031755016771 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Previous Chapter | Contents | Index

Appendix B: Instruction List

6.11.3 rdf Extensions to the GLOBAL directive

RDOFF global symbols can contain additional information needed by the static linker. You can mark a global symbol as exported, thus telling the linker do not strip it from target executable or library file. Like in ELF, you can also specify whether an exported symbol is a procedure (function) or data object.

Suffixing the name with a colon and the word export you make the symbol exported: 

    global  sys_open:export

To specify that exported symbol is a procedure (function), you add the word proc or function after declaration: 

    global  sys_open:export proc

Similarly, to specify exported data object, add the word data or object to the directive: 

    global  kernel_ticks:export data

6.11.4 rdf Extensions to the EXTERN directive

By default the EXTERN directive in RDOFF declares a "pure external" symbol (i.e. the static linker will complain if such a symbol is not resolved). To declare an "imported" symbol, which must be resolved later during a dynamic linking phase, RDOFF offers an additional import modifier. As in GLOBAL, you can also specify whether an imported symbol is a procedure (function) or data object. For example: 

    library $libc 
    extern  _open:import 
    extern  _printf:import proc 
    extern  _errno:import data

Here the directive LIBRARY is also included, which gives the dynamic linker a hint as to where to find requested symbols.

6.12 dbg: Debugging Format

The dbg output format is not built into NASM in the default configuration. If you are building your own NASM executable from the sources, you can define OF_DBG in outform.h or on the compiler command line, and obtain the dbg output format.

The dbg format does not output an object file as such; instead, it outputs a text file which contains a complete list of all the transactions between the main body of NASM and the output-format back end module. It is primarily intended to aid people who want to write their own output drivers, so that they can get a clearer idea of the various requests the main program makes of the output driver, and in what order they happen.

For simple files, one can easily use the dbg format like this: 

nasm -f dbg filename.asm

which will generate a diagnostic file called filename.dbg. However, this will not work well on files which were designed for a different object format, because each object format defines its own macros (usually user-level forms of directives), and those macros will not be defined in the dbg format. Therefore it can be useful to run NASM twice, in order to do the preprocessing with the native object format selected: 

nasm -e -f rdf -o rdfprog.i rdfprog.asm 
nasm -a -f dbg rdfprog.i

This preprocesses rdfprog.asm into rdfprog.i, keeping the rdf object format selected in order to make sure RDF special directives are converted into primitive form correctly. Then the preprocessed source is fed through the dbg format to generate the final diagnostic output.

This workaround will still typically not work for programs intended for obj format, because the obj SEGMENT and GROUP directives have side effects of defining the segment and group names as symbols; dbg will not do this, so the program will not assemble. You will have to work around that by defining the symbols yourself (using EXTERN, for example) if you really need to get a dbg trace of an obj-specific source file.

dbg accepts any section name and any directives at all, and logs them all to its output file.

Next Chapter | Previous Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdoc1.html0000644000000000000000000002166211026031754016674 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Next Chapter | Contents | Index

Chapter 1: Introduction

1.1 What Is NASM?

The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. It supports a range of object file formats, including Linux and *BSD a.out, ELF, COFF, Mach-O, Microsoft 16-bit OBJ, Win32 and Win64. It will also output plain binary files. Its syntax is designed to be simple and easy to understand, similar to Intel's but less complex. It supports all currently known x86 architectural extensions, and has strong support for macros.

1.1.1 Why Yet Another Assembler?

The Netwide Assembler grew out of an idea on comp.lang.asm.x86 (or possibly alt.lang.asm - I forget which), which was essentially that there didn't seem to be a good free x86-series assembler around, and that maybe someone ought to write one.

So here, for your coding pleasure, is NASM. At present it's still in prototype stage - we don't promise that it can outperform any of these assemblers. But please, please send us bug reports, fixes, helpful information, and anything else you can get your hands on (and thanks to the many people who've done this already! You all know who you are), and we'll improve it out of all recognition. Again.

1.1.2 License Conditions

Please see the file COPYING, supplied as part of any NASM distribution archive, for the license conditions under which you may use NASM. NASM is now under the so-called GNU Lesser General Public License, LGPL.

1.2 Contact Information

The current version of NASM (since about 0.98.08) is maintained by a team of developers, accessible through the nasm-devel mailing list (see below for the link). If you want to report a bug, please read section 11.2 first.

NASM has a WWW page at http://nasm.sourceforge.net. If it's not there, google for us!

The original authors are e-mailable as jules@dsf.org.uk and anakin@pobox.com. The latter is no longer involved in the development team.

New releases of NASM are uploaded to the official sites http://nasm.sourceforge.net and to ftp.kernel.org and ibiblio.org.

Announcements are posted to comp.lang.asm.x86, alt.lang.asm and comp.os.linux.announce

If you want information about NASM beta releases, and the current development status, please subscribe to the nasm-devel email list by registering at http://sourceforge.net/projects/nasm.

1.3 Installation

1.3.1 Installing NASM under MS-DOS or Windows

Once you've obtained the appropriate archive for NASM, nasm-XXX-dos.zip or nasm-XXX-win32.zip (where XXX denotes the version number of NASM contained in the archive), unpack it into its own directory (for example c:\nasm).

The archive will contain a set of executable files: the NASM executable file nasm.exe, the NDISASM executable file ndisasm.exe, and possibly additional utilities to handle the RDOFF file format.

The only file NASM needs to run is its own executable, so copy nasm.exe to a directory on your PATH, or alternatively edit autoexec.bat to add the nasm directory to your PATH (to do that under Windows XP, go to Start > Control Panel > System > Advanced > Environment Variables; these instructions may work under other versions of Windows as well.)

That's it - NASM is installed. You don't need the nasm directory to be present to run NASM (unless you've added it to your PATH), so you can delete it if you need to save space; however, you may want to keep the documentation or test programs.

If you've downloaded the DOS source archive, nasm-XXX.zip, the nasm directory will also contain the full NASM source code, and a selection of Makefiles you can (hopefully) use to rebuild your copy of NASM from scratch. See the file INSTALL in the source archive.

Note that a number of files are generated from other files by Perl scripts. Although the NASM source distribution includes these generated files, you will need to rebuild them (and hence, will need a Perl interpreter) if you change insns.dat, standard.mac or the documentation. It is possible future source distributions may not include these files at all. Ports of Perl for a variety of platforms, including DOS and Windows, are available from www.cpan.org.

1.3.2 Installing NASM under Unix

Once you've obtained the Unix source archive for NASM, nasm-XXX.tar.gz (where XXX denotes the version number of NASM contained in the archive), unpack it into a directory such as /usr/local/src. The archive, when unpacked, will create its own subdirectory nasm-XXX.

NASM is an auto-configuring package: once you've unpacked it, cd to the directory it's been unpacked into and type ./configure. This shell script will find the best C compiler to use for building NASM and set up Makefiles accordingly.

Once NASM has auto-configured, you can type make to build the nasm and ndisasm binaries, and then make install to install them in /usr/local/bin and install the man pages nasm.1 and ndisasm.1 in /usr/local/man/man1. Alternatively, you can give options such as --prefix to the configure script (see the file INSTALL for more details), or install the programs yourself.

NASM also comes with a set of utilities for handling the RDOFF custom object-file format, which are in the rdoff subdirectory of the NASM archive. You can build these with make rdf and install them with make rdf_install, if you want them.

Next Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdocb.html0000644000000000000000000056307711026031755016771 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Previous Chapter | Contents | Index

Appendix B: Instruction List

6.11.3 rdf Extensions to the GLOBAL directive

RDOFF global symbols can contain additional information needed by the static linker. You can mark a global symbol as exported, thus telling the linker do not strip it from target executable or library file. Like in ELF, you can also specify whether an exported symbol is a procedure (function) or data object.

Suffixing the name with a colon and the word export you make the symbol exported: 

    global  sys_open:export

To specify that exported symbol is a procedure (function), you add the word proc or function after declaration: 

    global  sys_open:export proc

Similarly, to specify exported data object, add the word data or object to the directive: 

    global  kernel_ticks:export data

6.11.4 rdf Extensions to the EXTERN directive

By default the EXTERN directive in RDOFF declares a "pure external" symbol (i.e. the static linker will complain if such a symbol is not resolved). To declare an "imported" symbol, which must be resolved later during a dynamic linking phase, RDOFF offers an additional import modifier. As in GLOBAL, you can also specify whether an imported symbol is a procedure (function) or data object. For example: 

    library $libc 
    extern  _open:import 
    extern  _printf:import proc 
    extern  _errno:import data

Here the directive LIBRARY is also included, which gives the dynamic linker a hint as to where to find requested symbols.

6.12 dbg: Debugging Format

The dbg output format is not built into NASM in the default configuration. If you are building your own NASM executable from the sources, you can define OF_DBG in outform.h or on the compiler command line, and obtain the dbg output format.

The dbg format does not output an object file as such; instead, it outputs a text file which contains a complete list of all the transactions between the main body of NASM and the output-format back end module. It is primarily intended to aid people who want to write their own output drivers, so that they can get a clearer idea of the various requests the main program makes of the output driver, and in what order they happen.

For simple files, one can easily use the dbg format like this: 

nasm -f dbg filename.asm

which will generate a diagnostic file called filename.dbg. However, this will not work well on files which were designed for a different object format, because each object format defines its own macros (usually user-level forms of directives), and those macros will not be defined in the dbg format. Therefore it can be useful to run NASM twice, in order to do the preprocessing with the native object format selected: 

nasm -e -f rdf -o rdfprog.i rdfprog.asm 
nasm -a -f dbg rdfprog.i

This preprocesses rdfprog.asm into rdfprog.i, keeping the rdf object format selected in order to make sure RDF special directives are converted into primitive form correctly. Then the preprocessed source is fed through the dbg format to generate the final diagnostic output.

This workaround will still typically not work for programs intended for obj format, because the obj SEGMENT and GROUP directives have side effects of defining the segment and group names as symbols; dbg will not do this, so the program will not assemble. You will have to work around that by defining the symbols yourself (using EXTERN, for example) if you really need to get a dbg trace of an obj-specific source file.

dbg accepts any section name and any directives at all, and logs them all to its output file.

Next Chapter | Previous Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdoc1.html0000644000000000000000000002166211026031754016674 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Next Chapter | Contents | Index

Chapter 1: Introduction

1.1 What Is NASM?

The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. It supports a range of object file formats, including Linux and *BSD a.out, ELF, COFF, Mach-O, Microsoft 16-bit OBJ, Win32 and Win64. It will also output plain binary files. Its syntax is designed to be simple and easy to understand, similar to Intel's but less complex. It supports all currently known x86 architectural extensions, and has strong support for macros.

1.1.1 Why Yet Another Assembler?

The Netwide Assembler grew out of an idea on comp.lang.asm.x86 (or possibly alt.lang.asm - I forget which), which was essentially that there didn't seem to be a good free x86-series assembler around, and that maybe someone ought to write one.

So here, for your coding pleasure, is NASM. At present it's still in prototype stage - we don't promise that it can outperform any of these assemblers. But please, please send us bug reports, fixes, helpful information, and anything else you can get your hands on (and thanks to the many people who've done this already! You all know who you are), and we'll improve it out of all recognition. Again.

1.1.2 License Conditions

Please see the file COPYING, supplied as part of any NASM distribution archive, for the license conditions under which you may use NASM. NASM is now under the so-called GNU Lesser General Public License, LGPL.

1.2 Contact Information

The current version of NASM (since about 0.98.08) is maintained by a team of developers, accessible through the nasm-devel mailing list (see below for the link). If you want to report a bug, please read section 11.2 first.

NASM has a WWW page at http://nasm.sourceforge.net. If it's not there, google for us!

The original authors are e-mailable as jules@dsf.org.uk and anakin@pobox.com. The latter is no longer involved in the development team.

New releases of NASM are uploaded to the official sites http://nasm.sourceforge.net and to ftp.kernel.org and ibiblio.org.

Announcements are posted to comp.lang.asm.x86, alt.lang.asm and comp.os.linux.announce

If you want information about NASM beta releases, and the current development status, please subscribe to the nasm-devel email list by registering at http://sourceforge.net/projects/nasm.

1.3 Installation

1.3.1 Installing NASM under MS-DOS or Windows

Once you've obtained the appropriate archive for NASM, nasm-XXX-dos.zip or nasm-XXX-win32.zip (where XXX denotes the version number of NASM contained in the archive), unpack it into its own directory (for example c:\nasm).

The archive will contain a set of executable files: the NASM executable file nasm.exe, the NDISASM executable file ndisasm.exe, and possibly additional utilities to handle the RDOFF file format.

The only file NASM needs to run is its own executable, so copy nasm.exe to a directory on your PATH, or alternatively edit autoexec.bat to add the nasm directory to your PATH (to do that under Windows XP, go to Start > Control Panel > System > Advanced > Environment Variables; these instructions may work under other versions of Windows as well.)

That's it - NASM is installed. You don't need the nasm directory to be present to run NASM (unless you've added it to your PATH), so you can delete it if you need to save space; however, you may want to keep the documentation or test programs.

If you've downloaded the DOS source archive, nasm-XXX.zip, the nasm directory will also contain the full NASM source code, and a selection of Makefiles you can (hopefully) use to rebuild your copy of NASM from scratch. See the file INSTALL in the source archive.

Note that a number of files are generated from other files by Perl scripts. Although the NASM source distribution includes these generated files, you will need to rebuild them (and hence, will need a Perl interpreter) if you change insns.dat, standard.mac or the documentation. It is possible future source distributions may not include these files at all. Ports of Perl for a variety of platforms, including DOS and Windows, are available from www.cpan.org.

1.3.2 Installing NASM under Unix

Once you've obtained the Unix source archive for NASM, nasm-XXX.tar.gz (where XXX denotes the version number of NASM contained in the archive), unpack it into a directory such as /usr/local/src. The archive, when unpacked, will create its own subdirectory nasm-XXX.

NASM is an auto-configuring package: once you've unpacked it, cd to the directory it's been unpacked into and type ./configure. This shell script will find the best C compiler to use for building NASM and set up Makefiles accordingly.

Once NASM has auto-configured, you can type make to build the nasm and ndisasm binaries, and then make install to install them in /usr/local/bin and install the man pages nasm.1 and ndisasm.1 in /usr/local/man/man1. Alternatively, you can give options such as --prefix to the configure script (see the file INSTALL for more details), or install the programs yourself.

NASM also comes with a set of utilities for handling the RDOFF custom object-file format, which are in the rdoff subdirectory of the NASM archive. You can build these with make rdf and install them with make rdf_install, if you want them.

Next Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdocb.html0000644000000000000000000056307711026031755016771 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Previous Chapter | Contents | Index

Appendix B: Instruction List

6.11.3 rdf Extensions to the GLOBAL directive

RDOFF global symbols can contain additional information needed by the static linker. You can mark a global symbol as exported, thus telling the linker do not strip it from target executable or library file. Like in ELF, you can also specify whether an exported symbol is a procedure (function) or data object.

Suffixing the name with a colon and the word export you make the symbol exported: 

    global  sys_open:export

To specify that exported symbol is a procedure (function), you add the word proc or function after declaration: 

    global  sys_open:export proc

Similarly, to specify exported data object, add the word data or object to the directive: 

    global  kernel_ticks:export data

6.11.4 rdf Extensions to the EXTERN directive

By default the EXTERN directive in RDOFF declares a "pure external" symbol (i.e. the static linker will complain if such a symbol is not resolved). To declare an "imported" symbol, which must be resolved later during a dynamic linking phase, RDOFF offers an additional import modifier. As in GLOBAL, you can also specify whether an imported symbol is a procedure (function) or data object. For example: 

    library $libc 
    extern  _open:import 
    extern  _printf:import proc 
    extern  _errno:import data

Here the directive LIBRARY is also included, which gives the dynamic linker a hint as to where to find requested symbols.

6.12 dbg: Debugging Format

The dbg output format is not built into NASM in the default configuration. If you are building your own NASM executable from the sources, you can define OF_DBG in outform.h or on the compiler command line, and obtain the dbg output format.

The dbg format does not output an object file as such; instead, it outputs a text file which contains a complete list of all the transactions between the main body of NASM and the output-format back end module. It is primarily intended to aid people who want to write their own output drivers, so that they can get a clearer idea of the various requests the main program makes of the output driver, and in what order they happen.

For simple files, one can easily use the dbg format like this: 

nasm -f dbg filename.asm

which will generate a diagnostic file called filename.dbg. However, this will not work well on files which were designed for a different object format, because each object format defines its own macros (usually user-level forms of directives), and those macros will not be defined in the dbg format. Therefore it can be useful to run NASM twice, in order to do the preprocessing with the native object format selected: 

nasm -e -f rdf -o rdfprog.i rdfprog.asm 
nasm -a -f dbg rdfprog.i

This preprocesses rdfprog.asm into rdfprog.i, keeping the rdf object format selected in order to make sure RDF special directives are converted into primitive form correctly. Then the preprocessed source is fed through the dbg format to generate the final diagnostic output.

This workaround will still typically not work for programs intended for obj format, because the obj SEGMENT and GROUP directives have side effects of defining the segment and group names as symbols; dbg will not do this, so the program will not assemble. You will have to work around that by defining the symbols yourself (using EXTERN, for example) if you really need to get a dbg trace of an obj-specific source file.

dbg accepts any section name and any directives at all, and logs them all to its output file.

Next Chapter | Previous Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdoc1.html0000644000000000000000000002166211026031754016674 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Next Chapter | Contents | Index

Chapter 1: Introduction

1.1 What Is NASM?

The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. It supports a range of object file formats, including Linux and *BSD a.out, ELF, COFF, Mach-O, Microsoft 16-bit OBJ, Win32 and Win64. It will also output plain binary files. Its syntax is designed to be simple and easy to understand, similar to Intel's but less complex. It supports all currently known x86 architectural extensions, and has strong support for macros.

1.1.1 Why Yet Another Assembler?

The Netwide Assembler grew out of an idea on comp.lang.asm.x86 (or possibly alt.lang.asm - I forget which), which was essentially that there didn't seem to be a good free x86-series assembler around, and that maybe someone ought to write one.

So here, for your coding pleasure, is NASM. At present it's still in prototype stage - we don't promise that it can outperform any of these assemblers. But please, please send us bug reports, fixes, helpful information, and anything else you can get your hands on (and thanks to the many people who've done this already! You all know who you are), and we'll improve it out of all recognition. Again.

1.1.2 License Conditions

Please see the file COPYING, supplied as part of any NASM distribution archive, for the license conditions under which you may use NASM. NASM is now under the so-called GNU Lesser General Public License, LGPL.

1.2 Contact Information

The current version of NASM (since about 0.98.08) is maintained by a team of developers, accessible through the nasm-devel mailing list (see below for the link). If you want to report a bug, please read section 11.2 first.

NASM has a WWW page at http://nasm.sourceforge.net. If it's not there, google for us!

The original authors are e-mailable as jules@dsf.org.uk and anakin@pobox.com. The latter is no longer involved in the development team.

New releases of NASM are uploaded to the official sites http://nasm.sourceforge.net and to ftp.kernel.org and ibiblio.org.

Announcements are posted to comp.lang.asm.x86, alt.lang.asm and comp.os.linux.announce

If you want information about NASM beta releases, and the current development status, please subscribe to the nasm-devel email list by registering at http://sourceforge.net/projects/nasm.

1.3 Installation

1.3.1 Installing NASM under MS-DOS or Windows

Once you've obtained the appropriate archive for NASM, nasm-XXX-dos.zip or nasm-XXX-win32.zip (where XXX denotes the version number of NASM contained in the archive), unpack it into its own directory (for example c:\nasm).

The archive will contain a set of executable files: the NASM executable file nasm.exe, the NDISASM executable file ndisasm.exe, and possibly additional utilities to handle the RDOFF file format.

The only file NASM needs to run is its own executable, so copy nasm.exe to a directory on your PATH, or alternatively edit autoexec.bat to add the nasm directory to your PATH (to do that under Windows XP, go to Start > Control Panel > System > Advanced > Environment Variables; these instructions may work under other versions of Windows as well.)

That's it - NASM is installed. You don't need the nasm directory to be present to run NASM (unless you've added it to your PATH), so you can delete it if you need to save space; however, you may want to keep the documentation or test programs.

If you've downloaded the DOS source archive, nasm-XXX.zip, the nasm directory will also contain the full NASM source code, and a selection of Makefiles you can (hopefully) use to rebuild your copy of NASM from scratch. See the file INSTALL in the source archive.

Note that a number of files are generated from other files by Perl scripts. Although the NASM source distribution includes these generated files, you will need to rebuild them (and hence, will need a Perl interpreter) if you change insns.dat, standard.mac or the documentation. It is possible future source distributions may not include these files at all. Ports of Perl for a variety of platforms, including DOS and Windows, are available from www.cpan.org.

1.3.2 Installing NASM under Unix

Once you've obtained the Unix source archive for NASM, nasm-XXX.tar.gz (where XXX denotes the version number of NASM contained in the archive), unpack it into a directory such as /usr/local/src. The archive, when unpacked, will create its own subdirectory nasm-XXX.

NASM is an auto-configuring package: once you've unpacked it, cd to the directory it's been unpacked into and type ./configure. This shell script will find the best C compiler to use for building NASM and set up Makefiles accordingly.

Once NASM has auto-configured, you can type make to build the nasm and ndisasm binaries, and then make install to install them in /usr/local/bin and install the man pages nasm.1 and ndisasm.1 in /usr/local/man/man1. Alternatively, you can give options such as --prefix to the configure script (see the file INSTALL for more details), or install the programs yourself.

NASM also comes with a set of utilities for handling the RDOFF custom object-file format, which are in the rdoff subdirectory of the NASM archive. You can build these with make rdf and install them with make rdf_install, if you want them.

Next Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdocb.html0000644000000000000000000056307711026031755016771 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Previous Chapter | Contents | Index

Appendix B: Instruction List

6.11.3 rdf Extensions to the GLOBAL directive

RDOFF global symbols can contain additional information needed by the static linker. You can mark a global symbol as exported, thus telling the linker do not strip it from target executable or library file. Like in ELF, you can also specify whether an exported symbol is a procedure (function) or data object.

Suffixing the name with a colon and the word export you make the symbol exported: 

    global  sys_open:export

To specify that exported symbol is a procedure (function), you add the word proc or function after declaration: 

    global  sys_open:export proc

Similarly, to specify exported data object, add the word data or object to the directive: 

    global  kernel_ticks:export data

6.11.4 rdf Extensions to the EXTERN directive

By default the EXTERN directive in RDOFF declares a "pure external" symbol (i.e. the static linker will complain if such a symbol is not resolved). To declare an "imported" symbol, which must be resolved later during a dynamic linking phase, RDOFF offers an additional import modifier. As in GLOBAL, you can also specify whether an imported symbol is a procedure (function) or data object. For example: 

    library $libc 
    extern  _open:import 
    extern  _printf:import proc 
    extern  _errno:import data

Here the directive LIBRARY is also included, which gives the dynamic linker a hint as to where to find requested symbols.

6.12 dbg: Debugging Format

The dbg output format is not built into NASM in the default configuration. If you are building your own NASM executable from the sources, you can define OF_DBG in outform.h or on the compiler command line, and obtain the dbg output format.

The dbg format does not output an object file as such; instead, it outputs a text file which contains a complete list of all the transactions between the main body of NASM and the output-format back end module. It is primarily intended to aid people who want to write their own output drivers, so that they can get a clearer idea of the various requests the main program makes of the output driver, and in what order they happen.

For simple files, one can easily use the dbg format like this: 

nasm -f dbg filename.asm

which will generate a diagnostic file called filename.dbg. However, this will not work well on files which were designed for a different object format, because each object format defines its own macros (usually user-level forms of directives), and those macros will not be defined in the dbg format. Therefore it can be useful to run NASM twice, in order to do the preprocessing with the native object format selected: 

nasm -e -f rdf -o rdfprog.i rdfprog.asm 
nasm -a -f dbg rdfprog.i

This preprocesses rdfprog.asm into rdfprog.i, keeping the rdf object format selected in order to make sure RDF special directives are converted into primitive form correctly. Then the preprocessed source is fed through the dbg format to generate the final diagnostic output.

This workaround will still typically not work for programs intended for obj format, because the obj SEGMENT and GROUP directives have side effects of defining the segment and group names as symbols; dbg will not do this, so the program will not assemble. You will have to work around that by defining the symbols yourself (using EXTERN, for example) if you really need to get a dbg trace of an obj-specific source file.

dbg accepts any section name and any directives at all, and logs them all to its output file.

Next Chapter | Previous Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdoc1.html0000644000000000000000000002166211026031754016674 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Next Chapter | Contents | Index

Chapter 1: Introduction

1.1 What Is NASM?

The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. It supports a range of object file formats, including Linux and *BSD a.out, ELF, COFF, Mach-O, Microsoft 16-bit OBJ, Win32 and Win64. It will also output plain binary files. Its syntax is designed to be simple and easy to understand, similar to Intel's but less complex. It supports all currently known x86 architectural extensions, and has strong support for macros.

1.1.1 Why Yet Another Assembler?

The Netwide Assembler grew out of an idea on comp.lang.asm.x86 (or possibly alt.lang.asm - I forget which), which was essentially that there didn't seem to be a good free x86-series assembler around, and that maybe someone ought to write one.

So here, for your coding pleasure, is NASM. At present it's still in prototype stage - we don't promise that it can outperform any of these assemblers. But please, please send us bug reports, fixes, helpful information, and anything else you can get your hands on (and thanks to the many people who've done this already! You all know who you are), and we'll improve it out of all recognition. Again.

1.1.2 License Conditions

Please see the file COPYING, supplied as part of any NASM distribution archive, for the license conditions under which you may use NASM. NASM is now under the so-called GNU Lesser General Public License, LGPL.

1.2 Contact Information

The current version of NASM (since about 0.98.08) is maintained by a team of developers, accessible through the nasm-devel mailing list (see below for the link). If you want to report a bug, please read section 11.2 first.

NASM has a WWW page at http://nasm.sourceforge.net. If it's not there, google for us!

The original authors are e-mailable as jules@dsf.org.uk and anakin@pobox.com. The latter is no longer involved in the development team.

New releases of NASM are uploaded to the official sites http://nasm.sourceforge.net and to ftp.kernel.org and ibiblio.org.

Announcements are posted to comp.lang.asm.x86, alt.lang.asm and comp.os.linux.announce

If you want information about NASM beta releases, and the current development status, please subscribe to the nasm-devel email list by registering at http://sourceforge.net/projects/nasm.

1.3 Installation

1.3.1 Installing NASM under MS-DOS or Windows

Once you've obtained the appropriate archive for NASM, nasm-XXX-dos.zip or nasm-XXX-win32.zip (where XXX denotes the version number of NASM contained in the archive), unpack it into its own directory (for example c:\nasm).

The archive will contain a set of executable files: the NASM executable file nasm.exe, the NDISASM executable file ndisasm.exe, and possibly additional utilities to handle the RDOFF file format.

The only file NASM needs to run is its own executable, so copy nasm.exe to a directory on your PATH, or alternatively edit autoexec.bat to add the nasm directory to your PATH (to do that under Windows XP, go to Start > Control Panel > System > Advanced > Environment Variables; these instructions may work under other versions of Windows as well.)

That's it - NASM is installed. You don't need the nasm directory to be present to run NASM (unless you've added it to your PATH), so you can delete it if you need to save space; however, you may want to keep the documentation or test programs.

If you've downloaded the DOS source archive, nasm-XXX.zip, the nasm directory will also contain the full NASM source code, and a selection of Makefiles you can (hopefully) use to rebuild your copy of NASM from scratch. See the file INSTALL in the source archive.

Note that a number of files are generated from other files by Perl scripts. Although the NASM source distribution includes these generated files, you will need to rebuild them (and hence, will need a Perl interpreter) if you change insns.dat, standard.mac or the documentation. It is possible future source distributions may not include these files at all. Ports of Perl for a variety of platforms, including DOS and Windows, are available from www.cpan.org.

1.3.2 Installing NASM under Unix

Once you've obtained the Unix source archive for NASM, nasm-XXX.tar.gz (where XXX denotes the version number of NASM contained in the archive), unpack it into a directory such as /usr/local/src. The archive, when unpacked, will create its own subdirectory nasm-XXX.

NASM is an auto-configuring package: once you've unpacked it, cd to the directory it's been unpacked into and type ./configure. This shell script will find the best C compiler to use for building NASM and set up Makefiles accordingly.

Once NASM has auto-configured, you can type make to build the nasm and ndisasm binaries, and then make install to install them in /usr/local/bin and install the man pages nasm.1 and ndisasm.1 in /usr/local/man/man1. Alternatively, you can give options such as --prefix to the configure script (see the file INSTALL for more details), or install the programs yourself.

NASM also comes with a set of utilities for handling the RDOFF custom object-file format, which are in the rdoff subdirectory of the NASM archive. You can build these with make rdf and install them with make rdf_install, if you want them.

Next Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdocb.html0000644000000000000000000056307711026031755016771 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Previous Chapter | Contents | Index

Appendix B: Instruction List

6.11.3 rdf Extensions to the GLOBAL directive

RDOFF global symbols can contain additional information needed by the static linker. You can mark a global symbol as exported, thus telling the linker do not strip it from target executable or library file. Like in ELF, you can also specify whether an exported symbol is a procedure (function) or data object.

Suffixing the name with a colon and the word export you make the symbol exported: 

    global  sys_open:export

To specify that exported symbol is a procedure (function), you add the word proc or function after declaration: 

    global  sys_open:export proc

Similarly, to specify exported data object, add the word data or object to the directive: 

    global  kernel_ticks:export data

6.11.4 rdf Extensions to the EXTERN directive

By default the EXTERN directive in RDOFF declares a "pure external" symbol (i.e. the static linker will complain if such a symbol is not resolved). To declare an "imported" symbol, which must be resolved later during a dynamic linking phase, RDOFF offers an additional import modifier. As in GLOBAL, you can also specify whether an imported symbol is a procedure (function) or data object. For example: 

    library $libc 
    extern  _open:import 
    extern  _printf:import proc 
    extern  _errno:import data

Here the directive LIBRARY is also included, which gives the dynamic linker a hint as to where to find requested symbols.

6.12 dbg: Debugging Format

The dbg output format is not built into NASM in the default configuration. If you are building your own NASM executable from the sources, you can define OF_DBG in outform.h or on the compiler command line, and obtain the dbg output format.

The dbg format does not output an object file as such; instead, it outputs a text file which contains a complete list of all the transactions between the main body of NASM and the output-format back end module. It is primarily intended to aid people who want to write their own output drivers, so that they can get a clearer idea of the various requests the main program makes of the output driver, and in what order they happen.

For simple files, one can easily use the dbg format like this: 

nasm -f dbg filename.asm

which will generate a diagnostic file called filename.dbg. However, this will not work well on files which were designed for a different object format, because each object format defines its own macros (usually user-level forms of directives), and those macros will not be defined in the dbg format. Therefore it can be useful to run NASM twice, in order to do the preprocessing with the native object format selected: 

nasm -e -f rdf -o rdfprog.i rdfprog.asm 
nasm -a -f dbg rdfprog.i

This preprocesses rdfprog.asm into rdfprog.i, keeping the rdf object format selected in order to make sure RDF special directives are converted into primitive form correctly. Then the preprocessed source is fed through the dbg format to generate the final diagnostic output.

This workaround will still typically not work for programs intended for obj format, because the obj SEGMENT and GROUP directives have side effects of defining the segment and group names as symbols; dbg will not do this, so the program will not assemble. You will have to work around that by defining the symbols yourself (using EXTERN, for example) if you really need to get a dbg trace of an obj-specific source file.

dbg accepts any section name and any directives at all, and logs them all to its output file.

Next Chapter | Previous Chapter | Contents | Index ./usr/share/doc/nasm/html/nasmdoc1.html0000644000000000000000000002166211026031754016674 0ustar rootrootNASM Manual

The Netwide Assembler: NASM

Next Chapter | Contents | Index

Chapter 1: Introduction

1.1 What Is NASM?

The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. It supports a range of object file formats, including Linux and *BSD a.out, ELF, COFF, Mach-O, Microsoft 16-bit OBJ, Win32 and Win64. It will also output plain binary files. Its syntax is designed to be simple and easy to understand, similar to Intel's but less complex. It supports all currently known x86 architectural extensions, and has strong support for macros.

1.1.1 Why Yet Another Assembler?

The Netwide Assembler grew out of an idea on comp.lang.asm.x86 (or possibly alt.lang.asm - I forget which), which was essentially that there didn't seem to be a good free x86-series assembler around, and that maybe someone ought to write one.

So here, for your coding pleasure, is NASM. At present it's still in prototype stage - we don't promise that it can outperform any of these assemblers. But please, please send us bug reports, fixes, helpful information, and anything else you can get your hands on (and thanks to the many people who've done this already! You all know who you are), and we'll improve it out of all recognition. Again.

1.1.2 License Conditions

Please see the file COPYING, supplied as part of any NASM distribution arc