Stored-program computer¶
A computer design in which a processor fetches instructions from an internal program store, with code and data held in shared or separate memory.
Core Idea¶
A stored-program computer represents executable instructions in an internal store and fetches them during execution. The instructions select operations without requiring the processor's control wiring to be changed for each task. Where the store can be loaded or rewritten, changing its instructions changes what the machine does; the possibility of updating a running machine is a further, configuration-dependent capability.[1][2]
The mechanism is instruction storage and fetch. It does not require one common memory for instructions and data. The Manchester Baby kept both in a CRT random-access store, whereas the ATmega328P fetches instructions from Flash program memory and uses a separate data-memory space. Those unlike machines preserve the same decisive relation between encoded instructions, a program store, and the processor.[1][2]
Structural Signature¶
- Encoded instructions. Operations must be represented as values in the program store. Fixed control wiring alone does not supply this role.[1][2]
- Internal program store. The computer retains the instruction sequence in memory available to its processor during execution. The medium can be volatile CRT RAM or nonvolatile Flash; the medium is not the identity.[1][2]
- Fetch and execution control. The processor obtains a stored instruction, interprets it as an operation, and continues through the program. A memory containing code that the processor never fetches is merely storage, not this execution design.[1][2]
- A loading or replacement possibility. A writable store makes changing tasks possible by changing instructions rather than rewiring control, as the Baby's keyboard loading demonstrates. This is a characteristic affordance, not a claim that every deployed device supports in-system rewrite.[1][2]
- Data organization as a variant. Operands may be held in the same memory as instructions or in a separate data space. Neither arrangement is constitutive of stored-instruction fetch.[1][2]
The first three roles identify the mechanism. The last two distinguish capabilities and implementations that must be checked for a particular machine.
What It Is Not¶
It is not a synonym for every programmable computer. A machine can be programmed through a physical configuration or another control path without the processor fetching encoded instructions from an internal program store. Conversely, a stored instruction need not be writable by the running application. The contrast is how execution receives its instructions, not whether a user can call the machine programmable.[1][2]
It is also not synonymous with a von Neumann shared-memory layout. The Baby used a common store, while the ATmega328P has separate program and data memories and buses. Treating self-modifying code, program generation, a compiler, or a bootloader as mandatory would incorrectly exclude legitimate stored-program designs. The ATmega328P provides bootloader support, but the capability and protections depend on configuration.[1][2]
Scope of Application¶
The identity applies to computer hardware in which a processor executes instructions fetched from an internal program memory. In the inspected sources this includes a historical research computer with a writable electronic random-access store and an embedded microcontroller with nonvolatile Flash program memory. The same test can be applied to other processors, but their memory organization, loading method, and protection rules must be established separately.[1][2]
The category concerns architecture, not a particular programming language, instruction set, manufacturer, or date of invention. A device's program can be small or large; the necessary question is whether encoded instructions in its store drive the execution cycle.
Clarity¶
Ask three questions in order: Where are the executable instructions represented? How does the processor fetch them? What changes when the task changes? The first two decide whether the stored-program identity is present. The third describes a machine's loading or update path and should not be silently upgraded into a universal self-rewrite claim.[1][2]
For the Baby, instructions and numbers shared CRT memory and a different program could be entered by resetting memory through a keyboard. For the ATmega328P, the CPU prefetches from Flash while data occupy a separate space; a configured bootloader can support software updates. These are different answers to the implementation questions, not different definitions of stored-program execution.[1][2]
Manages Complexity¶
Encoding operations in memory separates which program runs from the fixed circuitry that carries out instruction fetch and execution. The distinction lets an analyst describe a computer's changing tasks without redescribing its control wiring each time. Manchester's account explicitly contrasts loading a new program into memory with reconfiguring electronic circuitry.[1]
The simplification has a limit: it does not specify how quickly a program loads, whether program bytes are writable during execution, or whether code and operands share a bus. Those questions re-enter when comparing the CRT store with Flash and SRAM or assessing a concrete device's performance and protection settings.[1][2]
Abstract Reasoning¶
The central counterfactual is to hold the processor fixed and change the instruction contents. If the subsequent operations change because the processor fetches different stored instructions, the program is controlling the computation through the store. If changing the task instead requires rewiring the control circuit, the stored-program mechanism has not been shown.[1]
This reasoning also separates program storage from program/data unification. The Baby and the ATmega328P differ on the latter while both satisfy the former. An analyst who observes separate memories therefore cannot conclude that a machine lacks a stored program.[1][2]
Knowledge Transfer¶
The test transfers within computer architecture: locate encoded instructions, the store that retains them, and the processor's fetch path. It works for a CRT-memory research machine and for a Flash-based embedded controller despite their unlike eras and memory layouts. What does not transfer automatically is the Baby's shared writable store or the microcontroller's bootloader and lock-bit behavior.[1][2]
Calling a written recipe or an organization's instructions a “stored program” is a metaphor unless a computer actually fetches encoded instructions from a program store to control execution. The computer-architecture mechanism supplies the domain boundary.
Examples¶
Canonical: Manchester Small-Scale Experimental Machine¶
The Manchester Baby held both calculation numbers and encoded program instructions in a Williams-Kilburn CRT random-access store. Its processor read instructions successively. Another task could be set by resetting part of memory with a keyboard rather than reconfiguring circuitry. Mapped back: CRT words supply the encoded instructions and internal store; successive reads supply fetch; keyboard entry supplies a program-replacement path; shared storage for numbers is this machine's variant, not a universal requirement.[1]
Applied: ATmega328P embedded controller¶
The ATmega328P fetches instructions from on-chip Flash program memory, prefetching the next instruction while the current one executes. Its architecture has separate program and data memories and buses, with SRAM in the data space. A configured Flash-resident bootloader can update application code. Mapped back: Flash supplies encoded instructions and the internal store; CPU prefetch supplies the execution path; bootloader support supplies a conditional replacement route; separate SRAM is the contrasting data organization. An individual deployed unit's update capability depends on its configuration and protection settings.[2]
Structural Tensions¶
The two inspected machines establish different memory arrangements, but their descriptions do not by themselves establish a general two-sided design trade-off with a defensible decision rule. This entry therefore does not invent one. In a concrete design review, write access, retention, update time, and protection would require device-specific evidence before being framed as competing pressures.[1][2]
Structural–Framed Character¶
The entry is mixed, leaning structural within computing. Vocabulary travel: “stored instructions” is useful only when instruction values are actually fetched by a processor. Evaluative weight: the label identifies an execution arrangement, not a judgment that one computer is generally better. Institutional origin: historical naming does not create the mechanism; an operational fetch path does. Human-practice dependence: a person may load a program, but the constitutive relation is between stored instruction values and machine execution. Import versus recognition: the pattern can be recognized in unlike computer devices; applying it to an organization or recipe imports the term by analogy. Its character: mixed-structural, because the instruction-store/fetch relation transfers between unlike machines while processor instruction encoding keeps the literal identity within computing.
Structural Core vs. Domain Accent¶
The liftable skeleton includes encoding relevant features of an operation in a stored medium. The catalog's Representation Prime owns that target-to-medium relation, which is an internal constituent of this computer design. Whether the wider stored-representation/control relation deserves a distinct cross-domain Prime is a future-Prime question requiring unlike noncomputer cases. The named entry does not itself clear that bar: remove machine instructions, program memory, and processor fetch, and the resulting relation is no longer a stored-program computer. Those commitments form the domain core, not decorative vocabulary.
Instantiates / Related Primes¶
This entry is part of Representation.
The catalog's Representation Prime names the code-to-operation relation that every fetched instruction requires, giving a strict composition edge because Representation is inside this computer design. Symbolic Representation is related, but its full interpretive and community commitments have not been shown to be necessary for every machine. The live domain-specific Computer Architecture entry describes a whole system's organization, while Instruction Set Architecture describes the programmer-visible instruction contract. A stored-program arrangement can use an ISA, but the contract and the storage/fetch design are not the same identity. No other strict parent relation has been established.
Relationships to Other Abstractions¶
Current abstraction Stored-program computer Domain-specific
Parents (1) — more general patterns this builds on
-
Stored-program computer is part of Representation Prime
A stored-program computer requires encoded instructions whose values represent operations and operands under a processor decoding convention.Stored instruction words are a medium distinct from the operations they select. Instruction fields map to operation and operand effects according to a machine-specific decoding convention, preserving the features needed for execution while omitting circuit detail. The processor uses that mapping when it fetches and executes each instruction. Without this representation relation, stored bits cannot select operations. Thus Representation is an internal constituent of every stored-program computer, not a genus of computers; the parent is inside the child.
Hierarchy path (1) — routes to 1 parentless root
- Stored-program computer → Representation → Abstraction
Neighborhood in Abstraction Space¶
Stored-program computer sits in a sparse region of the domain-specific corpus (95th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Unclustered & Miscellaneous (2721 abstractions)
Nearest neighbors
- Instruction Set Architecture — 0.78
- Processor Design — 0.78
- Typed assembly language — 0.78
- Register–memory architecture — 0.77
- Random-Access Machine — 0.77
Computed from structural-signature embeddings · 2026-10-17
Not to Be Confused With¶
- Program-as-data capability. Shared writable instruction/data storage may enable it, but separate program Flash demonstrates that it is not necessary.[1][2]
- A bootloader. This is one conditional means of updating code, not the definition of a stored-program computer.[2]
- An instruction set architecture. An ISA specifies operations and programmer-visible state; it does not alone specify where a machine stores a running program.
- The first computer. Historical priority depends on the criteria being compared; no priority claim is needed to recognize the architecture.
References¶
[1] University of Manchester Computer50 archive, “The Manchester Small Scale Experimental Machine — The Baby”, Background paragraphs on CRT store, stored instructions, successive reads, and keyboard program replacement; Specification on store and input. University-hosted historical account, directly inspected; cited for this machine's described design, not a disputed universal priority claim. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t
[2] Atmel Corporation (2015). ATmega328P Datasheet, 7810D–AVR–01/15, §§6.1, 7.1–7.3, 26.2–26.5 (printed pp. 9, 17–18, 229–231). Manufacturer primary technical documentation, directly inspected; bootloader update support is configuration dependent. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s