CDC 6600

Grund- und Aufriss der CDC 6600 mit Bemaßung

Die CDC 6600. Hinter der Systemkonsole befinden sich zwei „Arme“ des kreuzförmigen Gehäuses mit geöffneten Verkleidungen. Innen sind einzelne Module zu sehen. Die Halterungen der Module sind angelenkt, um die dahinter liegenden Halterungen zugänglich zu machen. Jeder Arm der Maschine hatte bis zu vier solcher Halterungen. Rechts sieht man das Kühlsystem.

Systemkonsole eines CDC-6600-Systems. Bei diesem fortschrittlichen Design ersetzten Bildschirme und Tastatur die an damaligen Systemkonsolen üblichen Hunderte von Schaltern und Kontrollleuchten. Die softwaregesteuerten Bildschirme dienten zur Textanzeige in drei wählbaren Schriftgrößen und vermochten auch einfache Grafiken zu zeichnen. Im Gegensatz zu modernen Rastergrafik-Bildschirmen hatte die Konsole zwei Vektorbildschirme; in deren Font bestand jede Glyphe aus einer Reihe von Vektoren. Autovervollständigung von Schlüsselworten erlaubte eine schnellere Befehlseingabe.

Die CDC 6600 war das Flaggschiff der Großrechnersysteme aus der CDC-6000-Serie der Control Data Corporation. Allgemein als erster erfolgreicher Supercomputer angesehen, übertraf sie den vorherigen Rekordhalter der Branche, die IBM 7030 Stretch, um den Faktor drei. Mit einer Leistung von bis zu drei MegaFLOPS war die CDC 6600 von 1964 bis 1969 schnellster Computer der Welt, bis sie diesen Status an ihren Nachfolger, die CDC 7600, verlor.

Viele Exemplare wurden an verschiedene Kernwaffen-Labors geliefert, und einige fanden ihren Weg in die Computerlabors der Universitäten. Eine CDC 6600 ist im Computer History Museum in Mountain View (Kalifornien) ausgestellt. Die einzige noch lauffähige Maschine der CDC-6000-Serie wurde am Living Computers: Museum + Labs in Seattle restauriert und kann dort online genutzt werden.

Geschichte und Wirkung

→ Hauptartikel: Control Data Corporation

Die ersten Produkte von CDC basierten auf den bei ERA entwickelten Maschinen, die Seymour Cray nach seinem Wechsel zu CDC aktualisieren musste. Nach einer experimentellen Maschine namens Little Character wurde 1960 die CDC 1604 ausgeliefert, einer der ersten kommerziellen Computer auf Transistorbasis und eine der schnellsten Maschinen auf dem Markt. Das Management zeigte sich erfreut und plante eine neue Serie von Maschinen, die stärker auf die geschäftliche Nutzung zugeschnitten waren. Sie sollten beispielsweise Anweisungen für die Zeichenverarbeitung und das Speichern von Datensätzen enthalten. Cray war an einem solchen Projekt nicht interessiert und setzte sich zum Ziel, eine neue Maschine zu produzieren, die 50-mal schneller als die 1604 sein sollte. Als er gebeten wurde, einen detaillierten Bericht über die Pläne in einem und fünf Jahren in der Zukunft zu erstellen, schrieb er zurück, sein Fünfjahresziel sei, „den größten Computer der Welt zu produzieren“ – „der größte“ seinerzeit synonym mit „der schnellste“ – und sein Einjahresplan lautete, „ein Fünftel des Weges geschafft zu haben“.

Nach Umzug in ein neues Büro in der Nähe des ursprünglichen CDC-Hauptquartiers begann sein Kernteam, mit hochwertigen Versionen der „billigen“ Transistoren zu experimentieren, die Cray bei der 1604 verwendet hatte. Nach langen Versuchen stellten sie fest, dass sich Transistoren auf Germanium-Basis einfach nicht viel schneller betreiben ließen als bei der 1604. Die „Business-Maschine“, die das Management ursprünglich wollte und die sich jetzt als CDC 3000-Serie formierte, reizte sie so weit aus wie möglich. Als Lösung entschied Cray dann, mit den damals neuen Silizium-basierten Transistoren von Fairchild Semiconductor zu arbeiten, die gerade auf den Markt kamen und eine dramatisch verbesserte Schaltleistung boten.

In dieser Zeit wuchs CDC von einem Startup zu einem großen Unternehmen, und Cray wurde zunehmend frustriert über die seiner Ansicht nach lächerlichen Managementanforderungen. Die Situation spitzte sich zu, als sich 1962 die neue CDC 3600 der Produktionsreife näherte und genau das zu werden schien, was die Geschäftsleitung wollte und als sie es wollte. Cray sagte schließlich dem CEO von CDC, William Norris, dass sich etwas ändern müsse, sonst würde er das Unternehmen verlassen. Norris fand, dass er zu wichtig sei, um ihn zu verlieren, und gab Cray grünes Licht, ein neues Labor einzurichten, wo immer er wollte.

Nach kurzer Suche entschloss sich Cray, in seine Heimatstadt Chippewa Falls (Wisconsin) zurückzukehren, wo er ein Stück Land kaufte und ein neues Labor eröffnete.

Obwohl dies zu einer längeren Verzögerung bei der Konstruktion seiner neuen Maschine führte, begann die Entwicklung im neuen Labor ohne Eingriffe des Managements rasch. Zu dieser Zeit wurden die neuen Transistoren ziemlich zuverlässig, und mit ihnen gebaute Module funktionierten meist auf Anhieb einwandfrei. Die 6600 nahm Gestalt an, wobei Cray mit Jim Thornton, Systemarchitekt und „heimlichem Genie“ der 6600, zusammenarbeitete.

