DEV Community: ember_seed

A Deep Dive into the Memory Model

ember_seed — Wed, 05 Aug 2026 15:31:46 +0000

A Deep Dive into the Memory Model

From Source Code to Machine Instructions

A five-part journey through compilers, executables, virtual memory, and the CPU

Introduction: What Really Happens When Code Runs

Consider a simple C program:

include <stdio.h>

int value = 10;

int add(int a, int b) {

return a + b;

}

int main() {

int x = 5;

int result = add(x, value);

printf("%d", result);

return 0;

}

Most programmers look at this and see only the visible outcome:

5 + 10 = 15

But behind that single printed number lies a much deeper story. Where does the data actually live? Who moves it from one place to another? How does the CPU find the instructions it needs to run? And how does the result finally make its way to the screen?

Answering these questions means understanding a concept that many programmers use daily but rarely examine closely: the memory model.

What Is a Memory Model, Really?

Ask most developers what a "memory model" means, and the answer usually comes back in two words: stack and heap. That answer isn't wrong - it's just incomplete. A memory model is really a description of five things at once:

How data is stored
How data is accessed
How long data exists
Who is responsible for managing that lifetime
How different parts of a system communicate through memory

A program never leaps directly from C source code into RAM. Several distinct layers sit between the two, each one translating the layer below it into something the layer above can reason about. This article walks through all of them, one at a time, and then reassembles the full picture.

The Four Layers, at a Glance

Layer	What It Deals With	Typical Concepts
1. Programming Language	Human-readable code	scope, lifetime, ownership
2. Compiler	Translating code to instructions	registers, optimization, assembly
3. Operating System	Running the program as a process	virtual address space, .text/.data/.bss
4. CPU Architecture	Executing raw instructions	registers, cache, pipeline, ALU

The rest of this article follows a single program down through each of these layers - from the moment a developer types int x = 10; to the moment a number appears on screen.

Part 1 - The Layers Between Code and Memory

Layer 1: The Programming Language

At the C language level, a programmer thinks in terms of declarations like:

int x = 10;

malloc(...);

static int counter;

Underneath these simple lines, the language is quietly defining scope, lifetime, visibility, and ownership. Take this function:

void function() {

int x = 10;

}

The variable x is local: its lifetime begins when the function starts and ends the moment it returns. Compare that to a global declaration:

int global = 20;

This variable lives for as long as the program runs. At this stage nobody is thinking about CPU registers or physical RAM - the only question that matters is: what is this data, and how long should it exist?

Layer 2: The Compiler

The compiler is the bridge between what a human writes and what a machine can run. A line like:

int x = 10;

means nothing to the CPU on its own. The compiler has to decide whether that value belongs on the stack, whether it can live entirely inside a register, or whether it can be optimized away completely. An expression such as:

int result = a + b;

might be turned into assembly like:

mov eax, a

add eax, b

At this point the very idea of a "variable" starts to dissolve. The CPU never sees anything called result - it only ever sees a sequence of MOVE, ADD, and STORE operations.

Layer 3: The Operating System

Compilation produces an executable file, but a file sitting on disk isn't a running program yet. When the user launches it, the operating system kernel steps in and builds an entirely new environment for it, called a virtual address space. Inside that space the program sees familiar regions:

Region	Purpose
.text	Executable machine instructions
.data	Initialized global variables
.bss	Uninitialized global variables
Heap	Memory requested dynamically at runtime
Stack	Local variables and function call frames

The operating system gives every program the comfortable illusion that it owns all of memory by itself - it never has to think about other processes or the physical layout of RAM.

Layer 4: The CPU Architecture

At the very bottom, the CPU has no concept of variables, functions, objects, or C syntax. All it understands are raw machine instructions:

mov eax, 5

add eax, 10

Internally, it relies on a handful of hardware components working together: registers, cache, the MMU, the instruction pipeline, the ALU, and various execution units. The CPU's entire job is to follow instructions and move data around - nothing more, nothing less.

Putting the Four Layers Together

C Source Code
↓
Compiler
↓
Executable File
↓
Operating System Loader
↓
Process + Virtual Memory
↓
Memory Translation (MMU)
↓
CPU Execution
↓
Machine Instructions
↓
Final Result

