The Memory Management Unit (MMU) is incredibly fast, translating addresses on every single CPU cycle. But how does it keep track of where each address belongs?
Imagine if the MMU stored a mapping for every single byte of memory. If a process had a 4 GB address space, the Page Table would need to store 4 billion entries! The map itself would take up many gigabytes of physical RAM, leaving no room for the actual programs.
To solve this, systems divide memory into equal-sized blocks rather than mapping individual bytes.
* Pages: The equal-sized blocks that partition the Virtual Address Space of a process.
* Frames: The equal-sized blocks that partition the Physical RAM of the system.
Instead of translating individual byte coordinates, the Page Table simply translates entire Pages into Frames.
2. Why Equal Sizes?
If we partition memory into blocks, a crucial rule emerges: Pages and Frames must be exactly the same size.
Why? Because the MMU never modifies the entire address sequence. It only replaces the Page Number with the physical Frame Number. The rest of the address—the Offset—remains completely untouched.
* Page Number: Represents which block in the virtual address space is being accessed.
* Frame Number: Represents which physical block in the RAM chip is being targeted.
* Offset: Represents the specific byte offset within that block.
Because the offset is identical on both sides, the index of the byte inside the Page is exactly the same as the index of the byte inside the Frame. If the sizes differed, the offset would point to a completely different byte, scrambling data structure alignments.
The offset never changes. Page 0x12 translates into Frame 0x8A, but offset 0x34 maps directly to offset 0x34 inside the destination frame.
3. The Page Table
So, what is the Page Table?
It is simply an array indexed by the Page Number. Each entry in the Page Table (often called a Page Table Entry, or PTE) contains the corresponding Frame Number where that page is physically loaded.
Virtual Page Number
Valid Bit
Physical Frame Number
0x00
1
0x07
0x01
1
0x02
0x02
1
0x0A
0x03
1
0x05
If the CPU wants to access Virtual Address 0x011A (Page 0x01, Offset 0x1A), the MMU queries index 0x01 of the Page Table. The table returns Frame Number 0x02. The MMU then targets Physical Address 0x021A.
No math, no search loops. Just a direct index lookup.
4. EdgeCase: One Page Finds Its Frame
Let's watch a single Virtual Address complete the translation pipeline.
4.2.1 EdgeCase: Page-to-Frame Pipeline
5. Reflection
We now know the language of memory: Page sizes match Frame sizes, letting us translate coordinates by simply swapping the block headers while leaving the internal offset untouched.
But a structural bottleneck exists:
The Physical RAM chip contains only a limited number of Frame slots. What happens when a process attempts to read a Page that isn't currently loaded into any of those physical frames?
The operating system must make room. But how does it decide which page to evict, and how does the hardware handle this missing memory link?
Engineering concepts you don't just read — you experience.
Founded in 2026.
PrajnaEdge is a technology company exploring the space between understanding technology, experimenting with ideas, and turning them into things that can be experienced.
Our Mission
To make technology easier to explore, deeper to understand, and more exciting to experience.
Our Vision
To build a technology ecosystem where curiosity, experimentation and creation continuously lead to one another.
Where it began
Embedded Systems
PrajnaEdge began with Embedded Systems — exploring the foundations that connect hardware, software and intelligent computation.
The first technology universe is built around that foundation. The journey will expand as new ideas, experiments and products emerge.
I am the engineer behind the design, development, and content of PrajnaEdge. I build low-level systems where code directly controls hardware, bridging the gap between register-level silicon behavior and intelligent edge decision loops.
I am an Embedded Firmware Engineer focused on developing software for resource-constrained systems. My experience spans bare-metal firmware, device drivers, microcontroller peripherals, and communication protocols, working across the boundary between hardware and software.
My work has involved microcontroller-based systems, real-time behaviour, hardware interfaces, and communication technologies such as CAN, CAN FD, UART, SPI, and I²C. I am particularly interested in understanding systems from the lowest level upward—from registers and peripherals to intelligent edge systems.
ENGINEERING PHILOSOPHY
Engineering is not just about writing code; it is about managing constraints, timings, and physical hardware characteristics. True mastery of complex systems comes from understanding the interactions across different layers of the stack.
This conviction is why I built PrajnaEdge—to bridge the gap between conceptual theory and direct, register-level physical reality.
Open to collaborations, research, and interesting engineering conversations.
Help Improve PrajnaEdge
Found something to improve? I'd love to hear your thoughts.
Bare Metal
Software that runs directly on hardware without an operating system.
Applications
↑
Operating Systems
YOU ARE HERE
Bare Metal
Processor
↑
Hardware
"Every embedded application begins long before main()."
Operating Systems
An Operating System manages hardware and software resources so complex applications can work efficiently.
Applications
↑
YOU ARE HERE
Operating Systems
Bare Metal
↑
Processor
↑
Hardware
"When one loop is no longer enough to carry the burden."
Support PrajnaEdge
PrajnaEdge is an independent education platform built to make knowledge freely accessible.
If you find PrajnaEdge useful, you can support its continued development.
Your support helps fund the time, tools, infrastructure, and experimentation that go into building and maintaining PrajnaEdge.
Select Region
Select Amount
₹
Select an amount to support PrajnaEdge.
Legal Information
Product Terms & Licensing
1. Terms of Use
PrajnaEdge is an interactive learning platform designed for systems engineers, developers, and technology enthusiasts. The educational materials, simulation blocks, and visual code tracers are provided for instruction and concept validation. We make no warranty regarding their completeness or applicability to real-world industrial systems.
PrajnaEdge is committed to learning privacy. We do not sell user data. Analytical event tracking is used solely to study click telemetry and help improve visual guides.