Die ersten CDC 6600 wurden 1965 an Livermore und Los Alamos ausgeliefert. Sie wurden schnell zu einem unentbehrlichen System in wissenschaftlichen und mathematischen Rechenkreisen, wobei Systeme an das Courant Institute of Mathematical Sciences, das CERN, das Lawrence Radiation Laboratory und viele andere geliefert wurden. Insgesamt wurden etwa 50 Exemplare ausgeliefert, nach anderen Quellen über 100.

Cray wandte sich sofort ihrem Nachfolgemodell zu, das als CDC 7600 ausgeliefert werden sollte, und setzte sich dafür das Zehnfache der Leistung der 6600 als Ziel. Die späteren CDC Cyber 70- und 170-Computer waren der CDC 6600 im Gesamtdesign sehr ähnlich und nahezu vollständig abwärtskompatibel.

Die 6600 war dreimal schneller als die vorherige Rekordhalterin, die IBM 7030 Stretch; dies alarmierte IBM. Der damalige CEO Thomas J. Watson, Jr. schrieb ein Memo an seine Mitarbeiter: „Letzte Woche hat Control Data … das 6600-System angekündigt. Ich verstehe, dass im Labor, das das System entwickelt, nur 34 Personen arbeiten, einschließlich des Hausmeisters. Davon sind 14 Ingenieure und 4 Programmierer … Wenn ich diese bescheidenen Anstrengungen mit unseren umfangreichen Entwicklungsaktivitäten vergleiche, kann ich nicht nachvollziehen, warum wir unsere branchenführende Position verloren haben, indem wir jemand anderes den leistungsstärksten Computer der Welt anbieten lassen.“ Crays Antwort war sardonisch: „Es scheint, als hätte Mr. Watson seine eigene Frage beantwortet.“

Beschreibung

Typische Maschinen dieser Zeit verwendeten eine einzige CPU, um das gesamte System zu betreiben. Ein typisches Programm lud zuerst Daten in den Hauptspeicher (häufig unter Verwendung von vorgefertigtem Bibliothekscode), verarbeitete sie und schrieb sie dann zurück. Diese vielfältigen Aufgaben erforderten einen umfangreichen Befehlssatz und damit eine komplexe CPU. Dies wiederum implizierte eine große CPU, was zu Signalverzögerungen führte, während Informationen zwischen ihren einzelnen Modulen flossen. Diese Verzögerungen begrenzten die Leistung der Maschine; sie konnte nur mit einer Taktrate arbeiten, die es den Signalen erlaubte, rechtzeitig das nächste Modul erreichten.

Cray wählte einen anderen Ansatz. Zu dieser Zeit liefen CPUs in der Regel langsamer als der Arbeitsspeicher, an den sie angeschlossen waren. Beispielsweise benötigte ein Prozessor 15 Zyklen, um zwei Zahlen zu multiplizieren, während für jeden Speicherzugriff nur ein oder zwei erforderlich waren. Dies bedeutete, dass der Arbeitsspeicher während eines erheblichen Zeitanteils inaktiv war. Es war diese Leerlaufzeit, die die 6600 ausnutzte.

Die CDC 6600 verwendete einen vereinfachten Hauptprozessor, der so ausgelegt war, dass er mathematische und logische Operationen möglichst schnell ausführen konnte. Dazu musste er so klein wie möglich gebaut werden, um die Länge der Verkabelung und die damit verbundenen Signalverzögerungen zu verringern. Dies führte zum (meist) kreuzförmigen Hauptgehäuse der Maschine, in dem die Leiterplatinen für die CPU nahe der Mitte angeordnet waren. Die CPU wurde von zehn Peripherieprozessoren unterstützt, die zur Ein-/Ausgabe und zum Datentransfer an die CPU dienten. Die 6600 verwendete ein 60-Bit-Wort und eine Einerkomplement-Darstellung von Ganzzahlen, was spätere CDC-Maschinen bis in die späten 1980er-Jahre beibehielten. Damit waren sie neben der UNIVAC 1100/2200 und einigen DSPs die letzten Systeme mit einer derartigen Architektur.

Anstatt wie andere CPUs alle Rechen- und Steueraufgaben zu erledigen, führten die 6600-CPUs nur Arithmetik- und Logikoperationen aus. Dies ermöglichte eine viel kleinere CPU, die mit einer höheren Taktrate arbeiten konnte. In Kombination mit der höheren Schaltgeschwindigkeit der Siliziumtransistoren übertraf das neue CPU-Design alle damals verfügbaren Alternativen bei weitem. Das neue Design lief mit 10 MHz (100-ns-Takt) etwa zehnmal schneller als andere Maschinen auf dem Markt. Der einfache Prozessor war nicht nur schneller, sondern führte auch Befehle in weniger Taktzyklen aus. Beispielsweise konnte die CPU eine Multiplikation in zehn Zyklen durchführen.

Peripherieprozessoren (Eigenschaften)