The core idea to take away from this first layer of understanding is that memory is not simply a physical place where bytes sit. It's a stack of abstractions, each one built on top of the last:

Programming Language
↓
Compiler
↓
Operating System
↓
CPU Hardware

Each layer exists to hide complexity from the layer above it. That's precisely what lets a programmer write result = a + b; without ever thinking about registers, page tables, or electrical signals.

Part 2 - Executable Files, Loaders, and Process Memory Layout

Part 1 established the high-level path a program takes: source code becomes an executable, and the operating system turns that executable into a running process. Now it's time to zoom in on the step that happens in between - what actually lives inside an executable file before the CPU ever touches it?

What Is an Executable File?

Compiling a C program doesn't produce a running program - it produces a file containing everything the operating system needs to build one. On Windows, that file uses the PE (Portable Executable) format; on Linux, it typically uses ELF (Executable and Linkable Format). Either way, the format is far more than a wrapper around machine code. It also encodes where the code lives, where the data lives, which libraries are required, the program's entry point, the memory permissions each section needs, and instructions for how the OS should load everything.

Inside an Executable File

Take this small program:

include <stdio.h>

int global_initialized = 10;

int global_uninitialized;

int main() {

int local = 5;

printf("%d\n", local);

return 0;

}

Once compiled, its contents are split across distinct sections inside the file:

Header
↓
.text
↓
.data
↓
.bss
↓
Imports
↓
Other Data

.text - Program Instructions

The .text section holds machine instructions. A function like:

int add(int a, int b) {

return a + b;

}

compiles down to something like:

mov eax, ecx

add eax, edx

ret

This section is marked readable and executable, but normally not writable - code isn't supposed to modify itself, and that restriction improves security, stability, and the ability to share memory safely between processes.

.data - Initialized Global Data

A variable declared with an initial value, such as:

int counter = 100;

is stored directly in .data, complete with its starting value already baked into the executable. When the program loads, that value is copied straight into process memory.

.bss - Uninitialized Global Data

A variable with no initial value:

int total;

doesn't need to occupy space in the file at all. Storing thousands of zero bytes on disk would be wasteful, so .bss simply records an instruction: reserve this much memory and fill it with zero. The loader creates the actual zeroed bytes only when the program starts.

Stack - Temporary Function Memory

The stack comes into existence when the process starts. For a function like:

void function() {

int x = 20;

}

running it creates a small frame holding x = 20, and returning from it removes that frame automatically. The stack holds local variables, function parameters, return addresses, and other short-lived values - each function call gets its own stack frame, created and destroyed automatically.

Heap - Dynamic Memory

The heap, by contrast, is used only when a program explicitly asks for memory while it's running:

int *ptr = malloc(sizeof(int));

Here the operating system hands over space from the heap on request. The key difference from the stack is lifetime management: stack memory comes and goes automatically, while heap memory stays allocated until the programmer explicitly releases it.

From Executable to Process

A file sitting on disk is not the same thing as a process running in memory. When the user runs program.exe, the operating system kicks off a sequence of steps:

User Starts Program
↓
Kernel Creates Process
↓
Loader Reads Executable
↓
Maps Sections Into Virtual Memory
↓
Creates Page Tables
↓
Sets Initial CPU State
↓
CPU Starts Execution

What Does the Loader Actually Do?

The loader doesn't simply copy the whole file into RAM. Instead, it builds a memory view of the executable, mapping each section of the file into the freshly created virtual address space:

Stack
↓
Heap
↓
.bss
↓
.data
↓
.text

Entry Point - Where Execution Begins

Every executable declares a starting address called its entry point - for instance, 0x140001000. The loader writes this address into the CPU's instruction pointer register:

RIP = Entry Point

The CPU now knows where its first instruction lives. But there's a catch: that address is still a virtual address, not a physical location in RAM.

The First Connection Between OS and CPU

At this exact moment, two pieces are in place. The operating system has loaded the current process's page table address into the CR3 register, and the entry point address sits in RIP. With both ready, the CPU can begin execution - but it immediately faces a new problem:

The Next Question

