Erfahren Sie, wie die Idee der gespeicherten Programme — häufig mit John von Neumann verbunden — wiederverwendbare Software, Allzweckrechner und modernes Programmieren ermöglichte.
Im Kern der modernen Informatik steht eine einfache Frage: Was machte es möglich, dass eine Maschine viele verschiedene Aufgaben erfüllt, ohne jedes Mal umgebaut werden zu müssen? Frühe elektronische Rechner konnten zwar schnell rechnen, aber um die Aufgabe zu ändern, musste oft physisch an der Maschine verändert werden. Die Idee der gespeicherten Programme ist der Wendepunkt, der Computer wirklich programmierbar machte.
Ein speicherprogrammierter Computer legt die Anweisungen für eine Aufgabe (das Programm) im gleichen internen Speicher ab wie die Daten, an denen das Programm arbeitet. Statt Hardware umzustecken oder Schaltfelder neu zu konfigurieren, lädt man einen neuen Instruktionssatz in den Speicher und führt eine andere Aufgabe aus.
Das klingt heute banal, war aber ein tiefgreifender Wandel:
Das ist keine bloße historische Fußnote. Das Konzept erklärt, warum „Software“ als etwas Eigenständiges neben „Hardware“ existiert und warum ein Update heute neue Funktionen bringen kann, ohne die Chips auszutauschen.
In den folgenden Abschnitten betrachten wir die Probleme der frühen Rechner, was die gespeicherte‑Programm‑Lösung änderte, die Personen und Dokumente, die die Idee klärten (einschließlich des berühmten EDVAC‑Berichts), und wie der Begriff „von‑Neumann‑Architektur“ zu einem weit verbreiteten Entwurfsmodell wurde.
Obwohl John von Neumanns Name stark mit gespeicherten Programmen verbunden ist, wird die Anerkennung auf ein breiteres Team und eine ganze Epoche verteilt. Viele Forscher näherten sich ähnlichen Ideen, während sie die ersten praktischen elektronischen Computer bauten. Dieser Artikel behält diesen Kontext bei, weil das Verständnis der Teamleistung erklärt, wie sich die Idee so rasch verbreiten und zum Standardmodell werden konnte.
Vor der gespeicherten‑Programm‑Idee „liefen“ viele frühe Computer nicht im heutigen Sinn. Sie rechneten zwar beeindruckend, aber das Sagen, was zu tun ist, bedeutete häufig, die Maschine physisch zu verändern.
Eine verbreitete Methode waren Stecktafeln, Patchkabel und Schaltfelder. Bediener verbanden Steckkontakte, stellten Schalterreihen ein und passten manchmal Timing‑Elemente an, damit Signale in der richtigen Reihenfolge ankamen. Das „Programm“ war kein Datei‑Ladevorgang, sondern ein temporäres Verdrahtungsschema.
Dieses Vorgehen funktionierte, hatte aber versteckte Kosten: jede neue Aufgabe war ein kleines Ingenieursprojekt. Wollte man die Reihenfolge von Operationen ändern (addieren, multiplizieren, vergleichen, Schleifen), musste man vielleicht Dutzende oder Hunderte Verbindungen verschieben. Ein falsch gestecktes Kabel konnte subtile Fehler verursachen, weil die Logik über Hardwareverbindungen verteilt und nicht als lesbare Schritte dokumentiert war.
Umkonfigurieren konnte Stunden oder Tage dauern, besonders wenn die Maschine dafür abgeschaltet, neu verkabelt und getestet werden musste. Das führte zu geringer Flexibilität: Maschinen waren oft längere Zeit für einen bestimmten Berechnungstyp verplant, weil ein Wechsel so störend war.
Stellen Sie sich eine Maschine vor, die für die Berechnung von ballistischen Tabellen eingerichtet ist — lange, repetitive Rechnungen mit einer festen Formel. Wollte man dieselbe Maschine danach für die Aufbereitung statistischer Ergebnisse einer Volkszählung einsetzen, war das kein schnelles „Programm editieren und erneut ausführen“. Ablaufreihenfolge, Zwischenspeicher und bedingte Prüfungen konnten sich unterscheiden und erforderten ein vollständiges Neudesign der Stecktafel und erneute Verifikation.
Genau aus dieser Welt sollte der speicherprogrammierte Computer ausbrechen.
Ein speicherprogrammierter Computer ist eine Maschine, in der die Anweisungen (das Programm) im gleichen Arbeits‑Speicher liegen wie die Daten, mit denen das Programm arbeitet. Anders gesagt: der Rechner trennt nicht zwischen „was zu tun ist“ und „worauf gearbeitet wird“ — beides sind Bit‑Muster im Speicher.
Als die Pioniere vom Speicher sprachen, meinten sie das schnelle, direkt nutzbare interne Speichersystem — das, was wir heute am ehesten mit RAM vergleichen. Es ist der Ort, von dem die CPU schnell lesen und in den sie schreiben kann, während sie läuft.
Das unterscheidet sich vom langfristigen Speicher wie Festplatten oder SSDs. Solche Laufwerke sind gut zum Aufbewahren von Dateien bei ausgeschaltetem Gerät, aber sie sind nicht das unmittelbare Notizblatt, von dem die CPU konstant die nächste Anweisung holt oder Zwischenergebnisse aktualisiert.
Sobald Anweisungen im Speicher liegen, wird das Umschalten von Aufgaben deutlich einfacher: man lädt ein neues Programm in den Speicher und führt es aus, ohne umzubauen, umzustecken oder mechanisch neu zu konfigurieren. Dieselbe Allzweckmaschine kann morgens Löhne berechnen und nachmittags ballistische Aufgaben übernehmen — weil das „Wie“ der Aufgabe nur ein anderer Satz von Bits ist, den man ersetzen kann.
Stellen Sie sich eine Küche vor, in der Rezept und Zutaten im gleichen Vorratsschrank aufbewahrt werden. Der Koch (die CPU) geht wiederholt in den Schrank (Speicher), liest den nächsten Rezeptschritt (die Anweisung) und holt oder ändert Zutaten (Daten).
Möchten Sie ein anderes Gericht, müssen Sie die Küche nicht umbauen. Sie tauschen nur das Rezept — und benutzen dieselben Arbeitsflächen, den Ofen und die Utensilien.
John von Neumann „erfand“ den Computer nicht allein, und er entwickelte die Idee der gespeicherten Programme nicht im Alleingang. Was er jedoch sehr wirkungsvoll tat, war, ein vielversprechendes Konzept in eine klar formulierte, weithin verbreitete Entwurfsvorlage zu gießen, auf die andere Ingenieure und Labore aufbauen konnten.
Von Neumann war in Kriegs‑ und Nachkriegsprojekten der Rechenmaschinen beratend tätig, half Teams und schärfte die logische Struktur früher Entwürfe. Er hatte ein Talent, komplexe technische Entscheidungen klar und organisiert zu erklären. Das war wichtig, weil die Entwicklung elektronischer Rechner schnell voranschritt und mehrere Gruppen gleichzeitig ähnliche Probleme lösten.
Außerdem verfasste und verbreitete er einflussreiche Beschreibungen, wie ein Computer Programm‑Instruktionen im gleichen Speicher wie Daten halten kann. Diese klare Darstellung erleichterte es anderen, die Idee zu diskutieren, zu lehren und nachzubauen.
Namen bleiben oft an der Person haften, deren Darstellung zum Referenzpunkt wird — nicht unbedingt an der ersten Person mit einer Idee. Von Neumanns Ausarbeitungen wurden breit gelesen, kopiert und zitiert, sodass spätere Leser die Organisation der gespeicherten Programme natürlich mit ihm assoziierten.
Diese Zuschreibung vereinfacht die Geschichte: „von‑Neumann‑Architektur“ zu sagen ist leichter, als alle Beitragenden und Berichte aufzuzählen. Dabei verliert man jedoch leicht den differenzierten Blick auf die tatsächlichen Abläufe.
Die frühe elektronische Datenverarbeitung war eine kooperative Anstrengung von Mathematikern, Ingenieuren und Programmierern. Die gespeicherte‑Programm‑Idee reifte durch Diskussionen, Entwürfe, Prototypen und Revisionen in mehreren Teams. Von Neumanns bleibende Rolle war es, die Idee zu kristallisieren und zu verbreiten — ihre Verbreitung zu beschleunigen — nicht, sie allein erfunden zu haben.
EDVAC (Electronic Discrete Variable Automatic Computer) war eines der frühen Nachkriegsprojekte, das über „Einzelmaschinen“ hinausgehen wollte. Mindestens ebenso wichtig wie die Hardware war die Entscheidung, die Entwurfsprinzipien schriftlich festzuhalten und damit teilbar zu machen. Damals war Rechnerbau noch eng mit experimenteller Ingenieursarbeit verknüpft — Wissen lebte in Laborheften, Meetings und den Köpfen weniger Spezialisten. Ein Bericht konnte diese verstreuten Einsichten in eine Form bringen, die andere Teams diskutieren, kritisieren und wiederverwenden konnten.
Der First Draft of a Report on the EDVAC (häufig schlicht „EDVAC‑Bericht“) legte die gespeicherte‑Programm‑Idee konzeptuell dar: Ein Computer sollte Programm‑Instruktionen im gleichen internen Speicher wie Daten halten. Der Speicher ist nicht nur ein Ort, um Zahlen während einer Berechnung temporär zu halten — er enthält auch die Schritte, die der Maschine sagen, was als Nächstes zu tun ist.
Diese Darstellung macht aus einem Computer weniger ein festes Zweckgerät und mehr eine allgemeine Maschine, die durch Ändern des Speicherinhalts „umprogrammiert“ werden kann. Statt das System neu zu verkabeln, lädt man eine andere Instruktionsfolge.
Über das Konzept hinaus half der Bericht, die gemeinsame Sprache für Rechner zu standardisieren: Speicher, Steuerwerk, Rechenwerk und Ein/Ausgabe als getrennte funktionale Teile, die zusammenarbeiten. Eine geteilte Begrifflichkeit und eine weit verbreitete Beschreibung erklärten nicht nur EDVAC — sie gaben der ganzen Fachwelt ein gemeinsames Denkmodell zum Bauen, Vergleichen und Verbessern speicherprogrammierter Computer.
Die Frage „Wer hat den speicherprogrammierten Computer erfunden?“ lädt fast zwangsläufig zu einer Ein‑Namen‑Antwort ein — aber Wissenschaft und Technik funktionieren selten so. Ideen entwickeln sich oft parallel, werden durch Diskussionen geschärft und überzeugend, wenn sie in Hardware demonstriert werden.
John von Neumann ist eng mit der Idee verbunden, doch die frühe Arbeit umfasste viele Personen und Gruppen:
Ein speicherprogrammierter Computer ist kein einzelner Geistesblitz. Er vereint (1) die konzeptionelle Einsicht, dass Anweisungen wie Daten im Speicher liegen können, (2) das Ingenieurwissen zum Bau zuverlässiger Speicher‑ und Steuerwerke und (3) Programmierpraktiken, die das Design nutzbar machen. Verschiedene Personen trugen zu verschiedenen Teilen bei.
Ein weiterer Grund für die gemeinsame Anerkennung: Einen Vorschlag zu machen ist nicht dasselbe wie eine Maschine zu bauen, die zuverlässig Tag für Tag läuft. Berichte und Diskussionen machten das Konzept klarer; Prototypen und Produktionssysteme bewiesen die Umsetzbarkeit. Eine sorgfältige Geschichte würdigt beide Arten von Beiträgen, ohne einen simplen „Erfinder“ zu verlangen.
Wenn Leute von „von‑Neumann‑Architektur“ sprechen, meinen sie meist ein einfaches, oft gelehrtes Modell, wie ein speicherprogrammierter Computer organisiert ist. Es ist kein Markenname oder eine einzelne historische Maschine — sondern eine praktische Bezeichnung für ein Grundkonzept, das in vielen Computern wiederkehrt.
Konzeptionell sieht das Modell so aus:
Der Kernpunkt: Die CPU hat keinen separaten physischen Ort für „das Programm“ und „die Zahlen“. Sie holt alles aus dem Speicher.
Die CPU arbeitet ein Programm ab, indem sie meist eine Schleife durchläuft, die man als fetch–decode–execute beschreibt:
Die Beschreibung ist vereinfacht, fasst aber das Wesentliche: Das Programm ist eine Folge von im Speicher abgelegten Instruktionen, die die CPU schrittweise abarbeitet.
Instruktionen und Daten im selben Speicher zu haben macht einen Computer auf praktische Weise allgemein nutzbar:
„Von‑Neumann‑Architektur“ ist am besten als Kurzbezeichnung für das speicherprogrammierte Modell mit CPU, gemeinsamem Instruktions‑/Datenspeicher und I/O zu verstehen — stark mit von Neumanns klaren Erklärungen verbunden, auch wenn viele am Entstehen der Idee beteiligt waren.
Man spricht oft, als seien „von‑Neumann“ und „Harvard“ konkurrierende Philosophien. Tatsächlich sind es zwei praktische Möglichkeiten, wie Instruktionen und Daten angeordnet werden, damit der Rechner sie abrufen kann.
In einem von‑Neumann‑Design leben Instruktionen und Daten im gleichen Speicher und laufen meist über denselben Pfad zur CPU.
Das ist konzeptionell einfach: Programm‑Bytes liegen direkt neben Zahlen, Texten und Bildern. Es macht allgemeines Rechnen unkompliziert — Software lässt sich mit denselben Mechanismen wie Daten laden, ändern und speichern.
Der Nachteil: Wenn Instruktionen und Daten sich die „Straße“ teilen, konkurrieren sie um Bandbreite. (Man spricht hier manchmal vom „Bottleneck“.)
Eine Harvard‑Architektur trennt Instruktions‑ von Datenspeicher, oft mit separaten Pfaden für jeden.
Diese Trennung erleichtert es, die nächste Instruktion zu holen, während gleichzeitig Daten gelesen oder geschrieben werden — nützlich in kleinen, voraussehbaren Systemen. Ein typisches Beispiel sind viele Microcontroller, bei denen der Programmcode in Flash liegt und Variablen in RAM.
Moderne CPUs wirken für Software oft wie von‑Neumann‑Maschinen (ein einheitlicher Adressraum), nutzen intern aber Harvard‑ähnliche Tricks. Ein Beispiel sind getrennte Instruktions‑ und Daten‑Caches (I‑Cache und D‑Cache). Für das Programm fühlt es sich wie ein einziger Speicher an, die Hardware kann jedoch Code und Daten effizienter holen.
Merke: Es gibt keinen universellen Sieger. Von‑Neumann betont Einfachheit und Flexibilität; Harvard betont Trennung und Durchsatz. Viele Systeme kombinieren beides, um Programmierbarkeit, Kosten, Energieverbrauch und Geschwindigkeit auszubalancieren.
Ein speicherprogrammierter Computer lädt einen Instruktionssatz aus dem Speicher, führt ihn aus und kann später einen anderen laden. Dieser Wandel machte Software wiederverwendbar und teilbar: Ein Programm konnte einmal geschrieben, gespeichert, kopiert, verbessert und verteilt werden, ohne die Hardware zu berühren.
Wenn das Programm im Speicher liegt, kann dieselbe physische Maschine viele verschiedene Aufgaben erledigen, indem man einfach die Instruktionen austauscht. Das ist die praktische Bedeutung von „Allzweck“: eine Maschine, viele Programme. Der Computer ist nicht durch einen einzigen Workflow definiert, sondern wird zur Plattform.
Ein aktuelles Beispiel ist Ihr Laptop, der E‑Mail, Spiele und Tabellenkalkulationen ausführt — alles dieselbe Grundidee: die Hardware bleibt, die Programme wechseln.
Sobald Instruktionen wie Daten behandelt werden, wird es möglich, Software‑Schichten zu bauen, die das Schreiben von Software erleichtern:
Diese Werkzeuge beruhen auf der Annahme, dass Programme gespeichert, bewegt und manipuliert werden können wie andere Daten. So wurde Software zu einem Ökosystem statt zu einem einmaligen Artefakt.
Ein nützlicher Blick zurück: gespeicherte Programme ermöglichten Compiler und OS, die bessere Entwicklerwerkzeuge erlaubten — heute sehen wir weitere Abstraktionsebenen, bei denen man eine Anwendung in natürlicher Sprache beschreiben und Tools daraus produktiven Code erzeugen lassen kann. Zum Beispiel ist Koder.ai eine Plattform, bei der man Web‑, Backend‑ oder Mobile‑Apps per Chat‑Interface erstellt und auf LLMs sowie agentenbasierten Workflows setzt, um schneller von der Idee zum lauffähigen Code zu kommen.
Das Ergebnis bleibt derselbe positive Kreislauf: gespeicherte Programme machten bessere Werkzeuge möglich, bessere Werkzeuge ermöglichten ehrgeizigere Programme — und verwandelten Computer in flexible, allgemeine Maschinen.
Die Idee der gespeicherten Programme machte Computer flexibel, brachte aber auch eine praktische Einschränkung ans Licht, über die man bis heute spricht: den sogenannten „von‑Neumann‑Flaschenhals“. Bildlich gesprochen ist es ein Stau auf der Straße zwischen CPU (Arbeiter) und Speicher (Lager).
In einem typischen speicherprogrammierten Entwurf liegen Instruktionen und Daten im Speicher. Die CPU holt eine Instruktion, dann die benötigten Daten, schreibt Ergebnisse zurück — häufig über denselben Verbindungsweg. Kann dieser Weg nicht genug Information schnell genug transportieren, bleibt die CPU oft untätig, obwohl sie rechnen könnte.
Zwei Faktoren prägen diesen Flaschenhals:
Eine CPU kann Milliarden von Operationen pro Sekunde durchführen, aber wenn der Speicher nicht genug Daten liefert, bestimmt der langsamste Schritt die Leistung: das Ein‑ und Ausliefern der Bytes.
In der Praxis nutzen Rechner mehrere Techniken, um die Auswirkungen zu verringern:
Diese Maßnahmen beseitigen den Flaschenhals nicht, sorgen aber dafür, dass die CPU mehr arbeitet und weniger wartet.
Die gespeicherte‑Programm‑Idee ist kein Museumsexponat — sie ist das Fundament der Flexibilität moderner Geräte. Ihre Geräte müssen nicht „umverdrahtet“ werden, um Neues zu tun; sie laden einfach andere Instruktionen in den Speicher und führen diese aus.
Auf einem Smartphone lädt das Betriebssystem beim Antippen eines App‑Icons den Code (Instruktionen) vom dauerhaften Speicher in den Arbeitsspeicher, und die CPU führt ihn aus. Auf einem Laptop passiert dasselbe, wenn Sie einen Browser öffnen, ein Dokument bearbeiten oder ein Spiel starten. Auf Servern ist es noch offensichtlicher: Tausende wechselnder Workloads laufen auf derselben Hardware — Webanfragen, Datenbankabfragen, Hintergrundjobs — ohne Hardwareänderung.
Viele der Funktionen, die wie „Hardware“ wirken (Routing, Video‑Decoding, Fotoverbesserung, Energiemanagement), werden oft per Firmware und Systemsoftware aktualisiert — neue Instruktionen, gleiches Gerät.
Sprachen wie Python und JavaScript laufen oft über einen Interpreter oder eine VM. Der Quellcode wird in strukturierte Formen (Bytecode oder interne Instruktionen) übersetzt, die im Speicher abgelegt und schrittweise ausgeführt werden. JVM, .NET, WebAssembly‑Runtimes und Browser‑Engines folgen diesem Muster: Instruktionen werden als Datenstrukturen geladen, bewegt und ausgeführt.
Weil Instruktionen „nur“ Information sind, versuchen Angreifer manchmal, bösartigen Code als Daten einzuschleusen — klassisches Code‑Injection. Schutzmechanismen wie Speicher‑Schutz, Code‑Signing und nicht‑ausführbare Speicherregionen verhindern, dass unzuverlässige Daten als ausführbare Instruktionen gehandhabt werden.
Das alles führt zurück zum zentralen Versprechen der gespeicherten Programme: Flexibilität durch Software — neues Verhalten auf derselben Hardware.
Wenn Sie einen Rechner betrachten (oder ein Datenblatt lesen), helfen diese Fragen, das Grundmodell zu erkennen:
Wenn Sie mehr leicht zugängliche Beiträge wie diesen möchten, stöbern Sie in /blog.
Hinweis: Wenn Sie moderne Wege ausprobieren, Instruktionen in laufende Systeme zu überführen — sei es durch direktes Programmieren oder chatgesteuerte Build‑Plattformen wie Koder.ai — dokumentieren Sie, was Sie lernen. Koder.ai bietet außerdem ein Earn‑Credits‑Programm für veröffentlichte Inhalte und Empfehlungen, das eine praktische Finanzierung für weitere Experimente und Tutorials sein kann.
Ein speicherprogrammierter Computer hält Programm‑Anweisungen im gleichen internen Speicher wie die Daten, auf denen diese Anweisungen arbeiten. Um die Aufgabe zu ändern, lädt man einen anderen Satz von Anweisungen in den Speicher, statt die Hardware umzubauen oder neu zu verkabeln.
Vor den speicherprogrammierten Maschinen wurden viele Computer praktisch mit Stecktafeln, Patchkabeln und Schaltern „programmiert“. Das Ändern der Ablaufreihenfolge konnte Stunden oder Tage an Verkabelung und Tests bedeuten, und ein falsches Kabel konnte schwer zu findende Fehler verursachen.
Hier bedeutet „Speicher“ der schnelle Arbeitsspeicher des Computers (am ehesten vergleichbar mit modernem RAM), den die CPU während des Betriebs ständig lesen und schreiben kann. Das unterscheidet ihn von langfristigem Speicher (Festplatten/SSDs), der Programme und Dateien bei ausgeschaltetem Gerät aufbewahrt.
Der EDVAC‑Bericht beschrieb klar die Organisation, bei der Instruktionen und Daten denselben internen Speicher teilen, und bot eine nützliche Begrifflichkeit (Speicher, Steuerwerk, Rechenwerk, Ein-/Ausgabe). Diese Klarheit half anderen Teams, die Idee zu diskutieren, zu vergleichen und schneller ähnliche Systeme zu bauen.
Sein Name blieb haften, weil seine Beschreibungen weit verbreitet und leicht zitierbar waren — nicht, weil er der einzige Urheber war. Die speicherprogrammierte Idee entstand in einer weiten Gemeinschaft von Ingenieuren, Mathematikern und frühen Programmierern, die gleichzeitig an verwandten Problemen arbeiteten.
„Von‑Neumann‑Architektur“ steht meist für ein Modell mit:
Es ist eine praktische Lehrbezeichnung für das speicherprogrammierte Konzept, nicht der Anspruch auf eine einzige historische Maschine oder einen Alleinerfinder.
In einem von‑Neumann‑Design teilen sich Instruktionen und Daten denselben Speicher (und meist denselben Übertragungsweg). In einer Harvard‑Architektur sind Instruktions‑ und Datenspeicher getrennt (häufig mit getrennten Wegen). Viele moderne Systeme mischen beide Ansätze — z. B. ein einheitliches Adressmodell für Software, aber getrennte Instruktions‑ und Datencaches intern.
Der „von‑Neumann‑Flaschenhals“ bezeichnet die Leistungsbegrenzung, die entsteht, wenn CPU und Speicher denselben, begrenzten Kanal für Instruktionen und Daten nutzen. Häufige Gegenmaßnahmen sind Caches, Prefetching und Parallelität (z. B. mehrere Kerne), die das Warten reduzieren, aber die zugrunde liegende Einschränkung nicht vollständig aufheben.
Weil Programme als Informationen gespeichert werden, kann man Verhalten per Software ändern statt per Hardware. Daher laden Geräte beim Start Apps oder Updates in den Speicher und führen sie aus — dieselbe Hardware, unterschiedliche Instruktionen. So erklären sich App‑Wechsel, Firmware‑Updates und viele Funktionen, die scheinbar „Hardware‑like“ sind, aber per Software gesteuert werden.
Da Instruktionen in Form von Daten im Speicher vorliegen, versuchen Angreifer manchmal, untrusted data als ausführbaren Code einzuschleusen (z. B. Code‑Injection). Abwehrmaßnahmen sind Speicher‑Schutz (nicht ausfühnbare Bereiche), Code‑Signatur und andere Kontrollen, die Daten und ausführbaren Code trennen.
