Welcome to XCODX Online Compiler
Quick Start:
Ctrl+Enter Run code
Ctrl+S Save / Download
Ctrl+L Clear output
Select a language and start coding.
NASM x86-64 is the Netwide Assembler targeting the 64-bit amd64 architecture that modern Intel and AMD PCs and servers run. It shares NASM's clean Intel syntax with the 32-bit tool but exposes the 64-bit machine: sixteen general-purpose registers (`rax`, `rbx`, `rcx`, `rdx`, `rsi`, `rdi`, `rsp`, `rbp`, and `r8`-`r15`), 64-bit addressing, and the dedicated `syscall` instruction for entering the kernel. This is the assembly you meet in today's compiler output, disassemblers, and CTF challenges, and the level at which the System V calling convention decides how arguments travel in registers. As with all assembly there is no built-in library, so input and output happen through raw Linux system calls. On XCODX your source is assembled to a 64-bit ELF object and linked into a Linux executable, with the assembler version shown in the badge above the editor.
; NASM x86-64: write to stdout via the syscall instruction
section .data
msg db "Hello from x86-64 assembly!", 10
len equ $ - msg
section .text
global _start
_start:
mov rax, 1 ; sys_write
mov rdi, 1 ; fd = stdout
mov rsi, msg ; buffer address
mov rdx, len ; byte count
syscall
mov rax, 60 ; sys_exit
xor rdi, rdi ; status 0
syscallx86-64 assembly is for working where real modern software runs: reading what a C or Rust compiler emitted, tightening a hot inner loop, reverse engineering, CTF and exploit work, and learning the System V ABI that governs register-passed arguments and the stack. On XCODX the toolchain assembles and links your program so that `syscall`-based I/O — `write` with `rax` = 1, `read` with `rax` = 0, `exit` with `rax` = 60 — runs exactly as on a normal x86-64 Linux system, and stdin you type reaches your `read` buffer. There is no libc and no way to add libraries, so all formatting and parsing is manual and even trivial tasks take several instructions, which is deliberate. It fits study, small routines, and understanding the machine, not building full applications.
On x86-64 you use the `syscall` instruction instead of `int 0x80`, put the call number in `rax`, and pass arguments in `rdi`, `rsi`, `rdx`, `r10`, `r8`, and `r9`. The numbers differ too — `write` is 1, `read` is 0, `exit` is 60 — so 32-bit examples do not port over unchanged.
Use the `read` syscall: `rax` = 0, `rdi` = 0 for stdin, `rsi` = a buffer address, `rdx` = the maximum bytes to read, then `syscall`. Type the input into the Stdin Box on XCODX so it reaches the call. The bytes land in your buffer as raw text — usually with a trailing newline — which you then interpret yourself.
Under the System V ABI, `rbx`, `rbp`, and `r12`-`r15` are callee-saved, while `rax`, `rcx`, `rdx`, `rsi`, `rdi`, and `r8`-`r11` may be clobbered by a call. The `syscall` instruction additionally destroys `rcx` and `r11`, so never keep a live value in those across a syscall.
Your object is linked directly, without the C runtime that normally calls `main()`, so execution begins at `_start`. There is nothing to return to, so finish with the `exit` syscall (`rax` = 60, status in `rdi`); otherwise the CPU keeps executing past your code and faults.
No. The sandbox provides no libc, no packages, and no network, so you have only CPU instructions and raw syscalls. Formatting numbers, measuring strings, and allocating memory are all things you implement, which is the reality of programming at this level.
Very nearly. Compilers emit x86-64 in this same instruction set, though they follow the full ABI, link against libc, and optimize heavily, so their output is denser than hand-written examples. Assembling by hand here is a good way to read and understand that generated code — try compiling a small C function and comparing.
main.asmgassys_read syscall; NASM 64-bit Assembly
section .data
msg db "Hello from NASM 64-bit!", 0xA
len equ $ - msg
section .text
global _start
_start:
mov rax, 1
mov rdi, 1
mov rsi, msg
mov rdx, len
syscall
mov rax, 60
xor rdi, rdi
syscall