How does the CPU convert the virtual address sitting in RIP into a real location in physical memory? Answering that requires virtual memory, page tables, and the MMU - the subject of Part 3.

Part 3 - Virtual Memory, Pages, Page Tables, CR3, and the MMU

Part 2 left us at a critical juncture: the operating system had loaded the executable, created a process, and placed both an entry point in RIP and a page table address in CR3. The question left hanging was simple to ask but important to answer: RIP holds a virtual address - how does the CPU turn that into a real location in RAM? The answer lies in the virtual memory system.

What Is Virtual Memory?

A common misconception is that virtual memory is simply another kind of RAM. It isn't. Virtual memory is an addressing system created by the operating system - it gives every process its own private view of memory, entirely independent of what any other process is doing.

Two different programs can both reference the exact same virtual address, 0x140001000, while actually pointing at completely different physical memory underneath:

Process	Virtual Address	Physical Address
Process A	0x140001000	0x80001000
Process B	0x140001000	0x90001000

Each process has its own private mapping, so identical virtual addresses can resolve to entirely different physical locations. This isolation is one of the most important security guarantees a modern operating system provides.

The Virtual Address Space

Every process is handed its own virtual address space, typically laid out like this, from high addresses down to low:

Stack
↓
Heap
↓
.bss
↓
.data
↓
.text

Region	Contents	Typical Permissions
.text	mov eax, 5 / add eax, 10 - executable instructions	Read, Execute
.data	int counter = 100; - initialized globals	Read, Write
.bss	int value; - uninitialized globals, zero-filled	Read, Write
Heap	malloc() memory, lifetime controlled by the programmer	Read, Write
Stack	Local variables and function call frames	Read, Write

Memory Is Divided Into Pages

A virtual address space isn't one continuous block - it's carved up into small, fixed-size chunks called pages. A common page size is 4 KB, though other sizes exist depending on the architecture.

Page 0
↓
Page 1
↓
Page 2
↓
Page 3

Physical Memory Is Divided Into Frames

RAM is split up the same way, into blocks called frames:

Frame 0
↓
Frame 1
↓
Frame 2

Rule to Remember

Page size always equals frame size. If a page is 4 KB, its corresponding frame must also be 4 KB - a virtual page has to fit exactly into a physical frame.

The Page Table: The Translation Map

Something has to connect virtual pages to physical frames - that something is the page table, maintained by the operating system for every process:

Virtual Page	→	Physical Frame
Page 0	→	Frame 7
Page 1	→	Frame 20
Page 2	→	Frame 100

In essence, a page table is a dictionary: whenever the program asks for a given virtual address, the table says exactly where the real, physical data lives.

Where Does the CPU Find the Page Table?

This is where the CR3 register comes in. CR3 holds the base address of the current process's page table:

Process	CR3 Points To
Process A	Page Table A
Process B	Page Table B

When the scheduler switches which process is running, it also swaps the value in CR3 - instantly giving the CPU a completely different memory map to work from.

The MMU - Memory Management Unit

The MMU is a hardware component built into the CPU whose entire job is translating virtual addresses into physical ones, automatically and on every memory access. The programmer never calls it directly; the operating system simply configures it, and it runs silently underneath everything.

The TLB - The Missing Link Between MMU and Page Tables

Virtual memory provides isolation and flexibility, but it introduces a performance problem.

Every memory access requires translating a virtual address into a physical address. If the CPU had to walk the page table every single time, memory access would become much slower.

To solve this problem, modern CPUs include a small and extremely fast cache called the Translation Lookaside Buffer (TLB).

The TLB stores recently used virtual-to-physical address translations.

Instead of:

Virtual Address

↓

Page Table

↓

Physical Address

the CPU first checks:

Virtual Address

↓

TLB

↓

Physical Address

If the translation exists in the TLB, the CPU can immediately continue.

This is called a:

TLB Hit TLB Miss

If the translation is not found:

TLB Miss

occurs.

The CPU must perform a page table walk:

Virtual Address

↓

MMU

↓

TLB Check

↓

Miss

↓

CR3

↓

Page Table Hierarchy

↓

Physical Frame

↓

Update TLB

The next access to the same memory location can now use the cached translation.

The Real Memory Translation Path

The complete process is:

RIP / Register

