Implement Context Switching in Assembly

Saving What the CPU Forgets

A context switch swaps the CPU from one process to another. The hardware only knows about registers and the program counter; the kernel must persist everything else in the PCB before handing the core to a different address space. Get the stack pointer wrong and the next ret jumps into garbage.

Assembly-Level Steps

A minimal switch on x86-64 looks like this:

• Push callee-saved registers (rbx, rbp, r12-r15) onto the outgoing stack
• Store rsp into old_pcb->kernel_sp
• Load new_pcb->kernel_sp into rsp
• Pop registers and ret into the incoming thread

nasmCopy
Loading…

For example, if process A's kernel stack pointer is 0xFFFF8000 and B's is 0xFFFF7000, only two pointer writes separate their execution worlds.

Why This Matters in Production

This is literally what glibc's swapcontext()/ucontext.h and Boost.Context do under the hood, and it's the same register-save trick that powers Go's goroutine scheduler and Lua coroutines. Getting the callee-saved register set wrong here is a real class of bug: a single missing pushq %rbp silently corrupts the caller's stack frame and manifests as a crash arbitrarily far from the actual switch.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will implement switch_context in assembly and wire it to your scheduler. This exercise requires correct callee-saved discipline; debuggers show the same register blobs in core dumps when threads collide.