“Die Zukunft”. Immer amüsant zu sehen, was eintraf und was total daneben ging 😉

Ente gut,alles gut! Oder: Der letzte Teil (4).

Als eifriger Leser dieser Serie hast Du es geschafft. Dieses letzte Kapitel beschaeftigt sich mit der Zukunft der RISC Prozessoren. Nun denn…

Mit zunehmender Integrationsfaehigkeit der Halbleitertechnologie ist zu- naechst ein Uebergang zu 64 Bit Prozessoren zu erwarten. Erste Schritte in dieser Richtung sind schon gemacht (Intel 860). Fuer superschnelle An- wendungen wird man auf weniger hochintegrierbare Technologien uebergehen: ECL- und Gallium-Arsenid-Varianten mit Taktfrequenzen von 100 MHz und mehr sind bereits in der Ankuendigung (Motorola (Jaaaaa) und TI). Die Individualisierung der Rechnerhardware wird ebenfalls weiter anhalten: RISC Prozessorkerne eignen sich als Standartbausteine fuer Kundenspezifische Schalskreise (ASICs). Der Kunde kann um diese Kerne herum dann eine mass- geschneiderte Rechnerarchitektur entwerfen. Die waere ein Beitrag zur offenen RISC Architektur. Natuerlich werden auch zusaetzliche Funktionen auf dem Chip notwendig, vor allem solche, die das Testen der Bausteine und der auf ihnen laufenden Programme unterstuetzen sollen. In Zukunft werden sicher Trace Moeglichkeiten und Einsteigpunkte fuer Debuggig-Werk- zeuge und Monitore angeboten. Vom Standpunkt der Rechnerarchitektur am interessantesten ist sicher der Weg zu den Parallelrechnerstrukturen: Hier bieten sich verschiedenste Varianten an, drei davon erscheinen be- sonders erfolgreich. Die erste Variante bietet auf dem RISC Prozessorchip Kommunikationskanaele zu anderen Prozessoren. Diese vor allem von Trans- putern (Inmos) verwendete Strktur erlaubt ueber bitserielle Kanaele den Aufbau beliebig vernetzter Multiprozessorstrukturen, wobei die einzellnen Prozessoren ausschliesslich mit lokalen Hauptspeicher ausgestattet und damit relativ lose gekoppelt sind. In einem Feld von Tranputern werden gleichzeitig mehrere Befehlsstroemeausgefuehrt, die Parallelitaet erfolgt auf Prozessebene. Eine Parallelisierung ebenfalls auf Prozessebene, aller- dings bei anderer Kommmunikationsstruktur, wird von Multi-RISC-Prozessor- architekturen unterstuetzt, die ueber gemeinsame Speicher gekoppelt sind. Wegen der bei RISC Prozessoren allgemein benutzten Cachespeichern ent- steht dabei aber das Cache-Konsitenzproblem: mehrere Prozessoren arbeiten auf unterschiedlichen Kopien der (urspruenglich identischen) Information aus dem gemeinsamen Speicher. Dieser Fall tritt solange nicht ein, wie die Information nur gelesen wird. Schreibt jedoch nur ein Prozessor in seinen Cache und wird dieser Schreibvorgang an den gemeinsamen Hauptspeicher durchgereicht, so arbeiten zunaechst alle anderen Prozessoren mit einer abweichenden Version des gemeinsamen Speichers: es bestehen Inkonsis- tenzen. Wenn alle anderen Prozessoren diese Aenderungen rechtzeitig er- fahren, koennen sie sich darauf einstellen und etwa ihren Cache neu fuellen. Aus der Literatur sind eine vielzahl unterschiedlicher Cache- Konsistenz Protokolle bekannt, alle mit dem Ziel, das Entstehen inkon- sistenter Versionen von Informationen zu unterdruecken. Hersteller von RISC Arichitekturen bieten heute bereits Cache Bausteine mit Controller Funktionen an, die diese Cache-Konsistenz Protokollle realisieren. Neben Rechnerarchitekturen mit einer geringen Anzahl von Prozessoren, die alle auf einen gemeinsamen Speicher zugreifen, lassen sich so auch massiv parallele Strukturen aufbauen, die auf dem Konzept des verteilten gemeinsamen Speichers beruhen, der aber bemeinsame Speichermodule jeweils nur fuer bestimmte Prozessornachbarschaften vorsieht. Der wesentliche Unterschied zum Transputermodell besteht darin, dass der Zugriffspfad fuer die Kommunikation in voller Datenbusbreite anstatt nur bitseriell besteht und damit wesentlich schneller, aber natuerlich auch aufwendiger ist. Je nach Kommunikationsgrad der Anwendung wird man vermutlich beide Typen von Parallelrechnerstrukturen nutzbringend einbringen koennen. Die dritte Variante sieht Parallelitaet auf niedriger Ebene vor, naemlich im Prozessor selbst. Sie ist zudem mit den oben genannten Konzepten kombinierbar, bietet also unabhaengig vom beschriebenen Parallel-Processing eine eigenstaendige Dimension der Leistungssteigerung. Der Gedanke beruht letztendlich auf der Nachbildung von Rechnerstrukturen, wie sie mit dem ersten Numbercruncher- Superrechner CDC6000 vom genialen Entwurfsingeneur Seymour Cray vorgeschla- gen wurden und bis heute in diskreter Form auch im Superrechner CRAY vor- liegen. Pro Prozessor vervielfacht man die Anzahl der Rechenwerke und versucht, die verschiedenen Maschienenbefehle aus einem Befehlsstrom gegeneinander ueberlappt parallel in den Rechenwerken auszufuehren. Es handelt sich also um das Pipelining eines Maschienenbefehlsstroms auf hoher Ebene im Gegensatz etwa zum reinen Dekodierungs-Pipelining, wo nur die Instruktionen sozusagen stueckweise (im Maschienentakt) entschluesselt und ausgefuehrt werden. Zwei Verfahren zur Parallelisierung der Maschienen- befehle sind moeglich. Zum einen kann sie durch einen optimierenden Com- piler erfolgen, der Befehlswoerter neuer Art generiert: Jeder Maschienen- befehl erhaelt jeweils die Befehlanteile fuer jedes Rechenwerk. Man spricht dann von VLIW-Architekturen (Very Long Instruction Word). Die zweite Moeglichkeit besteht darin, die Maschienenbefehle durch geeignete Leitwerks- hardware zu parallelisieren. Eine solche Hardware muss wie der optimierende Compiler parallelitaetshindernde Merkmale erkennen. Das sind:

* Datenabhaengigkeiten

Berechnungs-Sequnzen beispielsweise, deren Ergebnisse aufeinander aufbauen, duerfen sich nur soweit ueberlappen, dass die Zwischenergebnisse noch weitergereicht werden koennen.

* Ressoucenkonflikte

Der Befehlsstrom darf z.B. nicht laengere Befehlssequenzen nur fuer ein Teil- oder Rechenwerk enthalten, wenn eine gleichzeitige Abarbeitung an- gestrebt wird.

* Komplexe Zeitbedingungen

Verschiedene Rechenwerke sind in der Regel auch unterschiedlich schnell. Wenn Resultate aus verschiedenen Rechenwerken voneinander abhaengen, muss die weitere Verarbeitung darauf abgestimmt (syncronisiert) werden.

Tatsaechlich kannte schon die CDC6000 solche Hardware, die damals “Score board” genannt wurde. Und auch neue RISC Architekturen bieten tatsaechlich auf einem Prozessorchip mehrere Rechenwerke zu einem Leitwerk an: neben einem Festkomma-Rechenwerk ein Gleitkomma-Rechenwerk, ein Adress-Rechen- werk usw.. Es koennen aber auch universell nutzbare Rechenwerke sein. Im Sinne der RISC Architekturstrategie (man verlagere soviel wie moeglich in die Compilezeit) ist sicher sie Optimierung durch entsprechende Compiler vernuenftiger. Sie hat allerdings den Nachteil, dass sehr grosse Instruk- tionswoerter in den Prozessor gebracht werden muessen. Ausserhalb des Prozessors, also im Hauptspeicher wird man diese daher wieder serialisieren und erst innerhalb der Prozessors entsprechend breite Datenpfade vorsehen. Auch sind die optimiernenden Compilertechniken, vor allem die sog. pfad- orientierte Kompaktifizierung (der Umbau der Codereihenfolge, um Ressourcenkonflikte und Datenabhaengigkeiten zu beruecksichtigen), noch nicht ohne Probleme. Erstaunlicherweise hat man uebrigens diese Opti- mierungsstrategie aus der Optimierung von Mikroprogrammen abgeleitet.

FAZIT:

Der Entwurf von Maschienenbefehlssaetzen, der durch den Zwang zur Kompa- tibilitaet lange Zeit sehr konservativ blieb, ist durch den Gedanken zu RISC Architekturen wieder interessant geworden. Wegen der Uebertragbarkeit alter Programme werden die CISC Architekturen allerdings weiterhin wichtig bleiben. Innovative parallele und Hoechstleistungssysteme jedoch werden vermehr auf RISC Prozessoren zurueckgreifen. Die Geschwindigkeitsschere zwischen Prozessortakt und Speichertakt hat dabei fuer die Rechnerarchi- tektur eine Fuelle von neuen Strukturen notwendig gemacht. Ob die Anzahl der heute angebotenen RISC Prozessoren allerdings auch kommerziell ueber- lebensfaehig ist, steht auf einem anderen Blatt.

Ich hoffe diese etwas ausfuehrlichere Mail ueber eine Prozessoridee hat Anklang gefunden. Leider bietet das Medium Mailbox keine Kontrolle wie gut etwas beim Leser ankommt (denn es gibt ja keine Verkaufzahlen). Doch wuerde es mich schon interessieren was ihr von dieser oder anderen Mails haltet…nicht um mich in Lobes oder Schmaehungshymnen zu aalen, sondern in Zukunft nicht Dinge zu veroeffentlichen, die eh kein Schwein liest. Also bitte, ein paar Zeilen des Kommentars! Danke!

mfg AXEL