↓

Virtual Address

↓

MMU

↓

TLB

↓

(found?)

Yes
|
↓

Physical Address

No
|
↓

CR3

↓

Page Table

↓

Physical Address

↓

Cache

↓

RAM Why TLB Matters

Without a TLB, every instruction fetch and every data access would require additional page table lookups.

The TLB allows virtual memory to keep its security and flexibility while avoiding the full cost of address translation on every access

The First Instruction Fetch, Fully Traced

With all the pieces now in place, we can trace exactly what happens when the loader sets RIP = 0x140001000 and the CPU asks for its first instruction:

RIP (Virtual Address)
↓
MMU
↓
CR3
↓
Page Table
↓
Physical Address
↓
Cache / RAM
↓
Instruction Fetch

Common Misconception

Many people assume the physical address, once found, gets written back into RIP. It doesn't. RIP always continues to hold a virtual address - the translation happens internally, on the fly, inside the CPU, every single time memory is accessed.

The Complete Picture So Far

Executable File
↓
Loader
↓
Process
↓
Virtual Address Space
↓
Page Table
↓
CR3
↓
MMU
↓
Physical Memory
↓
CPU Execution

At this stage, the operating system has fully prepared the memory world, and the CPU has successfully located its first instruction. One large question still remains: once an instruction physically reaches the CPU, what happens to it from that point on?

Part 4 - CPU Internals: Registers, Cache, and the Instruction Pipeline

Part 3 followed an instruction all the way to the CPU's doorstep. Now it's time to go inside: what does the CPU actually do with an instruction once it arrives, and how does it turn that instruction into a computed result?

The CPU Does Not Understand C Code

The CPU has no concept of variables, functions, loops, or objects. All it ever sees are machine instructions. A line like:

int result = 5 + 10;

becomes assembly such as:

mov eax, 5

add eax, 10

From the CPU's perspective, every program - no matter how complex - ultimately reduces to moving data, performing calculations, comparing values, and jumping to other instructions.

Registers - The Fastest Memory There Is

Inside the CPU sit a small number of extremely fast storage locations called registers. RAM is large but comparatively slow; registers are tiny but blazingly fast, and the CPU relies on them to hold current data, addresses, intermediate results, and execution state. Unlike RAM, a register isn't external memory at all - it's physically part of the CPU itself.

RIP - Instruction Pointer

RIP always holds the address of the next instruction to execute:

RIP = 0x140001000

Once that instruction finishes, RIP automatically advances to point at the next one.

General-Purpose Registers

These hold everyday working data - RAX, RBX, RCX, RDX, RSI, RDI, and R8 through R15. A pair of instructions like:

mov eax, 5

add eax, 10

simply means: set EAX to 5, then add 10 to it, leaving EAX holding 15.

RSP - Stack Pointer

RSP always tracks the current top of the stack. Whenever a function like:

int main() {

int x = 10;

}

runs, the CPU creates a stack frame, and RSP keeps track of exactly where that frame currently sits.

RBP - Base Pointer

RBP typically marks the beginning of the current stack frame, giving the compiler a stable reference point from which to access parameters and local variables:

Stack Frame (High → Low)	Pointer
Return Address
Local Variable	← RBP: Frame Start
Parameters	← RSP: Current Position

CR3 vs. the Execution Registers

It's worth being precise about the difference in roles here. CR3 answers the question "which memory map should I use?" - it belongs entirely to address translation. RIP, RSP, RAX, and the rest belong to execution itself, answering questions like "which instruction runs next?", "where is my current stack?", and "what value am I working with right now?"

Cache - Faster Than RAM

Even RAM is too slow to keep up with a modern CPU, which is why several layers of cache sit between the two:

CPU Registers
↓
L1 Cache
↓
L2 Cache
↓
L3 Cache
↓
RAM
↓
Storage

A cache stores both the raw data and the information needed to find it again quickly - for instance, an instruction cache entry might pair address 0x140001000 with the raw bytes 55 48 89 E5, while a data cache entry pairs address 0x5000 with the value 123.

Without a cache, every request for data has to travel all the way out to RAM and back - a comparatively slow round trip. With a cache in place, most requests are satisfied much closer to the CPU, which is dramatically faster.

