This content originally appeared on Level Up Coding - Medium and was authored by Tarun Chandragiri
How Your Program Actually Runs: From C to CPU.
The complete journey from compilation to hardware execution.
Ever wonder how your computer understands int x = 5;?
you type English-like words, hit compile, and somehow billions of microscopic switches start working in perfect harmony. It sounds like magic — but it’s actually an incredible chain of translations.
The fundamental puzzle: Computers only understand electricity — voltage high or voltage low, current flowing or not flowing. But we write programs using text, words & symbols.
How does your computer bridge this massive gap?
How do English-like programming languages become electrical patterns that hardware can actually process?
Today, we’re tracing that complete journey - from hitting “compile” to electrons moving in your processor. We’ll peel back each layer of abstraction, revealing how software and hardware teams up to run your programs.
Layer 1 : Writing Human-Readable Code (Your C Program)
Let’s start with something simple - your C code sitting in a .c file:
#include <stdio.h>
int main() {
int x = 5;
int y = 10;
int sum = x + y;
printf("Sum is: %d\n", sum);
return 0;
}
This looks perfectly readable to you, right ? Variables have simple names like x , y & Sum . We’re doing basic arithmetic — adding two numbers. Then we print the result. But your CPU has absolutely no idea what any of this means. Your processor doesn’t speak English. It doesn’t know what “Sum” means or what Printf does. It only understands patterns of electrical signals 0’s & 1's.
That’s where the first transformation begins, and it’s more interesting than you might think.
Layer 2: The Preprocessor Explodes Your 8 Lines Into Thousands
Before any real compilation happens , the preprocessor quietly does some behind-the-scenes work on your .c file. Think of it as your code’s personal assistant, handling all the “#” commands.
When the preprocessor sees #include <stdio.h> , it doesn’t just ignore it — it literally copies the entire stdio.h file (thousands of lines of function declarations) and pastes it right at the top of your code. But here’s the important part: it only brings in declarations like int printf(const char *format, ...); — think of these as “promises” that printf exists somewhere. The actual printf code still lives in a separate library file.
The preprocessor also handles #define statements, replaces macros, and processes conditional compilation directives. What comes out is a .i file - pure C code with no more "#" directives, just thousands of lines of expanded, ready-to-compile C code.
So your cute little addition program!! It’s now sitting in a file that’s probably 50KB+ in size. But every line is still human-readable C code — just a lot more of it. Ready for the real translation to begin?
Layer 3: The Compiler — From English to Assembly
Now comes the heavy lifting. The compiler takes your expanded .i file and performs the first major translation — converting your English-like code into assembly language, saved as a .s file.
Let’s see what happens to our simple addition:
Your C code :
int sum = x + y;
Becomes assembly (x86):
movl -8(%rbp), %eax ; Load x into register eax
addl -4(%rbp), %eax ; Add y to eax
movl %eax, -12(%rbp) ; Store result in sum
Notice something ? We’ve lost all our meaningful variable names. No more x , y or Sum just cryptic instructions like movl and addl , working with CPU registers like %eax and memory locations like -8(%rbp) .
The compiler has done the hard job of figuring out how to make your logic work with actual CPU instructions. But we’re still not at the finish line-this assembly code is still somewhat human-readable. Your CPU needs something even more basic.
Layer 4 : The Assembler — From words to Numbers
The assembler takes your .s assembly file and converts those human-readable mnemonics into pure binary machine code, creating an .o object file. This is where things get really interesting.
Remember our assembly instruction ?
movl -8(%rbp), %eax
The assembler converts this into raw hexadecimal:
8B 45 F8
Which is actually this in binary:
10001011 01000101 11111000
Now we’re talking the CPU’s native language — pure numbers! But here’s the catch: this .o file isn't complete yet. It has "holes" where external functions like printf are referenced but not defined. The assembler knows you want to call printf, but it doesn't know where printf actually lives in memory.
That’s where our next layer comes in to tie everything together.
Layer 5: The Linker — Connecting the Dots
The linker is like a detective solving a puzzle. It takes your .o object file and finds all those missing pieces - mainly the printf function from the C standard library.
Remember from layer 2 how the preprocessor only brought in printf’s declaration ( the “promise” that printf exists)? well, now the linker has to fulfill that promise by finding the actual printf implementation in the system’s C library and connecting your program to it.
Finally! you have a complete , runnable program sitting on your hard drive. But it’s still just a file full of binary numbers. How does it actually start running and doing work ?
Layer 6: The Operating System — Bringing Your Program to Life
When you double-click your executable or type ./program in terminal, the operating system becomes your program’s manager and bodyguard.
The OS loader reads your executable file from disk & copies it into RAM memory. But it doesn’t just dump it anywhere - it creates a dedicated memory space for your program, complete with sections for code , variables, and temporary storage(stack & heap).
The OS also creates a new process with a unique Process ID, sets up security permissions, and prepares to give your program CPU time, then waits while other programs get their turn.
When it’s finally your program’s turn, the real magic begins at the hardware level.
Layer 7: Inside the CPU — Fetch, Decode, Execute
Now we’re inside the processor itself! your CPU follows a simple but powerful cycle for every single instruction: Fetch , Decode & Execute.
Let’s trace our addition through this cycle:
Fetch: The CPU reads the binary instruction 8B 45 F8 (remember this from Layer 4?) from the memory into its instruction register.
Decode: The CPU’s control unit looks at this pattern and thinks, “Ah! this means load data from memory location [rbp — 8] into register eax.” It’s like the CPU suddenly understanding what that cryptic binary actually means.
Execute: The CPU sends control signals to move the value of variable x from memory into the eax register. Actual electrons start flowing through circuits.
This happens for every instruction in your program - load x , load y , add them, store result, call printf. Each operation is broken down into these fundamental steps, happening billions of times per second.
But how does this electronic “thinking” actually work ?
How do patterns of electricity become mathematical operations?
Layer 8: Logic Gates — The CPU’s Building Blocks
Here’s where software meets hardware in the most elegant way. Every operation your CPU performs - adding number, comparing values, moving data is built from combinations of simple logic gates.
Think of logic gates as tiny decision-makers that follow basic rules:
- AND gate: Give me 1 only if BOTH inputs are 1.
- OR gate: Give me 1 if EITHER inputs is 1.
- XOR gate: Give me 1 if inputs are DIFFERENT.
when your CPU adds 5+10 , it’s actually using a clever arrangement of XOR gates(for the sum) and AND gates(for the carry), processing each bit position:
0101 (5 in binary)
+ 1010 (10 in binary)
------
1111 (15 in binary)
Millions of these gates work together inside your processor, forming complex circuits like arithmetic logic units(ALUs), registers, and control units. Your simple addition operation flows through dozens of interconnected gates in nanoseconds.
What makes these gates actually work ?
What’s the fundamental switching mechanism ?
Layer 9: Transistors — The Ultimate Switches
We’ve finally reached the bottom! Every logic gate, every CPU operation, every bit of computation comes down to tiny switches called transistors. Modern processors contain billions — each one smaller than a virus.
Transistor: it’s an electrically controlled switch with three terminals (source, drain, and gate). When you apply voltage to the gate, it allows current to flow from source to drain (switch ON = 1). No voltage on the gate means no current flows (switch OFF = 0).
When you wrote int x = 5; , that “5” is stored as the binary pattern 0101 in your computer’s memory. This means four transistors: OFF-ON-OFF-ON. Your simple addition operation causes millions of transistors to switch in precise patterns, creating the electrical representation of mathematical logic.
Here’s the mind-blowing part: when you run your program, you’re literally conducting an orchestra of billions of microscopic switches, all flipping on and off millions of times per second, transforming your human thoughts into controlled patterns of electron flow through silicon.
Your code has become electricity itself.
The Complete Journey - From Thought to Electrons
Let’s take a moment to appreciate what just happened. You wrote eight simple lines of C code to add two numbers.
Software Layers: Your human-readable code expanded through preprocessing, got translated to assembly language, converted to binary machine code, linked with system libraries, and loaded into memory by the operating system.
Hardware Execution: The CPU fetched each binary instruction, decoded its meaning, and executed the operations through billions of logic gates built from transistors — microscopic switches that respond to electrical signals.
The Reality: When you type gcc program.c && ./program , you’re setting in motion a cascade that ends with precisely controlled electron movements through silicon crystals. Your abstract thoughts about adding numbers become physical reality in the form of electrical patterns.
About the Author :
If you enjoyed this deep dive into how code becomes hardware, follow me for more articles like this.
How Your Program Actually Runs : From C to CPU. was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Tarun Chandragiri
Tarun Chandragiri | Sciencx (2025-08-27T14:36:55+00:00) How Your Program Actually Runs : From C to CPU.. Retrieved from https://www.scien.cx/2025/08/27/how-your-program-actually-runs-from-c-to-cpu/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.