Die CPU hatte dabei nur einen eingeschränkten Befehlssatz aus einfachen Instruktionen: Während typische CPUs der Ära über einen komplexen Befehlssatz verfügten, der auch Anweisungen für alle normalen „Housekeeping“-Aufgaben wie Speicherzugriff und Ein-/Ausgabe umfasste, implementierte Cray diese Befehle bei der 6600 stattdessen in separaten, einfacheren „Peripherieprozessoren“ (PPs), die ausschließlich für solche Aufgaben vorgesehen waren. Dadurch kam die CPU mit einem viel kleineren Befehlssatz aus. Dies war die erste Implementation dessen, was später als Reduced Instruction Set Computer (RISC) bezeichnet wurde.

Durch den parallelen Betrieb von CPU, Peripherieprozessoren (PPs) und E/A wurde die Leistung der Maschine erheblich gesteigert. Normalerweise hätte eine Maschine mit mehreren Prozessoren auch viel mehr gekostet. Der Schlüssel zum Design der 6600 bestand darin, die PPs so einfach wie möglich zu gestalten. Sie basierten auf der einfachen 12-Bit-CDC 160-A, die viel langsamer als die CPU lief, Daten sammelte und über dedizierte Hardware mit hoher Geschwindigkeit als Bursts in den Hauptspeicher übertrug.

Die 10 PPs wurden virtuell implementiert; nur einen Prozessor gab es als Hardware. Dieser arbeitete mit 10 PP-Registersätzen zusammen, die die 10 PP-Instanzen repräsentierten (ähnlich modernen Multithreading-Prozessoren) und als barrel (Fass) bezeichnet wurden. Bildlich gesprochen, „drehte“ sich das barrel schrittweise, wobei umlaufend jeder PP-Registersatz über einen slot der PP-CPU zugeordnet wurde. Die CPU führte den Befehl des jeweiligen PP ganz oder teilweise aus, woraufhin sich das barrel wieder „drehte“ und der CPU den Registersatz (Zustand) des nächsten PP zuordnete. Es waren mehrere „Umdrehungen“ des barrel erforderlich, um eine Anweisung abzuarbeiten. Eine vollständige barrel-„Drehung“ dauerte 1000 Nanosekunden (100 Nanosekunden pro PP), und eine Anweisung benötigte eine bis fünf „Umdrehungen“, oder noch mehr im Fall eines Datenübertragungsbefehls.

Befehlssatz-Architektur

Die 6600-CPU würde man heute als RISC-System bezeichnen, bei dem der Prozessor für vergleichsweise einfache Befehle ausgelegt ist, die nur über begrenzten und genau definierten Speicherzugriff verfügen. Viele andere Maschinen verwenden komplexe Anweisungen – beispielsweise Abruf eines Operanden aus dem Speicher und dessen Addition in ein Register durch einen einzelnen Maschinenbefehl. Bei der 6600 erforderte das Laden des Werts aus dem Speicher einen eigenen Befehl und das Hinzufügen einen zweiten. Theoretisch war die Verarbeitung durch die zusätzlichen Speicherzugriffe zwar langsamer, doch dies wurde dadurch aufgewogen, dass in gut angeordnetem Code mehrere Befehle gleichzeitig verarbeitet werden konnten. Diese Vereinfachung zwang Programmierer auch dazu, sich ihrer Speicherzugriffe sehr bewusst zu sein und daher sorgfältig zu codieren, um sie so weit wie möglich zu reduzieren.

Modelle

Die CDC-6000-Serie umfasste vier Grundmodelle: die CDC 6400, die CDC 6500, die CDC 6600 und die CDC 6700. Sie unterschieden sich nur in ihren CPUs, bei denen es sich um zwei Arten handelte, die 6400-CPU und die 6600-CPU. Die 6400-CPU hatte eine einzige, umfassende Recheneinheit und keine getrennten Rechenwerke. Daher konnten sich die Ausführungszeiten der Anweisungen nicht überschneiden. Wenn beispielsweise in einer 6400-CPU eine Additionsanweisung unmittelbar auf eine Multiplikationsanweisung folgte, konnte die Addition erst gestartet werden, wenn die Multiplikation beendet war, so dass die Gesamtausführungszeit der beiden Anweisungen die Summe ihrer einzelnen Ausführungszeiten war. Dagegen hatte die 6600-CPU mehrere Rechenwerke, die gleichzeitig arbeiten konnten, d. h. „parallel“, was es der CPU ermöglichte, die Ausführungszeiten der Befehle zu überlappen. Eine 6600-CPU konnte beispielsweise im nächsten CPU-Zyklus nach dem Beginn eines Multiplikationsbefehls bereits mit der Ausführung eines Additionsbefehls beginnen (vorausgesetzt natürlich, dass das Ergebnis der Multiplikation kein Operand der Addition war); daher war die Gesamtausführungszeit der beiden Befehle einfach die (längere) Ausführungszeit des Multiplikationsbefehls. Die 6600-CPU hatte auch einen sogenannten instruction stack (Anweisungsstapel), eine Art Befehlscache, der dadurch zur Erhöhung des CPU-Durchsatzes beitrug, dass die CPU-Leerlaufzeit verringert wurde, die durch das Warten auf den Speicher beim Nachladen von Anweisungen verursacht wurde. Die beiden Arten von CPUs waren befehlskompatibel, so dass ein Programm, das auf einer der beiden lauffähig war, genauso auch auf der anderen lief, auf der 6600-CPU jedoch schneller. In der Tat waren alle Modelle der 6000er-Serie untereinander vollständig kompatibel. Die CDC 6400 hatte eine CPU (eine 6400-CPU), die CDC 6500 hatte zwei CPUs (beide 6400-CPUs), die CDC 6600 hatte eine CPU (eine 6600-CPU) und die CDC 6700 hatte zwei CPUs (eine 6600-CPU und eine 6400-CPU).