The Instruction Pipeline

A CPU doesn't finish one instruction completely before starting the next - it overlaps several instructions at once, a technique known as pipelining. The classic five-stage pipeline looks like this:

Fetch
↓
Decode
↓
Execute
↓
Memory
↓
Write Back

Fetch

The CPU retrieves the next instruction - say, add eax, ebx - from the instruction cache.

Decode

The decoder figures out what the instruction actually means: the operation is ADD, the inputs are EAX and EBX, and the output goes back into EAX.

Execute

The ALU performs the actual arithmetic - for example, 5 + 10 = 15.

Memory

If the instruction needs to read or write memory - as in mov eax, [address] - the CPU accesses cache first, falling back to RAM only if necessary.

Write Back

Finally, the result is written back into its destination register, ready for the next instruction to use.

The Complete CPU Execution Path

RIP
↓
Fetch Instruction
↓
Decode
↓
Read Registers
↓
Execute in ALU / FPU
↓
Memory Access (if needed)
↓
Write Result Back

Where Does the Final Result Actually Go?

The CPU never shows anything to the user by itself. A call like printf("%d", result); has to travel through several more layers before anything appears on screen:

Program
↓
C Library
↓
System Call
↓
Kernel
↓
Driver
↓
Hardware Output

The CPU calculates the answer. The operating system manages the resources needed to display it. The hardware produces the final visible effect. Each of the three plays a distinct, necessary role.

Part 5 - The Complete Journey: From C Code to CPU Result

Parts 1 through 4 examined each layer in isolation: how C becomes machine instructions, how an executable file is structured, how the operating system builds a process, how virtual memory and page tables work, and how the CPU itself processes instructions through registers, cache, and its pipeline. It's time now to connect every piece into one continuous story, following a single program from the first line of code to the final number on screen.

The Starting Point

Consider this small program:

include <stdio.h>

int global = 10;

int add(int a, int b) {

return a + b;

}

int main() {

int x = 5;

int result = add(x, global);

printf("%d\n", result);

return 0;

}

At the source level this looks almost trivially simple: x is 5, global is 10, their sum is 15, and that number gets printed. But underneath that simplicity, thousands of individual operations take place across every layer discussed so far.

Step 1 - Compilation

Everything begins with compilation, which transforms human-readable C into machine instructions through a multi-stage pipeline:

Source Code
↓
Preprocessor
↓
Compiler
↓
Assembly Code
↓
Assembler
↓
Object File
↓
Linker
↓
Executable File

The result is a file - program.exe on Windows, or simply program on Linux - containing .text, .data, .bss, metadata, library references, and an entry point. At this point the program is still nothing more than a file sitting on disk; it isn't running yet.

Step 2 - Starting the Program

The moment the user launches the executable, control passes to the operating system kernel, which creates a process. A process is far more than the executable file itself - it bundles together a virtual address space, page tables, register state, system resources, and a full execution context.

Step 3 - The Loader Builds the Memory Environment

The loader reads the executable and maps its sections into the new virtual address space:

Stack
↓
Heap
↓
.bss
↓
.data
↓
.text

The instruction add eax, ebx lands in .text. The variable int global = 10; lands in .data. The stack and heap are prepared and left ready for use once execution begins.

Step 4 - Creating Page Tables

The process now has a virtual address space, but physical RAM lives somewhere else entirely, so the OS builds a page table connecting the two:

Virtual Page	→	Physical Frame
Page 0	→	Frame 25
Page 1	→	Frame 80
Page 2	→	Frame 13

The OS then writes this page table's address into CR3, so the CPU always knows exactly which memory map belongs to the process currently running.

Step 5 - Starting CPU Execution

The loader sets RIP to the entry point - 0x140001000, for example - and the CPU immediately needs to fetch that first instruction. Translation kicks in right away:

RIP (Virtual Address)
↓
MMU
↓
CR3
↓
Page Table
↓
Physical Address
↓
Cache / RAM

The instruction successfully reaches the CPU.

Step 6 - The Instruction Pipeline Begins

Take a simple instruction like mov eax, 5 and follow it through the pipeline:

