The Stack

When used without other qualification, TheStack refers to one of two things (which in many systems are handled the same way).

• In languages such as CeeLanguage/CeePlusPlus, JavaLanguage, or RexxLanguage, a contiguous region of memory used to hold ActivationRecords (which in turn contain such things as local variables, function/method arguments, return address of caller, other things as required by the language). Note that not all languages use a single stack for this purpose--multithreaded programs in C/C++ use one stack per thread; some languages use a CactusStack, and some (like SmalltalkLanguage) allocate activation records on TheHeap.

• In StackBasedLanguages such as ForthLanguage, JoyLanguage, or PostScript, the implicit data stack which commands operate on or data can be stored for later processing. In Forth, for example, there are usually two stacks: one for manipulating arguments, and one for holding return addresses (often treated as a stack of partial continuations). Characteristically, there is no concept of an ActivationRecord in stack-based languages. In the particular case of Forth, some systems may use a separate "floating-point stack" if it's more convenient to do so (e.g., as when using an Intel 80x87-based FPU). Some ANSI Forth systems may even implement a fourth, transient stack called the control stack, for holding control-flow state while compiling definitions into executable form. This stack only exists while compiling, however.

RexxLanguage is not a stack-based language. It's an applicative, infix language just like BASIC or PL/1. I corrected this above. --SamuelFalvo?

In many architectures, TheStack has CPU support of some kind (a dedicated register to hold the current address--the StackPointer?, dedicated memory space, preferential cache treatment, etc). In many other architectures, a GeneralPurposeRegister? is used by convention (on PowerPC processors, register R1 is used as the stack pointer in the various PowerPc ApplicationBinaryInterface?s; even though there isn't anything special about this particular register in the InstructionSetArchitecture?).

As stacks generally have to occupy contiguous areas of address space, stack management can become a big problem with some operating systems, especially for multi-threaded programs. Also, since access to TheStack generally has to be fast, most languages do not peform runtime checks for stack overflow. (One common technique employed by many operating systems is to have a GuardPage? at the bottom/top of the stack; any memory access to this page results in a page fault. The JavaVirtualMachine is required to verify that the operand stack sizes are correct when loading a class.)

How does paging TheStack work? Don't interrupts use TheStack too?

In user applications, virtual memory pages related to the stack can be paged in and out, just like any other application data pages.

Software interrupts such as Unix signal/signal handlers do use TheStack; the previous context is pushed wherever the SP happens to be pointing.

More precisely: When an exception is triggered (either a software or hardware trap, interrupt, et. al.), the microprocessor pushes this information onto a kernel stack, not on the process stack. The kernel stack is located in a swath of memory that is guaranteed to always be in RAM at all times. The current user stack pointer (usually abbreviated USP, to distinguish it from the kernel or system stack pointer, SSP) is pushed onto the kernel stack, thus providing the necessary linkage to allow the kernel to return back to the user process. At it's option, the kernel MAY choose to off-load some state onto the user stack and adjust the USP accordingly, then return back to the user-mode process, thus effecting an "asynchronous subroutine" (as VMS calls them) or "signal" (as Unix calls them). --SamuelFalvo?

In some language implementations this has sometimes meant that a stack backtrace isn't available from the debugger from within a signal handler, because the previous stack frame isn't in the canonical form, since the signal handler function was called unexpectedly.

The OS stack is (in a protected memory environment) a separate area from that of application process stacks, and may or may not be paged. Operating systems typically have a certain set of pages that are locked in physical memory.

True (hardware) interrupts depend on the host cpu architecture for their details, but they switch to privileged mode and save context somewhere -- possibly in a reserved area, possibly on a stack. For the purpose of discussion one can imagine that it saves the previous context to the primary OS stack (there might be several in multi-threaded OSes).

The "bottom half" of interrupt handlers queue a request to handle the interrupt and then return as rapidly as possible; it's A Bad Thing to spend much time in interrupt routines. The OS then handles that request at its leisure.