Zentralprozessor (CP)

Register der CDC 6×00

59 . . . 17 . . . 00 (Bitposition) Operandenregister (60 Bit) X0 Register 0 X1 Register 1 X2 Register 2 X3 Register 3 X4 Register 4 X5 Register 5 X6 Register 6 X7 Register 7 Addressregister (18 Bit)   A0 Adresse 0   A1 Adresse 1   A2 Adresse 2   A3 Adresse 3   A4 Adresse 4   A5 Adresse 5   A6 Adresse 6   A7 Adresse 7 Inkrementregister (18 Bit)   B0 (alle Bits Null) Inkrement 0   B1 Inkrement 1   B2 Inkrement 2   B3 Inkrement 3   B4 Inkrement 4   B5 Inkrement 5   B6 Inkrement 6   B7 Inkrement 7

Der Zentralprozessor (Central Processor, CP) und der Hauptspeicher der Maschinen 6400, 6500 und 6600 hatten eine Wortlänge von 60 Bit. Der CP hatte acht Allzweck-60-Bit-Register X0 bis X7, acht 18-Bit-Adressregister A0 bis A7 und acht 18-Bit-„Inkrement“-Register B0 bis B7. B0 wurde von der Hardware permanent auf Null gehalten. Viele Programmierer fanden es nützlich, B1 auf 1 zu setzen und es auf ähnliche Weise als Festwert zu behandeln.

Es gab keine CP-Anweisungen für die Ein- und Ausgabe; diese wurden über Peripherieprozessoren (PP, siehe unten) ausgeführt. Auch gab es keine eigenen Opcodes zum Laden oder Speichern zwischen Hauptspeicher und Registern. Dies geschah vielmehr als Nebeneffekt der Zuordnung zu bestimmten A-Registern: Durch Setzen von A1 bis A5 wurde das Wort an dieser Speicheradresse in X1 bis X5 geladen, durch Setzen von A6 oder A7 wurde ein Wort von X6 oder X7 gespeichert. Mit A0 waren keine Nebenwirkungen verbunden. Eine separate Hardware-Lade-/Speichereinheit, die stunt box, führte die tatsächliche Datenbewegung unabhängig von der Operation des Befehlsstroms durch, so dass andere Operationen bereits abgeschlossen werden konnten, während noch auf den Speicher zugegriffen wurde; dies erforderte im besten Fall acht Zyklen.

Der 6600-CP enthielt zehn parallele Funktionseinheiten, mit denen mehrere Anweisungen gleichzeitig bearbeitet werden konnten. Heute ist dies als superskalares Prozessordesign bekannt, aber seinerzeit war es einzigartig. Im Gegensatz zu den meisten modernen CPU-Designs wurden funktionale Einheiten nicht per Pipeline verbunden. Die Funktionseinheit war belegt, wenn ihr eine Anweisung erteilt wurde, und blieb es für die gesamte Zeit, die zur Ausführung dieser Anweisung erforderlich war. (Im Gegensatz dazu wurde bei den Rechenwerken der CDC 7600 das Pipelining eingeführt.) Im besten Fall konnte alle 100 ns ein Befehl an ein Rechenwerk erteilt werden. Das System las und decodierte Anweisungen aus dem Speicher so schnell wie möglich, im Allgemeinen schneller, als sie ausgeführt werden konnten, und leitete sie zur Verarbeitung an die Rechenwerke weiter. Dies waren:

• Gleitkommamultiplikation (zwei Instanzen)
• Gleitkommadivision
• Gleitkommazahladdition
• „lange“ Ganzzahladdition
• Inkrementierer (zwei Instanzen; führte Laden/Speichern des Speichers aus)
• Verschiebung
• Boolesche Logik
• Verzweigung

Gleitkommaoperationen hatten in dieser Architektur einen hohen Stellenwert: Die CDC 6600 (und Verwandte) waren praktisch als einzige in der Lage, eine 60-Bit-Gleitkomma-Multiplikation in einer Zeit vergleichbar mit der für eine Verzweigung durchzuführen.

60-Bit-Festkomma-Addition und -Subtraktion wurden in der Long Add Unit ausgeführt, wobei negative Zahlen durch ihr Einerkomplement dargestellt wurden. Die Festkomma-Multiplikation wurde als Sonderfall in der Gleitkomma-Multiplikationseinheit durchgeführt. War der Exponent Null, so führte die FP-Einheit eine 48-Bit-Gleitkomma-Multiplikation mit einfacher Genauigkeit durch und löschte den oberen Teil mit dem Exponenten, was ein 48-Bit-Integer-Ergebnis lieferte. Die Ganzzahldivision wurde von einem Makro ausgeführt, das in Gleitkommazahlen und zurück konvertierte.

Zuvor ausgeführte Anweisungen wurden in einem Cache von acht Wörtern gespeichert, dem stack (Stapel). In-Stack-Sprünge waren schneller als Out-of-Stack-Sprünge, da kein Speicherabruf erforderlich war. Der stack wurde durch eine unbedingte Sprunganweisung gelöscht, so dass unbedingte Sprünge an Schleifenenden üblicherweise als bedingte Sprünge geschrieben wurden, die immer erfolgreich waren.