Stage	What Happens
Fetch	The instruction moves from the instruction cache into the CPU
Decode	The CPU identifies the operation (Move), destination (EAX), and value (5)
Execute	The execution unit performs EAX = 5
Write Back	The result, 5, is stored in the EAX register

Step 7 - The Function Call and the Stack

When result = add(x, global); executes, the CPU builds a new stack frame to hold everything the function call needs:

Stack Frame (High → Low)
Return Address
Parameter b
Parameter a
Local Data

RSP tracks the current stack position throughout, while RBP marks the base of this particular frame - together they let the compiler generate code that reliably finds parameters and locals.

Step 8 - The Calculation Itself

With everything in place, the CPU finally performs the arithmetic: two register values flow into the ALU, which computes 5 + 10 and stores the result, 15, back into a register.

Step 9 - Printing the Result

The CPU has no idea what a screen is. Producing visible output means calling out through several more layers:

Application
↓
C Standard Library
↓
Operating System API
↓
System Call
↓
Kernel
↓
Driver
↓
Display Hardware

The kernel communicates with the hardware, and only then does 15 finally appear on the screen.

The Complete Memory Model, End to End

Developer
↓
C Source Code
↓
Compiler
↓
Executable File
↓
Operating System Loader
↓
Process
↓
Virtual Address Space
↓
Page Table
↓
CR3
↓
MMU
↓
Cache / RAM
↓
CPU Registers
↓
Instruction Pipeline
↓
ALU
↓
Result
↓
Kernel
↓
Hardware

Final Understanding

The single most important idea in this entire journey is that a program is never executed directly from the file sitting on disk. It passes through layer after layer of abstraction, and each layer sees something completely different:

Layer	What It Sees
Programmer	result = a + b;
Compiler	Variables and instructions
Operating System	A process and its memory mappings
CPU	An ADD instruction
Hardware	Electrical signals

Every layer hides complexity from the one above it - and that hiding is exactly what allows modern computers to execute billions of instructions per second while programmers get to write simple, readable code.

Conclusion

Understanding the memory model ultimately means understanding how programming languages, compilers, operating systems, memory management, CPU architecture, and hardware execution all connect into a single continuous chain. Once that connection clicks into place, entire fields open up more easily - debugging, reverse engineering, operating system development, performance optimization, and systems programming all become far less mysterious.

A program is not just code.

It is a journey through multiple layers of abstraction until it becomes physical computation.

Why I Built a Scientific Calculator in Pure C for Terminal Environments

ember_seed — Sat, 30 May 2026 04:53:44 +0000

For most people, opening a calculator means launching a GUI application or typing a quick expression into Python.

For me, neither felt ideal.

A large part of my work happens inside terminals: remote servers, SSH sessions, minimal Linux installations, recovery environments, virtual machines, and development systems where a terminal is always available but a graphical environment is not guaranteed.

I wanted a scientific calculator that felt native to that environment.

Not a Python script.

Not a desktop application.

Not something that required package installation, runtime environments, or external dependencies.

Just a single executable that could be compiled anywhere and run immediately.

So I built one.

Why Not Python?

Before someone asks: Python is excellent.

I use Python regularly and have no problem with it.

The goal of this project was never to replace Python.

The goal was to build a tool with different trade-offs.

With Python, even a simple calculation requires starting an interpreter:

python -c "print(2+2)"

That is perfectly reasonable.

But in terminal-centric workflows, I wanted something that behaves more like a traditional Unix utility:

calculator

Instant startup.

No runtime.

No dependency management.

No interpreter.

No virtual environments.

Just a native executable.

Why Terminal First?

Modern software increasingly assumes graphical environments.

Yet terminals remain one of the most important interfaces in computing.

System administrators live in terminals.

Embedded developers use terminals.

Linux users spend hours inside terminals.

SSH sessions are terminals.

Containers are terminals.

Rescue environments are terminals.

Many scientific calculators either require a GUI or offer only basic arithmetic.

I wanted something that remained entirely inside the command line while still providing advanced mathematical functionality.

Features Beyond Basic Arithmetic

The project started as a simple calculator.

It gradually evolved into something closer to a lightweight mathematical toolkit.

Expression Parsing

The calculator supports full mathematical expressions:

