Your First Assembly Program

The traditional first program in any language prints a greeting and exits, and assembly is no exception — but writing it forces you to confront details a high-level language normally hides entirely, such as exactly how a program talks to the operating system. On Linux x86-64, a program requests OS services through system calls: placing a syscall number in RAX, arguments in RDI, RSI, RDX (and further registers as needed), then executing the syscall instruction, which transfers control to the kernel and returns with a result in RAX. Printing text requires the write syscall (number 1), which needs a file descriptor (1 for standard output) in RDI, a pointer to the bytes to print in RSI, and the byte count in RDX; exiting cleanly requires the exit syscall (number 60), which needs only an exit code in RDI. There is no print() function to call — you are directly issuing the same low-level request that every print statement in every higher-level language eventually boils down to.

A minimal NASM program is organized into sections that tell the assembler and linker how to lay out the final binary. The .data section holds initialized values known at assembly time — a string like msg db 'Hello, Assembly!', 10 stores the literal bytes of the message plus a trailing newline (byte value 10), and equ msg_len, $ - msg computes the string's length automatically by subtracting the label's address from the current position ($). The .text section holds actual instructions, and by Linux convention the label _start marks the program's true entry point — not main, which is a C runtime convention; the linker needs global _start so this symbol is visible outside the file and can be used as the entry point when producing the executable. Every instruction in .text executes strictly in order unless a jump, call, or syscall return redirects control, which is why the exit syscall must appear as literally the last thing the program does — without it, execution would fall off the end of _start into whatever bytes happen to follow in memory, causing a crash.

Producing a runnable program from the source requires the two-stage toolchain covered elsewhere in this course: nasm -f elf64 hello.asm -o hello.o assembles the source into an ELF object file, encoding each mnemonic into its machine-code bytes and recording the _start symbol so it's visible to the linker; ld hello.o -o hello then links that single object file into a final executable, since this minimal program makes no external library calls and therefore has no unresolved symbols to worry about. Running ./hello executes the binary directly — the Linux kernel's ELF loader maps the file's sections into a fresh process's address space, sets RIP to the _start label's address, and execution begins exactly where you wrote it to begin. Checking echo $? immediately afterward reveals the process's exit code, which is precisely the value you placed in RDI right before the exit syscall — a concrete, observable confirmation that the assembly you wrote is genuinely controlling the CPU end to end, with no runtime or interpreter standing between your instructions and the hardware.