Das System verwendete einen 10-MHz-Takt mit einem Vierphasensignal. Eine Gleitkommamultiplikation dauerte zehn Zyklen, eine Division 29, und die Gesamtleistung unter Berücksichtigung von Speicherverzögerungen und anderen Problemen betrug etwa 3 MFLOPS. Mit den besten verfügbaren Compilern konnten FORTRAN-Programme gegen Ende der Maschinengeschichte mit einer Dauerleistung von etwa 0,55 MFLOPS rechnen.

Speicherorganisation

Benutzerprogramme konnten nur einen zusammenhängenden Bereich des Hauptspeichers verwenden. Der Teil des Speichers, auf den ein laufendes Programm Zugriff hatte, wurde von den Registern RA (Relative Address) und FL (Field Length) bestimmt, auf die das Benutzerprogramm keinen Zugriff hatte. Wenn ein Anwenderprogramm versuchte, ein Wort im Hauptspeicher an der Adresse a zu lesen oder zu schreiben, überprüfte der Prozessor zunächst, ob a zwischen 0 und FL-1 lag. War dies der Fall, so griff der Prozessor auf das Wort im Hauptspeicher unter der Adresse RA+a zu. Dieser Vorgang wurde als base-bound relocation bezeichnet. Jedes Anwenderprogramm sah den Hauptspeicher als einen zusammenhängende Block von Wörtern mit der Länge FL, beginnend mit der Adresse 0; tatsächlich konnte sich das Programm irgendwo im physischen Speicher befinden. Mit dieser Technik konnte jedes Anwenderprogramm vom Betriebssystem im Hauptspeicher verschoben werden, solange das RA-Register seine Position im Speicher widerspiegelte. Ein Anwenderprogramm, das versuchte, auf Speicher außerhalb des zulässigen Bereichs zuzugreifen (d. h. mit einer Adresse, die nicht kleiner als FL ist), löste einen Interrupt aus und wurde vom Betriebssystem beendet. In diesem Fall erstellte das Betriebssystem möglicherweise einen Core-Dump, der den Inhalt des Programmspeichers aufzeichnete und in einer Datei speicherte, so dass der Entwickler des Programms erfahren konnte, was geschehen war. Man beachte den Unterschied zu virtuellen Speichersystemen; in diesem Fall muss sich der gesamte adressierbare Speicherplatz eines Prozesses im Hauptspeicher befinden, muss zusammenhängend sein, und seine Größe darf nicht größer sein als die tatsächliche Speicherkapazität.

Mit Ausnahme der ersten sieben Exemplare der CDC 6000-Serie konnten alle Geräte mit einem optionalen Extended Core Storage (ECS)-System konfiguriert werden. ECS wurde aus einer anderen Art von Kernspeicher hergestellt als der Hauptspeicher, verdrahtet mit nur zwei Drähten pro Kern im Gegensatz zu fünf Drähten für jenen. Dadurch war er zwar langsamer als der Hauptspeicher, aber wirtschaftlicher zu fertigen. Da er sehr breite Übertragungen durchführte, war seine sequentielle Übertragungsrate dieselbe wie die des Hauptspeichers. Eine 6000-CPU konnte Blockspeicherübertragungen direkt zwischen dem Programm (oder Betriebssystem) eines Benutzers und der ECS-Einheit durchführen. Es wurden breite Datenpfade verwendet, daher war dies eine sehr schnelle Operation. Ähnlich wie beim Hauptspeicher wurden die Speichergrenzen beim ECS vom Betriebssystem mit einem Relativadresse/Feldlänge-Mechanismus verwaltet. ECS konnte für eine Vielzahl von Zwecken verwendet werden, etwa für Benutzerdaten-Arrays, die für den zentralen Speicher zu groß waren zum Speichern häufig verwendeter Dateien, zur Auslagerung und sogar als Kommunikationspfad in einem Multi-Mainframe-Komplex.

Peripherieprozessoren (PPs)

Um die „Housekeeping“-Aufgaben zu erledigen, die in anderen Designs der CPU zugewiesen waren, baute Cray zehn weitere Prozessoren ein, die teilweise auf seinem früheren Computer CDC 160-A basierten. Diese Computer, Peripheral Processors oder PPs genannt, waren eigenständige Vollcomputer, wurden jedoch für E/A-Aufgaben und das Ausführen des Betriebssystems optimiert. (Wesentliche Teile des Betriebssystems liefen auf den PPs, sodass die Leistung des Zentralprozessors größtenteils für Benutzerprogramme verfügbar blieb.) Nur die PPs hatten Zugriff auf die E/A-Kanäle. Einer der PPs war für die Gesamtsteuerung der Maschine zuständig, einschließlich der Steuerung des Programms, das auf der Haupt-CPU ausgeführt wurde, während den anderen verschiedenen E/A-Aufgaben zugewiesen waren. Wenn das CP-Programm eine Betriebssystemfunktion ausführen musste, stellte es eine Anforderung an eine bestimmte Speicherstelle (Referenzadresse+1), die von PP0 überwacht wurde. Falls erforderlich, wies PP0 einen anderen PP zu, um den erforderlichen Code zu laden und um die Anfrage zu bearbeiten. Der PP löschte dann RA+1, um das CP-Programm über die Beendigung der Aufgabe zu informieren.

Die besondere Rolle des PP0 bei der Steuerung der Maschine war ein potentieller Single Point of Failure, da im Falle seiner Fehlfunktion die gesamte Maschine ausfallen konnte, selbst wenn die neun anderen PPs und die CPU noch ordnungsgemäß funktionierten. Cray behob diese Schwachstelle beim Design des Nachfolgemodells 7600 dadurch, dass hier jeder PP der Controller sein konnte und die CPU einem anderen diese Rolle zuweisen konnte.

