Implement Context Switching in Assembly

Topic Overview

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.

Your Task

Simulate cooperative green threads on x86-64, using a context switch that follows the System V ABI. A switch_context function is an ordinary call, so it only has to preserve the callee-saved registers: rbx rbp r12 r13 r14 r15 (and rsp, which is implicit in the saved stack). The caller-saved registers (rax rcx rdx rsi rdi r8–r11) are not saved. After a switch they hold whatever the previous task left in them. Run the task programs and show exactly what survives a yield.

Input

cCopy
Loading…

REG is one of the 15 general-purpose registers rax rbx rcx rdx rsi rdi rbp r8 … r15 (rsp is not allowed). Leading spaces are ignored.

Rules

• All 15 registers start at 0. The first task starts running immediately.
• yield switches to the next live task in declaration order (wrapping around). It saves the current task's six callee-saved registers and loads the next task's six. A task that has never run loads zeros from its initial fake frame. If no other task is alive, print NAME: yield, no other task and continue.
• exit marks the task dead and switches to the next live task without saving anything. If no task is left, the run ends.
• An unknown instruction or register prints NAME: bad instruction: LINE and is skipped.

Output

cCopy
Loading…

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Keep one shared array of 15 CPU registers, and give each task only a six-entry save area. That is all the real switch_context stores (plus the stack pointer).
2. Leave the caller-saved registers alone during a switch, so that the "leak" between tasks is visible.

Hidden tests cover caller-saved values leaking between three tasks, register-to-register mov and add, all six callee-saved registers surviving several round trips, yield when every other task has exited, implicit exit at the end of a program, and bad instructions such as rsp or unknown opcodes.