When used without other qualification, The Stack refers to one of two things (which in many systems are handled the same way).
In languages such as Cee Language/Cee Plus Plus, Java Language, or Rexx Language, a contiguous region of memory used to hold Activation Records (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 Cactus Stack, and some (like Smalltalk Language) allocate activation records on The Heap.
In Stack Based Languages such as Forth Language, Joy Language, or Post Script, 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 Activation Record 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.
Rexx Language is not a stack-based language. It's an applicative, infix language just like BASIC or PL/1. I corrected this above. --Samuel Falvo
In many architectures, The Stack has CPU support of some kind (a dedicated register to hold the current address--the Stack Pointer, dedicated memory space, preferential cache treatment, etc). In many other architectures, a General Purpose Register is used by convention (on PowerPC processors, register R1 is used as the stack pointer in the various Power Pc Application Binary Interfaces; even though there isn't anything special about this particular register in the Instruction Set Architecture).
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 The Stack 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 Guard Page at the bottom/top of the stack; any memory access to this page results in a page fault. The Java Virtual Machine is required to verify that the operand stack sizes are correct when loading a class.)
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 The Stack; 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). --Samuel Falvo
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.
See original on c2.com 