What architectural state is saved during context switch?

Question

What architectural state is saved during context switch? As far as I know, what is saved is the following

Set of registers including PC counter TLB (If it is not flushed...) what else ? Memory? (containing stack, heap, data)... ? Is it just left in the memory?

Answer 1

Memory/stack heap are part of the process's address space so there is no need to save them. Yes, they can be left there. Each process would have it's own starting address in physical memory.

Processes appear to be using, from their userland point of view, their own full range of memory starting from 0x00000000 (some operating systems trap accesses in the first page 0x00000000-0x00000fff to catch null pointers? - for these the effective start is 0x00001000) However, the MMU remaps memory behind the scenes with page tables and all that good stuff. So this is how memory can be allocated to a userland process, without the process even knowing or caring except for the total amount of memory (the upper limit) it can access.

The stack pointer, however, does need to be saved, but that's part of the registers.

Answer 2

Depends on the processor and, by inference, what is needed to represent the task state. Also depends, to a degree, on the OS.

In the old original (pre-virtual-memory) Unix the registers would be saved into a fixed location in memory, then the entire user memory written to disk and a new user memory image read in. (Unix "fork" was accomplished by simply skipping the "read it in" step.) This was very quickly supplanted by a virtual swap scheme when CPUs with TLBs became available ("Berkley Unix").

In a Burroughs-style stack architecture all that need be swapped (in theory) is the stack pointer and the task ID. Memory addressing (in the original) is via "capabilities" and "segments", vs using a TLB.

Older register architectures with TLB-based virtual memory required that the TLBs (and sometimes cache) at least be invalidated on swap, in addition to swapping the program registers (including IAR, condition code, etc). Newer TLB-based architectures finesse this issue various ways, avoiding flushing so that a fairly quick switch back does not need to reload everything. (For this reason, on multiprocessor system, tasks are often given an "affinity" of a given processor, to minimize the amount of TLB/cache reloading.)