DEV Community: Harsh Thalwal

I Built a 64-bit OS from Scratch in C and Assembly — No GRUB, No Shortcuts

Harsh Thalwal — Thu, 28 May 2026 08:25:13 +0000

Most people learn how operating systems work from textbooks.
I decided to just build one.

Not with GRUB. Not with UEFI abstractions. Just raw x86_64 Assembly, freestanding C, and a lot of time spent reading Intel manuals at 2am.

This is the story of AxiomX-OS — a fully custom x86_64 operating system I built from scratch, including its own 4-stage bootloader, physical and virtual memory manager, round-robin scheduler with context switching, and an interactive shell with 24 built-in commands.

Here's what I built and how.

Why build an OS?

"How does an OS actually work?" is one of those questions that deserves a real answer — not a textbook chapter, but actual code running on actual hardware.

I wanted to understand what happens between pressing the power button and running a program. Every layer of abstraction people take for granted — memory, processes, interrupts — I wanted to build myself.

So I did.

The Architecture: A Custom 4-Stage Bootloader

Most hobby OS projects start with GRUB. I didn't want that. GRUB hides too much — I wanted to understand the full boot sequence from the very first instruction the CPU executes.

AxiomX boots through 4 stages, all written in pure x86 Assembly:

Stage 0  →  Stage 1  →  Stage 2  →  Stage 3  →  Kernel
 BIOS        Real         Protected    Long        64-bit C
 MBR         Mode         Mode         Mode        Entry

Stage 0 (MBR): The BIOS loads 512 bytes from sector 0 into memory at 0x7C00. That's your entire budget for the first stage — 512 bytes to set up the stack, load the next stage, and hand off control.

Stage 1 (Real Mode): Running in 16-bit real mode with access to BIOS interrupts. I use this stage to call the E820 BIOS interrupt to build a memory map of the system — which memory regions are usable, reserved, or ACPI-related. This data is critical for the physical memory manager later.

Stage 2 (Protected Mode): Sets up a Global Descriptor Table (GDT), enables the A20 line, and jumps into 32-bit protected mode. No more BIOS calls from here.

Stage 3 (Long Mode): Sets up page tables for identity mapping, enables PAE and long mode via MSRs, and finally jumps into 64-bit mode before handing off to the C kernel entry point.

Writing this from scratch taught me more about x86 architecture than any textbook ever could.

Memory Management: PMM + VMM + Heap

Once the kernel is running, the first thing it needs is memory management.

Physical Memory Manager (PMM)

The PMM tracks which physical pages (4KB each) are free or used, using a bitmap allocator. Each bit represents one 4KB page. Allocating memory is a matter of finding the first 0 bit, flipping it to 1, and returning that page's address.

Simple in concept, but getting the bitmap correctly initialized from the E820 map — respecting reserved regions, kernel regions, and usable RAM — took careful work.

[pmm] Initialised: 32736 total pages, 31967 free pages

Virtual Memory Manager (VMM)

The VMM implements x86_64 paging using a PML4 page table structure with 2MB huge pages. Every virtual address goes through a 4-level page table walk before reaching physical memory.

Setting up identity mapping for the first 128MB of memory means the kernel's virtual addresses match its physical addresses — which simplifies early kernel development enormously.

[vmm] PML4 at 0x4000, 128MB identity-mapped

Kernel Heap

On top of the VMM sits a simple dynamic heap allocator — the kernel equivalent of malloc and free. Without this, the kernel can't dynamically allocate data structures at runtime.

Interrupts: IDT + PIT

The Interrupt Descriptor Table (IDT) tells the CPU what to do when an interrupt fires — whether it's a hardware timer, a keyboard press, or a CPU exception like a page fault.

Setting up the IDT involves writing 256 entries, each pointing to an ISR (Interrupt Service Routine). The tricky part is that the CPU pushes different amounts of data onto the stack for different exceptions, so you need stub handlers in Assembly to normalize the stack before jumping into C.

The PIT (Programmable Interval Timer) fires at 100 Hz — 100 times per second. Every tick is used by the scheduler to decide whether to switch tasks.

[pit] Initialised at 100 Hz (divisor=11931)

Scheduler: Round-Robin with Context Switching

The scheduler is probably the most satisfying part to get working.

AxiomX uses a round-robin scheduler — each task gets a fixed quantum (10 ticks), and when the quantum expires, the PIT fires an interrupt and the scheduler picks the next task in the queue.

The hard part is context switching — saving the current task's CPU state (all registers, stack pointer, instruction pointer) and restoring the next task's state, all in Assembly, while making it transparent to both tasks.

[sched] Initialised. Idle PID=0, quantum=10 ticks

Watching three stress workers run simultaneously for the first time — each completing exactly 50,000 iterations and confirming round-robin — was genuinely one of the best moments of this project:

AxiomX-OS> stress
  worker0 : 50000 iters
  worker1 : 50000 iters
  worker2 : 50000 iters
  Round-robin confirmed

The Shell: 24 Built-in Commands

AxiomX drops into an interactive shell on boot, with 24 built-in commands including:

mem — live memory stats and usage bar
ps — list processes and states
schedviz — visual scheduler state and timing
hexdump <addr> — hex dump memory at any address
virt2phys <addr> — walk page tables and translate virtual → physical address
regs — dump all CPU registers
stack — dump current stack + call frame chain
trace on|off — live kernel event tracing
cpuinfo — CPU info via CPUID
vmmap — virtual memory layout

TAB autocomplete and UP/DOWN history navigation are also implemented.

What I Learned

Building an OS from scratch teaches you things that no amount of high-level programming can:

Nothing is magic. Every abstraction you use daily — malloc, processes, file I/O — is code someone wrote. Once you write it yourself, you stop taking it for granted.
The CPU is deeply weird. Real mode, protected mode, long mode, segment registers, MSRs, the A20 line — x86 has 40 years of backwards compatibility baked in and it shows.
Debugging without tools is humbling. No gdb, no printf (at first), no stack traces. Just a serial port, a hex dump, and careful thinking.
The Intel manual is your best friend. Seriously. Every answer is in there.

What's Next

AxiomX-OS is still a work in progress. Planned next steps:

[ ] PS/2 Keyboard driver
[ ] FAT32 filesystem
[ ] Userspace & syscall interface
[ ] ELF loader
[ ] Basic process isolation

Try It Yourself

The full source code is on GitHub — including all 4 bootloader stages, the kernel, and a Makefile to build and run it in QEMU:

👉 github.com/ChairSleeper/AxiomX-OS

Requirements: nasm, gcc (x86_64-elf cross-compiler), ld, qemu-system-x86_64, make.

make        # build everything
make run    # run in QEMU

If this project was useful or interesting to you, consider supporting my open source work:

💖 github.com/sponsors/ChairSleeper

Every bit helps me keep building. Thanks for reading!

Rust vs C: Who is really better?

Harsh Thalwal — Mon, 10 Nov 2025 10:57:48 +0000

For decades, C has been the backbone of systems programming — powering everything from operating systems to embedded chips. But in the last few years, a new challenger, Rust, has risen with a bold promise: the performance of C without the memory bugs.

So, in this era of safer and faster programming, the question is — who wins: Rust or C?

The Legacy of C

C is the language that built the modern computing world. Created in the 1970s at Bell Labs, it’s behind UNIX, Linux, and most device firmware.

Developers love C for its speed, portability, and direct control over hardware. You know exactly what the machine is doing, line by line. But that power also comes with danger — memory leaks, segmentation faults, and buffer overflows have haunted C developers for decades.

Still, C’s simplicity and predictability made it irreplaceable — until Rust arrived.

The Rise of Rust

Rust, born at Mozilla in the 2010s, set out to fix what C could not: memory safety without performance loss.

It introduced a powerful ownership system, where the compiler enforces strict rules about who owns and accesses memory. This prevents common errors like dangling pointers or data races before your program even runs.

In short — if your Rust code compiles, it’s probably safe.

And unlike garbage-collected languages like Java or Python, Rust doesn’t rely on a runtime to manage memory. You get C-like performance with far fewer crashes.

Performance and Safety: Head to Head

Both C and Rust compile to machine code, so performance-wise, they’re neck and neck.

However, Rust takes the edge when it comes to concurrent programming — it makes sure your threads don’t access the same data in unsafe ways. In C, that’s entirely up to you (and your debugging skills).

Rust’s biggest win is memory safety. Where C demands discipline, Rust enforces it automatically. You spend less time tracking bugs and more time building actual features.

Developer Experience

C is minimalist — you can learn it quickly, but mastering it safely takes years. Rust is the opposite: it’s harder to learn, but once you grasp it, it feels empowering.

The Rust compiler is famously strict but extremely helpful. With tools like Cargo (package manager) and Clippy (linter), writing modern, maintainable code is easier than ever.

It’s not rare to see developers say, “Rust made me a better programmer.”

Use Cases and Ecosystem

C excels in: operating systems, embedded systems, compilers, and hardware-level programming.
Rust excels in: web servers, game engines, blockchain, and safety-critical systems.

Big names like Microsoft, Google, and Amazon are already integrating Rust into their core infrastructure — often replacing old C/C++ modules for better security and reliability.

That says a lot about where the industry is heading.

Verdict: Not Rivals, but Partners

So, who wins — Rust or C?

It’s not really a battle. C remains unbeatable for ultra-low-level tasks and legacy systems. But Rust is the natural successor for projects that demand both speed and safety.

In truth, Rust doesn’t want to replace C — it wants to evolve it.
One built the digital world; the other is making it safer.