Jeder PP verfügte über einen eigenen Speicher mit 4096 12-Bit-Wörtern; dieser Speicher diente sowohl zur E/A-Pufferung als auch zur Programmspeicherung. Dagegen nutzten die zehn PPs einen gemeinsamen Prozessor in einer Konfiguration mit der Bezeichnung barrel and slot. Dies bedeutete, dass der slot (Prozessor) einen Befehlszyklus des ersten PP, dann einen Befehlszyklus des zweiten usw. in einem Round-Robin-Verfahren ausführte. Dies geschah sowohl aus Kostengründen als auch, weil für den Zugriff auf den CP-Speicher 10 PP-Taktzyklen erforderlich waren: Wenn ein PP auf den CP-Speicher zugriff, waren die Daten verfügbar, wenn der PP das nächste Mal seine slot-Zeit erhielt.

Wortlängen, Zeichen

Der Zentralprozessor hatte 60-Bit-Wörter, die Peripherieprozessoren dagegen 12-Bit-Wörter. CDC benutzte den Begriff Byte für 12-Bit-Einheiten, die von PP verwendet werden. Die Zeichenlänge war 6 Bit, und die Anweisungen des CP waren entweder 15 Bit oder 30 Bit mit einem vorzeichenbehafteten 18-Bit-Adressfeld, wobei das letztere einen direkt adressierbaren Speicherplatz von 128K Wörtern des Zentralspeichers ermöglichte. (Modern in 8-Bit-Bytes ausgedrückt, waren dies 0,94 MB.) Der vorzeichenbehaftete Charakter der Adressregister begrenzte ein einzelnes Programm auf 128K Wörter. (Spätere CDC 6000-kompatible Maschinen konnten einen Hauptspeicher von 256K oder mehr Wörtern haben, wenn das Budget dies zuließ, aber die einzelnen Benutzerprogramme waren immer noch auf 128K Wörter beschränkt.) CPU-Anweisungen mussten an einer Wortgrenze beginnen, wenn sie Ziel einer Sprunganweisung oder eines Subroutine-Rücksprungs waren, sodass manchmal No-Op-Befehle erforderlich waren, um die letzten 15, 30 oder 45 Bits eines Wortes aufzufüllen. Erfahrene Assembler-Programmierer konnten ihre Programme optimieren, indem sie diese No-Op-Bereiche mit anderen Anweisungen füllten, die später im Programm benötigt wurden.

Die 6-Bit-Zeichen in einer als CDC Display Code bezeichneten Codierung konnten zum Speichern von bis zu 10 Zeichen in einem Wort verwendet werden. Sie erlaubten einen Zeichensatz von 64 Zeichen, ausreichend für alle Großbuchstaben, Ziffern und einige Satzzeichen und jedenfalls, um FORTRAN zu schreiben oder finanzielle oder wissenschaftliche Berichte zu drucken. Tatsächlich wurde der CDC Display Code in zwei Varianten eingesetzt - 64 Zeichen und 63 Zeichen. Der 64-stellige Zeichensatz hatte den Nachteil, dass zwei aufeinanderfolgende Doppelpunkt-Zeichen als Zeilenende interpretiert wurden, wenn sie am Ende eines 10-Byte-Wortes standen. Eine spätere Variante, genannt 6/12 Display Code, wurde auch in den Timesharing-Systemen KRONOS und NOS verwendet, um den kompletten ASCII-Zeichensatz weitgehend kompatibel mit älterer Software zu nutzen.

Da es keinerlei Anweisungen zur Adressierung von Bytes gab, musste man Code schreiben, um Zeichen in Wörter zu packen und zu verschieben. Die sehr großen Wörter und die vergleichsweise geringe Speicherkapazität führten dazu, dass Programmierer häufig Speicher einsparten, indem sie Daten auf Bitebene in Wörter packten.

Aufgrund der großen Wortlänge und mit 10 Zeichen pro Wort war es oft schneller, mehrere Wörter gleichzeitig zu verarbeiten, als sie zu entpacken, zu verarbeiten und neu zu packen. Beispielsweise war der CDC-COBOL-Compiler bei der Verarbeitung von Dezimalfeldern mit dieser Technik recht gut. Derartige Techniken werden heutzutage häufig in den „Multimedia“ -Anweisungen aktueller Prozessoren verwendet.

Physisches Design

Ein CDC-6600-Logikmodul mit 64 Siliziumtransistoren in Cordwood-Technik. Die Koaxialstecker sind Testanschlüsse. Das Modul wurde über die Frontplatte durch Wärmeleitung gekühlt. Die CDC 6600 enthielt fast 6.000 solcher Module.

Die Maschine war in einem Gehäuse in Form eines Pluszeichens untergebracht, mit einer Pumpe und einem Wärmetauscher in den äußersten 46 cm der vier Arme. Gekühlt wurde mit Freon, das in der Maschine zirkulierte und Wärme an eine externe Kühlwasserversorgung weiterleitete. Jeder Arm konnte vier Chassis mit einer Dicke von jeweils 20 cm aufnehmen, die in der Nähe der Mitte angelenkt waren und sich wie ein Buch öffnen ließen. Die Kreuzung des „Plus“ war mit Kabeln gefüllt, die die Chassis miteinander verbanden. Die Chassis waren von eins (mit allen zehn PPs und ihren Speichern sowie den zwölf eher minimalen E/A-Kanälen) bis 16 nummeriert. Der Hauptspeicher für die CPU war auf viele Chassis verteilt. In einem System mit nur 64K Wörtern des Hauptspeichers wurde einer der Arme des „Plus“ weggelassen.