2+3*4
sqrt(16)
sin(pi/2)

It also supports implicit multiplication:

2pi
3(2+4)
(x+1)(x-1)

which feels natural when entering mathematical expressions.

Scientific Functions

Built-in support includes:

Trigonometric functions
Inverse trigonometric functions
Degree-based variants
Logarithms
Exponentials
Roots
Factorials
Rounding functions

Examples:

sin(pi/2)
sind(90)
sqrt(25)
log2(1024)
fact(5)
Number Base Support

Working close to hardware often means switching between number systems.

The calculator supports:

0b1010
0o77
0xFF

as inputs and can convert values between bases.

Equation Solving

Instead of only evaluating expressions, the calculator can solve equations.

Supported modes include:

Quadratic equations
Cubic equations
General numerical root finding

Example:

x^2 - 2 = 0

which converges to:

1.414213562...

using Newton-Raphson iteration.

Numerical Differentiation

Given any expression containing x, the calculator can estimate its derivative numerically.

Example:

f(x) = x^2

at:

x = 2

returns:

f'(2) = 4
ASCII Graph Plotting

This is one of my favorite features.

Graphing normally requires graphical libraries.

Instead, this calculator renders graphs directly in the terminal using ASCII characters.

No GUI.

No plotting framework.

Just text.

Example:

y = x^2

can be visualized directly inside a terminal window.

Matrix Operations

The calculator also includes support for 2×2 matrix operations:

Addition
Multiplication
Determinant
Inverse

which makes it useful for basic linear algebra tasks.

Why a Single File?

One criticism I expect is:

"Why is everything in one file?"

Because simplicity was a design goal.

This project is intentionally small enough that opening a single source file provides a complete view of the entire program.

There is no build system.

No project hierarchy.

No dependency graph.

No package manager.

No generated code.

A developer can open the source, scroll through it, understand it, modify it, and compile it.

That simplicity has value.

Especially for educational projects.

Especially for C.

What I Learned

The most interesting part of this project wasn't writing mathematical functions.

It was building the expression parser.

Supporting features like:

2pi
3(2+4)
root(8,3)
logbase(100,10)

required much more thought than I initially expected.

The project also reinforced something I appreciate about C:

For small system-oriented utilities, C remains remarkably effective.

The language gives direct control, fast execution, minimal overhead, and broad portability.

Future Plans

There are still many things I'd like to improve:

Better matrix support
More graphing capabilities
Additional numerical methods
Persistent history
Improved expression parsing

But even in its current form, the calculator already serves the purpose that motivated the project:

Providing a capable scientific calculator that feels at home in terminal environments.

Repository

If you're interested in terminal tools, C programming, parsers, or numerical methods, I'd love to hear your feedback and ideas for future improvements.

EmberSeed / ADVANCED-TERMINAL-CALCULATOR

Advanced Terminal Calculator – A powerful CLI scientific calculator with trig, logs, roots, base conversion, equation solver, differentiation, matrix ops, ASCII plotting, and history. No GUI, just pure math in your terminal.

🧮 Advanced Terminal Calculator

A zero-dependency scientific calculator written in C.

This project combines an expression parser, scientific functions, numerical methods, equation solving, graph plotting, and basic matrix operations into a single self-contained terminal application.

The entire implementation is contained in a single source file and depends only on the C standard library and libm.

✨ Features

1. Arithmetic & Expressions

Supported operators:

Features:

Full operator precedence
Parentheses
Implicit multiplication
Right-associative exponentiation

Examples:

2+3*4          -> 14
(2+3)*4        -> 20
2pi            -> 6.28318...
3(2+4)         -> 18
2^3^2          -> 512
10%3           -> 1

2. Trigonometric Functions

Radians:

sin
cos
tan
asin
acos
atan

Degrees:

sind
cosd
tand
asind
acosd
atand

Examples:

sin(pi/2)      -> 1
cos(0)         -> 1
tan(pi/4)      -> 1

sind(90)       -> 1
cosd(180)      -> -1
tand(45)       -> 1

3. Logarithmic & Exponential Functions

Supported:

ln
log
log10
log2
logbase(x,base)
exp

Examples:

ln(e)              -> 1

…

View on GitHub