Mikroprozessoren: Die Evolution des Stored-Program-Computing

In den frühen Tagen des Computings erkannten Pioniere wie Alan Turing und John von Neumann, dass eine wirklich nützliche Maschine mehr tun muss als nur eine Befehlsliste abzuarbeiten – sie muss in der Lage sein, Daten im selben Speicherpool zu speichern, abzurufen und zu modifizieren. Dieser Einblick führte zum Konzept des Stored-Program-Computers.

Turings theoretische Maschine basierte auf einem sequenziell zugreifenden Band, um sowohl Programm-Instruktionen als auch Daten zu halten. Eine Steuer-Schaltung las das Band, führte Operationen aus und schrieb Ergebnisse zurück auf das Band oder bewegte das Band, um neue Daten zu lesen. Moderne Systeme ersetzen dieses Band durch Random-Access-Memory (RAM), was denselben Zweck mit weit höherer Geschwindigkeit und Flexibilität erfüllt.

Eine nützliche Analogie stammt von früher automatischer Werkzeugmaschinensteuerung. Open-Loop- oder Numerical-Control (NC) Systeme führten eine Drehbank oder Fräse, indem sie Instruktionen folgten, die als Löcher in Papierband kodiert waren. Die Maschine bewegte sich blind, dem Band folgend, ohne Bewusstsein des Werkstückzustands.

Weil das Gerät „blind“ für seine Umgebung war, konnte es Änderungen wie Metallausdehnung oder Werkzeugverschleiß nicht kompensieren. Der Programmierer musste auch jede mögliche Instruktionssequenz antizipieren, da das Band Read-Only war und die Maschine keinen internen Speicher hatte, um ihren Zustand zu tracken.

Das Aufrüsten auf einen Endlichen Zustandsautomaten (FSM) gab dem Werkzeug ein rudimentäres Gedächtnis: durch Rückführung einiger Datenbits in die Adresslogik konnte das System einfache Zustände wie „Kühlmittel an“ oder „Werkzeug in Position“ merken. Doch dies reichte noch nicht für echte Flexibilität.

Der Durchbruch kam mit Closed-Loop Numerical Control (CNC), wo das Programm neue Daten in beschreibbaren Speicher (RAM) schreiben konnte. Das Steuerungssystem konnte dann aufzeichnen, was es getan hatte, und sich an sensor-detektierte Änderungen anpassen – ähnlich wie ein Zerspaner Notizen auf einem Notizblock für spätere Referenz macht.

Informatiker träumen lange von Maschinen, die ihren eigenen Code modifizieren können, analog wie das menschliche Gehirn Synapsen durch Erfahrung stärkt. Für solche selbst-modifizierenden Programme muss der ausführbare Code im selben beschreibbaren Speicher residieren, der Daten speichert – eine Vorstellung, die heute noch an der Forschungsfrontier steht.

Die meisten Software folgt noch fixen Instruktionssequenzen, die nur ein separates Datenfeld alterieren. Um das Stored-Program-Modell wirklich zu unterstützen, brauchen wir mehr als einen FSM: wir brauchen einen Read/Write-Speicher, eine Datenverarbeitungseinheit und einen sophistizierten Controller.

Read/Write-Speicher wird bereitwillig durch Static oder Dynamic RAM Chips bereitgestellt – erschwinglich und schnell. Logische Operationen werden von einer Arithmetic Logic Unit (ALU) gehandhabt, die arithmetische und Boolesche Funktionen ausführen kann.

Die Control Unit orchestriert Datenbewegung zwischen Speicher, ALU und externen Geräten. Sie nutzt Tri-State-Puffer, um Daten auf Bussen zu routen, und Dekodierlogik, um binäre Instruktionscodes in Aktionen zu übersetzen.

Beispielinstruktionen könnten lauten: „Addiere den Wert an Adresse 0010 zum Wert an Adresse 1101“, oder „Berechne die Parität des Bytes an Adresse 0111“. Die Abbildung von Binärcodes zu Operationen ist willkürlich, ähnlich dem frühen ASCII-Standard, obwohl Instruktionssets typischerweise herstellerspezifisch sind.

Wenn Read/Write-Speicher, eine ALU und eine Control Unit integriert sind – oft auf einem einzelnen Chip – bilden sie einen Prozessor. Ein Prozessor mit minimalem externem Speicher ist ein Mikroprozessor; gekoppelt mit Bus-Control-Schaltung wird er zur Central Processing Unit (CPU).

Die CPU-Operation wird im Fetch/Execute-Zyklus gekapselt. Der Program Counter hält die Adresse der nächsten Instruktion. Die Control Unit liest diese Adresse in den Memory Address Bus, holt die Instruktion aus dem RAM und speichert sie in einem temporären Register.

Benötigt die Instruktion Operanden, gibt die Control Unit zusätzliche Speicherzugriffe aus, routet die geholten Daten zu ALU-Registern. Die ALU führt dann die angeforderte Operation aus, platziert das Ergebnis im Accumulator. Schließlich inkrementiert der Program Counter, und der Zyklus wiederholt sich.

Mikroprozessor (CPU)

--------------------------------------
| ** Program Counter ** |
| (inkrementiert Adresswert gesendet an |
| externe Speicherchips zum Holen |
| der nächsten Instruktion) |==========> Address Bus
| (zu RAM Speicher) |
--------------------------------------
| ** Control Unit ** |<=========> Control Bus
| (dekodiert Instruktionen gelesen aus | (an alle Geräte die
| Programm im Speicher, aktiviert Fluss | Adress- und/oder Datenbusse teilen;
| von Daten zu und von ALU, internen | arbitriert alle Bus-
| Registern, und externen Geräten) | kommunikation)
--------------------------------------
| ** Arithmetic Logic Unit (ALU) ** |
| (führt alle mathematischen |
| Berechnungen und Booleschen |
| Funktionen aus) |
--------------------------------------
| ** Register ** |
| (kleine Read/Write-Speicher für |
| Halten von Instruktionscodes, |
| Fehlercodes, ALU-Daten, etc; |
| inkludiert den "Accumulator") |<=========> Data Bus
| (von RAM Speicher und anderen |
| externen Geräten) |
--------------------------------------

Selbst einfachste Operationen erfordern viele Mikro-Schritte. Komplexe Arithmetik wie Exponentiation involviert wiederholte Iterationen basischer Funktionen. Betrachten Sie die tausenden Zyklen, die eine Flugsimulator-Grafikengine pro Frame für Display-Refresh ausführen muss.

Die schiere Geschwindigkeit des Fetch/Execute-Zyklus macht dies machbar. Manche Designs betten ein kleines Programm – genannt Mikrocode – in einem internen ROM ein. Mikrocode handhabt die Sub-Schritte komplexer Operationen, sodass der Programmierer eine einzelne High-Level-Instruktion ausgeben kann, statt jedes Detail zu schreiben.

Auf diese Weise enthält ein Prozessor einen Prozessor: ein Programm, das inside einem Programm läuft, das Entwicklung vereinfacht während Performance bewahrt.