Introduction: Welcome to the World of Assembly Source Files
Let me tell you something that took me years to fully appreciate: an assembly source file is not just a list of instructions. It’s a carefully structured document that tells the assembler not just what to do, but how to organize your program in memory, where to place your data, and how to resolve symbols across multiple files. If you’ve ever looked at an assembly file and felt like you were reading ancient hieroglyphics, you’re not alone — but by the end of this article, you’ll be reading them like poetry.
In this article — the sixth in our series — we’re going to tear apart the anatomy of an assembly source file and examine every organ, every cell, and every DNA strand. We’ll look at sections, directives, pseudo-instructions, and all those weird bracket-heavy syntax differences between NASM and MASM that make you wonder if Intel and AT&T were having some kind of typographical war.
Grab a coffee. This is going to be a deep dive.
The Anatomy of an Assembly Source File: Sections, Directives, Instructions — What’s What
When you open a well-written assembly source file (let’s say a .asm file), you’re looking at three distinct categories of content, and confusing them is like confusing nouns, verbs, and punctuation in a sentence. Let me break it down for you.
Instructions: The Actual Machine Code
Instructions are what the CPU actually executes. They’re the verbs of your program. When you write MOV AX, 5, you’re telling the assembler to emit machine code that loads the value 5 into the AX register. Instructions become actual bytes in your executable file — they take up space in the .text or .code section.
Here’s what an instruction looks like:
MOV AX, 5 ; This becomes machine code: B8 05 00 (for 16-bit)
ADD BX, CX ; This becomes machine code: 03 D9
JMP somewhere ; This becomes machine code: E9 xx xx (relative jump)
Every instruction has a one-to-one (or sometimes one-to-many) relationship with machine code bytes. The assembler’s job is to translate these human-readable mnemonics into the binary patterns that the CPU’s decode unit expects.
Directives (Pseudo-Instructions): Instructions to the Assembler Itself
Here’s where things get interesting. Directives — also called pseudo-instructions — are commands that you give to the assembler, not to the CPU. They don’t become machine code. Instead, they control how the assembler organizes your code, allocates memory, defines symbols, or includes other files.
Think of directives as the “meta-language” of assembly programming. They’re instructions about instructions.
Here are some common directives you’ll encounter:
.DATA ; Directive: start the data section
.CODE ; Directive: start the code section
DB 10 ; Directive: define a byte with value 10
DW 1000 ; Directive: define a word (2 bytes) with value 1000
MSG DB 'Hello', 0 ; Directive: define a string of bytes
None of these become executable code. Instead, they tell the assembler: “Hey, reserve some space here” or “Put this data at this address” or “This is where the code section starts.”
Sections (Segments): The Organizational Backbone
Sections — sometimes called segments in the 16-bit world — are the major organizational units of your assembly program. They’re like the chapters of a book, except each chapter goes into a different part of memory when your program runs.
In modern assembly (32-bit and 64-bit), we typically use these sections:
.text(or.code): Where your executable instructions go. This is typically marked read-only and executable..data: Where your initialized global and static variables go. Read-write, not executable..bss: Where your uninitialized variables go. The assembler doesn’t actually allocate space in the file; it just records how much space the program will need at runtime..rodata: Read-only data, like string constants. This goes in a section that’s readable but not writable.
In 16-bit DOS assembly (MASM/TASM), you’ll see segments instead of sections:
DATA SEGMENT
MSG DB 'Hello, World!$'
DATA ENDS
CODE SEGMENT
ASSUME CS:CODE, DS:DATA
START:
; code here
CODE ENDS
The difference between “segments” and “sections” is mostly terminology — segments are the 16-bit real mode concept, while sections are the modern ELF/PE concept — but they serve the same organizational purpose.
The Full Anatomy: Putting It All Together
Here’s what a complete, well-structured assembly source file looks like:
; ============================================
; Complete Assembly Source File Example
; ============================================
; ---- Directive area: Tell the assembler what processor we're targeting
.386 ; Enable 32-bit instructions
.MODEL FLAT, C ; Flat memory model, C calling convention
; ---- Data section: All our variables go here
.DATA
prompt DB 'Enter your name: ', 0
greeting DB 'Hello, ', 0
userName DB 100 DUP(?) ; Reserve 100 bytes for user input
nameLen DD 0 ; 32-bit integer for name length
; ---- Uninitialized data section
.BSS
buffer RESB 256 ; Reserve 256 bytes, uninitialized
; ---- Code section: All our instructions go here
.CODE
; ---- Our main procedure
main PROC
; Set up the data segment
MOV EAX, @DATA ; Get the data segment address
MOV DS, EAX ; Load it into DS
; Call a function to print the prompt
PUSH OFFSET prompt ; Push address of prompt string
CALL printf ; Call C library's printf
ADD ESP, 4 ; Clean up the stack (cdecl calling convention)
; Read user input (simplified - would use fgets in real code)
PUSH OFFSET userName
CALL gets
ADD ESP, 4
; Print greeting
PUSH OFFSET greeting
CALL printf
ADD ESP, 4
; Print user's name
PUSH OFFSET userName
CALL printf
ADD ESP, 4
; Exit
PUSH 0
CALL exit
main ENDP
; ---- End of file
END main
Every line in this file serves a purpose. The directives (.386, .MODEL, .DATA, .CODE) tell the assembler how to organize things. The DB, DD, DUP(?) pseudo-instructions define data. The MOV, PUSH, CALL, ADD instructions become machine code. And the PROC and ENDP keywords define procedure boundaries.
Understanding this anatomy is crucial because when something goes wrong — and something will go wrong — you need to know whether the problem is in your instructions, your directives, or your section definitions.
