TEMPLATE
RAM SEGMENTS
Stack: Local variables and function call management; grows downwards.
To easily visualize how the call stack grows in memory, imagine an icicle forming on a rooftop. The rooftop represents high memory addresses (e.g.,
0xFFFFFF), while the tip of the icicle represents low memory addresses. As water drips and freezes, the icicle grows downward, extending farther from the roof. The stack behaves the same way: each new function call pushes (adds) a new stack frame downward (lower) in memory, toward lower addresses, just like an icicle lengthening toward its tip.
Heap: Dynamically allocated memory (e.g., via
malloc); grows upwards..bss (block started by symbol - READ/WRITE): Stores uninitialized global/static variables (they get zero-initialized by OS).
.data (initialized data - READ/WRITE - NOT EXECUTABLE): Stores initialized global and static variables.
.text (code section - READ-ONLY - EXECUTABLE): Contains program instructions; usually at the lowest addresses.
X86: GCC METHOD
;*######################################################################################
; Dev: cnd.dev
; Program Name: FileName-v1.0.0-linux-x86-64
; Version: 1.0.0 //Major.Minor.Update
; Date: 181445MAR25
; Filename: filename.c
; Dependency: N/A
; Compile Cmd: gcc -m64 -O1 filename.c -o filename-v1.0.0-linux-x86-64
; Synopsis: ...
; - Overview: describes what the program does, how it works, and its key components
; - Technical: ...
;#####################################################################################*/
;INCLUDE FILES
section .bss
; uninitialized data
section .data
; initialized data
section .text
global _start ; Entry point for the program (used by linker)
_start:
; ********** FUNCTION PROLOGUE *********
push ebp ; Save base pointer of the previous stack frame
mov ebp, esp ; Establish a new stack frame for this function
; ********** CODE STARTS HERE **********
end:
; *********** CODE ENDS HERE ***********
mov eax, 0 ; Set return value to 0 (success)
mov esp, ebp ; Restore original stack pointer
pop ebp ; Restore previous base pointer
ret ; Return from _start (only valid if this is called as a function)X64: NASM METHOD
;*######################################################################################
; Dev: cnd.dev
; Program Name: FileName-v1.0.0-linux-x86-64
; Version: 1.0.0 ; Major.Minor.Update
; Date: 181445MAR25
; Filename: filename.asm
; Dependency: N/A
; Compile Cmd: nasm -f elf64 filename.asm -o filename.o && ld filename.o -o filename-v1.0.0-linux-x86-64
; Synopsis:
; - Overview: describes what the program does, how it works, and its key components
; - Technical: ...
;######################################################################################*/
; SECTION: INCLUDE FILES
; Declare printf as an external function (from libc)
section .bss
; Uninitialized data (e.g., buffers, counters)
section .data
; Initialized data (e.g., strings, format specifiers)
; Code section (actual instructions)
section .text
; Make the _start label visible to the linker
global _start
; Entry point of the program
_start:
; ********** CODE STARTS HERE **********
; Example: write "Hello\n" to stdout
mov rax, 1 ; syscall: write
mov rdi, 1 ; file descriptor: stdout
mov rsi, message ; pointer to message
mov rdx, message_len ; message length
syscall
; Exit
mov rax, 60 ; syscall: exit
xor rdi, rdi ; status: 0
syscall
; *********** CODE ENDS HERE ***********
; SECTION: DATA
section .data
message db "Hello, world!", 10
message_len equ $ - message
X64: W/ FUNCTIONS
The ordering of section directives in my assembly source may differ from the conventional .data, .bss, .text layout typically used by others. This is intentional, as the arrangement serves purely as a visualization aid. Placing .bss, .data, and .text in a custom order helps me mentally associate each memory section with my own conceptual model of how a program is represented in memory. Although the assembler and linker ultimately determine the true physical layout, organizing the sections in a way that aligns with my personal understanding allows me to more clearly internalize how each region is defined, how they differ in purpose, and how they relate to one another within a process’s memory space. This approach enhances my comprehension while leaving the actual binary structure unchanged.
extern printf
section .bss
section .data
radius dq 10.0
section .text
;----------------------------------------------
area:
section .data
.pi dq 3.141592654 ; local to area
section .text
push rbp
mov rbp, rsp
movsd xmm0, [radius]
mulsd xmm0, [radius]
mulsd xmm0, [.pi]
leave
ret
;----------------------------------------------
circum:
section .bss
section .data
.pi dq 3.14 ; local to circum
section .text
push rbp
mov rbp, rsp
movsd xmm0, [radius]
addsd xmm0, [radius]
mulsd xmm0, [.pi]
leave
ret
;----------------------------------------------
circle:
section .bss
section .data
.fmt_area db "The area is %f",10,0
.fmt_circum db "The circumference is %f",10,0
section .text
push rbp
mov rbp, rsp
call area
mov rdi,.fmt_area
mov rax,1 ; area in xmm0
call printf
call circum
mov rdi,.fmt_circum
mov rax,1 ; circumference in xmm0
call printf
leave
ret
;----------------------------------------------
global main
main:
push rbp
mov rbp, rsp
call circle
leave
retLast updated