Die Logik der Maschine wurde in Module mit einer Größe von etwa 6,4 cm im Quadrat und einer Dicke von 2,5 cm verpackt. Jedes Modul hatte einen Stecker (30 Stifte, zwei vertikale Reihen zu je 15) an der Rückseite und sechs Testanschlüsse an der Vorderseite. Das Modul wurde zwischen zwei Aluminiumkühlplatten platziert, um Wärme abzuleiten. Es bestand aus zwei parallelen Leiterplatten, wobei die Komponenten entweder auf einer der Leiterplatten oder zwischen den beiden Leiterplatten montiert waren. Dies ergab eine sehr hohe Packungsdichte – im Allgemeinen nicht zu reparieren, aber mit guten Wärmeübertragungseigenschaften und als englisch cordwood construction bekannt.

Betriebssystem und Programmierung

Es gab einen wunden Punkt bei der Entwicklung des 6600-Betriebssystems: nicht eingehaltene Termine. Die Maschinen hatten ursprünglich ein sehr einfaches Ablaufsteuerungssystem namens COS (Chippewa Operating System), das man auf der Grundlage des früheren CDC 3000-Betriebssystems schnell „zusammengewürfelt“ hatte, um irgendetwas zum Systemtest vor Auslieferung lauffähig zu haben. Die Maschinen sollten jedoch mit einem viel leistungsstärkeren System namens SIPROS (Simultaneous Processing Operating System) ausgeliefert werden, das in der System Sciences Division des Unternehmens in Los Angeles entwickelt wurde. Die Kunden waren von der Funktionsliste von SIPROS beeindruckt, und viele ließen SIPROS in ihre Lieferverträge eintragen.

SIPROS erwies sich als großes Fiasko. Die Zeitpläne für die Entwicklung rutschten weiter ab und kosteten CDC erhebliche Gewinne in Form von Bußgeldern für Lieferverzögerungen. Nach einigen Monaten des Wartens mit sonst versandfertigen Maschinen wurde das Projekt schließlich abgebrochen. Die Programmierer, die an COS gearbeitet hatten, hatten wenig Vertrauen in SIPROS und hatten weiter an der Verbesserung von COS gearbeitet.

Die Betriebssystementwicklung wurde dann in zwei Lager aufgeteilt. Die CDC-sanktionierte Entwicklung von COS wurde im Softwareentwicklungslabor von Sunnyvale (Kalifornien) durchgeführt. Viele Kunden erhielten schließlich ihre Systeme mit dieser Software ausgeliefert, die damals als SCOPE (Supervisory Control Of Program Execution) bekannt war. SCOPE Version 1 war im Wesentlichen ein deassembliertes COS; SCOPE Version 2 unterstützte neue Geräte und Dateisysteme. SCOPE Version 3 umfasste Unterstützung für permanente Dateien, EI/200-Remote-Batch-Unterstützung und INTERCOM-Time-Sharing-Unterstützung. SCOPE hatte immer erhebliche Zuverlässigkeits- und Wartbarkeitsprobleme.

SCOPE 3.1 der CDC 6000-Serie erstellt sich selbst, während es auf dem Desktop-CYBER-Emulator ausgeführt wird

Die „Untergrund-Entwicklung“ von COS fand im Montagewerk in Arden Hills (Minnesota), statt. MACE ([Greg] Mansfield and [Dave] Cahlander Executive) wurde größtenteils von einem einzelnen Programmierer außerhalb der Geschäftszeiten geschrieben, wenn Maschinen verfügbar waren. Der Funktionsumfang war im Wesentlichen derselbe wie bei COS und SCOPE 1. Das frühere COS-Dateisystem wurde beibehalten, die Codemodularität wurde jedoch erheblich verbessert, um die Zuverlässigkeit des Systems und die Anpassungsfähigkeit an neue Speichergeräte zu verbessern. Zwar war MACE nie ein offizielles Produkt, jedoch vermochten viele Kunden, es sich bei CDC zu verschaffen.

Die inoffizielle MACE-Software wurde später anstelle des offiziellen SCOPE-Produkts als Grundlage für das nächste CDC-Betriebssystem, KRONOS, ausgewählt, das nach dem griechischen Gott der Zeit benannt wurde. Man sagt, dass Dave Mansfield die Bibliothek der Universität von Minnesota anrief und nach einem alten Wort fragte, das „Zeit“ bedeutet. Er schrieb „Kronos“ anstelle von „Chronos“ auf. Der Haupt-Vermarktungsgrund war die Entwicklung des TELEX-Timesharing-Features und des BATCHIO-Remote-Batch-Features. Kronos verwendete weiterhin das COS/SCOPE-1-Dateisystem und fügte eine permanente Dateifunktion hinzu.

Als Versuch, die Betriebssystemprodukte SCOPE und Kronos zu vereinheitlichen, wurde NOS (Network Operating System) entwickelt. NOS sollte das einzige Betriebssystem für alle CDC-Maschinen sein, eine Tatsache, die CDC stark bewarb. Viele SCOPE-Kunden waren weiterhin softwareabhängig von der SCOPE-Architektur, sodass CDC sie einfach in NOS/BE (Batch Environment) umbenannte und behaupten konnte, dass alle Benutzer NOS ausführten. In der Praxis war es viel einfacher, die Kronos-Codebasis zu ändern, um SCOPE-Funktionen hinzuzufügen, als umgekehrt.

