Vom
Universalrechner zur ReAl-Maschine
Ganz einfache Prozessoren
Beginnen wir mit einer
der einfachsten praxisbrauchbaren Architekturen – der
Akkumulatormaschine mit Indexregister (vgl. beispielsweise
Motorola MC6800).
Die Universalregistermaschine
Wäre es nicht besser,
mehrere Register zu haben, die wir freizügig als
Akkuumulatoren oder als Adreß- bzw. Indexregister
nutzen können? Beispiele gibt es genügend,
vom S/360 über die PDP10 bis zu Atmel AVR usw.
Die erste ReAl-Maschine
So weit ist der Schritt
eigentlich gar nicht... Wir haben schließlich
genügend Transistoren. Geben wir also jedem Registerpaar
eine eigene ALU. Eines der Register ist jeweils der
Akkumulator. Die Registerauswahl wird eingespart. Das
vermindert die Durchlaufverzögerung. Alle ALUs
können gleichzeitig arbeiten. Somit kann der innewohnende
(inhärente) Parallelismus tatsächlich ausgenutzt
werden.
Beim Akkumulatorprinzip
wird einer der Registerinhalte (= eine Variable) immer
überschrieben. Was aber, wenn der bisherige Wert
dieser Variable woanders noch gebraucht wird?
Also machen wir besser
alle Verknüpfungen zu funktionellen Zuordnungen
und halten Operanden und Ergebnisse voneinander getrennt.
Es sind mehr Register, aber die können wir uns
leisten. Wir müssen sie ja nicht adressieren (im
Operationsbefehl) und auswählen (in der Schaltung).
Um n ALUs parallel zu
nutzen, müssen n Operationscodes gleichzeitig anliegen.
Solche Befehle würden sehr lang werden (VLIW-Prinzip).
In Programmschleifen sind sie immer wieder neu zu holen.
Die weitaus meisten Programmabläufe sind Schleifen.
Also sagen wir besser jedem Rechenwerk von vornherein,
was es zu tun hat. Jedes dieser Werke ist eine Ressource.
Wenn wir genau wissen,
was im Programmablauf zu tun ist, können wir auch
für jeden Verarbeitungsvorgang eine spezielles
Werk bereitstellen. Die Frage, ob spezielle Werke ohne
oder universelle Werke (ALUs) mit Funktionsauswahl ist
eine Frage der Optimierung. Ebenso, ob die Funktion
während des Verarbeitungsabaufs umgeschaltet werden
soll oder nicht. Die Maschinenprogrammfertigung beginnt
jedenfalls damit, für jeden Programmvorgang eine
eigene Ressource vorzusehen, ganz so, als ob wir genug
von allem hätten. Optimieren können wir später...
|