Final Thoughts

Rust and C aren’t enemies — they’re milestones.
C gave us control; Rust gives us confidence.

In the end, the best developers aren’t the ones who pick sides. They’re the ones who know when to use which.

Beginner friendly Postfix-Prefix tutorial for CLI Calculator in Python.

Harsh Thalwal — Thu, 23 Jan 2025 18:30:00 +0000

Hello everyone!👋
I’m sure you’ve all seen many simple calculator tutorials online—whether on YouTube, other social media, or well you get the idea! There are tons of beginner-friendly calculator tutorials out there, but most are limited to something like this:

Enter n1 : 2
Enter n2 : 3
Enter operator (+,-,*,/) : +
Result : 5

As a coder and user, I found this approach a bit tedious. Entering numbers and operators separately feels clunky and restricts you from solving more complex expressions quickly. So, I thought, why not create a simple yet powerful calculator that can handle full mathematical expressions in one go? Something like this:

Enter : 23 - 21 * 32 / 34 + 1000
Result: 1003.2352941176471

I won’t say it’s perfect (don’t worry — the answer is correct!), but I really like how it lets me enter full expressions naturally. Plus, it’s a fun challenge to flex my problem-solving skills 😅. In this blog, I’ll share how I built this calculator, the hurdles I faced, and how you can create your own to tackle complex math with ease!

In this tutorial, I’ll keep things simple. There will still be room for improvement — and that part is up to you!

So, let’s get started! 🚀

The plan was quite simple.

Take the user input, which would be an infix expression (something like this :- 2+1-2+32).
Convert it into postfix. Which would look like this : [ 2,1,2,32,+,-,+ ].
And then solve it. How? It’s explained later in this blog post.

1. Taking the user input.

def main():
    valid_inputs = ['0','1','2','3','4','5','6','7','8','9','+','-','*','/']
    try:
        user_input = input('Enter : ')
        user_input = user_input.replace(" ","")
        for char in user_input:
            if char not in valid_inputs:
                raise ValueError("Invalid input")
    except Exception as e:
        print(e)
        return
    userinput_to_infix_generator(user_input)
if __name__ == "__main__":
    main()

Inside the main() function I did two things.

Taking the user input.
Making sure that it was a valid input.

If there is problem with the expressions like having an invalid symbol the code immediately raises a value error.

valid_inputs = ['0','1','2','3','4','5','6','7','8','9','+','-','*','/']
    try:
        user_input = input('Enter : ')
        user_input = user_input.replace(" ","")
        for char in user_input: <-----
            if char not in valid_inputs:
                raise ValueError("Invalid input")
    except Exception as e:
        print(e)
        return

The loop checks each character (char) from the user's input. If any character isn't in the valid_inputs list, a ValueErroris raised. If all characters are valid, the code moves on to the next step.

Once it’s done with comparison and it was a success. It calls the function userinput_to_infix_generator(user_input) with user_input as argument.

The userinput_to_infix_generator(user_input) function takes the clean input and turns it into a list of tokens we can later convert from infix to postfix.

You're right! Here's your full section rewritten cleanly in Markdown, with everything from your original idea included, and polished for clarity and readability — all ready to be pasted into your blog:

`userinput_to_infix_generator(user_input)`

The code itself isn’t very complex — it just turns the user_input string into a list called infix, where each number and operator is stored as a separate item.

def userinput_to_infix_generator(user_input):
    infix = []
    temp = ""
    symbols = ['+', '-', '/', '*']
    for i in user_input:<-------
        if i not in symbols:
            temp = temp + i
        else:
            infix.append(temp)
            infix.append(i)
            temp = ""
    if temp:
        infix.append(temp)
    infix_to_postfix(infix)

The key part of this function is how it handles the input when numbers are written together without clear spaces — for example, 223+32. We don't want to treat '2', '2', and '3' as separate characters. Instead, we need to combine them into a full number like "223" and then store it in the list.

This is handled inside the loop:

If the character is not an operator (+, -, *, /), it's added to a temporary string temp.
When an operator is found, the function:

1. Adds the number stored in `temp` to the `infix` list,

2. Then adds the operator,

3. And resets `temp` for the next number.

Finally, after the loop ends, if temp still holds the last number, it adds that to the list too.

Example:

For input: 12+7*5 The resulting infix list would be: ['12', '+', '7', '*', '5']

2. Convert it to postfix

Alright, now that we’ve turned our input string into a nice clean list (our infix expression), the next step is to convert that into postfix format. This part is super important — because computers find postfix (also known as Reverse Polish Notation) much easier to solve than regular infix math.

At first, I wrote a big if-else mess (you might’ve done that too 😅), but then I realized: why not use a simple approach that handles everything neatly using operator precedence?

Here’s the final version I settled on:

def infix_to_postfix(infix):
    postfix = []
    stack = []
    precedence = {'+': 1, '-': 1, '*': 2, '/': 2}
    for token in infix:
        if token not in precedence:
            postfix.append(token)
        else:
            while stack and precedence.get(stack[-1], 0) >= precedence[token]:
                postfix.append(stack.pop())
            stack.append(token)
    while stack:
        postfix.append(stack.pop())
    postfix_to_solution(postfix)

But what’s really going on here?

I created a precedence dictionary to decide which operators are stronger (* and / are stronger than + and -).
Then, I loop through each token in the infix list:
- If it’s a number, it goes straight to the postfix list.
- If it’s an operator, we compare it with the one on top of the stack:
  - If the stack's operator has higher or equal precedence, we pop it out and add it to postfix.
  - Otherwise, we just push our current operator onto the stack.
Once we're done looping, we pop any remaining operators from the stack and add them to the result.

Example Time!

Let’s say the infix expression is:

['12', '+', '7', '*', '5']

This function turns it into:

['12', '7', '5', '*', '+']

3. Solve it

`postfix_to_solution(postfix)`

Alright, we’ve got our expression nicely converted into postfix form. Now it’s time for the grand finale — solving it! This function takes that postfix list and actually computes the answer. Here's the code:

def postfix_to_solution(postfix):
    stack = []
    for token in postfix:
        if token.isdigit():
            stack.append(int(token))
        else:
            b = stack.pop()
            a = stack.pop()
            if token == '+':
                stack.append(a + b)
            elif token == '-':
                stack.append(a - b)
            elif token == '*':
                stack.append(a * b)
            elif token == '/':
                stack.append(a / b)
    if stack:
        print("Result:", stack[0])

What’s happening here?

This is a classic postfix evaluation using a stack:

If the token is a number, we push it onto the stack.
If it’s an operator (+, -, *, or /), we pop two numbers from the stack:
- a and b, where a is the second-last and b is the last one pushed.
We perform the operation: a + b, a - b, etc., and push the result back onto the stack.
In the end, if everything went well, the stack will contain one final value — the answer!

Example:

Say your postfix list is:

['12', '7', '5', '*', '+']

Here's how the evaluation would go:

Push 12
Push 7
Push 5
See * → pop 5 and 7 → push 35
See + → pop 35 and 12 → push 47

Final result: `47`

Quick Note

This code uses `int()` to convert digits, so it won’t work with decimal numbers like `2.5` yet. If you want to support floats, just change `int(token)` to `float(token)` — easy fix!

And that’s it…, now ask yourself.

“Is there any room of improvement?”

Yes! A lot!.

There’s also one major issue with this calculator. Try giving it an input like 2++3-2 — yeah, it breaks! 😅 It doesn’t currently handle invalid operator sequences properly. I’m leaving this part on you to fix.

There are a lot of other things you can do with this, maybe try adding brackets support?.

🎯 Wrapping it up

This calculator may be simple, but building it helped me understand how real interpreters work behind the scenes. From reading input, validating it, converting between notations, and finally evaluating — it’s all there.

There’s still room for improvements — like handling decimals, parentheses, or even making a GUI. But I’ll leave that challenge to you!

Thanks for reading 😄

Let me know in the comments what you added or improved!

DEV Community: Harsh Thalwal

I Built a 64-bit OS from Scratch in C and Assembly — No GRUB, No Shortcuts

Why build an OS?

The Architecture: A Custom 4-Stage Bootloader

Memory Management: PMM + VMM + Heap

Physical Memory Manager (PMM)

Virtual Memory Manager (VMM)

Kernel Heap

Interrupts: IDT + PIT

Scheduler: Round-Robin with Context Switching

The Shell: 24 Built-in Commands

What I Learned

What's Next

Try It Yourself

Rust vs C: Who is really better?

The Legacy of C

The Rise of Rust

Performance and Safety: Head to Head

Developer Experience

Use Cases and Ecosystem

Verdict: Not Rivals, but Partners

Final Thoughts

Beginner friendly Postfix-Prefix tutorial for CLI Calculator in Python.

1. Taking the user input.

userinput_to_infix_generator(user_input)

Example:

2. Convert it to postfix

But what’s really going on here?

Example Time!

3. Solve it

postfix_to_solution(postfix)

What’s happening here?

Example:

Final result: 47

Quick Note

This code uses int() to convert digits, so it won’t work with decimal numbers like 2.5 yet. If you want to support floats, just change int(token) to float(token) — easy fix!

There are a lot of other things you can do with this, maybe try adding brackets support?.

🎯 Wrapping it up

`userinput_to_infix_generator(user_input)`

`postfix_to_solution(postfix)`

Final result: `47`

This code uses `int()` to convert digits, so it won’t work with decimal numbers like `2.5` yet. If you want to support floats, just change `int(token)` to `float(token)` — easy fix!