Im Umfeld des Montagewerks wurden auch andere Betriebssysteme hergestellt, die niemals für den Kunden bestimmt waren. Dazu gehörten die Engineering-Tools SMM für Hardware-Tests und KALEIDOSCOPE für Software-„Smoke-Tests“. Ein weiteres, von CDC-Außendiensttechnikern häufig zum Testen verwendetes Tool war MALET (Maintenance Application Language for Equipment Testing), mit dem Komponenten und Geräte nach Reparaturen oder Servicearbeiten durch Ingenieure einem Stresstest unterzogen wurden. Bei den Testbedingungen wurden häufig Festplattenpakete und Magnetbänder verwendet, die absichtlich mit Fehlern versehen waren, um festzustellen, ob die Fehler von MALET und dem Techniker erkannt wurden.

Datei:NOSv1.3.png

NOS 1.3

Die Namen SCOPE und COMPASS wurden von CDC sowohl für die CDC-6000-Serie einschließlich der 6600 als auch für die CDC-3000-Serie verwendet:

• COMPASS hießen die Assemblersprachen in beiden Familien.
• SCOPE wurden die Betriebssysteme der Serien 3000 und 6000 genannt.

CDC 7600

Die CDC 7600 sollte ursprünglich auch mit den vorhandenen Maschinen der 6000er-Serie vollständig kompatibel sein. Sie wurde ursprünglich als CDC 6800 bezeichnet. Während der Entwicklung stellten die Entwickler jedoch fest, dass die Beibehaltung vollständiger Kompatibilität mit den vorhandenen Maschinen der 6000er-Serie die mögliche Leistungssteigerung einschränken würde, und beschlossen, die Kompatibilität für die Leistung zu opfern. Während die CPU der CDC 7600 im Wesentlichen befehlskompatibel mit den CPUs 6400 und 6600 war und Code-Portabilität auf der Quelltext-Ebene der höheren Programmiersprache ermöglichte, war die Hardware der CDC 7600, insbesondere die ihrer Peripheral Processor Units (PPUs), ganz anders. Die CDC 7600 benötigte ein anderes Betriebssystem. Dies erwies sich als Segen, da die Konstrukteure einige der Merkmale des 6000er-Designs verbessern konnten, beispielsweise die vollständige Abhängigkeit des letzteren von Peripherieprozessoren (PPs), insbesondere dem ersten (PP0 genannt), um den Betrieb des gesamten Computersystems einschließlich der CPU zu steuern. Im Gegensatz zur 6600-CPU konnte die CPU der CDC 7600 ihren eigenen Betrieb steuern. Tatsächlich wurden die Maschinen der 6000er-Serie mit dieser Funktion nachgerüstet.

Literatur

• Control Data 6400/6500/6600 Computer Systems Reference Manual. Revision H. Control Data Corporation, St. Paul, MN 21. Februar 1969 (archive.org [abgerufen am 7. Oktober 2019]). 
• James E. Thornton: Considerations in Computer Design – Leading up to the Control Data 6600. Control Data Corporation. 1963. Abgerufen am 7. Oktober 2019.
• James E. Thornton: Parallel operation in the Control Data 6600. In: AFIPS Proc. FJCC, pt. 2. 26, pp. 33-40, 1964. Abgerufen am 7. Oktober 2019.
• James E. Thornton: Design of a Computer – The Control Data 6600. Scott, Foresman and Co, Glenview, IL 1970, LCCN 74-096462 (bitsavers.org [PDF; abgerufen am 7. Oktober 2019]). 
• Ralph Grishman: Assembly language programming for the control data 6000 series and the Cyber 70 series. 1974 (bitsavers.org [PDF; abgerufen am 7. Oktober 2019]). 
• Speed and Power (Understanding Computers). Time-Life Books, 1990, ISBN 0-8094-7586-3. 

Weblinks

• Neil R. Lincoln: Reminiscences of computer architecture and computer design at Control Data Corporation. Charles Babbage Institute, University of Minnesota. 1975. Abgerufen am 7. Oktober 2019. – Organisierte Diskussion, moderiert von Neil R. Lincoln über Computer-Architektur und -Design bei der Control Data Corporation (CDC) mit 18 CDC-Ingenieuren: Robert Moe, Wayne Specker, Dennis Grinna, Tom Rowan, Maurice Hutson, Curt Alexander, Don Pagelkopf, Maris Bergmanis, Dolan Toth, Chuck Hawley, Larry Krueger, Mike Pavlov, Dave Resnick, Howard Krohn, Bill Bhend, Kent Steiner, Raymon Kort, and Lincoln. Zu den Diskussionsthemen zählen CDC 1604, CDC 6600, CDC 7600, CDC 8600, CDC STAR-100 und Seymour Cray.
• Gordon Bell: A Seymour Cray Perspective. In: Seymour Cray Lecture Series. University of Minnesota. 10. November 1997. Abgerufen am 7. Oktober 2019.
• CDC 6600's Five Year Reign. Computer History Museum. 2003. Abgerufen am 7. Oktober 2019: „The 6600 had 400,000 transistors and more than 100 miles of wiring.“ – Bebilderter Überblick.

Einzelnachweise

Vorgänger	Amt	Nachfolger
IBM 7030 Stretch	World’s most powerful computer 1964–1968	CDC 7600