Community hub
0 subscribers8 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Netwide Assembler.
Nothing was collected or created yet.
Netwide Assembler
View on Wikipediafrom Wikipedia
 |
| NASM | |
|---|---|
 | |
| Original authors | Simon Tatham, Julian Hall |
| Developers | H. Peter Anvin, Chang Seok Bae, Jim Kukunas, Frank B. Kotler, Cyrill Gorcunov |
| Initial release | October 1996 |
| Stable release | 3.01[1] 
/ 11 October 2025 |
| Repository | |
| Written in | Assembly, C[2] |
| Operating system | Unix-like, Windows, OS/2, MS-DOS |
| Available in | English |
| Type | x86 assembler |
| License | BSD 2-clause |
| Website | nasm.us |
The Netwide Assembler (NASM) is an assembler and disassembler for the Intel x86 architecture. It can be used to write 16-bit, 32-bit (IA-32) and 64-bit (x86-64) programs. It is considered one of the most popular assemblers for Linux and x86 chips.[3]
It was originally written by Simon Tatham with assistance from Julian Hall. As of 2016[update], it is maintained by a small team led by H. Peter Anvin.[4] It is open-source software released under the terms of a simplified (2-clause) BSD license.[5]
Features
[edit]NASM can output several binary formats, including COFF, OMF, a.out, Executable and Linkable Format (ELF), Mach-O and binary file (.bin, binary disk image, used to compile operating systems), though position-independent code is supported only for ELF object files. It also has its own binary format called RDOFF.[6]
The variety of output formats allows retargeting programs to virtually any x86 operating system (OS). It can also create flat binary files, usable to write boot loaders, read-only memory (ROM) images, and in various facets of OS development.[6] It can run on non-x86 platforms (if NASM itself is compiled for that platform) as a cross assembler, such as PowerPC and SPARC, though it cannot generate programs usable by those machines.
NASM uses a variant of Intel assembly syntax instead of AT&T syntax.[7] It also avoids features such as automatic generation of segment overrides (and the related ASSUME directive) used by MASM and compatible assemblers.[6]
Development
[edit]NASM version 0.90 was released in October 1996.[5]
Version 2.00 was released on 28 November 2007, adding support for x86-64 extensions.[4] The development versions are not uploaded to SourceForge.net, but are checked into GitHub with binary snapshots available from the project web page.
In July 2009, as of version 2.07, NASM was released under the Simplified (2-clause) BSD license. Previously, because it was licensed under LGPL, it led to development of Yasm, a complete rewrite of under the New BSD License. Yasm offered support for x86-64 earlier than NASM. It also added support for GNU Assembler syntax.
RDOFF
[edit]Relocatable Dynamic Object File Format (RDOFF) is used by developers to test the integrity of NASM's object file output abilities. It is based heavily on the internal structure of NASM,[8] essentially consisting of a header containing a serialization of the output driver function calls followed by an array of sections containing executable code or data. Tools for using the format, including a linker and loader, are included in the NASM distribution.
Until version 0.90 was released in October 1996, NASM supported output of only flat-format executable files (e.g., COM files). In version 0.90, Simon Tatham added support for an object-file output interface, and for DOS .OBJ files for 16-bit code only.[9]
NASM thus lacked a 32-bit object format. To address this lack, and as an exercise to learn the object-file interface, developer Julian Hall put together the first version of RDOFF, which was released in NASM version 0.91.[9]
Since this initial version, there has been one major update to the RDOFF format, which added a record-length indicator on each header record,[10] allowing programs to skip over records whose format they do not recognise, and support for multiple segments; RDOFF1 only supported three segments: text, data and bss (containing uninitialized data).[8]
The RDOFF format is strongly deprecated and has been disabled starting in NASM 2.15.04.[11]
See also
[edit]
References
[edit]- ^ https://www.nasm.us/docs/3.01/nasmac.html.
{{cite web}}: Missing or empty|title=(help) - ^ "NASM, the Netwide Assembler". GitHub. 25 October 2021.
- ^ Ram Narayan. "Linux assemblers: A comparison of GAS and NASM". IBM. Archived from the original on 3 October 2013.
two of the most popular assemblers for Linux, GNU Assembler (GAS) and Netwide Assembler (NASM)
- ^ a b "The Netwide Assembler". Retrieved 27 June 2008.
- ^ a b "NASM Version History". Retrieved 3 August 2019.
- ^ a b c "NASM Manual". Archived from the original on 23 February 2009. Retrieved 15 August 2009.
- ^ Randall Hyde. "NASM: The Netwide Assembler". Archived from the original on 12 September 2010. Retrieved 27 June 2008.
- ^ a b "NASM Manual Ch. 6". Retrieved 27 June 2008.
- ^ a b "NASM CVS". 8 June 2008. Retrieved 27 June 2008.
- ^ "V1-V2.txt". 4 December 2002. Retrieved 27 June 2008.
- ^ "Relocatable Dynamic Object File Format (deprecated)".
Further reading
[edit]- Jeff Duntemann (2000). Assembly Language Step by Step. J Wiley and Sons. ISBN 0-471-37523-3.
External links
[edit]- Official website
- Netwide Assembler on SourceForge
- Special edition for Win32 and BeOS.
- A comparison of GAS and NASM at IBM
- "Netwide Assembler". Freecode.: a converter between the source format of the assemblers NASM and GAS
Netwide Assembler
View on Grokipediafrom Grokipedia
History
Origins
The Netwide Assembler (NASM) was founded by Simon Tatham and Julian Hall in 1996 as an open-source project aimed at addressing the limitations of proprietary assemblers like Microsoft's MASM, which were often restricted to specific platforms and lacked broad portability. By designing NASM for modularity and cross-platform compatibility, the creators sought to enable developers to assemble x86 code across diverse environments without vendor lock-in.[4] The project's initial release, version 0.90, arrived in October 1996, introducing the first stable iteration with core support for 16-bit and 32-bit x86 instructions. This version focused on essential features like object file output, making it suitable for DOS and early Windows systems, while its modular architecture laid the groundwork for compatibility with Unix-like operating systems through flexible format handling.[5] From its outset, NASM found early traction among hobbyist programmers and open-source enthusiasts, who valued its free availability and simplicity for crafting low-level system code, such as bootloaders and utilities, independent of commercial tools.[6]Key Milestones
The Netwide Assembler (NASM) achieved a significant advancement with the release of version 2.00 on November 28, 2007, which introduced full support for the x86-64 (AMD64) architecture and enhanced output capabilities for the ELF format, enabling more robust 64-bit assembly on Unix-like systems.[2][7] This version marked the beginning of the NASM 2 series, which served as the stable production branch until 2025, broadening its applicability in modern operating systems and compilers.[2] In 2016, H. Peter Anvin assumed the role of lead maintainer, bringing stability to the project after the original developers, including Simon Tatham and Julian Hall who founded NASM in 1996, reduced their involvement.[1] This transition ensured continued reliability and fostered incremental improvements in the assembler’s core functionality. The NASM 3.00 series represented a major architectural evolution by incorporating support for Intel's APX instruction encodings, which extend general-purpose registers (GPRs) for improved performance in advanced x86 workloads, alongside preprocessor enhancements designed to better handle dynamic and evolving codebases.[2] These updates positioned NASM to accommodate emerging Intel extensions like AVX10, maintaining its relevance in high-performance computing environments.[8] Culminating the initial 3.00 efforts, version 3.01 was stably released on October 11, 2025, addressing bug fixes and enhancements such as instruction encoding corrections and new preprocessor functions.[1][2] This release solidified the 3 series as the current production standard, emphasizing portability across diverse hardware ecosystems.[2]Technical Features
Syntax and Directives
The Netwide Assembler (NASM) employs an Intel-style syntax for assembly language instructions, which differs from the AT&T syntax used by GNU Assembler (GAS) by omitting percent signs for registers and using a destination-source operand order. For instance, the instruction to move the value from register EBX to EAX is written asmov eax, ebx in NASM, rather than movl %ebx, %eax in AT&T syntax. This convention aligns with documentation from Intel and simplifies readability for developers familiar with x86 processor manuals.[9]
NASM source lines follow a flexible layout consisting of optional label, instruction or directive, operands, and comments separated by semicolons. Labels end with a colon (optional in some contexts), and lines can be continued using a backslash. Valid label characters include alphanumeric symbols, underscores, and special characters like $, #, @, ~, ., and ?, with a maximum length of 4095 characters. Whitespace is ignored except to separate tokens, enabling compact or verbose coding styles.[10]
Key directives facilitate code organization and repetition. The SECTION directive defines segments for code, data, or other purposes, such as section .text for executable instructions or section .data for initialized variables, promoting modular structure across object files. The EQU directive assigns constants without reserving memory, as in msglen equ $-message to compute string lengths at assembly time. For generating repeated data or instructions, TIMES repeats the following element a specified number of times, exemplified by times 64 db 0 to fill 64 bytes with zeros, which is useful for aligning data or initializing buffers.[11][12]
NASM's preprocessor provides robust capabilities for conditional assembly and macro expansion, enhancing code portability and maintainability. Conditional directives like %if, %elif, %else, and %endif evaluate expressions at preprocessing time to include or exclude code blocks, such as %if 1 db 'yes' %else db 'no' %endif for simple branching. File inclusion via %include "filename.inc" allows modular source organization by embedding external files. Macro definitions use %define for single-line substitutions, like %define foo bar to replace foo with bar, while multi-line macros are declared with %macro and %endmacro, supporting parameters and local labels for complex templates. Additionally, the preprocessor handles arithmetic expressions and string manipulation within macros, enabling dynamic computations like %define param1 5 followed by %assign result param1 * 2. These features support Intel-style conventions throughout, including in macro expansions.[13][14]
Output Formats
NASM supports a variety of output formats to ensure compatibility across different operating systems and use cases, allowing users to generate object files or executables suitable for linking, loading, or direct execution.[15] The flat binary format, specified as-f bin, produces pure binary output files with a default extension of none, ideal for direct ROM loading, MS-DOS .COM or .SYS files, and bootloaders or operating system code. This format includes no metadata or relocation information, relying on directives like ORG for specifying the program origin and supporting sections for organized code and data placement. It defaults to 16-bit mode but can handle 32-bit or 64-bit code via the BITS directive. Related formats include Intel Hex (-f ith, extension .ith) and Motorola S-Record (-f srec, extension .srec), which encode the flat memory image from binary sections for use in embedded systems and firmware programming.[16][17][18]
For legacy DOS and OS/2 environments, the OMF (Object Module Format) output via -f obj generates .obj files compatible with Microsoft linkers, supporting both 16-bit and 32-bit code with segments and groups. A variant, -f obj2 (introduced in version 3.01, 2025), targets OS/2 32-bit systems, defaulting to 32-bit mode and grouping segments into FLAT.[19][2]
For early Unix-like systems, NASM offers the a.out format via -f aout (or -f aoutb for BSD variants like NetBSD, FreeBSD, and OpenBSD), generating object files with a .o extension that conform to the traditional Unix executable and linking format. This format supports standard sections such as .text, .data, and .bss, and is suitable for legacy Linux and Minix environments, though it lacks modern features like position-independent code in basic configurations.[20][21]
The COFF (Common Object File Format) output, invoked with -f coff, targets DJGPP and other DOS extenders, producing .o files for 32-bit code linking, while the related -f win32 and -f win64 formats generate COFF-compatible objects for Microsoft Windows environments, with .obj extensions. These support sections like code, data, rdata, and bss, enabling integration with Windows linkers for both 32-bit and 64-bit x86 applications, including position-independent code via wrt ..imagebase in 64-bit mode.[22][23][24]
Modern Linux and Unix systems utilize the ELF (Executable and Linkable Format) through -f elf32, -f elf64, or -f elfx32, outputting .o files that include rich metadata for dynamic linking, shared libraries, and executables. This format accommodates attributes like alloc, exec, write, and tls for sections, with support for position-independent code using WRT directives, making it the default choice for contemporary x86 development on these platforms. Since version 3.0 (2025), ELF supports sparse output files to efficiently handle large uninitialized regions if the host OS allows.[25][2]
For macOS, the Mach-O format is available via -f macho32 or -f macho64, producing .o files compatible with Apple's linker, using a "segment,section" naming convention and flags such as data, code, and bss to define memory properties. This ensures seamless integration into macOS X binaries and bundles. Since version 3.0 (2025), Mach-O also supports sparse output files.[26][2]
As a legacy format, RDOFF (Relocatable Dynamic Object File Format) was once used for DOS debugging and simple relocation in flat or segmented code but has been deprecated due to obsolescence and replacement by formats like ELF and OMF. It was disabled in NASM version 2.15.04, released in August 2020, after being broken since at least version 2.14, with full removal of support and tools occurring in version 2.16.[27][28]
NASM's cross-platform capabilities extend to its output generation, as the assembler compiles on any platform supporting ANSI C, including non-x86 hosts like PowerPC or ARM processors, yet can produce binaries targeted at x86 architectures without host architecture dependencies.[15]
Usage
Assembly Process
The assembly process in NASM begins with invoking the assembler from the command line to translate assembly source code into an object file or executable. The basic syntax isnasm [options] input.asm, where the -f option specifies the output format, such as -f elf64 for 64-bit ELF objects on Linux, and -o designates the output file, as in nasm -f elf64 input.asm -o output.o[29]. This generates a relocatable object file suitable for linking; for instance, the resulting output.o can then be linked into an executable using a tool like ld, such as ld -o program output.o[29]. NASM supports a variety of output formats, including bin for flat binaries and win64 for Windows PE files, allowing flexibility across operating systems[29].
NASM performs symbol resolution through a multi-pass mechanism, typically requiring at least two passes to handle forward references and undefined labels: the first pass scans the source to build a symbol table, while subsequent passes resolve addresses and generate code. With the default optimization level (-Ox), NASM employs additional passes to minimize code size by optimizing branch offsets and immediate values, continuing until no further improvements are made or a limit is reached via the --limit-passes option[30]. Errors during this process, such as undefined labels or syntax issues, are reported to stderr with details including file name, line number, and error message; for example, an undefined symbol triggers a fatal error halting assembly, while warnings for potential issues like orphaned labels can be enabled with -w+label-orphan and treated as errors using -w+error[31].
Optimization flags allow users to balance code size, speed, and assembly time. The -O option controls this: -O0 disables optimization for faster assembly akin to older NASM versions, -O1 applies minimal changes like signed byte immediates, and -Ox (default since version 2.09) enables full multi-pass optimization for compact output, with -Ov displaying the number of passes executed[30]. For debugging, the -g flag generates debug information in DWARF format by default, embeddable in the object file for use with tools like GDB, and can be combined with -F dwarf to explicitly select the format among options like stabs or CV8[32]. These features ensure NASM's assembly process is robust for both development and production workflows.
Companion Tools
The Netwide Disassembler (ndisasm) serves as a key companion tool to NASM, enabling the conversion of x86 binary files back into readable assembly code by leveraging the same instruction table as the assembler.[33] This utility is particularly valuable for reverse-engineering tasks, where it processes raw binary data without requiring support for complex object file formats like ELF, focusing instead on flat binaries commonly found in legacy systems or embedded environments.[33] To use ndisasm, users specify the bit width of the target code with the-b option, followed by the input file, and redirect output to an assembly file; for example, the command ndisasm -b 32 input.bin > output.asm disassembles a 32-bit binary into Intel-syntax assembly code.[33] Additional options enhance flexibility, such as -o to set the input origin address (e.g., -o 100h for DOS .COM files loaded at offset 0x100) or -i for automatic synchronization on PC-relative jumps to improve disassembly accuracy in mixed code and data sections.[33]
In debugging workflows, ndisasm integrates seamlessly for analyzing DOS executables, boot sectors, or firmware images, allowing developers to inspect machine code independently of NASM's full assembly capabilities.[33] For instance, it can handle 16-bit code in legacy .COM programs or 64-bit firmware binaries, providing a lightweight alternative to more comprehensive tools like objdump for targeted reverse-engineering without parsing structured formats.[33]
Development
Core Team and Licensing
The Netwide Assembler (NASM) is currently maintained by a core development team led by H. Peter Anvin, a software engineer at Intel Corporation, with active contributions from developers including Cyrill Gorcunov, Sheng Yongjie, and Maciej Wieczor-Retman.[1] This leadership structure supports ongoing enhancements and bug fixes, drawing on a broader global community of programmers who participate through open-source collaboration.[34] Originally initiated by Simon Tatham and Julian Hall in the 1990s, the project has evolved under Anvin's guidance to ensure portability and modularity across x86 architectures.[1] In July 2009, with the release of version 2.07, NASM transitioned from the GNU Lesser General Public License (LGPL) to the 2-clause BSD license, a permissive open-source license that allows free use, modification, and distribution, including in proprietary software, provided the original copyright notice and disclaimer are retained.[2][35] This change, also known as the Simplified BSD License, simplified redistribution by removing copyleft requirements, thereby increasing NASM's adoption in diverse commercial and academic environments.[36] NASM's development is hosted on GitHub under the repository netwide-assembler/nasm, where over 66 contributors collaborate on code, documentation, and testing.[34] The platform facilitates issue tracking through GitHub's integrated tools, enabling users to report bugs, propose features, and review pull requests, while release management follows a structured process with stable versions, release candidates, and pre-releases announced via the official website.[1] This governance model emphasizes community involvement and rigorous peer review to maintain the assembler's reliability and cross-platform compatibility.[34]Recent Enhancements
The NASM 3 series, introduced in version 3.00 on October 3, 2025, marks a significant evolution by incorporating support for Intel's Advanced Performance Extensions (APX). This includes encodings for extended general-purpose registers (GPRs) and new opcodes designed to boost computational efficiency in x86 assembly code.[2][8] Preprocessor enhancements in the 3 series streamline code development and maintenance. Key additions include new functions like%find(), %pathsearch(), and %realpath() for advanced string and path operations, alongside directives such as %iffile for conditional file checks and %note for inline annotations. These upgrades improve expression evaluation and loop constructs, including more robust %rep/%endrep mechanisms, enabling developers to evolve assembly macros with greater flexibility and reduced complexity.[2]
Version 3.01, released on October 11, 2025, builds on these foundations with additional enhancements including a new obj2 version of the obj output format for improved OS/2 compatibility and the %selbits() preprocessor function for segment bit selection.[2][1]