Konzeption, Entwurf und Realisierung eines Prozessors fu r die funktionale Programmiersprache Scheme als VLSI-Chip in Standard- und Makrozellentechnik Dissertation zur Erlangung des Doktorgrades at Hamburg am Fachbereich Informatik der Universit vorgelegt von Jo rg Lohse aus Hamburg Hamburg, 1990 Genehmigt vom Fachbereich Informatik der Universit at Hamburg auf Antrag von Prof. Dr.-Ing. Klaus Lagemann (Referent) und Prof. Dr. Gu orz nther G (Korreferent) und Prof. Dr. Peter Marwedel (Korreferent) Hamburg, den 29. 10. 1990 (Datum der Disputation) Prof. Dr. Christopher Habel Der Sprecher des Fachbereichs Inhaltsverzeichnis Zusammenfassung x Summary xi Danksagungen xii Kurzfassung xiii 1 Einleitung 1 2 Die Programmiersprache Scheme 2.1 Aufbau von Scheme : : : : : : : : : : : : : : : : : 2.2 Vergleich von Scheme mit Pascal : : : : : : : : : : 2.2.1 Daten : : : : : : : : : : : : : : : : : : : : : 2.2.2 Prozeduren : : : : : : : : : : : : : : : : : : 2.2.3 Gultigkeitsbereiche von Variablen (Scoping) 2.2.3.1 Die dynamische Variablenbindung 2.2.3.2 Die statische Variablenbindung : : 2.2.3.3 Closures : : : : : : : : : : : : : : 2.2.4 Kontrollkonstrukte : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3.1 Reprasention der Objekte : : : : : : : : : : : : : : : : : 3.1.1 Reprasentation von Daten : : : : : : : : : : : : : 3.1.1.1 Symbole : : : : : : : : : : : : : : : : : 3.1.1.2 Zahlen : : : : : : : : : : : : : : : : : : 3.1.1.3 Zeichen (Chars) : : : : : : : : : : : : : 3.1.1.4 Zeichenketten (Strings) : : : : : : : : : 3.1.1.5 Die leere Liste : : : : : : : : : : : : : : 3.1.1.6 Paare und Listen : : : : : : : : : : : : : 3.1.1.7 Vektoren : : : : : : : : : : : : : : : : : 3.1.2 Interne Objekte : : : : : : : : : : : : : : : : : : : 3.1.2.1 Closures : : : : : : : : : : : : : : : : : 3.1.2.2 Bindungsumgebungen (Environments) : 3.1.2.3 Controlframes : : : : : : : : : : : : : : 3.1.2.4 Interne Darstellung von Programmen : 3.2 Die Speicherverwaltung : : : : : : : : : : : : : : : : : : 3.2.1 Referenzenzahlung : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3 Die Implementierung von Scheme i : : : : : : : : : : : : : : : : : : 3 3 4 4 5 5 6 6 7 8 11 11 14 14 14 15 15 16 16 17 17 17 18 20 23 24 25 ii INHALTSVERZEICHNIS 3.2.2 Mark-and-Sweep Algorithmus : : : : : : : : : : : : : : : : : : : : : : : : : : 3.2.3 Stop-and-Copy Algorithmus : : : : : : : : : : : : : : : : : : : : : : : : : : : 3.2.4 Inkrementelle Garbage Collection : : : : : : : : : : : : : : : : : : : : : : : : 4 Wichtige Implementationen von Scheme 4.1 Interpretation der Quelldarstellung : : : : 4.2 Interpretation von S-Code : : : : : : : : : 4.2.1 MIT C-Scheme : : : : : : : : : : : 4.2.2 Scheme-79 : : : : : : : : : : : : : : 4.2.3 Scheme-81 : : : : : : : : : : : : : : 4.3 Ubersetzung in virtuellen Maschinencode 4.3.1 PC Scheme : : : : : : : : : : : : : 4.3.2 MacScheme : : : : : : : : : : : : : 4.4 Ubersetzung in realen Maschinencode : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5.1 Folgerungen aus den bestehenden Implementationen : : : 5.2 Hardware-unterstutzte Implementationen von LISP : : : : 5.3 Eine neue Scheme-Implementation : : : : : : : : : : : : : 5.3.1 Verwandte Arbeiten : : : : : : : : : : : : : : : : : 5.4 Reprasentation der Objekte : : : : : : : : : : : : : : : : : 5.4.1 Das Speicherwort : : : : : : : : : : : : : : : : : : : 5.4.2 Die Typen der Objekte : : : : : : : : : : : : : : : 5.4.3 Darstellung von Bindungsumgebungen : : : : : : : 5.4.4 Darstellung von Controlframes und Continuations 5.4.5 Darstellung von Codevektoren : : : : : : : : : : : 5.5 Diskussion der Randbedingungen fur den Befehlssatz : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 Konzeption einer neuen Implementation 6 Entwurf integrierter Schaltungen 6.1 Integrierte Schaltungen : : : : : : : : : : : : : : : : 6.2 Entwurfsverfahren fur integrierte Schaltungen : : : : 6.2.1 Der Full-Custom Entwurf : : : : : : : : : : : 6.2.2 Der Semi-Custom Entwurf : : : : : : : : : : : 6.2.2.1 Die Gate-Array-Technik : : : : : : : 6.2.2.2 Die Standardzell-Technik : : : : : : 6.2.2.3 Die Makrozell-Technik : : : : : : : : 6.3 Der Ablauf eines Semi-Custom Entwurfs : : : : : : : 6.3.1 Schaltplaneingabe : : : : : : : : : : : : : : : 6.3.2 Netzlistenkompilation : : : : : : : : : : : : : 6.3.3 Logiksimulation : : : : : : : : : : : : : : : : : 6.3.4 Testmustergenerierung oder Fehlersimulation 6.3.5 Chipkonstruktion : : : : : : : : : : : : : : : : 6.3.6 Resimulation mit Leitungslaufzeiten : : : : : 6.4 Fertigungsmoglichkeiten fur Hochschulen : : : : : : : 6.5 Folgerungen fur den Entwurf des Scheme-Prozessors : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 25 26 26 28 28 29 29 29 31 32 33 33 34 35 35 35 36 40 40 41 42 43 43 44 44 46 46 47 47 48 48 49 50 51 51 53 53 53 54 54 55 56 iii INHALTSVERZEICHNIS 7 Festlegung von Architektur und Befehlssatz 7.1 Register- oder Stackarchitektur : : : : : : : : : : : : 7.1.1 Register mit VENUS-S : : : : : : : : : : : : 7.1.2 Wahl einer Stackarchitektur : : : : : : : : : : 7.2 Denition und Implementation eines Befehlssatzes : 7.2.1 Die Prozessorregister : : : : : : : : : : : : : : 7.2.1.1 Der Stack : : : : : : : : : : : : : : : 7.2.1.2 Die Environmentzeiger : : : : : : : 7.2.1.3 Der Controlframezeiger : : : : : : : 7.2.1.4 Der Funktionszeiger : : : : : : : : : 7.2.1.5 Der Programmzahler : : : : : : : : 7.2.1.6 Die Register der Speicherverwaltung 7.2.1.7 Die Register fur Speicherzugrie : : 7.2.1.8 Der Instructioncache : : : : : : : : : 7.2.1.9 Weitere Register : : : : : : : : : : : 7.2.1.10 Verwendung der Register : : : : : : 7.2.2 Wahl der Befehle : : : : : : : : : : : : : : : : 7.3 Literatur uber Befehlssatze fur LISP-Dialekte : : : : 7.3.1 Der Befehlsatz von Schooler und Stamos : : : 7.4 Der Befehlssatz des Scheme-Prozessors : : : : : : : : 7.4.1 Zugri auf Variable und Konstante : : : : : : 7.4.2 Sprungbefehle und Verzweigungen : : : : : : 7.4.3 Aufruf und Ruckkehr von Prozeduren : : : : 7.4.4 Typprufungen und Vergleiche : : : : : : : : : 7.4.5 Befehle fur Listen- und Vektoroperationen : : 7.4.6 Numerische Befehle : : : : : : : : : : : : : : 7.4.7 Zeichen- und zeichenkettenorientierte Befehle 7.5 Reprasentation der Befehle : : : : : : : : : : : : : : 7.6 Beispiele fur Programme in Bytecode : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8.1 Entwurfsebenen : : : : : : : : : : : : : : : : : : : : : : : : : : : 8.2 Verhaltensbeschreibung des Scheme-Prozessors : : : : : : : : : 8.2.1 Analyse der Verhaltensbeschreibung : : : : : : : : : : : 8.3 Strukturbeschreibung des Scheme-Prozessors auf RT-Ebene : : 8.3.1 Das Operationswerk : : : : : : : : : : : : : : : : : : : : 8.3.1.1 Die Registerbank : : : : : : : : : : : : : : : : : 8.3.1.1.1 Auswahl einzelner Felder der Register 8.3.1.1.2 Signale der Registerbank : : : : : : : 8.3.1.1.3 Ausgabe von Konstanten : : : : : : : 8.3.1.1.4 Einfuhrung von Pseudoregistern : : : 8.3.1.2 Die ALU : : : : : : : : : : : : : : : : : : : : : 8.3.1.3 Der Buszugrismodul : : : : : : : : : : : : : : 8.3.1.4 Das gesamte Operationswerk : : : : : : : : : : 8.3.1.4.1 Verbindungen zum Steuerwerk : : : : 8.3.1.4.2 Testbarkeit des Operationswerks : : : 8.3.2 Das Steuerwerk : : : : : : : : : : : : : : : : : : : : : : : 8.3.2.1 Der Befehlsdekoder : : : : : : : : : : : : : : : 8.3.2.2 Die Folgeadresteuerung : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8 Entwurf und Realisierung des Prozessors : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 57 57 57 58 58 59 59 59 59 59 59 60 60 60 61 61 62 65 65 66 66 66 66 69 69 69 70 70 70 73 73 76 78 79 80 81 81 81 83 83 84 84 86 86 89 89 91 91 iv INHALTSVERZEICHNIS 8.3.2.3 Gewahrleistung der Testbarkeit : : : : : : : : : : : : : : : : 8.3.2.4 Zeitbedingungen zwischen Operationswerk und Steuerwerk 8.4 Erstellung des Mikroprogramms : : : : : : : : : : : : : : : : : : : : : : : : : 8.4.1 Veroentlichungen u ber automatische Mikroprogrammgenerierung : 8.4.2 Mikroprogrammgenerierung fur den Scheme-Prozessor : : : : : : : : 8.5 Validierung von RT-Struktur und Mikroprogramm : : : : : : : : : : : : : : 8.6 Realisierung des Scheme-Prozessors mit VENUS-S : : : : : : : : : : : : : : 8.6.1 Realisierung des Buszugrismoduls : : : : : : : : : : : : : : : : : : : 8.6.2 Realisierung der ALU : : : : : : : : : : : : : : : : : : : : : : : : : : 8.6.3 Realisierung der Registerbank : : : : : : : : : : : : : : : : : : : : : : 8.6.3.1 Funktionseinheiten der Registerbank : : : : : : : : : : : : : 8.6.3.2 Realisierung der Spezialregister : : : : : : : : : : : : : : : : 8.6.4 Realisierung des Operationswerks : : : : : : : : : : : : : : : : : : : : 8.6.4.1 Validierung des Operationswerks : : : : : : : : : : : : : : : 8.6.5 Realisierung des Steuerwerks : : : : : : : : : : : : : : : : : : : : : : 8.6.5.1 Validierung des Steuerwerks : : : : : : : : : : : : : : : : : 8.6.6 Realisierung des Prozessors : : : : : : : : : : : : : : : : : : : : : : : 8.6.6.1 Validierung des Prozessors : : : : : : : : : : : : : : : : : : 8.6.6.2 Gewahrleistung der Testbarkeit des Prozessors : : : : : : : 9 Die Ergebnisse 9.1 9.2 9.3 9.4 Das Chip : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Die Implementation : : : : : : : : : : : : : : : : : : : : : : : Vergleich mit Scheme-81 : : : : : : : : : : : : : : : : : : : : : Neuere Veroentlichungen u ber Prozessorentwurfe fur Scheme 9.4.1 Scheme-86 : : : : : : : : : : : : : : : : : : : : : : : : : 9.4.2 Texas Instruments' LISP-Chip : : : : : : : : : : : : : 9.5 Bewertung der Ergebnisse : : : : : : : : : : : : : : : : : : : : 10 Schlussbetrachtungen 10.1 Ausblick : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 10.1.1 Vervollstandigung der Implementation : : : : : : : : : 10.1.2 Verbesserungsmoglichkeiten des Prozessors : : : : : : 10.1.3 Entwurfsmoglichkeiten bei anderen Randbedingungen 10.1.3.1 Einu eines anderen Entwurfssystems : : : 10.1.3.2 Einu eines anderen Zielrechners : : : : : : 10.2 Anwendung auf neuartige Entwurfssoftware : : : : : : : : : : A Der Befehlssatz des Scheme-Prozessors A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8 A.9 Zugrie auf Variablen : : : : : : : : : : : : : Zugrie auf Konstanten : : : : : : : : : : : : Sprung- und Verzweigungsbefehle : : : : : : : Aufruf und Ruckkehr von Prozeduren : : : : Typprufungen und Vergleiche : : : : : : : : : Listen- und Vektorbefehle : : : : : : : : : : : Numerische Befehle : : : : : : : : : : : : : : : Zeichen- und zeichenkettenorientierte Befehle Sonstige Befehle : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : und LISP : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 92 93 94 94 95 98 102 102 102 102 105 105 107 109 109 111 111 111 114 115 115 118 119 120 120 121 123 124 124 124 125 126 126 126 127 129 129 130 130 130 130 131 131 131 132 INHALTSVERZEICHNIS v B Gehause und Anschlussbelegung des Scheme-Prozessors 133 C Externe Beschaltung des Scheme-Prozessors 135 D Test der gefertigten Prozessoren 138 Literaturverzeichnis 140 Eidesstattliche Erklarung 148 Lebenslauf 149 C.1 Der Taktgenerator : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 135 C.2 Die Chipselectlogik : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 137 Abbildungsverzeichnis 2.1 2.2 2.3 2.4 2.5 2.6 2.7 Konstanten verschiedener Objekttypen in Scheme. : : : : : : Ubergabe der Identitatsfunktion in Pascal und Scheme. : : : Beispiel fur dynamische Variablenbindung. : : : : : : : : : : : Verwendungsmoglichkeit fur eine Closure. : : : : : : : : : : : Veranschaulichung der Closures. : : : : : : : : : : : : : : : : Beispiel fur call-with-current-continuation . : : : : : : : Beispiel fur die unbegrenzte Lebensdauer einer Continuation. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 6 6 7 8 9 10 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 Beispielprogramm fur die Objektreprasentation. : : : : : : : : : : Veranschaulichung der Zeiger auf Objekte. : : : : : : : : : : : : : Das Paar (6 . ()) bei Typreprasentation im Zeiger. : : : : : : : Das Paar (6 . ()) bei Typreprasentation im Objekt. : : : : : : Uber Zeiger zu referenzierende Fliekommazahl (boxed FLONUM). Reprasentation eines Strings als kontinuierlicher Speicherbereich. Aufbau einer CONS-Zelle. : : : : : : : : : : : : : : : : : : : : : : Reprasentation der Liste (1 2 3) mit CONS-Zellen. : : : : : : : Reprasentation der Liste (1 2 3) in CDR-Kodierung. : : : : : : Reprasentation des Vektors #(1 2 3). : : : : : : : : : : : : : : : Beispielprogramm fur einen Prozeduraufruf. : : : : : : : : : : : : Die Bindungsumgebung von f nach dem Funktionsaufruf. : : : : Reprasentation der Bindungsumgebung von f durch Vektoren. : Reprasentation der Bindungsumgebung von f durch Listen. : : : Beispiel fur die unbegrenzte Lebensdauer einer Continuation. : : Implementierung einer Continuation. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 11 12 13 13 15 15 16 16 17 17 18 18 19 20 21 22 4.1 Das Wordformat von Scheme-79. : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4.2 Mit Scheme-79 gerechnetes Testprogramm. : : : : : : : : : : : : : : : : : : : : : : 4.3 Das Wordformat von Scheme-81. : : : : : : : : : : : : : : : : : : : : : : : : : : : : 29 30 31 5.1 5.2 5.3 5.4 5.5 5.6 5.7 : : : : : : : 38 39 41 43 43 44 44 6.1 Schematischer Aufbau eines Gate-Arrays. : : : : : : : : : : : : : : : : : : : : : : : 6.2 Schematischer Aufbau eines Standardzell-ICs. : : : : : : : : : : : : : : : : : : : : : 48 49 Der Scheme-Prozessor in einem 68000-Rechner. : : : : : : : Der Scheme-Prozessor am 68000-Bus. : : : : : : : : : : : : Struktur der Speicherworte des Scheme-Prozessors. : : : : : Bindungsumgebung nach Prozeduraufruf (f 'A 2 "abc"). Aufbau eines Controlframes. : : : : : : : : : : : : : : : : : : Aufbau eines Codevektors. : : : : : : : : : : : : : : : : : : : Codevektor der Prozedur list. : : : : : : : : : : : : : : : : vi : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : vii ABBILDUNGSVERZEICHNIS 6.3 Ausschnitt aus einer Standardzellzeile. : : : : : : : : : : : : : : : : : : : : : : : : : 6.4 Schematischer Aufbau eines Makrozell-ICs. : : : : : : : : : : : : : : : : : : : : : : 6.5 Schematischer Ablauf eines Entwurfs mit VENUS. : : : : : : : : : : : : : : : : : : 50 51 52 7.1 7.2 7.3 7.4 7.5 7.6 Die Register nach Aufruf einer Funktion mit drei Parametern. : Format der Verzweigungsbefehle. : : : : : : : : : : : : : : : : : Der Stack nach Anlegen eines Controlframes. : : : : : : : : : : Der Stack nach Evaluieren von Parametern und Prozedur g. : : Der Stack nach Aufruf der Prozedur. : : : : : : : : : : : : : : : Die Befehlsformate des Scheme-Prozessors. : : : : : : : : : : : : : : : : : 61 66 67 68 69 70 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 74 75 76 79 80 82 86 8.9 8.10 8.11 8.12 8.13 8.14 8.15 8.16 8.17 8.18 8.19 8.20 8.21 8.22 8.23 Sichten und Abstraktionsebenen bei Spezikation und Entwurf (Y-Diagramm). : : Beitrag von VENUS-S zum Entwurfsproze als Y-Diagramm. : : : : : : : : : : : : Die Entwurfsebenen des Prozessors. : : : : : : : : : : : : : : : : : : : : : : : : : : Operationswerk und Steuerwerk des Scheme-Prozessors. : : : : : : : : : : : : : : : Schematische Struktur des Operationswerks. : : : : : : : : : : : : : : : : : : : : : : Die Signale der Registerbank. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Struktur der ALU. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Buszugrismodul und Registerbank sowie die Verbindungen des Scheme-Prozessors zur Auenwelt. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Das Operationswerk des Scheme-Prozessors. : : : : : : : : : : : : : : : : : : : : : : Das Steuerwerk des Scheme-Prozessors. : : : : : : : : : : : : : : : : : : : : : : : : RT-Spezikation des Befehlsdekoders in Karl II. : : : : : : : : : : : : : : : : : : : Generierung des Mikroprogramms. : : : : : : : : : : : : : : : : : : : : : : : : : : : Protokoll eines Mikroprogrammcompilerlaufes. : : : : : : : : : : : : : : : : : : : : Ausschnitt aus dem erzeugten binaren Mikroprogramm. : : : : : : : : : : : : : : : Einbindung des RT-Simulators in die Entwurfsprogramme. : : : : : : : : : : : : : : Realisierung der Registerbank mit Multiplexern. : : : : : : : : : : : : : : : : : : : Realisierung der Registerbank mit Tri-State-Bussen. : : : : : : : : : : : : : : : : : Plazierung der Standardzellen in der Registerbank. : : : : : : : : : : : : : : : : : : Die Struktur der Registerbank. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Plazierung des Operationswerks. : : : : : : : : : : : : : : : : : : : : : : : : : : : : Simulation des Operationswerks auf Gatterebene. : : : : : : : : : : : : : : : : : : : Simulation des Steuerwerks auf Gatterebene. : : : : : : : : : : : : : : : : : : : : : Plazierung des Scheme-Prozessors. : : : : : : : : : : : : : : : : : : : : : : : : : : : 87 88 90 91 95 99 99 101 103 103 104 106 108 110 112 113 9.1 9.2 9.3 9.4 Das Layout des Scheme-Prozessors. : : : : : : : : : : Photo des Scheme-Prozessors im geoneten Gehause. Photo des Chips im Gehause. : : : : : : : : : : : : : Operationswerk des LISP-Prozessors von TI. : : : : 116 117 117 122 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : B.1 Das Gehause PGA-88 der Scheme-Prozessors. : : : : : : : : : : : : : : : : : : : : : 133 C.1 Die Takte des Scheme-Prozessors. : : : : : : : : : : : : : : : : : : : : : : : : : : : : 136 C.2 Der Taktgenerator fur den Scheme-Prozessor im Atari ST. : : : : : : : : : : : : : : 136 C.3 Die Chipselectlogik fur den Scheme-Prozessor im Atari ST. : : : : : : : : : : : : : 137 Tabellenverzeichnis 2.1 Schlusselworte in Scheme. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2.2 Objekte in Scheme. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3 4 3.1 CDR-Codes. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 16 4.1 Durch Scheme-79 unterstutzte Standardprozeduren. : : : : : : : : : : : : : : : : : 30 5.1 Verteilung der CPU-Zeit in LISP-Programmen nach [StHe88]. : : : : : : : : : : : : 5.2 Belegungen der CDR-Codes. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5.3 Vom Scheme-Prozessor unterstutzte Objekte. : : : : : : : : : : : : : : : : : : : : : 37 42 42 6.1 Integrationsgrade integrierter Schaltungen. : : : : : : : : : : : : : : : : : : : : : : : 6.2 Mogliche Chipgroen fur Hochschulentwurfe. : : : : : : : : : : : : : : : : : : : : : 46 55 7.1 Die Register des Scheme-Prozessors. : : : : : : : : : : : : : : : : : : : : : : : : : : 7.2 Im Mikroprogramm realisierte Standardprozeduren. : : : : : : : : : : : : : : : : : 60 64 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14 8.15 Tabellarische Form des Y-Diagramms. : : : : : : : : : : : : : : : : : : : : : Tabellarische Form des Y-Diagramms beim Entwurf des Scheme-Prozessors. Bestandteile des Verhaltenssimulators. : : : : : : : : : : : : : : : : : : : : : Grammatik in der Verhaltensbeschreibung vorkommender Ausdrucke. : : : Operationen der Feldauswahl. : : : : : : : : : : : : : : : : : : : : : : : : : : Register und Pseudoregister in der Registerbank. : : : : : : : : : : : : : : : Operationen von Addierer und Komplementer. : : : : : : : : : : : : : : : : Operationen des Shifters. : : : : : : : : : : : : : : : : : : : : : : : : : : : : Mikrobefehle fur die Folgeadrebestimmung. : : : : : : : : : : : : : : : : : : Mikroinstruktionsabarbeitung ohne Pipelining. : : : : : : : : : : : : : : : : Mikroinstruktionsabarbeitung mit Pipelining. : : : : : : : : : : : : : : : : : Mikrobefehle einer Mikroinstruktion. : : : : : : : : : : : : : : : : : : : : : : Statistik des Operationswerks. : : : : : : : : : : : : : : : : : : : : : : : : : : Statistik des Steuerwerks (ohne ROM). : : : : : : : : : : : : : : : : : : : : : Statistik des Scheme-Prozessors. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 74 : 76 : 77 : 78 : 82 : 85 : 85 : 85 : 92 : 93 : 93 : 94 : 109 : 111 : 113 9.1 Vergleich des Scheme-Prozessors mit anderen 68000-Implementationen. : : : : : : : 118 9.2 Vergleich des Scheme-Prozessors mit Scheme-81. : : : : : : : : : : : : : : : : : : : 119 9.3 Statistik des LISP-Chips von TI. : : : : : : : : : : : : : : : : : : : : : : : : : : : : 122 B.1 Die Anschlubelegung der Scheme-Prozessors. : : : : : : : : : : : : : : : : : : : : : 134 viii TABELLENVERZEICHNIS ix D.1 Ergebnisse des Tests der Prozessoren. : : : : : : : : : : : : : : : : : : : : : : : : : 139 x ZUSAMMENFASSUNG Konzeption, Entwurf und Realisierung eines Prozessors fu r die funktionale Programmiersprache Scheme als VLSI-Chip in Standard- und Makrozellentechnik Zusammenfassung Das Ziel dieser Arbeit war eine neue Hardwareimplementation der Programmiersprache Scheme. Ein als integrierter Schaltkreis realisierter Prozessor wird in vorhandene 68000-Mikrorechner eingesetzt und arbeitet einen Scheme-spezischen Befehlssatz ab. Der Prozessor ermoglicht eine beschleunigte und speicherplatzeziente Implementation von Scheme. Die bisherigen Pozessorentwurfe zielten darauf ab, einige Grundeinsichten zu gewinnen, und sie begnugten sich deshalb mit dem unumganglichen Minimum an Objekttypen: Nur Zahlen und CONS-Zellen wurden reprasentiert. Dagegen stellt sich diese Arbeit zusatzlich den Kriterien praktischer Nutzbarkeit: dabei waren vor allem schwierige Anforderungen zur Objektreprasentation | ezienter Zugri, kompakte Reprasentation, groe Vielfalt der Objekte | unter restriktiven Randbedingungen, wie z.B. begrenzte Chipache, zu erfullen. Der Reprasentation der Programme, der Schnittstelle zwischen Hardware und Software, wird dabei eine besondere Bedeutung zugemessen. Ausgehend von dem Stand der Technik in Compilerbau einerseits und den Entwurfs- und Fertigungsmoglichkeiten andererseits wurde der Befehlssatz festgelegt. Die entwickelte Architektur umfat eine 24-Bit ALU, eine Tag-orientierte 3-Port Registerbank, einen parallel arbeitenden Buszugrismodul und ein mikroprogrammiertes Steuerwerk mit 2-stuger Pipeline. Die Mikroprogramme wurden durch einen dafur erstellten Compiler automatisch aus der Verhaltensbeschreibung generiert. Das Entwurfsvorgehen berucksichtigte durch Entwurfssoftware und Fertigungsmoglichkeiten bestehende Randbedingungen und erlaubte den Entwurf des Prozessors in kurzer Zeit. Insbesondere wurden Simulationsstimuli und erwartete Simulationsergebnisse automatisch generiert und die erzielten Simulationsergebnisse mit den erwarteten automatisiert verglichen. Die Struktur des Prozessors auf Gatterebene erwies sich als sehr komplex. Sie enthalt mehr als die doppelte vom Hersteller angegebene maximal erreichbare Transistorzahl und bewirkte extrem lange Laufzeiten und das Uberschreiten der Kapazitat der Entwurfsprogramme. Die als integrierte Schaltungen gefertigten Prototypen wurden in einen Atari ST eingebaut. Damit gerechnete Benchmarks weisen eine Geschwindigkeitssteigerung um einen Faktor von uber zehn gegenuber anderen 68000-Implementationen aus, und selbst gegenuber in 68000-Maschinencode ubersetzten Programmen erzielen diese Chips eine Verdopplung bis Versiebenfachung der Geschwindigkeit. SUMMARY xi The conceptual and structural design of a processor for the functional programming language Scheme in VLSI standard- and macro-cell technique. Summary We are aiming to provide a new hardware implementation of the programming language Scheme [Rees86]. The hardware implementation is realized as an integrated circuit which can be added to available 68000-systems. The processor which runs Scheme-specic machine code is fast and makes ecient use of memory. Previous hardware implementations of Scheme [Suss81, Bata82] were based on the (theoretical) minimum of number and CONS-cell object types. In this project this overt theoretical view is rejected for a practical approach: In the practice of programming Scheme the language implementation has to provide ecient access to a large number of diverse object types. These requirements are our main design criteria. The representation of programs | interface between hardware and software | is considered especially important. The state of the art in compiler construction on the one hand and the design software and fabrication facility on the other hand lead to the instruction set. The developed architecure consists of a 24-bit ALU, a tag-oriented 3-port register bank, an autonomous bus controler, and a micro-programed control unit with 2-stage pipeline. The neccessary micro-programs were generated automatically from the behavioural description. The design process was restricted by the production facility's time table and the available design software. (For example the whole design had to be completed within a time-span of 11 months). Our approach was to write programs which generated simulation data and expected results. These expected simulation results were automatically compared with the results of the simulation. The gate-level complexity of the processor is very high. It has twice the transistor count as provided by the available design software. The capacity of the design software was greatly overstretched and the great number of components led to extremely long program runs. Prototypes of the chip were tested with an Atari ST. Benchmark results show a speed gain of a factor of ten compared to other 68000 Scheme software implementations. It is even two to seven times faster than compiled 68000 machine code. xii Danksagungen Ich danke Prof. Dr.-Ing. K. Lagemann fur die freundliche Unterstutzung dieses Projekts. Ferner danke ich Prof. Dr. Gunther Gorz fur das Interesse an diesen Arbeiten, fur das Uberlassen der Benchmarkprogramme und fur die fruchtbaren Diskussionen. An der Ausfuhrung der Arbeiten waren Kollegen und Studenten beteiligt: Mein besonderer Dank gilt den Kollegen Dr. Reinhard Rauscher und Bernd Schutz fur ihre Unterstutzung bis hin zur Beteiligung an der Schaltplaneingabe und Simulation der Registerbank. Norman Hendrich danke ich fur die zuverlassige Realisierung des Buszugrismoduls mit VENUS-S. Lars Hagge, Lars Larsson und Dirk Michelsen gebuhrt Dank fur die Realisierung von groen Teilen des Steuerwerks. Andreas Gromann und Marcus Schorn haben fast alle der nicht als Prozessorbefehle vorhandenen Standardprozeduren implementiert. Ingo Marks hat einen bildschirmorientierten Editor erstellt, und Thomas Scharler hat die gefertigten Chips getestet. Auch dem Rechenzentrum des Fachbereichs gebuhrt Dank fur die Duldung der vielen Batchjobs mit unbegrenzter Laufzeit auf der VAX-8550. Nur dadurch war es moglich, den Befehlssatz und das Mikroprogramm so intensiv zu simulieren, da sie unabanderlich in einem integrierten Schaltkreis untergebracht werden konnten. KURZFASSUNG xiii Konzeption, Entwurf und Realisierung eines Prozessors fu r die funktionale Programmiersprache Scheme als VLSI-Chip in Standard- und Makrozellentechnik (Kurzfassung) Das Ziel dieser Arbeit war eine neue Hardwareimplementation der Programmiersprache Scheme [Rees86]. In dieser Arbeit werden die Programmiersprache Scheme [Rees86] und die Engpasse bei der Implementierung dieser Sprache beschrieben. Als Engpasse wurden Typenprufungen zur Laufzeit, hauge und aufwendige Prozeduraufrufe, die Speicherverwaltung sowie die Notwendigkeit, lokale Variablen und Controlframes im allgemeinen Fall nicht in einem Stack allozieren zu konnen, identiziert. Zur Entscharfung dieser Engpasse wurde eine Hardwareimplementation konzipiert, die speziell auf Scheme zugeschnitten ist. Fur die Konzeption dieser Implementation wurden bestehende Hardware- und Software-Implementationen von Scheme analysiert und Voraussetzungen fur eine eziente Implementation erarbeitet. Diese Voraussetzungen bestehen in einer ezienten Reprasentation der Objekte, im Schonen der rechenzeitintensiven Speicherverwaltung durch die Allokation von lokalen Variablen und Controlframes | soweit das moglich ist | im Stack und in der Verlagerung der Typprufungen und der Speicherverwaltung in Hardware. Als Ziel einer solchen neuartigen Hardwareimplementation wurde ein Scheme-Prozessor, der als integrierter Schaltkreis in einen vorhandenen 68000-Rechner [68000] eingesetzt werden soll, gewahlt. Diese Wahl fuhrte zur zusatzlichen Randbedingung, da der Hauptspeicher eine knappe Resource ist, mit der sparsam umzugehen ist. Als Entwufssystem fur den integrierten Schaltkreis stand die Software VENUS-S der Siemens AG zur Verfugung [Horb86] mit Fertigungsmoglichkeiten in einem 2 CMOS-Proze [Stei88]. Die zeitlich beschrankte Nutzungsmoglichkeit von VENUS-S fuhrte zu der Forderung, den Prototyp des Scheme-Prozessors in nur 11 Monaten bis zur Fertigungsreife zu entwerfen. Auch dieser Zeitplan hatte Einu auf das Entwurfsvorgehen. Der Entwurf mit dem beschriebenen Ziel und unter den dargestellten Randbedingungen begann mit der Bestimmung der Reprasentation der Objekte, insbesondere mit der Reprasentation der Programme. In diesem Ansatz uberwindet dieser Entwurf die festgefahrene Konzeption der beste- xiv KURZFASSUNG henden, am M.I.T. entworfenen Scheme-Prozessoren [Suss81, Bata82]. Die bestehenden Entwurfe gingen von einer theoretisch ausreichenden, minimal notigen Vielfalt von Objekten aus: Nur Zahlen und CONS-Zellen wurden implementiert. In dieser Arbeit wird bei der Objektreprasentation praktischen Anforderungen | ezienter Zugri, kompakte Reprasentation, groe Vielfalt der Objekte | gefolgt. Die hier gewahlte Objektreprasentation wurde in einer fruhen Phase, vor Erstellung der Verhaltensbeschreibung, vorgegeben und damit sichergestellt, da sie bei Spezikation weiterer Parameter und beim Hardwareentwurf nicht mehr zur Disposition gestellt werden konnte. Programme werden in dieser Implementation durch Bytecode reprasentiert. Bytecode ist sehr kompakt (Faktor 3 kompakter als der Code der bestehenden Scheme-Prozessoren [ScSt84] und Faktor 5 kompakter als 68000-Maschinencode [Sem87]). Die eziente Ubersetzung von Scheme in Bytecode ist bereits Stand der Technik [BaJe86, Sem87, ScSt84, Kran88]. Listen werden durch CDR-Kodierung [Hans69] reprasentiert, ein zuvor nur bei kommerziellen LISP-Maschinen eingesetztes Verfahren. Am Anfang des Entwurfsprozesses stand der Entwurf eines Befehlssatzes und die Festlegung der benotigten Prozessorregister. Ein Befehlssatzinterpreter wurde erstellt und um einen SchemeCompiler, die Speicherverwaltung und diverse Scheme-Standardprozeduren erweitert. Entstanden war damit eine Verhaltensbeschreibung des Prozessors in Form einer Software-Implementation von Scheme. Diese Verhaltensbeschreibung wurde genutzt, um den Befehlssatz zu erproben und zu optimieren und um noch vor der Fertigstellung des Prozessors Software fur den Prozessor zu erstellen. Nachdem das Verhalten des zu entwerfenden Prozessors in Form einer Verhaltensbeschreibung speziziert war, begann der Hardwareentwurf einer Struktur auf Registertransferebene. Es stand nur eine sehr kurze Zeit bis zum Abgabetermin des fertigen Chips zur Verfugung, und dieser restriktive Zeitplan erforderte die Entwicklung eines systematischen Vorgehens beim Entwurf: Um systematisch eine Prozessorarchitektur entwerfen zu konnen, wurde die als Pascalprogramm vorliegende Verhaltensbeschreibung analysiert. Die erhaltenen Analyseergebnisse umfassen hauge auftretende Befehlsfolgen, die Verteilung der Register und Registerfelder in Ausdrucken und Zuweisungen, die verwendete Konstrollstrukturen und eine Grammatik der enthaltenen Ausdrucke. Diese Analyseergebnisse beschreiben Anforderungen an die Hardwarearchitektur des entworfenen Prozessors. Zusatzliche die Vielzahl der moglichen Architekturen einschrankende Randbedingungen kommen aus dem IC-Entwurfssystem mit Standard- und Makrozellentechnik und den Fertigungsmoglichkeiten hinzu. Die Anforderungen und Randbedingungen bestimmen die entworfene Architektur: Die Haugkeit der Ausdrucke mit zwei Operanden erforderte eine Registerbank mit mindestens zwei Ausgangsports, das Entwurfssystem erlaubt nur die Realisierung einer solchen Registerbank aus Standardzellen, eine platzaufwendige Losung, die nur eine geringe Anzahl von Registern zulat und damit zur Entscheidung fur einen stackorientierten Befehlssatz fuhrte. Die bei der Analyse der Verhaltensbeschreibung ermittelten haugen Schreib- und Lesezugrie auf einzelne Felder der Register fuhrte zur Entscheidung fur eine Registerbank mit drei Ports, die neben den Portadressen auch die einzelnen Felder direkt adressieren kann. Die Spezikation der ALU wurde direkt aus der Grammatik der in der Analyse ermittelten Ausdrucke entwickelt. Die ALU kann alle diese Ausdrucke in 20 ns berechnen. Ein Hauptspeicherzugri des Prozessors dauert, durch die Verwendung des vorhandenen Hauptspeichers im PC bedingt, bis zu zehn Zyklen. Hauptspeicherzugrie waren deshalb zu reduzieren. Ferner entstand ein Buszugrismodul, der parallel zur Abarbeitung des Mikroprogramms im Scheme-Prozessor diese Zugrie abwickelt. Das Mikroprogramm verzogert daher die in anderen LISP-Prozessoren parallel ausfuhrbaren Typenprufungen bis zum nachsten Hauptspeicherzugri und kann sie daher fast immer ohne zusatzlichen Zeitbedarf ausfuhren. Die Struktur des Steuerwerks wurde so entworfen, da sie sowohl den Anforderungen aus der Analyse der Verhaltensbeschreibung dient als auch den Randbedingungen des Entwurfssystems KURZFASSUNG xv genugt: Ein mikroprogrammiertes Steuerwerk mit einem Mikroprogramm-ROM mit 39 Bit Breite und 1024 Worten, der mit dem Entwurfssystem maximal moglichen ROM-Groe, ermoglicht eine Vielzahl von aus den Kontrollstrukturen der Verhaltensbeschreibung entwickelten Folgeadressierungen. Das Steuerwerk beinhaltet eine zweistuge Pipeline und gewahrleistet auch die bei ICEntwurfen sehr wichtige Testbarkeit des Prozessors. Das Mikroprogramm wurde automatisch durch einen fur diesen Zweck erstellten optimierenden Compiler aus der Verhaltensbeschreibung generiert. Ein neuartiger RT-Simulator simulierte RT-Struktur und Mikroprogramm und verglich seine Ergebnisse parallel mit einer Simulation der Verhaltensbeschreibung. Nach simulativer Validierung der Verhaltensbeschreibung erfolgte die Realisierung der RTStruktur mit dem auf Gatterebene aufsetzenden Chip-Entwurfssystem VENUS-S. Die Struktur wurde manuell auf Gatterebene transformiert und in VENUS-S eingegeben und simuliert. Die automatische Generierung von Simulationsstimuli und einer Spezikation des erwarteten Verhaltens durch den RT-Simulator wurde entwickelt, um die Struktur auf Gatterebene systematisch validieren zu konnen. Die Simulationsergebnisse wurden durch (neu erstellte und vorhandene) Programme mit der Spezikation des erwarteten Verhaltens verglichen und erlaubten so eine eziente Validierung der Struktur auf Gatterebene. Die Struktur des Prozessors aus Gatterebene erwies sich als sehr komplex. Sie enthalt mehr als die doppelte vom Hersteller fur die zur Verfugung stehende Chipache angegebene maximal erreichbare Transistorzahl und bewirkte extrem lange Laufzeiten und das Uberschreiten der Kapazitat der Entwurfsprogramme. Um diese Schaltung auf der Chipache unterbringen zu konnen, waren detaillierte Uberlegungen u ber eine optimale Plazierung der Zellen auf dem Chip und das manuelle Plazieren von uber 90 % aller Standardzellen notig. Der Prozessor wurde bei der Siemens AG gefertigt. Die gefertigten Prototypen wurden auf Herstellungfehler getestet und die korrekt gefertigten Exemplare in einen Atari ST eingebaut. Gerechnete Benchmarks weisen eine Geschwindigkeitssteigerung mit einem Faktor von uber zehn gegenuber anderen 68000-Implementationen aus, und selbst gegenuber in 68000-Maschinencode ubersetzten Programmen bewirken die Chips eine Verdopplung bis Versiebenfachung der Geschwindigkeit. Damit ist das Ziel einer ezienten, speicherplatzsparenden Implementation fur 68000-Rechner erreicht. Ein Vergleich des Prozessors mit den Entwurfen des MITs zeigt die Richtigkeit der hier zugrunde gelegten Implementationsentscheidungen: Von praktischen Anforderungen ausgehend konnte ein Prozessor entworfen werden, der die gesamte Sprache unterstutzt und ein Vielfaches der in den bisherigen Prozessoren unterstutzten Standardprozeduren in die Hardware verlagert. Das Resultat ist der erste wirklich einsetzbare Scheme-Prozessor. Abschlieend werden weitere Arbeiten beschrieben. Diese umfassen eine kurze Beschreibung der bestehenden Implementation und geplante Erweiterungen. Der Einu der Randbedingungen auf den Prozessor-Entwurf wird untersucht und dabei diskutiert, welche alternative Moglichkeiten die IC-Entwurfssoftware anderer Hersteller geboten hatte. Auch wird beschrieben, wie der Scheme-Prozessor fur andere Zielrechner aussehen mute. Den Abschlu bildet eine Darstellung der Vorteile, die ein zukunftiges Expertensystem aus dem hier entwickelten Entwurfsverfahren gegenuber traditionellen Synthesewerkzeugen ziehen kann. Kapitel 1 Einleitung Programmiersprachen sind so alt wie die elektronische Datenverarbeitung. Am Anfang der Entwicklung erlaubten Assembler die symbolische Benennung von Maschinenbefehlen und Hauptspeicheradressen. Spater etablierten sich problemorientierte Programmiersprachen, die Programme auch zwischen unterschiedlichen Rechnern portabel gestalten sollten. Heute gibt es eine Vielzahl von Programmiersprachen fur die unterschiedlichsten Anwendungsgebiete. LISP ist die nach FORTRAN zweitalteste heute noch eingesetzte hohere Programmiersprache. LISP wurde bereits 1960 von John McCarty beschrieben [McCa60]. Der Begri "funktionale Sprache\ wird von den Verfechtern seiteneektfreier Sprachen, die mit dem 1971 in Wadsworths Dissertation erstmals beschrieben [Wads71] Verfahren der Graphenreduktion implementiert werden, mit einem Anspruch auf Ausschlielichkeit fur sich reserviert. Diese Sprachen und ihre Implementierung ist bei Peyton Jones [Peyt87] dargestellt und in deutscher Sprache zum Beispiel von Maurer und Wilhelm [MaWi89] zusammengefat. In dieser Arbeit erstreckt sich der Begri funktionale Sprachen auch auf LISP und seine Dialekte. LISP ist mit seinen Eigenschaften, der gleichen Darstellung fur Programme und Daten sowie der dynamischen Typisierung im Gegensatz zu den reinen funktionalen Sprachen wie etwa ML, Ponder, Lazy ML und Miranda [Peyt87] eine sehr weit verbreitete Programmiersprache, die insbesondere im Bereich der kunstlichen Intelligenz immer mehr Verwendung ndet. Scheme, ein Dialekt von LISP, entstand 1975 am Massachusetts Institute of Technology (MIT) [SuSt75]. Die statischen Gultigkeitsbereiche fur Variablen erlaubten die Aufhebung einer Einschrankung traditioneller LISP-Dialekte bei der Verwendung von Funktionen: Funktionen konnen in Scheme ohne Komplikationen auch als Funktionswerte zuruckgegeben und als Parameter an Funktionen ubergeben werden. Damit war Scheme eine orthogonal aufgebaute Sprache, in der Funktionen gegenuber allen anderen Objekten nicht eingeschrankt wurden, und Scheme erlangte an amerikanischen Universitaten Bedeutung, wo Yale die ahnliche Sprache T [Rees84] entwickelte und Scheme auch an der Indiana University implementiert wurde [Fell83, Frie85]. Sogar in der Grundausbildung der Informatik- und Elektrotechnikstudenten wurde Scheme an diesen Hochschulen eingesetzt. Der Kurs am MIT wurde besonders durch das Lehrbuch von Abelson und Sussman "Structure and Interpretation of Computer Programs\ [AbSu85] verbreitet. Nach diesem Lehrbuch wird inzwischen an vielen Hochschulen auch in Europa die Informatikgrundausbildung gegeben und damit auch Scheme verwendet. Scheme ist eine Stufe eines europaischen LISP-Standards [Padg86] und wird auch von der IEEE genormt. Die wachsende Anzahl von Lehrbuchern fur Scheme [Dybv87, Eise88, Smit88] zeigt die steigende Akzeptanz der Sprache. Der Preis, den der Anwender bei der Nutzung einer Sprache wie Scheme zahlen mu, besteht zum einen in zusatzlichem Aufwand zur Laufzeit (Typprufungen, aufwendige Prozeduraufrufe, Un- 2 KAPITEL 1. EINLEITUNG terstutzung von Closures1 und Continuations2 ohne Restriktionen) und zum anderen in durch die Datenstrukturen (Objekte mit Garbage Collection) verursachtem Rechenzeit- und Speichermehrbedarf. Von vielen Anwendern wird eine Scheme-Implementation auf herkommlichen Rechnern (Universalrechnern) aufgrund der Laufzeiten und des Speicherbedarfs als nicht akzeptabel empfunden. Gerade dies war die Intention fur eine Hardwareimplementation, die einen preiswerten Mikrorechner durch einen zusatzlichen Scheme-Prozessor gegenuber Softwareimplementationen um den Faktor 10 beschleunigt und auch den Speicherplatzbedarf verringert. Diese Arbeit stellt nicht nur die Hardwareimplementation vor; auch die dafur entwickelten neuen Techniken, die die gesamten Entwicklung in elf Monaten erlaubten, werden ebenso wie die gewahlten Entwurfsentscheidungen, die es ermoglichten, mehr als die doppelte Transistorzahl, als der Hersteller angibt, auf dem entworfenen integrierten Schaltkreis unterzubringen, beschrieben. Ferner wird der entstandene Chip mit den Entwurfen des MITs verglichen und gezeigt, da dieser Chip als einziger die Sprache Scheme vollstandig unterstutzt und auch im Vergleich mit den bisherigen Prozessoren ein Vielfaches der Anzahl von Standardprozeduren als Prozessorbefehle bietet. 1 Folge: 2 Folge: Die lokalen Variablen einer Prozedur bleiben auch nach Ruckkehr von der Prozedur noch zugreifbar. Eine Prozedur kann nach einmaligem Aufruf beliebig haug zuruckkehren. Kapitel 2 Die Programmiersprache Scheme Die Programmiersprache Scheme ist ein Dialekt der Sprache LISP, die 1960 zuerst beschrieben wurde [McCa60]. Der derzeit aktuelle Report der Sprache Scheme ist der "Revised3 Report on the Algorithmic Language Scheme\ 1 [Rees86]. Da Scheme ausschlielich in Forschung und Lehre genutzt wird, unterliegt es laufenden Veranderungen, denen im Abstand von einigen Jahren jeweils ein neuer Report Rechnung tragt [StSu78, Clin85, Rees86]. Der "Revised4 Report\ soll 1990 erscheinen [WG89] und den aktuellen Report ablosen. Ferner wird Scheme international standardisiert (IEEE P1178, ISO/IEC JTC1/SC22/WG16), wobei der "Revised4 Report\ auch als Vorschlag fur diese Standards dienen soll [WG89]. In diesem Kapitel soll ein Uberblick uber Prinzipien und Eigenschaften der Sprache Scheme gegeben werden. Auf Unterschiede zu traditionellen LISP-Dialekten wird hingewiesen. Fur eine vollstandige, systematische Darstellung wird auf den Sprachreport [Rees86] verwiesen. Dort wird die Sprache erklart, und es werden dort Syntax und Semantik formal speziziert. 2.1 Aufbau von Scheme Scheme besteht aus Ausdrucken, die entweder primitive Ausdrucke (primitive expressions) oder abgeleitete Ausdrucke (derived expressions) sind. Die abgeleiteten Ausdrucke dienen der bequemen und besonders lesbaren Notation, sie werden vor der Auswertung der Ausdrucke in Kombinationen primitiver Ausdrucke ubersetzt. => and begin case cond define delay do else if lambda let let* letrec or quasiquote quote set! unquote unquote-splicing Tabelle 2.1: Schlusselworte in Scheme. Scheme kennt Schlusselworte (Tabelle 2.1), die nicht als Bezeichner Verwendung nden durfen. 1 Dieser Titel ist an die Reports von Algol-60 [Naur63] angelehnt. 4 KAPITEL 2. DIE PROGRAMMIERSPRACHE SCHEME Primitive und abgeleitete Ausdrucke werden syntaktisch durch die Schlusselworte von Prozeduraufrufen unterschieden. Scheme ist eine in einer interaktiven Umgebung verwendete Programmiersprache. Der Programmierer gibt Denitionen und Ausdrucke ein, die sofort ausgewertet werden. Programme und Daten werden (extern) gleich dargestellt. Ausdrucke und Denitionen sind als Programme zu interpretierende Daten. 2.2 Vergleich von Scheme mit Pascal Hier sollen die Unterschiede zu Pascal [JeWi78] als Vertreter einer verbreiteten, modernen Universalsprache dargestellt werden. 2.2.1 Daten In Pascal haben Variablen, Parameter von Prozeduren und Funktionen sowie die Funktionswerte einen festen vom Programmierer festzulegenden Typ. Diese Typen werden aus einer Menge skalarer Typen gewahlt (Aufzahlungen, Boolean, Char, Integer, Real) und konnen zu strukturierten Typen (Array, File, Pointer, Recond, Set) kombiniert werden. Die Implementation von Pascal erfolgt durch einen Compiler, der die Typinformationen verwendet, um Speicher zu allozieren (z.B. belegt ein Datum vom Typ Boolean in der Regel weniger Speicherplatz als eines vom Typ Real), Typwandlungen vorzunehmen (z.B. bei Zuweisung eines Integer-Ausdrucks an eine Realvariable), Operationen auszuwahlen (z.B. bei +: Integeraddition, Realaddition oder Mengenvereinigung) und Uberpr ufungen zur Ubersetzungszeit vorzunehmen (z.B. fuhrt ein Vergleich zwischen Daten der Typen Char und Integer bei der Ubersetzung zu einer Fehlermeldung). Eine Reihe von Einschrankungen der Typen moglicher Daten besagen, da Funktionen nur Daten skalarer Typen und Pointer als Funktionswert haben durfen (also in einem Maschinenwort unterzubringende Daten), wahrend Variablen und Parameter Daten aller Typen aufnehmen durfen. Auch konnen Konstante von strukurierten Typen (auer von Strings und Sets) nicht notiert werden. Die Programme in Scheme arbeiten auf Objekten. Objekte bestehen aus einem Typ und einem Datum. Diese Objekte konnen als Parameter an Prozeduren ubergeben werden, als Funktionswert von Prozeduren dienen und an Variablen gebunden werden. Die Tabelle 2.2 zeigt eine Liste von Objekttypen in Scheme, in der neben Objekten wie Zahlen auch Paare und Vektoren aufgefuhrt Boole'sche Konstante Zahl String Symbol Character leere Liste Paar Vektor Prozedur Tabelle 2.2: Objekte in Scheme. sind. Vektoren entsprechen den Feldern (Arrays) in Pascal: Sie beeinhalten Verweise auf eine beim Erzeugen des Vektors festgelegte Anzahl von Objekten, auf welche mit einem berechneten Index zugegrien werden kann. Paare sind Objekte, die Verweise auf zwei Objekte, den CAR und den CDR enthalten. Paare dienen zum Aufbau verketteter Datenstrukturen, von denen Listen die 2.2. VERGLEICH VON SCHEME MIT PASCAL 5 haugste Verwendung sind, bei denen der CAR auf ein Objekt in der Liste verweist und der CDR auf den Rest der Liste (ein weiteres Paar oder die leere Liste) zeigt. Konstanten aller in der Tabelle aufgefuhrten Objektypen konnen in Scheme notiert werden (Abbildung 2.1). #t #f 7 "String" xyz #\A () (a . b) (a b c) #(1 2 3) (lambda (a) (* a a)) ; ; ; ; ; ; ; ; ; ; Boole'sche Werte Zahl Zeichenkette Symbol Zeichen 'A' leere Liste Punktepaar Listenschreibweise fur (a . (b . (c . ()))) Vektor Prozedur fur Quadrierung Abbildung 2.1: Konstanten verschiedener Objekttypen in Scheme. 2.2.2 Prozeduren Pascal unterscheidet Prozeduren und Funktionen. Prozeduren sind Unterprogramme, die fur Seiteneekte aufgerufen werden. Funktionen konnen in Ausdrucken verwendet werden; sie liefern einen Funktionswert. Prozeduren und Funktionen konnen zwar als Prozedurparameter u bergeben werden. Sie konnen jedoch nicht an Variablen zugewiesen oder in Datenstrukturen aufgenommen werden. In Scheme sind Prozeduren nichts grundsatzlich anderes als Daten; Prozeduren zahlen, wie in Tabelle 2.2 gezeigt, zu den Objekten. Prozeduren sind Objekte, die als Operation den Aufruf erlauben. Alle Prozeduraufrufe liefern einen Funktionswert, der bei manchen Prozeduren, die wegen ihrer Seiteneekte aufgerufen werden, nicht deniert ist. Da Prozeduren Objekte sind, unterliegen sie, verglichen mit den anderen Objekten, keinerlei Einschrankungen: Prozeduren konnen wie alle Objekte als Parameter an Prozeduren u bergeben werden, als Funktionswert von Prozeduren dienen, an Variablen gebunden und in Datenstrukturen aufgenommen werden. Auch konnen, wie in Abbildung 2.1 gezeigt, Prozeduren in Scheme als Konstanten notiert werden, d.h. ohne einen Namen zu erhalten, z.B. als Parameter bei einem Funktionsaufruf dienen. Die Abbildung 2.2 zeigt eine Anwendung dieser Moglichkeit in einem Beipielprogramm, das die Identitatsfunktion als einzigen Parameter an eine Prozedur f u bergibt. In der Pascalversion mu nicht nur die Identatsfunktion benannt (mit id) werden, daruberhinaus sind auch Typen fur Parameter und Funktionswert zu spezizieren, wodurch diese Identitatsfunktion nur fur Fliekommazahlen nutzbar ist. Fur andere Typen mussen gesonderte Identitatsfunktionen programmiert werden. Die Identitatsfunktion in Scheme erlaubt beliebige Argumente und benotigt auch keinen Namen. 2.2.3 Gultigkeitsbereiche von Variablen (Scoping) Die dynamische Variablenbindung wurde in LISP-Dialekten seit 1960 bis zur Entwicklung von Scheme [SuSt75] ausschlielich verwendet. Erst Common LISP [Stee84] fuhrte | aufgrund der Erfahrungen mit Scheme | die statische Variablenbindung ein. 6 KAPITEL 2. PROCEDURE call f with id; FUNCTION id(r: real): real; BEGIN id := r END; BEGIN call f with id f(id) END; f DIE PROGRAMMIERSPRACHE SCHEME f Beispiel in Pascal g f Identitatsfunktion g g (define (call f with id) (f (lambda (r) r))) ; Beispiel in Scheme ; Identitatsfunktion: (lambda (r) r) Abbildung 2.2: Ubergabe der Identitatsfunktion in Pascal und Scheme. 2.2.3.1 Die dynamische Variablenbindung Bei der dynamischen Variablenbindung werden die Bindungen freier Variablen einer Prozedur bei den Aufrufern der Prozedur gesucht. Die Abbildung 2.3 zeigt ein Beispiel fur die traditionell (define (f x) (* x y)) (define (g y) (f 3)) (f 7) (g 2) )f )g ) )6 = = = Fehler: y nicht gebunden = Abbildung 2.3: Beispiel fur dynamische Variablenbindung. in Lisp verwendete dynamische Variablenbindung, die in Scheme nicht verwendet wird. Wie im Report [Rees86] steht nach "=)\ das Ergebnis der Auswertung eines Ausdrucks. Zuerst werden die Prozeduren f und g deniert. Die Prozedur f multipliziert ihren Parameter mit dem Ergebnis der Evaluation von y, und g ruft f mit dem Argument 3 auf. Wenn f mit einem beliebigen Argument aufgerufen wird, erfolgt eine Fehlermeldung, weil y nicht an einen Wert gebunden ist. Wenn hingegen g mit einem Argument aufgerufen wird, so wird das Argument an y gebunden. g ruft f auf, und f evaluiert y zu dem in g gebundenen Wert. Die dynamische Variablenbindung bewirkt, da die Bindungen der Aufrufer einer Prozedur nach der Bindung einer nichtlokal gebundenen Variablen durchsucht werden. 2.2.3.2 Die statische Variablenbindung In Scheme haben Variablen einen begrenzten Gultigkeitsbereich, der dem blockorientierter Programmiersprachen wie Algol, PL/1 und Pascal entspricht. Scheme weicht damit von traditionellen LISP-Dialekten ab. Bei statischer Variablenbindung ist eine Variable nur in einem statischen Bereich sichtbar. Mit statischem Bereich ist gemeint, da der Bereich aus dem Programmtext erkennbar ist, nicht von der Ausfuhrung, wie etwa der Aufruolge bei der dynamischen Variablenbindung, abhangt. Lambda-Ausdrucke konnen geschachtelt werden; nur innerhalb der Lambda-Ausdrucke sind die Parameter sichtbar. 2.2. VERGLEICH VON SCHEME MIT PASCAL 7 Der Aufruf der Prozedur g in Abbildung 2.3 wurde in Scheme genau wie der Aufruf von f mit der Fehlermeldung abbrechen, weil die Variable y in der Prozedur f nicht in der statischen Umgebung gefunden werden kann. Zusatzlich zu den Parametern der Lambda-Ausdrucke gibt es in Scheme eine globale Bindungsumgebung, in der die Bindungen an Variablen gesucht werden, wenn sie nicht lokal oder in einer statisch umschlieenden Umgebung gebunden sind. In diese globale Bindungsumgebung kann mit define eine Bindung geandert oder neu eingerichtet werden. 2.2.3.3 Closures Ein Lambda-Ausdruck ergibt bei der Auswertung ein Prozedurobjekt. Dieses Prozedurobjekt enthalt in Scheme die bei der Auswertung des Lambda-Ausdrucks bestehende Bindungsumgebung. Wenn die Prozedur aufgerufen wird, wird die im Prozedurobjekt gespeicherte Bindungsumgebung um die Bindungen der aktuellen Parameter an die formalen Parameter erweitert. Ein Prozedurobjekt, das die Bindungsumgebung bei seiner Entstehung speichert, wird Closure genannt. Als deutscher Begri wird, zumindest in [MaWi89], "Abschlu\ verwendet. Die Kombination statischer Variablenbindung mit Closures erlaubt die Verwendung von Prozeduren als Parameter und Funktionswerte von Prozeduren. Die Abbildung 2.4 zeigt eine Prozedur make-proc , die als Funktionswert eine Prozedur (eine Closure) liefert. Ein Aufruf der Proze(define (make-proc op) (lambda (a) (op a a))) (make-proc *) (define sqr (make-proc *)) (sqr 16) (define string-twice (make-proc string-append)) (string-twice "abc") (sqr 4) ) make-proc ) ) sqr ) 256 ) string-twice ) "abcabc" ) 16 = = Prozedurobjekt = = = = = Abbildung 2.4: Verwendungsmoglichkeit fur eine Closure. dur make-proc liefert ein Prozedurobjekt, eine Closure als Funktionswert. Es handelt sich bei dem Funktionswert um eine Prozedur, die ein Argument erwartet und es als beide Parameter beim Aufruf einer zweistelligen Funktion ubergibt. Die zweistellige Funktion ist das Argument von make-proc . Die Denition von sqr deniert eine Prozedur fur die Quadrierung von Zahlen, weil make-proc als Argument die Multiplikationsprozedur ubergeben wird. Die Prozedur string-twice bewirkt eine Verdopplung von Strings, weil string-append seine Argumente konkateniert. Die Aufrufe arbeiten deshalb wie beschrieben, weil das Prozedurobjekt eine Closure ist, die die jeweilige Bindung an op gespeichert hat (Abbildung 2.5). Die Modellierung von Prozedurparametern durch Closures ist nicht auf Scheme beschrankt. Jede Programmiersprache mit statischer Variablenbindung, die geschachtelte Prozeduren und Prozedurparameter unterstutzt, mu als Prozedurparameter eine Closure ubergeben. Eine solche Programmiersprache ist Pascal. Ein in Pascal arbeitender Programmierer wird wohl nie in die Lage kommen, in Begrien wie Closures sein Programm beschreiben zu mussen. Wenn in Pascal aber eine Prozedur als Parameter u bergeben wird, wird tatsachlich die Anfangsadresse des Codes der Prozedur und ein Verweis auf die statisch umgebende Bindungsumgebung (static link) u bergeben 8 KAPITEL 2. DIE PROGRAMMIERSPRACHE SCHEME Globale Bindungsumgebung sqr: make proc: ? 6 6 Closure Code ? Param: op (lambda (a) (op a a)) ? Closure Code Param: a ? ? Env op: * (op a a) Abbildung 2.5: Veranschaulichung der Closures. (vergl. S. 6-90 in [Lohs86]). Diese beiden Daten bilden eine Closure. Weil in Pascal Prozedurparameter (Closures) nicht an Variablen zugewiesen und nicht als Funktionswert zuruckgegeben werden konnen, kann weder die Closure noch die von ihr referenzierte Bindungsumgebung eine langere Lebensdauer als die sie einrichtende Prozedur haben. Die Moglichkeiten wie lokaler Zustand, die Closures in Scheme dem Programmierer bieten, sind in Pascal nicht moglich. Diese Einschrankungen ermoglichen, da in Pascal alle Bindungsumgebungen im Stack angelegt werden konnen. 2.2.4 Kontrollkonstrukte Die wichtigsten Kontrollstrukturen in Pascal sind Schleifenkonstrukte (while, repeat und for) und Bedingungen (if und case). Zudem konnen Prozeduren (auch rekursiv) aufgerufen werden und Sprunge (goto) lokal innerhalb einer Prozedur und in statisch ubergeordnete Prozeduren erfolgen. Scheme kennt als primitive Ausdrucke die bedingte Auswertung (if) und den Prozeduraufruf als Kontrollstrukturen. Unter den abgeleiteten Ausdrucken sind cond, case und do Kontrollstrukturen, die in Kombinationen der primitiven Ausdrucke if und Prozeduraufruf ubersetzt werden. Iterationen konnen durch endrekursive (tail recursive) Prozeduraufrufe modelliert werden, da festgelegt ist, da endrekursive Aufrufe bei konstantem Speicherbedarf zu implementieren sind2 . Eine weitere machtige Kontrollstruktur wird durch die Standardprozedur call-with-currentcontinuation bereitgestellt, die die Programmfortsetzung (Continuation) als Prozedur (escape 2 Die Optimierung der Endrekursion ist nur bei statischer Variablenbindung m oglich, da bei dynamischer Variablenbindung die Bindungen des Aufrufers erhalten bleiben mussen. 2.2. VERGLEICH VON SCHEME MIT PASCAL 9 procedure) zuganglich macht. Call-with-current-continuation erwartet eine Prozedur mit einem Parameter als Argument. Wenn call-with-current-continuation aufgerufen wird, bindet es die Fortsetzung des gesamten Programms als einstellige Prozedur an diesen Parameter und ruft seinen Prozedurparameter anschlieend auf. Die Fortsetzung des Programms ist ein Prozedurobjekt ohne jegliche Beschrankungen; es kann wie alle Objekte als Parameter an Prozeduren u bergeben werden, als Funktionswert von Prozeduren dienen, an Variablen gebunden und in Datenstrukturen aufgenommen werden. Insbesondere ist die Lebensdauer der Continuation unbegrenzt. Sie kann mehrfach aufgerufen und auch noch nach der Ruckkehr von call-with-current-con(define (div-list l1 l2) (call-with-current-continuation (lambda (exit) (define (div a1 a2) (if (null? a1) '() (if (zero? (car a2)) (exit "Fehler: Division durch 0") (cons (/ (car a1) (car a2)) (div (cdr a1) (cdr a2)))))) (div l1 l2)))) = div-list (div-list '(4 6 8) '(1 2 4)) = (4 3 2) (div-list '(4 6 8) '(1 0 4)) = "Fehler: Division durch 0" ) ) ) Abbildung 2.6: Beispiel fur call-with-current-continuation. tinuation aufgerufen werden. Continuations bieten u ber die Modellierung Pascals nicht-lokaler gotos hinaus die Moglichkeiten zum Programmieren von Koroutinen [Hayn84, Hayn86] und Back- tracking. Die Fortsetzung ist eine Prozedur mit einem Parameter, welcher den Funktionswert von call-with-current-continuation bildet. Call-with-current-continuation kann damit nach einem einzigen Aufruf beliebig haug und mit unterschiedlichen Funktionswerten zuruckkehren. Im Beispielprogramm in Abbildung 2.6 wird call-with-current-continuation als Fehlerausgang eingesetzt. Die Prozedur div-list erwartet zwei Listen als Parameter und liefert eine Liste mit den Quotienten der Elemente der Parameter. Eine Division durch null wird vermieden, und fuhrt zum Aufruf der Continuation mit Ruckgabe eines Strings mit einer Fehlermeldung. Ein Beispiel, das die unbegrenzte Lebensdauer einer Continuation demonstriert, zeigt Abbildung 2.7. Die globale Variable g wird deniert, damit sie bei der Ausfuhrung von f zur Verfugung steht. Die Prozedur f hat eine lokale Variable counter, die am Anfang auf null initialisiert wird, anschlieend wird der Funktionswert des Aufrufs call-with-current-continuation mit drei multipliziert ausgegeben, eine neue Ausgabezeile begonnen, die Variable counter um eins erhoht und als Funktionswert zuruckgegeben. Nach diesem ersten Aufruf ist der Funktionswert von callwith-current-continuation 1 und damit der verdreifachte Wert 3. Der Funktionswert von f ist 1, da counter auf 1 gesetzt wurde. Gleichzeitig wurde die Continuation an die globale Variable g gebunden. Nach dem ersten Aufruf der Continuation ist der Funktionswert von call-withcurrent-continuation 7 und damit der verdreifachte Wert 21. Der Funktionswert von f ist 2, da counter auf 2 erhoht wurde. Der zweite Aufruf von g zeigt, da die Continuation beliebig oft aufgerufen werden kann. 10 KAPITEL 2. DIE PROGRAMMIERSPRACHE SCHEME ) (define g '()) = g (define (f) (let ((counter 0)) (write (* 3 (call-with-current-continuation (lambda (conti) (set! g conti) 1))) (newline) (set! counter (+ counter 1)) counter)) = f (f) = 1 ; Ausgabe: 3 (g 7) = 2 ; Ausgabe: 21 (g -2) = 3 ; Ausgabe: -6 ) ) ) ) Abbildung 2.7: Beispiel fur die unbegrenzte Lebensdauer einer Continuation. Kapitel 3 Die Implementierung von Scheme Hier sollen die Probleme und Losungsmoglichkeiten bei der Implementierung von Scheme beschrieben werden. Unter Implementierung wird hier immer die allgemeine Aufgabe der Modellierung einer Scheme-Umgebung auf einem realen Rechner verstanden. Ein konkretes Programm oder eine Hardware, die das leistet, wird hier als Implementation bezeichnet. Beschrieben werden Reprasentationsmoglichkeiten der Objekte. Objekte sind sowohl die extern reprasentierbaren Daten als auch interne Strukturen wie Bindungsumgebungen, Closures, Controlframes und Continuations, die bei der Abarbeitung von Scheme-Ausdrucken entstehen. In der Unterstutzung einer speicherplatz- und rechenzeitezienten Reprasentation der Objekte unterscheidet sich der hier zu beschreibende Scheme-Prozessor grundlegend von seinen Vorgangern. Objekte haben eine unbegrenzte Lebensdauer. Objekte mussen grundsatzlich in einem Heap alloziert werden. Der Implementierung fallt die Aufgabe zu, nicht mehr referenzierte Objekte zu identizieren und deren Speicher wiederzuverwenden. 3.1 Reprasention der Objekte Objekte werden in Scheme an Bezeichner gebunden und als Funktionswert von Prozeduren zuruckgeliefert. Da diese Objekte sehr haug umfangreiche Datenstrukturen sind, werden die Objekte tatsachlich nur einmal im Speicher reprasentiert. Bestimmte Standardprozeduren konnen Objekte erzeugen. Bei der Ubergabe von Parametern und der Ruckgabe von Funktionswerten werden keine Objekte kopiert oder erzeugt, sondern Zeiger verwendet. Als Beispiel dient das Programm in Abbildung 3.1. In diesem Programm wird eine Liste an die globale Variable a gebunden. Beim Einlesen dieser (define a '(1 2 3)) (define b a) (define c (cdr a)) Abbildung 3.1: Beispielprogramm fur die Objektreprasentation. Liste, der Transformation von der externen in die interne Darstellung durch die Standardprozedur read, wird diese Liste im Speicher abgelegt. Die Abbildung 3.2 zeigt die globale Bindungsumgebung und das genau einmal reprasentierte Objekt. An die globale Variable b wird ein weiterer Verweis an das nur einmal reprasentierte Objekt gebunden. Die Bindung an c zeigt, da auch 12 KAPITEL 3. DIE IMPLEMENTIERUNG VON SCHEME Globale Bindungsumgebung c: b: a: ?? 1 - ?2 - 3 () Abbildung 3.2: Veranschaulichung der Zeiger auf Objekte. Standardprozeduren (wie cdr) einen Zeiger zuruckliefern; kein Objekt wird kopiert. Wegen der Verwendung dieser Zeiger ist es auch nicht ganz korrekt, die Parameterubergabe in Scheme als Werteparameterubergabe zu bezeichnen. Zwar werden Ausdrucke erst ausgewertet und dann das Ergebnis an Parameter gebunden, jedoch werden Zeiger auf die Ergebnisse u bergeben. So ist die Parameterubergabe von Vektoren in Scheme eine Variablenparameterubergabe. An Bezeichner konnen in Scheme Objekte beliebiger Typen gebunden werden. An Prozeduren konnen Objekte beliebiger Typen u bergeben und auch von diesen zuruckgegeben werden. Standardprozeduren sind nur fur Objekte bestimmter Typen deniert. Beispielsweise ist die Prozedur * fur die Multiplikation nur fur numerische Objekte als Argumente deniert. Zur Laufzeit mussen Standardprozeduren die Typen ihrer Argumente u berprufen und eventuell einen Fehler melden. Objekte mussen einschlielich ihrer Typen bei der Implementierung reprasentiert werden. Bei der Implementierung von LISP-Dialekten ist die Entscheidung zu fallen, wie die Typen der Objekte reprasentiert werden konnen: Da Zeiger auf die Objekte verwendet werden, kann einerseits der Typ im Objekt kodiert sein (tagged objects), andererseits konnen die Zeiger eine Kennzeichnung erhalten, auf Objekte welchen Typs sie zeigen (tagged pointers). Die Kennzeichnung der Zeiger ist selbst dann moglich, wenn neben der Adresse kein weiterer Platz fur einen Typ reserviert wird: Dann wird der Hauptspeicher in Seiten eingeteilt, und in jeder Seite werden nur Objekte eines bestimmten Typs untergebracht (BIBOP1 -Verfahren); der Typ ist dann Teil der Adresse. Bei durch Typen gekennzeichneten Zeigern kann der Typ auch angeben, da anstelle des Zeigers schon das Datum steht. Insbesondere Integerzahlen, Boole'sche Werte und Zeichen (Chars) werden auf diese Weise platzsparend und ezient reprasentiert. Die Abbildung 3.3 zeigt die Typreprasentation im Zeiger, wahrend Abbildung 3.4 die Typreprasentation im Objekt demonstriert. Die Typreprasentation im Zeiger weist einen geringeren Speicherbedarf auf, weil fur die Zahlenkonstante und die leere Liste kein Zeiger auf ein Objekt gespeichert werden mu, sondern die Zahl selber und bei der leeren Liste auer dem Typ kein weiteres Datum zu reprasentieren ist. Ein weiterer Vorteil der Typreprasentation im Zeiger ist bei den relativ haugen Typprufungen (null?, pair?, symbol?, : : : ) gegeben: Es wird ein Speicherzugri gespart, weil der Typ schon zusammen mit dem Zeiger zur Verfugung steht, wahrend bei der Typreprasentation im Objekt erst noch u ber den Zeiger der Typ einzulesen ist. Eine weitere Anforderung an Reprasentationen der Objekte stammt von der Speicherverwaltung. Alle verbreiteten Algorithmen zur Speicherverwaltung in LISP-Dialekten mussen Referenzen auf noch benotigte Objekte folgen. Sie mussen dazu Informationen vornden, um Zeiger von Daten wie Zahlen, Zeichen und Maschinencodebefehlen unterscheiden zu konnen. Zeigern wird gefolgt, 1 BIg Bag Of Pages. Ein Extremfall dieses Verfahrens ist je ein Speicherbereich pro Objekttyp. 3.1. 13 DER OBJEKTE REPRASENTION Pair ? Fixnum 6 1 Wort - () CONS-Zelle - Abbildung 3.3: Das Paar (6 . ()) bei Typreprasentation im Zeiger. ? Pair ? Fixnum 6 ? () Abbildung 3.4: Das Paar (6 . ()) bei Typreprasentation im Objekt. 14 KAPITEL 3. DIE IMPLEMENTIERUNG VON SCHEME wahrend die anderen Daten nicht als Zeiger interpretiert werden durfen. 3.1.1 Reprasentation von Daten Daten werden im Report [Rees86] die extern reprasentierbaren Objekte genannt. Daten konnen vom Programmierer notiert werden. Auch Programme gehoren zu den Daten. 3.1.1.1 Symbole Symbole sind in traditionellen LISP-Dialekten als Zeiger auf Propertylisten implementiert und zu einer Liste, der oblist, zusammengefat. Die Zusammenfassung in der oblist dient dazu, da alle Symbole (insbesondere fur die Garbage Collection und den Reader) erreichbar sind. Die Auswertung von Ausdrucken ist in den traditionellen LISP-Dialekten mit Inspektionen der Propertylisten verbunden. In Scheme wird bei der Auswertung keine Propertyliste benotigt. Propertylisten sind in Scheme nicht einmal vorgesehen, obwohl einige Implementationen sie als Erweiterung bereitstellen. Eine oblist wird in Scheme auch nicht gefordert. In Scheme ist die einzige Operation auf Symbolen der Vergleich. Auch wenn Symbole als Bezeichner in Bindungsumgebungen Verwendung nden, bleibt der Vergleich beim Suchen nach einem Bezeichner die einzige Operation2 . Beim Einlesen und Ausgeben wird zwischen der externen Darstellung der Symbole und der internen gewandelt. Die interne braucht nur den Vergleich zuzulassen, wodurch eziente Reprasentationen Zahlen oder Zeiger (z. B. auf die Lokation einer globalen Bindung) sind. Die Speicherverwaltung einer Implementation kann nicht mehr verwendete Symbole ermitteln und den durch sie belegten Speicher freigeben. Viele LISP-Implementationen verzichten auf das Ermitteln von durch nicht mehr benotigte Symbole belegten Speichers. 3.1.1.2 Zahlen Scheme kennt ganze Zahlen, rationale Zahlen, reelle Zahlen und komplexe Zahlen. Neben dem Typ und dem Wert der Zahlen ist als Attribut die Exaktheit zu reprasentieren und beim Einlesen und bei Operationen zu berucksichtigen. Fur die Reprasentation der Objekte bei der Implementierung der Sprache ist weniger diese Hierarchie der Zahlenmengen von Interesse als die Unterscheidung nach der Groe des fur die Darstellung der Zahlen benotigten Speichers. Bei den ganzen Zahlen wird zwischen solchen, die in einem fur den Anteil des Datums in einem Speicherwort zur Verfugung stehenden Bereichs Platz nden (FIXNUMs) und solchen, die sich uber mehrere Speicherworte erstrecken (BIGNUMs), unterschieden. Reelle Zahlen werden als Fliekommazahlen (FLONUMs) dargestellt. ur BIGNUMs und FIXNUMs werden, wie in Abbildung 3.3 gezeigt, in einem Wort untergebracht. F FLONUMs wird Speicher alloziert und ein Zeiger auf die Zahl verwendet (boxed numbers). Dieses Verfahren bewirkt, da der Zugri langsamer erfolgt, weil zusatzliche Speicherzugrie u ber einen Zeiger erfolgen mussen, und da Speicher verbraucht wird, wodurch zusatzlicher Aufwand durch die Speicherverwaltung entsteht. Implementationen versuchen daher, Zahlen moglichst direkt und nicht uber Zeiger reprasentieren zu konnen: So verwendet beispielsweise die Lispmaschine Symbolics 3600 Worte von 34-Bit Breite, um zusammen mit einem 2-Bit Typfeld noch 32-Bit ganze und Fliekommazahlen in einem Wort reprasentieren zu konnen [Moon85]. Bei der Verwendung von Zeigern auf Zahlen, ist zu berucksichtigen, da neben den Zahlen noch die Information fur die 2 Tats achlich braucht eine Implementation zur Laufzeit in Scheme nicht nach einer Bindung zu suchen: Ein Compiler kann wie in herkommlichen Sprachen mit statischer Variablenbindung die Positionen innerhalb der Bindungsumgebungen ermitteln und braucht die Bezeicher zur Laufzeit nicht zu reprasentieren. 3.1. 15 DER OBJEKTE REPRASENTION Speicherverwaltung abzulegen ist, da es sich nicht um Zeiger handelt. In der Abbildung 3.5 wird das durch Aufteilung in Worte des Typs FIXNUM erreicht. Bei BIGNUMs ist auch noch die Lange der Zahl im Speicher abzulegen. Flonum ? Fixnum FP-Zahl Fixnum FP-Zahl Teil 1 Teil 2 Abbildung 3.5: Uber Zeiger zu referenzierende Fliekommazahl (boxed FLONUM). 3.1.1.3 Zeichen (Chars) Zeichen unterscheiden sich nur im Typ von FIXNUMs. Der Report [Rees86] erlaubt sogar eine Identitat von Zeichen mit Zahlen. Beim Einlesen durfen Zeichen in Zahlen gewandelt werden und sind dann durch Scheme-Programme nicht mehr von Zahlen zu unterscheiden. 3.1.1.4 Zeichenketten (Strings) Zeichenketten konnen als Listen von Zeichen dargestellt werden oder als Lange gefolgt von einzelnen Zeichen im Speicher stehen. Die Wahl der Reprasentation hangt von den Fahigkeiten der Speicherverwaltung, namlich inwieweit Speicherbereiche unterschiedlicher Lange verwaltet werden konnen, ab. Die in Abbildung 3.6 dargestellte Reprasentation speichert jeweils drei Zeichen des Strings in einem Wort, das durch den Typ FIXNUM vor Veranderungen bei der Speicherverwaltung geschutzt wird. String ? Fixnum Lange 6 Fixnum 'Str' - Fixnum 'ing' Zeichen des Strings - Abbildung 3.6: Reprasentation eines Strings als kontinuierlicher Speicherbereich. 16 KAPITEL 3. DIE IMPLEMENTIERUNG VON SCHEME 3.1.1.5 Die leere Liste Die leere Liste ist durch ihren Typ bestimmt. Dieses Objekt wurde in Abbildung 3.3 gezeigt. Die Reprasentation durch einen eigenen Typ anstelle eines Paares mit einer fur die leere Liste reservierten Adresse berucksichtigt, da sich die leere Liste und Paare bezuglich der Pradikate pair? und null? unterscheiden. 3.1.1.6 Paare und Listen Paare und die aus ihnen konstruierten Listen werden in LISP-Dialekten praktisch immer als CONSZellen reprasentiert: Eine CONS-Zelle wird aus zwei direkt im Speicher aufeinander folgenden Maschinenworten3 gebildet, dem CAR und dem CDR der in Abbildung 3.7 gezeigten CONS-Zelle. Eine Liste (1 2 3) wird durch CONS-Zellen, wie in Abbildung 3.8 gezeigt, reprasentiert. CAR CDR Abbildung 3.7: Aufbau einer CONS-Zelle. 1 - 2 - 3 NIL Abbildung 3.8: Reprasentation der Liste (1 2 3) mit CONS-Zellen. Auallig ist, da bei durch CONS-Zellen dargestellten Listen die uberwiegende Anzahl der CDR der CONS-Zellen einen Zeiger auf eine weitere CONS-Zelle oder die leere Liste enthalt. Da in LISP und Scheme fast alle Datenstrukturen Listen sind, kann durch Berucksichtigung dieser Eigenschaft eine Kompression der Listen bis auf halbierten Speicherbedarf erzielt werden: Bei der CDR-Kodierung [Hans69] werden nicht mehr CONS-Zellen aus zwei Maschinenwortern verwaltet, sondern einzelne Maschinenworter, die CAR-Felder reprasentieren und um einen 2 Bit breiten CDR-Code erweitert sind. Der CDR-Code kann die in Tabelle 3.1 gezeigten Werte annehmen. Normal Next Nil Indirekt Das folgende Speicherwort enthalt den CDR. Dieser Fall ist identisch zu CONSZellen. Der CDR ist eine Liste, dessen erstes Element an der nachsten Adresse liegt. Ein Zeiger auf den CDR wird daher nicht mehr reprasentiert. Letztes Element der Liste, der CDR ist die leere Liste. Zeiger auf Zelle mit CDR-Code Normal, in der CAR und CDR stehen. Diese Verweise entstehen nur, wenn mit der destruktiven Operation set-cdr! bei CDR-Code Next oder Nil gearbeitet wird. Tabelle 3.1: CDR-Codes. Die Liste (1 2 3) wird mit CDR-Kodierung, wie in Abbildung 3.9 gezeigt, reprasentiert. 3 Hier wird von modernen Architekturen mit groem Adreraum ausgegangen. Viele LISPs wurden urspr unglich auf dem DECsystem10 implementiert. Dort ist ein Maschinenwort 36 Bit breit, und Adressen sind 18 Bit breit, so da eine CONS-Zelle ein Maschinenwort belegt [Gabr85]. Auch eine Implementation von MacLISP auf einem TR440 allozierte CONS-Zellen in nur einem 48-Bit Wort als zwei Zeiger von jeweils 24-Bit [Laub76]. 3.1. 17 DER OBJEKTE REPRASENTION NXT 1 NXT 2 NIL 3 Abbildung 3.9: Reprasentation der Liste (1 2 3) in CDR-Kodierung. In diesem Beipiel hat sich der Speicherbedarf fur die Liste durch die CDR-Kodierung von 6 Speicherwortern auf 3 Speicherworter halbiert. Der Preis fur die CDR-Kodierung ist, da bei jeder der Listenoperationen car und cdr immer anhand des CDR-Codes verzweigt werden mu: Bei car mu Indirekt anders behandelt werden, bei cdr mussen sogar alle vier Falle unterschieden werden. Wegen der damit verbundenen zusatzlichen Abfragen und Verzweigungen wird die CDR-Kodierung nur in Hardwareimplementationen eingesetzt. 3.1.1.7 Vektoren Vektoren in Scheme sind die aus anderen Programmiersprachen bekannten Felder. Ein zur Laufzeit errechneter Index wahlt ein Element aus. Auch in Scheme konnen Vektoren als Block von im Speicher aufeinander folgenden Elementen reprasentiert werden. Zusatzlich mu auch die Lange des Vektors fur die Standardprozedur vector-length und die Speicherverwaltung reprasentiert sein. Die Abbildung 3.10 zeigt die Darstellung eines Vektors als kontinuierlicher Speicherbereich. Vector ? Fixnum Lange 3 Fixnum - 1 Fixnum 2 Fixnum Elemente des Vektors 3 - Abbildung 3.10: Reprasentation des Vektors #(1 2 3). 3.1.2 Interne Objekte Unter internen Objekten sind jene Objekte zu verstehen, die bei der Abarbeitung von SchemeProgrammen entstehen. Zu diesen Objekten gehoren neben Interndarstellungen von Programmen insbesondere Closures, Bindungsumgebungen und Controlframes. 3.1.2.1 Closures Die Reprasentation einer Closure entspricht der einer CONS-Zelle, da auch eine Closure ein Objekt ist, das auf genau zwei weitere Objekte | die interne Reprasentation ihrer Prozedur und die beim Erzeugen der Closure aktuelle Bindungsumgebung | verweist (vergl. Abbildung 2.5 auf Seite 8). 18 KAPITEL 3. DIE IMPLEMENTIERUNG VON SCHEME 3.1.2.2 Bindungsumgebungen (Environments) Bindungsumgebungen werden beim Aufruf einer Prozedur eingerichtet. Die Ergebnisse der Auswertung der aktuellen Parameter werden an die formalen Parameter aus dem -Ausdruck der aufgerufenen Prozedur gebunden und bilden zusammen mit einem Zeiger auf die statisch ubergeordnete Bindungsumgebung eine Bindungsumgebung. Ein Beispielprogramm fur einen Prozeduraufruf steht in Abbildung 3.11. Eine Prozedur f mit den beiden formalen Parametern a und b wird deniert und anschlieend mit den aktuellen Parametern 1 und 2 aufgerufen. Die Abbildung 3.12 (define f (lambda (a b) (cons a b))) (f 1 2) Abbildung 3.11: Beispielprogramm fur einen Prozeduraufruf. zeigt die Bindungsumgebung nach Aufruf der Prozedur f: Die aktuellen Parameter, in diesem Fall die Zahlen 1 und 2, sind an die formalen Parameter a und b gebunden, und die Bindungsumgebung enthalt einen Verweis auf die statisch u bergeordnete Bindungsumgebung, in diesem Fall die globale Bindungsumgebung. Bei der Evaluierung der Symbole werden die Bindungen entlang Globale Bindungsumgebung f: ? 6 6 Closure Code ? Param: a, b (cons a b) - a: 1 Env b: 2 Abbildung 3.12: Die Bindungsumgebung von f nach dem Funktionsaufruf. der verketteten Bindungsumgebungen gesucht. Die Bindungen von a und b werden in der rechts unten in der Abbildung gezeigten Bindungsumgebung gefunden. Die Bindung von cons wird in der ubergeordneten Bindungsumgebung, der globalen Bindungsumgebung gefunden. Da Scheme eine Sprache mit statischer Variablenbindung ist, in der die lokalen Variablen nur in einem aus dem Programmtext ermittelbaren Bereich sichtbar sind, brauchen die Bindungen der Variablen zur Laufzeit nicht wirklich gesucht zu werden. In diesem Beispiel heit das: Die Variablen a und b sind nur innerhalb der Prozedur f sichtbar. Bei der Ausfuhrung der Prozedur mu nur gepruft werden, da exakt zwei Parameter u bergeben wurden. Die Zugrie auf die Bindungen der Parameter konnen unabhangig von deren Namen erfolgen. Der Ausdruck 19 DER OBJEKTE REPRASENTION 3.1. (cons a b) im -Ausdruck kann durch (cons [Arg 1] [Arg 2]) ersetzt werden, so da auf einen Parameter mit einer bestimmten Nummer zugegrien wird, ohne da dessen Name zu reprasentieren ist. Im allgemeinen Fall ist diese Nummer ein Paar, bestehend aus der Nummer der Variablen und der Schachtelungstiefe der Bindungsumgebung. Wenn die Bindung an cons an dritter Stelle in der globalen Bindungsumgebung steht, kann der Ausdruck weiter zu ([Arg 3,1] [Arg 1,0] [Arg 2,0]) vereinfacht werden. In diesem resultierenden Ausdruck sind keine Variablennamen mehr enthalten. Es wird lediglich auf Positionen von Lokationen innerhalb der Bindungsumgebungen zugegrien. Auf die Bindungsumgebung der Prozedur f kann nur innerhalb der Prozedur zugegrien werden. Mit dem Verlassen der Prozedur bleibt kein Zeiger auf die Bindungsumgebung zuruck. Der durch die Bindungsumgebung belegte Speicher wird von der Speicherverwaltung zu einem spateren Zeitpunkt als nicht mehr belegt identiziert und einer erneuten Verwendung zugefuhrt. Der zusatzliche Aufwand durch Funktionsaufrufe fur die Speicherverwaltung kann entfallen, wenn die Bindungsumgebungen fur Prozeduren wie f, deren Bindungsumgebung nach Ende des Prozeduraufrufs nicht mehr zugreifbar ist, auf einem Stack angelegt werden. Bei der Denition einer Prozedur kann ermittelt werden, ob die Bindungsumgebung der Prozedur nach Ruckkehr von der Prozedur noch zugreifbar bleiben mu [BaJe86, McDe80, Stee78]. Ein Allozieren von Bindungsumgebungen auf einem Stack verringert den Rechenzeitaufwand fur die Speicherverwaltung. Nicht alle Bindungsumgebungen konnen auf dem Stack alloziert werden: Die Bindungsumgebung der Prozedur make proc in Abbildung 2.4 auf Seite 7 bleibt, wie in Abbildung 2.5 gezeigt, nach Ruckkehr von der Prozedur zugreifbar. globale Bindungsumgebung Closure Cons 6 f - Env Bindung von cons Fixnum 1 Bindung von A Fixnum 2 Bindung von B Abbildung 3.13: Reprasentation der Bindungsumgebung von f durch Vektoren. Die vorausgegangenen Absatze haben Moglichkeiten aufgezeigt, inwieweit Zugrie auf die Bindungen ezient gestaltet werden konnen und da die Speicherverwaltung von den Bindungsumgebungen der Mehrzahl der Prozeduren entlastet werden kann. Die Reprasentation der Bindungsumgebungen bleibt noch zu zeigen: Die zu wahlende Reprasentation ist von den Moglichkeiten der Speicherverwaltung abhangig. Wenn die Speicherverwaltung Blocke unterschiedlicher Lange 20 KAPITEL 3. DIE IMPLEMENTIERUNG VON SCHEME bereitstellen kann, konnen Bindungsumgebungen als Vektoren der Bindungen reprasentiert werden (Abbildung 3.13). Die Bindungen konnen damit durch indizierten Zugri gelesen und zugewiesen werden. Implementationen mit Speicherverwaltungen, die nur Blocke fester Lange (namlich CONS-Zellen) bereitstellen konnen, mussen Bindungsumgebungen durch Listen reprasentieren (Abbildung 3.14). Der Zugri auf die Bindungen erfolgt dann durch Schachtelungen der Prozeduren car und cdr, wobei rechenzeitintensiv den verketteten CONS-Zellen gefolgt wird. globale Bindungsumgebung f - 6 Env - Pair - Pair Clo- Cons Pair sure - Bindung von cons Pair - Fixnum 1 Pair - Bindung von A Fixnum 2 () Bindung von B Abbildung 3.14: Reprasentation der Bindungsumgebung von f durch Listen. Wenn man ein Register env annimmt, das einen Zeiger auf die Bindungsumgebung enthalt, kann der Ausdruck (cons a b) bei Reprasentation der Bindungsumgebungen durch Listen durch ((caddar env) (cadr env) (caddr env)) ersetzt werden. Bei Reprasentationen der Bindungsumgebungen durch Vektoren wird der Ausdruck durch ((vector-ref (vector-ref env 0) 2) (vector-ref env 1) (vector-ref env 2)) ersetzt. Die Reprasentation als Vektor benotigt nicht nur weniger Speicherplatz, sie ist auch ezienter im Zugri: Die Anzahl der Speicherzugrie ist bei vector-ref konstant, wahrend sie bei c...r proportional zur Schachtelungstiefe ist. 3.1.2.3 Controlframes Bei der Abarbeitung eines Programms in Scheme rufen Prozeduren sich selbst oder andere Prozeduren auf. Dabei sind zwei Falle zu unterschieden: Ein Prozeduraufruf als letzte Aktion in der Abarbeitung einer Prozedur und ein Prozeduraufruf, an den anschlieend die aufrufende Prozedur fortzusetzen ist. Im folgenden Programm wird iteriere immer endrekursiv, und +, * und > werden nicht endrekursiv aufgerufen: (define (fakultaet n) (define (iteriere produkt zaehler) (if (> zaehler n) produkt (iteriere (* zaehler produkt) (+ zaehler 1)))) (iteriere 1 1)) Bei nicht endrekursiven Aufrufen mu der Zustand bei der Ausfuhrung der aufrufenden Prozedur gesichert und nach der Ruckkehr von der aufgerufenen Prozedur wiederhergestellt werden. Dieser Zustand wird in Controlframes abgelegt. Der Zustand besteht aus Registern, wie einem Zeiger auf den noch abzuarbeitenden Rest der aufrufenden Prozedur (Programmzahler bei Maschinencode) 3.1. DER OBJEKTE REPRASENTION 21 und den Zeiger auf die Bindungsumgebung der aufrufenden Prozedur. Auch Zwischenergebnisse werden im Controlframe gespeichert. Im obigen Beispiel werden vor dem Aufruf von * die Prozeduren + und - aufgerufen. Die Reihenfolge dieser beiden Aufrufe ist nicht speziziert. Jedoch ist beim zweiten Aufruf das Ergebnis des ersten schon vorhanden, und dieses Ergebnis wird als Zwischenergebnis im Controlframe gespeichert. Die Reprasentation der Controlframes kann, abhangig von den Moglichkeiten der Speicherverwaltung, als Vektoren oder Listen erfolgen. Der Zugri auf die Daten in den Controlframes erfordert bei Vektoren weniger Speicherzugrie, und Vektoren belegen weniger Speicherplatz. Controlframes konnen, wie bei nahezu allen anderen Programmiersprachen, auf einem Stack angelegt werden, wenn der Ablauf eines Scheme-Programms ausschlielich aus Prozeduraufrufen besteht. Die Verwendung des Stacks entlastet, wie bei den Bindungsumgebungen beschrieben, die Speicherverwaltung. ) (define g '()) = g (define (f counter) (write (* 3 (call-with-current-continuation (lambda (conti) (set! g conti) 1))) (newline) (set! counter (+ counter 1)) counter) = f (f 0) = 1 ; Ausgabe: 3 (g 7) = 2 ; Ausgabe: 21 (g -2) = 3 ; Ausgabe: -6 ) ) ) ) Abbildung 3.15: Beispiel fur die unbegrenzte Lebensdauer einer Continuation. Die Standardprozedur call-with-current-continuation kann unter Ruckgi auf die Controlframes implementiert werden: Call-with-current-continuation ruft seinen Parameter, eine einstellige Closure, auf. Bei diesem Aufruf wird, wie bei jedem nicht endrekursiven Aufruf, ein Controlframe angelegt, in den der Zustand fur die Fortsetzung der Ausfuhrung des Ausrufers nach call-with-current-continuation eingetragen wird. An die einstellige Closure, den Parameter von call-with-current-continuation, soll eine Continuation ubergeben werden, die die Fortsetzung der Programmausfuhrung nach call-with-current-continuation ermoglicht. Diese Continuation wird durch den Controlframe reprasentiert, in den zuvor der Zustand fur diese Fortsetzung eingetragen wurde. Der Aufruf der Continuation wird durch Restaurieren des Zustandes aus diesem zuvor gesicherten Controlframe erreicht. Die Abbildung 3.16 zeigt die Ausfuhrung des Beispielprogramms nach Ausfuhren von (set! g conti). Die Abbildung zeigt, da die Continuation als Zeiger auf einen Controlframe implementiert wird. In diesem Beispiel wird die Continuation an eine globale Variable gebunden, und die Continuation wird mehrfach aufgerufen. Daher konnen die zu einer Continuation gehorenden Controlframes nicht im Stack alloziert werden; sie sind in Scheme ein Objekt mit unbegrenzter Lebensdauer. Im Gegensatz zu Bindungsumgebungen kann aus dem Programmtext nicht ermittelt werden, welche Controlframes im Heap zu allozieren sind. Das Anlegen aller Controlframes im Heap verlangsamt die Programmausfuhrung durch Belastung der Speicherverwaltung. Das grundsatzliche Anlegen von Controlframes in einem Stack und Kopieren aller Controlframes in den Heap, sobald 22 KAPITEL 3. DIE IMPLEMENTIERUNG VON SCHEME Globale Bindungsumgebung g: f: ? 6 6 Closure Code ? Param: counter ? Env counter: 0 ? (write (* 3 (call/cc ) ) ) (newline) (set! counter (+ counter 1)) counter ? Closure Code ? Param: conti 6 6 Env conti: (set! g conti) 1 Abbildung 3.16: Implementierung einer Continuation. ? Controlframe Env PC temp: 3 3.1. DER OBJEKTE REPRASENTION 23 call-with-current-continuation aufgerufen wird, erlaubt den ezienten Ablauf von Program- men, die keine Continuations verwenden. Eine Vielzahl verschiedener Stategien zur ezienten Allozierung von Controlframes werden von Clinger et al. [Clin88] beschrieben. 3.1.2.4 Interne Darstellung von Programmen Unter Programmen sind im folgenden die Ausdrucke innerhalb eines -Ausdrucks zu verstehen. Scheme ist eine interaktive Sprache, in der der Programmierer Ausdrucke eingibt, die sofort ausgewertet werden und Denitionen eingibt, die die globale Bindungsumgebung erweitern und insbesondere Prozeduren denieren. In Scheme werden diese Prozedurdenitionen als Einheiten wie Programme in anderen Programmiersprachen behandelt, das heit, sie werden zum Beispiel in Maschinencode u bersetzt. Die Auswertung eines -Ausdrucks ergibt eine Closure. Neben der schon beschriebenen Bindungsumgebung enthalt die Closure auch einen Verweis auf beim Aufruf der Closure auszuwertende Ausdrucke. Die Darstellung der Ausdrucke eines -Ausdrucks ist eine wichtige Entscheidung bei der Implementierung von Scheme. Moglich ist eine groe Zahl von Varianten von der Ubernahme der Quelldarstellung bis hin zur Ubersetzung in realen Maschinencode. Die Ubernahme der Quelldarstellung als interne Reprasentation fur Programme wird bei interpretierenden Implementationen gewahlt. Eine solche Implementation ist insbesondere dann sehr einfach zu erstellen, wenn sie in einem LISP-Dialekt erfolgt. In diesem Fall stehen Standardfunktionen, Daten und die Speicherverwaltung schon zur Verfugung. Es bleiben nur Bindungsumgebungen und Controlframes durch vorhandene Datenstrukturen zu reprasentieren und ein Interpreter zu erstellen. Diese Implementationen fur (groe Teile von) Scheme sind von so geringem Umfang, da sie in diversen Veroentlichungen komplett abgedruckt sind [AbSu85, Dybv87, SuSt75]. Ein gravierender Nachteil dieser besonders einfachen Implementationsart besteht darin, da | wie allgemein bei Interpretation gegenuber Kompilation | bestimmte Aufgaben immer wieder zur Laufzeit wiederholt werden: Neben dem Parsen des Programms mussen die Bindungen von Variablen zur Laufzeit gesucht werden, und es mu vor jedem Prozeduraufruf festgestellt werden, ob Endrekursion vorliegt. Eine weitere Klasse von Implementationen stellt Programme in Listen dar, transformiert aber die Quelldarstellung. Insbesondere werden die Variablennamen, wie bei den Bindungsumgebungen beschrieben, durch Adressen (Paare aus Level und Position) ersetzt und endrekusive durch Kennzeichnung von anderen Prozeduraufrufen unterschieden. Diese Implementationen sind weniger rechenzeitintensiv als reine Interpreter. Die nachste Klasse von Implementationen ubersetzt Programme in einen virtuellen Maschinencode. Dieser Maschinencode ist speziell auf Scheme zugeschnitten und beinhaltet Befehle fur Prozeduraufrufe, Variablenzugrie und Standardfunktionen. Im Gegensatz zur Listendarstellung stehen wie bei realem Maschinencode aufeinander auszufuhrende Befehle an aufeinander folgenden Speicherplatzen. Der in der Listendarstellung notige Zeiger auf den nachsten "Befehl\ entfallt, so da der Maschinencode kompakter als Listen ist und mit weniger Speicherzugrien abgearbeitet werden kann. Der virtuelle Maschinencode ist haug ein Bytecode: Ein Code, in dem jedes Byte einen Befehl oder einen Operanden enthalt. Bytecode kann sehr ezient auf einer realen Maschine interpretiert werden, weil das ganze Byte als Index in eine Sprungtabelle dienen kann (sog. Threaded-Code-Technik [BaJe86]). Ein Extremfall bei der Kompilation von Scheme ist die Ubersetzung in realen Maschinecode. Die Ubersetzung ermoglicht eine maximale Ablaufgeschwindigkeit der Programme. Die Ubersetzung in realen Maschinencode ist zeitintensiver als die in einen Scheme-spezischen virtuellen Code. Ferner benotigt realer Maschinencode mehr Speicherplatz als ein virtueller Code wie z.B. Bytecode. 24 KAPITEL 3. DIE IMPLEMENTIERUNG VON SCHEME 3.2 Die Speicherverwaltung Scheme vermittelt seinem Programmierer die Illusion eines unbegrenzt groen Speichers. Objekte werden mit Konstruktoren (cons, make-vector, make-string), mit Prozeduren, die letztlich Konstruktoren aufrufen (z. B. read), bei Rechnungen mit BIGNUMs und FLONUMs und auch beim Aufruf von Prozeduren fur das Anlegen von Bindungsumgebungen und Controlframes erzeugt. Der Report uber Scheme [Rees86] schreibt vor, da alle Objekte eine unbegrenzte Lebensdauer haben (unlimited extent). Da alle realen Maschinen nur uber einen begrenzt groen Hauptspeicher verfugen, ist eine Speicherverwaltung ein integraler Teil jeder Implementation der Sprache. Die Speicherverwaltung hat die Aufgabe, nicht mehr referenzierbare Objekte zu identizieren und den durch diese belegten Speicherplatz fur neu anzulegende Objekte wiederzuverwenden. Speicherverwaltungen unterscheiden sich hinsichtlich mehrerer Anforderungen: Speicherverwaltungen konnen fur die Verwaltung von Speicherbereichen fester oder variabler Lange ausgelegt sein. Speicherverwaltungen von Blocken fester Lange konnen nicht mehr referenzierte Objekte einfach zu einer Freispeicherliste zusammenfassen, von der dann weitere Anforderungen von Speicher befriedigt werden. Speicherverwaltungen von Blocken variabler Lange sind mit der Fragmentierung des Speichers konfrontiert. Um Anforderungen nach beliebig groen Blocken befriedigen zu konnen, mussen sie entweder die Fragmentierung beseitigen, indem noch referenzierte Blocke verschoben werden (Kompaktizierung), oder sie versuchen, aneinander angrenzende, nicht mehr referenzierte Blocke zusammenzufassen. Speicherverwaltungen konnen auf Maschinen mit realem und solche mit virtuellem Speicher zugeschnitten sein. Die Annahme lokaler Speicherzugrie, fur die nur ein Teil des Datenbereichs eines Prozesses jeweils im realen Hauptspeicher sein mu, fuhrt zum Konzept eines virtuellen Speichers, in den auf Anforderung (bei Seitenfehlern) Seiten aus dem Hintergrundspeicher in den realen Hauptspeicher verlagert werden. Speicherverwaltungen mussen bei virtuellem Speicher einerseits selbst u berwiegend lokale Speicherzugrie ausfuhren und andererseits die noch referenzierbaren Objekte zur Ermoglichung lokaler Zugrie umgruppieren. Speicherverwaltungen konnen unterbrechend arbeiten: Sie werden nur dann aktiviert, wenn der gesamte Speicher belegt ist. Sie unterbrechen dann das Ausfuhren des SchemeProgramms fur eine spurbare Zeit (im Bereich von Sekunden bis Minuten) fur die Ausfuhrung einer Garbage Collection. Die Garbage Collection ist das Ermitteln aller noch zugreifbaren Objekte im Speicher, mit dem Ziel, den Rest, den durch nicht mehr zugreifbare Objekte belegten Speicher, fur weitere Speicheranforderungen zur Verfugung zu stellen zu konnen. Speicherverwaltungen konnen auch inkrementell arbeiten: Sie verschranken dabei die Ausfuhrung des Scheme-Programms mit der Garbage Collection. Das Scheme-Programm lauft zwar langsamer ab, es wird aber nie fur langere Wartezeiten unterbrochen. Implementationen, an die Echtzeitanforderungen fur bestimmte Anwendungen (z. B. Steuerungsaufgaben) oder aus ergonomischen Grunden gestellt werden, mussen eine inkrementelle Garbage Collection verwenden. Die folgenden Abschnitte stellen drei grundsatzlich unterschiedliche Algorithmen fur unterbrechende Garbage Collection vor: Referenzenzahlung, Mark-and-Sweep und Stop-and-Copy. Anschlieend erfolgt die Beschreibung inkrementeller Algorithmen. Dazu gehoren sowohl inkrementell in die Programmausfuhrung eingearbeitete Varianten der unterbrechenden Algorithmen als auch einige Erweiterungen, die nur bei inkrementeller Garbage Collection verwendet werden. 3.2. DIE SPEICHERVERWALTUNG 25 Der Stellenwert der Garbage Collection Algorithmen kann an der Vielzahl der vorliegenen Algorithmen gemessen werden. Die meisten Veroentlichungen stellen ein in einer bestimmten Implementation genutztes Verfahren vor [AbSu85, BaJe86, Bake78, Broo84, Chen70, Hend80, uber verschiedene Garbage Collection Algorithmen LiHe83, Moon84, ScWa67]. Ein Uberblick ndet sich in [Knut68], [Alle78] und [Gabr87]. 3.2.1 Referenzenzahlung Die Referenzenzahlung ist ein verbreitetes Verfahren bei der Speicherverwaltung von Objekten [Knut68]. Jedes Objekte enthalt dabei ein zusatzliches Feld, das die Anzahl der Referenzen auf das Objekt angibt. Beim Einrichten und Loschen von Referenzen wird die Anzahl im Objekte jeweils angepat. Sobald diese Anzahl gleich null wird, ist bekannt, da das Objekt nicht mehr benotigt wird und der durch dieses Objekt belegte Speicherplatz neu vergeben werden kann. Bevor dieser Speicherplatz neu vergeben werden kann, mussen alle im nicht mehr benotigten Objekt bestehenden Referenzen geloscht werden, wobei moglicherweise weitere Objekte als nicht mehr benotigt identiziert werden und rekursiv weitere Referenzen geloscht werden mussen. Neben zirkularen Datenstrukturen, bei denen auch nach Aufheben der letzten Referenz auf die Gesamtstruktur die Anzahlen in den Objekten nicht null werden, werden in LISP-Dialekten uberwiegend Objekte geringer Groe (CONS-Zellen) verwaltet, bei denen ein zusatzliches Feld einen groen Speichermehrbedarf bedeutet. Zudem andern sich in LISP Referenzen auf Objekte sehr haug (bei jeder Parameterubergabe werden neue Referenzen u bergeben, bei Ruckkehr von einer Prozedur diese Referenzen geloscht), so da durch Aktualisierung der Anzahl-Felder ein bedeutender Mehrbedarf an Rechenzeit entsteht. Daher wird die Referenzenzahlung bei LISP, auer bei einigen Interlisp-Dialekten [Deut80], sehr selten verwendet [Gabr87]. 3.2.2 Mark-and-Sweep Algorithmus Der Mark-and-Sweep Algorithmus ist der alteste Algorithmus fur LISP, der schon bei der ersten LISP-Implementation von McCarthy beschrieben wurde [McCa60]. Der Mark-and-Sweep Algorithmus ist nach seinen beiden Phasen benannt. Die erste Phase markiert alle erreichbaren Objekte. Alle Objekte enthalten ein zusatzliches Markierungsbit, das zu Beginn der Garbage Collection zuruckgesetzt ist. Bei erreichten Objekten wird es gesetzt. Die Markierungsphase besteht im Durchlaufen der Baumstrukturen. Wenn dabei ein noch nicht markiertes Objekt angetroen wird, wird es markiert und seine Unterobjekte durchlaufen. Da das Durchlaufen von Baumen bei Programmierung in ublicher Weise einen Stack benotigt und die Garbage Collection hingegen einsetzt, wenn kein Speicher mehr frei ist, wird haug der Algorithmus nach Schorr und Waite [ScWa67] eingesetzt, der ohne einen Stack arbeitet, dafur die Zeiger verandert und dazu wesentlich mehr Speicherzugrie ausfuhrt. Die zweite Phase geht sukzessive den gesamten Speicher sequentiell durch, setzt die Markierungen markierter Objekte zuruck und fat nichtmarkierte Objekte zu einer Freispeicherliste zusammen. Der Mark-and-Sweep Algorithmus kann, insbesondere in der Erweiterung nach Schorr und Waite, den gesamten Speicher fur Objekte nutzen. Er ist besonders fur Implementationen geeignet, die Blocke fester Lange verwalten, da er nicht kompaktiziert. Bei Systemen mit virtuellem Speicher ist neben der fortbestehenden Fragmentierung auch die in der zweiten Phase (SweepPhase) erfolgende Inspektion des gesamten Speichers nachteilig: Dabei werden alle Seiten vom Hintergrundspeicher sequentiell in den Hauptspeicher gelesen. 26 KAPITEL 3. DIE IMPLEMENTIERUNG VON SCHEME 3.2.3 Stop-and-Copy Algorithmus Ein in LISP-Implementationen weit verbreiteter Algorithmus ist der Stop-and-Copy Algorithmus [Chen70]. Der Stop-and-Copy Algorithmus nutzt jeweils nur eine Halfte des zur Verfugung stehenden Speichers. Wenn in der einen Halfte kein Speicher mehr alloziert werden kann, werden alle noch referenzierbaren Objekte an den Anfang der zweiten Halfte kopiert und anschlieend die zweite Halfte zum Allozieren von Speicher genutzt, bis die beiden Halften bei der nachsten Garbage Collection wieder ihre Rollen vertauschen. Auch der in dieser Arbeit beschriebene Prozessor verwendet eine Variante des Stop-and-Copy Verfahrens; daher soll es hier genauer beschrieben werden: Fur das Stop-and-Copy-Verfahren wird der Speicher in zwei Halften aufgeteilt und jeweils immer nur in einer der Halften Speicher vergeben. Die Speicherverwaltung verwaltet dazu einen Zeiger free auf den Anfang des freien Bereichs. Wenn Speicher angefordert wird, wird free um die benotigte Blockgroe erhoht und free vor der Erhohung als Anfangsadresse des zugeteilten Speichers zugewiesen. Der Stop-andCopy Algorithmus kann daher Blocke unterschiedlicher Lange liefern. Wenn beim Stop-and-Copy Algorithmus mehr Speicher angefordert wird, als noch in der zuzuteilenden Halfte des Speichers frei ist, erfolgt die Garbage Collection: Das neue Register scan und free werden mit der Anfangsadresse der nicht genutzten Speicherhalfte geladen. Die von Registern und Stack zugegrienen Objekte werden reloziert: Wenn Register oder Verweise im Stack auf einen Vorwartsverweis zeigen, wird die neue Adresse eingetragen, sonst werden die Objekte nach free kopiert, die Adresse von free in Register und Stack eingetragen, an die alte Adresse des Objekts ein Vorwartsverweis auf die neue Adresse geschrieben und free um die Groe des Objekts erhoht. Anschlieend wird scan solange reloziert und erhoht, bis scan und free auf die gleiche Adresse weisen. Der Stop-and-Copy Algorithmus kompaktiziert den benutzten Speicher am Anfang der Halfte. Deswegen wird er besonders haug fur Rechner mit virtuellem Speicher eingesetzt. Ferner inspiziert der Algorithmus nur alle kopierten Objekte und nicht den gesamten Speicher, eine deutliche Verbesserung gegenuber dem Mark-and-Sweep Algorithmus. Ein Nachteil des Stop-and-Copy Algorithmus gegenuber anderen Verfahren ist die jeweilige Nutzung nur der Halfte des Speichers. Daher werden Varianten eingesetzt, bei denen die benutzten Objekte auf einen Hintergrundspeicher kopiert werden, (free und scan sind dann wahrend der Garbage Collection Positionen in einer Plattendatei) dort reloziert werden und anschlieend in den Hauptspeicher zuruckgeschieben werden. 3.2.4 Inkrementelle Garbage Collection Die Referenzenzahlung ist ein inkrementelles Verfahren, weil es die Operationen fur die Speicherverwaltung auf den normalen Programmablauf, namlich beim Erzeugen und Loschen von Referenzen, verteilt. Es wurde zwar bei einer experimentellen LISP-Maschine von Xerox implementiert [Deut80], ist bei LISP aus den bei der Beschreibung der Referenzenzahlung erwahnten Grunden jedoch nicht verbreitet. Ein verbreiteter inkrementeller Algorithmus ist eine von Baker [Bake78] beschriebene und in der M.I.T. LISP-Maschine [Gree77] eingesetzte inkrementelle Version des Stop-and-Copy Algorithmus: Wahrend aller Speicheranforderungen werden immer einige Objekte reloziert. Wahrend des normalen Abarbeitens von Programmen mu dann nach Zugri auf ein Objekt immer auf eine Vorwartsreferenz abgefragt werden und dieser gegebenenfalls gefolgt werden. Wegen dieser zahlreichen Abfragen wird inkrementelle Garbage Collection bei LISP nur in Hardwareimplementationen eingesetzt. Neuere inkrementelle Garbage Collection Algorithmen machen sich Untersuchungsergebnisse 3.2. DIE SPEICHERVERWALTUNG 27 uber die Lebensdauer der Objekte in typischen LISP-Programmen zu nutze: Neu allozierte Objekte sind mit hoher Wahrscheinlichkeit schon bei der nachsten Garbage Collection nicht mehr zugreifbar. Objekte, die schon mehrere Garbage Collections u berlebt haben, werden mit hoher Wahrscheinlichkeit auch noch weitere Garbage Collections uberleben. Als Konsequenz aus diesen Untersuchungen wird der Speicher in verschiedene Blocke eingeteilt, in die Objekte unterschiedlicher Generationen eingetragen werden. Ein Objekt gelangt in die nachste Generation, wenn es eine generationsspezische Anzahl von Garbage Collections u berlebt hat. Die LISP-Implementation fuhrt Garbage Collections fur Blocke mit kurzlebigen Objekten wesentlich hauger aus als fur Blocke mit langerlebigen Objekten und vermeidet nicht nur die zeitintensive Garbage Collection fur Speicherbereiche, in denen kaum freier Speicher zu erlangen ist. Vielmehr wird die Garbage Collection auf einen lokalen Speicherbereich beschrankt und damit bei virtuellem Speicher eine wesentliche Beschleunigung erzielt. Dieses Verfahren wird von Symbolics verwendet [Moon84]. Es nutzt fur die Garbage Collection in den einzelnen Blocken den inkrementellen Stop-and-Copy Algorithmus. Zusatzlicher Aufwand entsteht dabei durch Referenzen von Objekten aus einem Block in einen anderen. Solche Referenzen erfolgen u ber Tabellen. Zudem mussen Objekte ein Feld fur die Anzahl der Garbage Collections, die sie schon uberlebt haben, enthalten, damit feststellbar ist, wann sie in die nachste Generation ubergehen. Kapitel 4 Wichtige Implementationen von Scheme Dieses Kapitel soll typische Implementationen von Scheme mit ihren Vor- und Nachteilen vorgestellen. Im nachsten Kapitel wird dann eine neue Implementation konzipiert, die Schwachen der bestehenden Implementationen durch ein neues Konzept u berwindet. Eine Einteilung der existierenen Implementationen kann nach unterschiedlichen Kriterien erfolgen: nach den Rechnerklassen auf denen sie laufen (Mikrorechner, Workstations, Grorechner, Spezialhardware), nach dem Einsatzbereich (Ausbildung, Programmentwicklung, Einsatz beim Anwender) und nach bei der Implementierung gewahlte Alternativen (interpretierende oder compilierende Implementation, mit oder ohne Unterstutzung virtuellen Speichers, unterbrechende oder inkrementelle Garbage Collection). Hier sollen die Implementationen nach den bei der Implementierung gewahlten Alternativen fur die Reprasentation der Programme, entspechend der Einteilung in Kapitel 3.1.2.4, dargestellt werden. Diese Alternativen beeinussen insbesondere den Rechenzeit- und Speicherbedarf, zwei aussagekraftige Vergleichskategorien fur Algorithmen und Programme. Allen hier vorgestellten Implementationen gemeinsam ist die Objektreprasentation durch Typen im Zeiger (tagged pointer). Auch werden Listen immer aus CONS-Zellen gebildet; keine Scheme-Implementation verwendet CDR-Kodierung. Die Speicherverwaltungen arbeiten alle unterbrechend. Sie unterscheiden sich in den Algorithmen (Stop-and-Copy oder Mark-and-Sweep) und in der Moglichkeit, Objekte variabler Lange zu unterstutzen. 4.1 Interpretation der Quelldarstellung Die erste Implementation von Scheme war ein in LISP erstellter Interpreter. Der Quellcode in MacLISP ist im Anhang von [SuSt75], der ersten Veroentlichung u ber Scheme, enthalten. Da LISP eine Programmiersprache ist, die "rapid prototyping\ und das Parsen von in Listenstruktur dargestellten Ausdrucken besonders unterstutzt, ist diese Art der Implementation war sehr einfach zu bewerkstelligen. Das darunterliegende LISP stellt die Daten, die Standardprozeduren und die Speicherverwaltung bereit. Ein Nachteil besteht in dem groen Speicherbedarf, weil das LISP-System, das nur zum Teil genutzt wurde, immer vorhanden war. Ferner ist die Ablaufgeschwindigkeit der Programme gering. 4.2. 29 INTERPRETATION VON S-CODE 4.2 Interpretation von S-Code Interpretierende Implementationen stellen das abzuarbeitende Programm als Listenstruktur dar. Transformationen des Programms in eine Interndarstellung des Interpreters ermoglichen ein ezi enteres Abarbeiten als die Ubernahme der Quelldarstellung es erlaubt. Diese Darstellung wird | zumindest beim MIT | S-Code genannt. In S-Code werden Variablennamen durch lexikalische Adressen ersetzt, werden endrekursive Prozeduraufrufe gekennzeichnet, und es werden weitere Typen fur die Bestandteile der Kernsprache eingefuhrt, damit der Interpreter nicht das erste Symbol einer Liste suchen und anhand dessen verzweigen mu. Bei S-Code besteht die Grundroutine des Interpreters aus einer Tabelle, u ber die abhangig von dem Typ der S-Code-Listen verzweigt wird. Diese Typen spielen also die Rolle von Opcodes in Maschinensprachen. Im Gegensatz zu Maschinensprachen bleibt das S-Code Programm eine listenformige Darstellung des Parsebaumes. S-Code wurde am MIT bei Softwareimplementationen (Chipmunk Scheme, C-Scheme) und Hardwareimplementationen (Scheme-79, Scheme-81) eingesetzt. Die Hardwareimplementation Scheme-86 [BeWu88a], die nur simuliert, aber nicht fertiggestellt wurde, wird in Kapitel 9.4.1 beschrieben. 4.2.1 MIT C-Scheme MIT C-Scheme [CSch84] ist eine vollstandige, portable Implementation von Scheme, die im Gegensatz zu allen anderen hier beschriebenen Implementationen auch komplexe und rationale Zahlen bereitstellt. Sie loste beim MIT das Chipmunk Scheme, eine auf inzwischen veralteten Rechnern 9836 von Hewlett Packard (68000 mit 12,5 MHz, 4 MByte Hauptspeicher, kein virtueller Speicher) in 68000-Assembler erstellte Implementation, ab. C-Scheme ist ein sehr umfangreiches Programm mit sehr groem Speicherbedarf, das nur auf 32 Bit Rechnern mit virtuellem Speicher unter Unix und VMS eingesetzt wird. C-Scheme unterstutzt Objekte mit variabler Lange und verwendet den Stop-and-Copy Algorithmus fur die Garbage Collection. 4.2.2 Scheme-79 Scheme-79 ist der erste Schemeprozessor, der gefertigt und getestet wurde. Scheme-79 besteht aus zehn Registern, Inkrementer, Dekrementer und einem Komparator, der nur auf Gleichheit prufen kann sowie aus je einem Mikroprogramm- und Nanoprogramm-PLA. Uber diese Vergleiche, das Inkrementieren und Dekrementieren hinausgehende Operationen sind nicht moglich. Insbesondere beherrscht der Prozessor keine weitere Arithmetik. Die einzige Speicherstruktur sind aus 2 Maschinenworten bestehende CONS-Zellen. Die Programme sind als Listenstruktur in S-Code mit Typen im Pointer dargestellt, und auch der Stack wird aus CONS-Zellen im Heap alloziert. Die Maschinenworte sind 32 Bit breit, wovon 24 Bit fur die Pointer auf CONS-Zellen oder fur Integer, 7 Bit fur den Typ und 1 Bit fur die Speicherverwaltung genutzt werden (Abbildung 4.1). GC 31 Typ 24 Datum oder Pointer Abbildung 4.1: Das Wordformat von Scheme-79. Das Chip implementiert die in Tabelle 4.1 angegebenen Standardprozeduren. 0 30 KAPITEL 4. WICHTIGE IMPLEMENTATIONEN VON SCHEME cons car cdr set-car! set-cdr! 01+ 1+ null? zero? eq? null? pair? number? Tabelle 4.1: Durch Scheme-79 unterstutzte Standardprozeduren. Scheme-79 kann Interrupts bearbeiten und selbst auslosen. Die Speicherverwaltung, die Abarbeitung von S-Code und die Bearbeitung von Interrupts sind im Mikroprogramm untergebracht. Unterprogramme im Mikroprogramm sind nicht vorgesehen; daher realisiert ein Nanoprogramm haug wiederkehrende Ablaufe und steuert Hauptspeicherzugrie. Die Garbage Collection erfolgt nach dem Mark-and-Sweep Algorithmus modiziert nach Schorr und Waite [ScWa67], um Listen durchlaufen zu konnen, ohne dazu einen Stack zu benotigen. Scheme-79 wurde in kurzer Zeit { [Holl80] berichtet von funf Wochen { entworfen. Die Register und Komparatoren wurden dabei von Hand entworfen und die PLAs von einem PLA-Generator erzeugt. In weiteren 5 Monaten wurden noch Fehler berichtigt, bis die Fertigung 1979 / 1980 mit einem NMOS Proze unter Verwendung der Entwurfsregeln von Mead und Conway [MeCo80] mit 1 = 1; 25 erfolgte. Bis auf zwei Entwurfsfehler { einer davon in der Garbage Collection { funktionierte einer von vier gefertigten Chips und hat Testprogramme ausfuhren konnen [Holl80]. In [Holl80] wird die Taktfrequenz mit 625 KHz angegeben, dabei aber erwahnt, da dies noch nicht die maximale Taktfrequenz des 45 mm 2 groen Chips ist. (define (+ x y) (if (zero? x) y (+ (-1+ x) (1+ y)))) (define (fib x) (cond ((zero? x) 0) ((zero (-1+ x)) 1) (else (+ (fib (-1+ (fib 20) ; + mu auf -1+ und 1+ zuruckgefuhrt werden ; fib(0) = 0 ; fib(1) = 1 x)) (fib (-1+ (-1+ x))))))) Abbildung 4.2: Mit Scheme-79 gerechnetes Testprogramm. In Abbildung 4.2 ist das Testprogramm gezeigt, mit dem die Entwerfer Scheme-79 und einen MacLISP-Interpreter auf einem DEC KA-10 Prozessor verglichen haben. Scheme-79 erhielt dazu 256 KByte Hauptspeicher und benotigte bei leerem Speicher 1 Minute und bei halber Fullung 3 Minuten. Der MacLISP Interpreter rechnete 3,6 Minuten, und ein vom MacLISP Interpreter ausgefuhrter Scheme Interpreter benotigte 9 Minuten [Suss81]. Resultate fur compiliertes MacLISP und ohne Denition fur +, da der KA-10 Prozessor im Gegensatz zu Scheme-79 Additionen beherrscht, sind nicht veroentlicht. 1 Der Parameter ist ein Ma f ur die Gute bei der IC-Fertigung: Die nacheinander auf die Siliziumscheibe gebrachten Strukturen sind um weniger als gegeneinander versetzt. Abhangig von diesem Parameter werden die Groen und Abstande der Strukturen gewahlt. Beispielsweise werden Metalleitungen minimal 3 breit und mit mindestens 3 Abstand gegenuber anderen Metalleitungen verlegt [MeCo80]. Die Lange eines Gatters wird meistens als Prozema angegeben; sie betragt 2. Scheme-79 wurde daher mit einem 2,5-Proze gefertigt. 4.2. 31 INTERPRETATION VON S-CODE Ein Einsatz von Scheme-79 ist kaum sinnvoll, da bis auf Inkrementieren und Dekrementieren keine Arithmetik moglich ist. Addition und Subtraktion konnen zwar prinzipiell auf die Addition und Subtraktion von 1 zuruckgefuhrt werden, aber ohne ein Pradikat, das negative Zahlen von positiven unterscheidet, kann Addition und Subtraktion nur fur positive Zahlen realisiert werden. Zudem ist naturlich eine Addition, die auf die Addition von 1 zuruckgefuhrt wird, fur praktisch alle Anwendungen zu inezient. Ferner belegt der Stack, der als Liste aus CONS-Zellen implementiert ist, doppelt so viel Speicher wie er benotigte, wenn als kontinuierlicher Speicherbereich realisiert worden ware. Noch gravierender ist vermutlich der zusatzliche Aufwand fur die Garbage Collection, der durch diese Realisierung des Stacks entsteht. Zwar erlaubt diese Implementation des Stacks eine problemlose Realisierung von Continuations, aber die meisten Programme werden gerade dadurch und aufgrund der daraus folgenden haugen Garbage Collections wesentlich langsamer. Tatsachlich ergeben Untersuchungen der Entwerfer, da Scheme-79 80% seiner Zeit mit Garbage Collection verbringt [Holl80]. Auerdem sind Bindungsumgebungen | wie alle Daten | als Listen dargestellt. Daher mu zum Aunden oder Andern der Bindung einer Variable immer mit den Listenoperationen zur gesuchten Stelle vorgedrungen werden. Das ezientere Indizieren einer als kontinuierlicher Speicherbereich reprasentierten Bindungsumgebung ist nicht moglich. 4.2.3 Scheme-81 Scheme-81 [Bata82] ist die zweite bekannte Hardwareimplementation von Scheme. Auch Scheme81 interpretiert S-Code und kann Interrupts bearbeiten. Scheme-81 implementiert ein Busprotokoll, das es verschiedenen Prozessoren erlaubt, unterschiedliche Standardprozeduren zu implementieren und diese allen beteiligten Prozessoren zur Verfugung zu stellen. Scheme-81 hat in diesem Konzept speziell die Aufgabe, den S-Code zu interpretieren und den anderen Prozessoren auf Anforderung Speicher zuzuweisen. Jeder dieser maximal 31 Prozessoren verfugt u ber maximal 16 Millionen CONS-Zellen Hauptspeicher, und Objekte im Speicher eines Prozessors konnen auch in den Speicher eines anderen Prozessors verweisen. Die einzige implementierte Speicherstruktur sind aus 2 Maschinenworten bestehende CONSZellen. Die Programme sind | wie bei Scheme-79 | als Listenstruktur in S-Code mit Typen im Pointer dargestellt, und auch die Stacks werden aus CONS-Zellen im Heap alloziert. Zusatzlich waren Vektoren als Speicherstruktur zwar geplant, konnten aber aus Platzgrunden nicht realisiert werden [Bata82]. Die Maschinenworte sind 36 Bit breit, wovon 29 Bit fur die Pointer auf CONS-Zellen oder fur Integer, 7 Bit fur den Typ genutzt werden (Abbildung 4.3). 35 Typ 29 Datum oder Pointer 0 Abbildung 4.3: Das Wordformat von Scheme-81. Von 29 Bit breiten Adressen werden die obersten 5 Bit zur Adressierung des Prozessors und die unteren 24 Bit zur Adressierung einer CONS-Zelle im Speicher dieses Prozessors verwendet. Die Struktur von Scheme-81 ist in [Bata82] leider nicht sehr genau beschrieben: Daten wie Anzahl der Register, welche Operationen ausgefuhrt werden konnen sowie wieviele und welche Standardprozeduren des S-Codes interpretiert werden, sind nicht veroentlicht. 32 KAPITEL 4. WICHTIGE IMPLEMENTATIONEN VON SCHEME Die Register von Scheme-81 sind in Teilfelder aufgespalten und mit Operationseinheiten wie Shifter und Inkrementer vereinigt. Daher konnen viele Operationen gleichzeitig auf unterschiedlichen Registern und Teilfeldern der Register ausfgefuhrt werden. Diese Parallelitat bedingte ein horizontales Mikroprogrammwort von uber 200 Bit Breite, das dann durch Einteilung in Felder und Hinzutreten von Dekoder-PLAs bei Beibehaltung der Parallelitat schmaler wurde. Die Register sind als "Racks\ [StSu80b], ein Kunstwort aus "Register\ und "Stack\, ausgefuhrt: Jedem Register wird ein eigener Stack und ein Zustandsbit zugeordnet. Das Zustandsbit speichert, ob ein Register gesichert oder restauriert werden soll und fuhrt diese Operation nur dann aus, wenn der Registerinhalt wirklich verandert oder gelesen wird. Dadurch werden u berussige Stackoperationen zur Laufzeit optimiert. Das Mikroprogramm realisiert den S-Code Interpreter und die Speicherverwaltung nach dem Stop-and-Copy Algorithmus sowie den Bus-Controller fur die Vernetzung mehrerer Prozessoren und wurde durch Einfuhrung von Unterprogrammen auf 374 Mikroinstruktionen reduziert, die in einem PLA untergebracht sind. Als Groe des Chips wird bei einem 2; 0 -Proze eine Flache von 85 mm2 angegeben. Stacks und Bindungsumgebungen werden wie in Scheme-79 aus CONS-Zellen aufgebaut. Die Garbage-Collection verwendet den Stop-and-Copy-Algorithmus, wobei alle vernetzten Prozessoren eine Garbage-Collection durchfuhren mussen, sobald einem der Prozessoren der Speicherplatz ausgeht. Ob Scheme-81 eine verbesserte Integerarithmetik aufweist, geht aus [Bata82] leider nicht hervor. Ferner sind keine Berichte vom Test oder Einsatz von Scheme-81 veroentlicht. Eine Anfrage des Verfassers bei Gerald J. Sussman ergab, da Scheme-81 nach einer Fertigung nicht weiterverfolgt wurde. Nach der Fertigung des Chips wurden Fehler gefunden. Der gefertigte Scheme-81 hatte einfache Programme etwa so schnell wie compiliertes MacLISP auf dem Prozessor KL-10 ausgefuhrt [Suss88]. Die Frage nach einer Aufzahlung der implementierten Standardprozeduren wurde nicht beantwortet. Ein Fazit der Scheme-Prozessoren-Entwurfe am MIT veroentlicht Wu in einem neueren MITMemo [Wu88]: "In 1979 and 1982 two attempts were made to implement an SCode interpreter in microcode on a microprocessor. ::: A complete Scheme system never ran on any of them and extensive performance testing was not completed.\ [Wu88] 4.3 Ubersetzung in virtuellen Maschinencode Die Ubersetzung in virtuellen Maschinencode erlaubt Implementationen auf Mikrorechnern. Der virtuelle Maschinencode bewirkt eine sehr kompakte Reprasentation von Programmen und kommt damit dem begrenzten Hauptspeicher von Mikrorechnern entgegen. Die Implementation umfat einen Compiler, der Ausdrucke von Scheme in den virtuellen Maschinencode ubersetzt. Als virtueller Maschinencode wird ein Bytecode gewahlt, in dem Befehle ein Byte und mogliche Argumente auch Bytes umfassen. Diese Darstellung ist sowohl kompakt als auch ezient durch Programme auf Mikrorechnern interpretierbar. Ferner werden die Bytecodebefehle auf Scheme zugeschnitten. Aufrufe von Standardprozeduren konnen in einen einzigen Befehl u bersetzt werden, der dann Typprufungen und generische Operationen umfat. Andere Befehle erlauben den Zugri auf Argumente und den Aufruf von Prozeduren. Die Orientierung des Befehlssatzes an der Sprache tragt auch wesentlich zur Kompaktheit der reprasentierten Programme bei. Schooler und Stamos berichten von Untersuchungen von Chris Hanson am MIT, nach denen Programme in Bytecode um den Faktor drei weniger Speicherplatz als in S-Code belegen [ScSt84]. 4.3. UBERSETZUNG IN VIRTUELLEN MASCHINENCODE 33 Implementationen, denen ein Bytecode zugrundeliegt, sind PC Scheme [BaJe86], MacScheme [Sem87], XScheme [Betz89] und eine in [ScSt84] vorgeschlagene Macintosh-Implementation, die allerdings nie realisiert wurde [BaJe86]. Da alle diese Implementationen fur Mikrorechner konzipiert sind, unterstreicht die Bedeutung der Programmreprasentation durch Bytecode fur diese Rechnerklasse. XScheme ist eine frei kopierbare, vollstandig in C erstellte Implementation, die noch sehr fehlerbehaftet ist und besonders auf Rechnern betrieben wird, fur die keine anderen Implementationen erhaltlich sind. Die beiden anderen Implementationen sollen genauer vorgestellt werden. 4.3.1 PC Scheme Die bekannteste | und nach Meinung Vieler die beste (z. B. [Shep87]) | Implementation fur Mikrorechner ist PC Scheme der Firma Texas Instruments. Es ist eine auf IBM PCs und ATs unter MS-DOS ablauahige Implementation, bei der Schemeprogramme in einen registerorientierten Bytecode u bersetzt werden. Der registerorientierte Bytecode wird von einem in Assembler und in C geschriebenen Programm interpretiert. Neben dem Compiler, der mit Closure- und Environmentanalysen und weiteren Optimierun gen einen gelungenen Kompromi zwischen Ubersetzungszeit und Ausfuhrungszeit des erzeugten Codes darstellt, tragen der enthaltene Editor Edwin und die Erweiterung fur objektorientierte Programmierung SCOOPS viel zur Beliebtheit von PC Scheme bei. PC Scheme verwendet Typreprasentation im Pointer mit dem BIBOP-Verfahren. Es unterstutzt Stack und Heap, wobei im Heap eine Garbage Collection nach dem Mark-and-Sweep Algorithmus mit anschlieender Kompaktizierungsphase erfolgt. Continuations werden nur bei Bedarf und bei Stackuberlauf in den Heap kopiert [BaJe86]. Die Grenzen von PC Scheme sind durch den begrenzten Hauptspeicher gegeben. PC Scheme ist besonders fur das Entwickeln kleinerer Programme geeignet. Die vom 80286-Prozessor adressierbaren 640 KByte sind sehr schnell erreicht. Ab Version 3.00 werden zwar bis zu 2,5 MByte unterstutzt, aber nur um den Preis einer deutlich geringeren Ablaufgeschwindigkeit (Faktor 2 bis 3). Eine Version, die bis zu 4 MByte Speicher in Protected Mode unterstutzt, wird in Produkten von TI eingesetzt, aber nicht separat vertrieben. 4.3.2 MacScheme MacScheme ist eine Implementation auf dem Apple Macintosh. Sie ist in die Bedienungsoberache des Macintosh integriert und verwendet zum Beispiel deren Editor. Die ursprungliche Implementation von 1985 ubersetzt Programme in einen stackorientierten Bytecode. Benchmarks laufen um den Faktor 2 bis 3 langsamer auf einem Macintosh mit 512 KByte Hauptspeicher als in PC Scheme auf einem IBM AT [BaJe86]. Die Autoren von PC Scheme fuhren diesen Unterschied auf die Uberlegenheit ihres registerorientierten Bytecodes zuruck. Uber Interna von MacScheme ist sehr wenig veroentlicht. Aus [Clin88] geht jedoch hervor, da die Version von 1985 die Verwaltung von Speicherbereichen unterschiedlicher Lange unterstutzt und nur einen Heap verwendet. Durch das Anlegen aller Bindungsumgebungen und Controlframes im Heap und die dadurch bewirkte Belastung fur die Speicherverwaltung sind die Benchmarkergebnisse wahrscheinlich besser erklarbar als durch Unterschiede im Modell der Bytecodemaschine. Die aktuelle Version von MacScheme [Sem87] unterstutzt sowohl Stack als auch Heap und erlaubt die Ubersetzung von Prozeduren wahlweise in Bytecode und in realen Maschinencode. Sie beeinhaltet umfangreiche Unterstutzungen fur die Nutzung der Macintosh Benutzeroberache durch Scheme-Programme. Die Benchmarks laufen etwa Faktor zwei schneller als in PC Scheme, wenn sie in realen Maschinencode u bersetzt werden [Clin88]. 34 KAPITEL 4. WICHTIGE IMPLEMENTATIONEN VON SCHEME 4.4 Ubersetzung in realen Maschinencode Eine Geschwindigkeitssteigerung der Programme gegenuber Bytecode-basierten Implementationen in realen Maschinencode erzielt werden. Die Ubersetzung in realen Makann durch Ubersetzung schinencode ist mit zwei Problemen verbunden: Realer Maschinencode benotigt wesentlich mehr Speicherplatz als Bytecode. MacScheme unterstutzt in der Version 1.5 sowohl Bytecode als auch 68000-Code. Das Handbuch [Sem87] gibt an, da realer Maschinencode um den Faktor funf platzaufwendiger ist (Seite I-30 in [Sem87]). Ferner sind Programme in realem Maschinencode schwerer auszutesten als Programme in Bytecode oder Listendarstellung [Sem87]. Compiler, die echten Maschinencode erzeugen, sind Liar [Roza84] und Orbit [Kran86, Kran88]. Wahrend Liar erst 1989 in die -Testphase kam, ist Orbit seit 1986 im T-System, einem Schemeahnlichen LISP-Dialekt der Yale-Universitat, im Einsatz. Alle drei Compiler erzeugen, ebenso wie ein in [Feel86] beschriebener Compiler, 68000Maschinencode. Wegen des Platzbedarfs des erzeugten Codes werden sie auf Workstations eingesetzt, die gegenuber Mikrorechnern u ber einen groen Hauptspeicher und fast immer sogar in realen virtuellen Speicher verfugen. Beispielsweise wird fur MacScheme bei der Ubersetzung Maschinencode ein Macintosh II mit 5 MByte Hauptspeicher empfohlen [Sem87]. Im erzeugten Maschinencode wird auf Typenprufungen verzichtet (vergl. Beispiele fur den erzeugten Code in [Kran86]), da nur so ein groer Geschwindigkeitsgewinn gegenuber interpretiertem virtuellen Code erreichbar ist. Wegen des Verzichts auf Typenprufungen sind solche Implementationen fur Lehre und Programmentwicklung weniger geeignet als fur das Erzielen einer maximalen Ablaufgeschwindigkeit von ausgetesteten Programmen. Kapitel 5 Konzeption einer neuen Implementation In diesem Kapitel soll ein Konzept fur eine neue Implementation der Sprache Scheme dargelegt werden, dem in den folgenden Kapiteln die Darstellung der Realisierung des Konzeptes folgt. Das Konzept berucksichtigt die Erfahrungen mit den bestehenden Implementationen und gewahrleistet auch die Realisierbarkeit unter restriktiven personellen und nanziellen Randbedingungen. 5.1 Folgerungen aus den bestehenden Implementationen uber bestehende Implementationen von Scheme. Das vorangegangene Kapitel bot einen Uberblick Es existieren sowohl interpretierende als auch compilierende Implementationen. Die interpretierenden Implementationen sind in der Ausfuhrungsgeschwindigkeit der Programme erwartungsgema den compilierenden Implementationen unterlegen. Als Vorteil der interpretierenden Implementationen wird die Nahe des reprasentierten Programms zur Quelldarstellung angefuhrt, die beim Austesten der Programme besonders vorteilhaft sei. Tatsachlich setzten sich compilie rende Implementationen durch, und diese beinhalten das Debuggen unterstutzende Ubersetzungsmodi [BaJe86, Sem87]. Die Entwicklung von Compiler fur Scheme ist vom Forschungsstadium (etwa Rabbit [Stee78]) zu praktisch eingesetzten Compilern auf Mikrorechnern [BaJe86, Sem87] und auf Workstations [Kran86, Kran88] gediehen. Die Darstellung der Objekte ist ein zentrales Kriterium fur die Ezienz einer Implementation. Die Darstellung der Prozeduren, die in Scheme auch Objekte sind, ist zentral fur Ausfuhrungsgeschwindigkeit und Speicherbedarf der Programme. Auch die Speicherverwaltung beeinut die Ezienz einer Implementation. Eine Speicherverwaltung, die Objekte variabler Lange unterstutzt, ist zwar aufwendiger als eine, die nur Objekte fester Lange verwalten kann. Die Unterstutzung Objekte variabler Lange ist aber fur eine eziente Objektreprasentation unverzichtbar. 5.2 Hardware-unterstutzte Implementationen von LISP Neben den Scheme-Chips (Scheme-79 und Scheme-81) vom MIT bestehen Erfahrungen mit LISP u ber LISP-MaMaschinen als Forschungsgegenstand und kommerzielles Produkt. Ein Uberblick schinen ndet sich in [PlTh87]. Pleszkun und Thazhuthaveetil sehen dort drei Aufgaben bei der Implementierung von LISP-Dialekten, die durch Hardware zu beschleunigen sind: 36 KAPITEL 5. KONZEPTION EINER NEUEN IMPLEMENTATION 1. Ezienter Prozeduraufruf. 2. Manipulation von Bindungsumgebungen und Controlframes. 3. Zugri auf Listen und Reprasentation derselben. 4. Speicherverwaltung. Die Entwicklung der heutigen LISP-Maschinen begann 1977 mit dem LISP-Maschinen-Projekt am MIT [Gree77], das durch Berichte u ber mit mikroprogrammierten Rechnern [Deut80] bei Xerox PARC gesammelte Erfahrungen initiiert wurde [PlTh87]. Die MIT-LISP-Maschine ist ein mikroprogrammierter 32-Rechner, dessen Architektur und Befehlssatz auf LISP zugeschnitten sind. LISP-Funktionen konnten interpretiert, in die Maschinensprache der LISP-Maschine compiliert und sogar in Mikroprogramme der LISP-Maschine ubersetzt werden. Die MIT-LISP-Maschine ist als Arbeitsplatzrechner (Workstation) konzipiert; nur ein Benutzer kann sie zu einer Zeit verwenden. Sie implementiert auch erstmals die CDR-Kodierung [Hans69] zur Reduktion des Speicherbedarfs von Listen. Die MIT-LISP-Maschine war der Ausgangspunkt fur kommerzielle Entwicklungen: Die Maschinen Symbolics 3600, LMI Lambda und TI Explorer sind alle als Arbeitsplatzrechner konzipiert und verfolgen unterschiedliche Aspekte der MIT-LISP-Maschine weiter. Symbolics hat das Wortformat auf 36 Bit Breite erweitert und kann damit 32-Bit Zahlen ezient reprasentieren und bietet virtuellen Speicher [Moon84, Moon85]. Die Maschine LMI Lambda ermoglicht den Anwendern das Ubersetzen von LISP-Funktionen in Mikroprogramme [Gabr87]. Die Klasse der Arbeitsplatzrechner ist nur eine der untersuchten Moglichkeiten fur eine hardware-unterstutzte LISP-Implementierung. Andere Verfahren nutzen Multiprozessorarchitekturen, die entweder unterschiedliche Prozessoren fur verschiedene Aufgaben enthalten oder eine Vielzahl gleicher Prozessoren fur eine parallele Abarbeitung von LISP-Programmen einsetzen. Diese Systeme benden sich, im Gegensatz zu LISP-Maschinen, noch im Forschungsstadium und werden nicht kommerziell eingesetzt [PlTh87]. Die verbreiteten LISP-Maschinen sind mikroprogrammiert und haben einen LISP-spezischen Maschinenbefehlssatz. Die sturmische Entwicklung der RISC-Prozessoren hat in neuester Zeit auch Prozessoren fur LISP hervorgebracht. Basierend auf der Entwicklung des RISC-Prozessors SOAR (Smalltalk on a RISC) fur Smalltalk in Berkeley durch Ungar [Pend86] wurde in Berkeley von Kong der LISP-Prozessor SPUR (Symbolic Processing using RISC) entwickelt [Kong89]. Ferner entstand mit MIPS-X an der Stanford University ein LISP-Prozessor in der RISC-Philosophie [StHe88]. Beide Prozessoren, SPUR und MIPS-X, sind noch Prototypen. Berichte vom praktischen Einsatz oder von der Fertigstellung einer kompletten Workstation mit LISP-Umgebung liegen bis dato nicht vor. Fur eine Unterstutzung der Implementierung durch Hardware mussen besonders kritische Operationen identiziert werden. Tabelle 5.1 zeigt die Verteilung der CPU-Zeit bei der Abarbeitung von LISP-Programmen nach in [StHe88] veroentlichten Untersuchungen der Stanford University. Diese Werte berucksichtigen den CPU-Zeitbedarf fur die Speicherverwaltung nicht mit. Sie basieren auf zehn Testprogrammen mit zusammen ca. 11500 Zeilen Quellcode [StHe88]. 5.3 Eine neue Scheme-Implementation Insbesondere da Scheme immer starker in der Lehre eingesetzt wird, ergibt sich der Wunsch nach einer neuen Implementation, die auf preiswerten Rechnern ablauft. Ein Einsatz von Scheme auf herkommlichen Timesharing-Rechnern ist aufgrund des ihres groen benotigten Prozeadreraums und der geringen Lokalitat der Zugrie im virtuellen Speicher zu verwerfen. Das Ziel ist daher, die verbliebenen Nachteile der schon sehr guten Implementationen auf Mikrorechnern (PC Scheme 5.3. 37 EINE NEUE SCHEME-IMPLEMENTATION Funktionsaufrufe CAR / CDR Zugrie auf lokale Variablen CONS Typpradikate Arithmetik Vektoren Zugri auf leere Liste 20 % 18 % 17 % 11 % 11 % 6% 5% 3% Tabelle 5.1: Verteilung der CPU-Zeit in LISP-Programmen nach [StHe88]. und MacScheme) durch neue Konzepte zu u berwinden. Zusammenfassend sind Anforderungen an die neue Implementation: 1. Hohe Ablaufgeschwindigkeit. Die Ablaufgeschwindigkeit soll sich der in imperativen Sprachen erstellter Programme weiter nahern. 2. Geringer Hauptspeicherbedarf. Eine gute Nutzung der bei Mikrorechnern knappen Resource Hauptspeicher bewirkt eine Beschleunigung der Ausfuhrungsgeschwindigkeit durch die Reduktion von Garbage Collections und ermoglicht umfangreichere Systeme (komfortable Editoren, Debugger und Benutzeroberachen, komplexere Compiler, mehr Standardprozeduren). 3. Schnelle oder inkrementelle Garbage Collection. Die Garbage Collection ist ein standiges Argernis fur die Programmierer in LISP-Dialekten. Die Relevanz dieses Punktes zeigt ein Bericht David Moons von Symbolics uber die Akzeptanz der Garbage Collection durch die Kunden der LISP-Maschinen seiner Firma: "Users of the 3600 and its predecessors have avoided the garbage collector whenever possible. They found that garbage collection made interactive response so poor and unpredictable, and its overhead was so high, that it was preferable to turn o garbage collection and simply wait for the unevitable exhaustion of virtual address space (at which point the system crashes and must be re-booted).\ [Moon84] Diesen drei Anforderungen kann durch folgende Spezikationen entsprochen werden: 1. Eine hohe Ablaufgeschwindigkeit ist durch einen optimierenden Compiler erreichbar. Durch die zusatzliche Forderung nach geringem Hauptspeicherbedarf ist nur durch Interpretation von Bytecode | der etwa Faktor funf weniger Speicherplatz als realer Maschinencode beansprucht [Sem87] und etwa Faktor drei weniger Platz als S-Code belegt [ScSt84] | und einen optimierenden Compiler, der Scheme in Bytecode ubersetzt, erzielbar. Eine Bytecodeimplementation war bisher immer mit einem Interpreter in Maschincode verbunden, der den virtuellen Bytecoderechner auf dem realen Rechner implementierte. Eine Hardwareimplementation des Bytecodeinterpreters ist ein neuer Ansatz, der gegenuber den bestehenden Scheme-Prozessoren eine ezientere Implementation durch Nutzung des erlangten Stands der Compiler-Technik fur Scheme verspricht. Der hardwareimplementierte Bytecodeinterpreter hat Typprufungen, Laufzeitprufungen bei Prozeduraufrufen und Standardprozeduren zu implementieren. 38 KAPITEL 5. KONZEPTION EINER NEUEN IMPLEMENTATION 2. Geringer Hauptspeicherbedarf der Daten lat sich durch CDR-Kodierung [Hans69] erreichen. Dieses Verfahren wird nur in Hardwareimplementationen eingesetzt, da es bei jeder primitiven Listenoperation eine Verzweigung anhand eines CDR-Kodes bedingt. Ferner ist der Hauptspeicherbedarf durch Reprasentation der Programme in Bytecode zu senken. 3. Eine schnelle Garbage Collection kann durch Verlagerung in den Hardware-Bytecodeinterpreter erreicht werden. Ferner ist die Belastung der Speicherverwaltung durch das Allozieren von Controlframes und Bindungsumgebungen auf einem Stack gering zu halten. Die Hardwareimplementation eines Bytecodeinterpreters verspricht aus den oben genannten Grunden also eine Scheme-Implementation mit hoher Ablaufgeschwindigkeit bei geringem Hauptspeicherbedarf. Bei einer solchen Hardwareimplementation wird ein Prozessor, der zentrale Teil eines Rechners, neu entworfen. Ein neuer Prozessor bedingt einen sehr groen personellen Aufwand fur das Erstellen von Hardware und Software, die den Prozessor zu einem einsatzfahigen Rechner erweitern. Der Prozessor ist um Speicher und Ein-/Ausgabesysteme zu erweitern. Programme mussen neben dem Scheme-Compiler ein Betriebssystem, eine Benutzeroberache und Bibliotheken umfassen. Das Ergebnis ware eine komplette Scheme-Workstation. Der Entwurf und Bau einer Scheme-Workstation erfordert zu groe personelle und nanziellen Mittel. Daher mute ein Konzept entwickelt werden, das so weit wie moglich vorhandene preiswerte Hardware und Software (Betriebssystem) nutzt. Es el die Entscheidung zugunsten eines Scheme-Prozessors, der in einen vorhandenen Mikrorechner eingesetzt wird. Der Mikrorechner stellt seinen Hauptspeicher, sein Betriebssystem und Bibliotheken mit Routinen fur Arithmetik, das Wandeln von Zahlen in Strings, u.s.w. zur Verfugung. Der Scheme-Prozessor arbeitet einen eigenen, Scheme-spezischen Maschinencode ab und u bernimmt auch die Speicherverwaltung. Der Scheme-Prozessor wird in einem vorhandenen Mikrorechner eingesetzt, welcher die Einund Ausgabe und Rechnungen mit Fliekommazahlen ubernimmt, sowie seinen Hauptspeicher mit dem Koprozessor teilt (Abbildung 5.1). In diversen Veroentlichungen wurde der Prozessor als KoAdressen, Daten, Kontrolle E/A 68000 Speicher SchemeProzessor Abbildung 5.1: Der Scheme-Prozessor in einem 68000-Rechner. prozessor bezeichnet [LoRa89a, LoRa89b, Lohs89], weil er nur zusammen mit einem Wirtsprozessor, der die Ein- und Ausgabe sowie Rechnungen mit Fliekommazahlen ubernimmt, einsatzfahig ist. Der Name Koprozessor ist jedoch im wahrsten Sinne des Wortes zu verstehen, da der SchemeProzessor nicht wie etwa ein Arithmetik-Koprozessor, nur fur bestimmte Operationen von einem Wirtsprozessor hinzugezogen wird. Tatsachlich holt der Scheme-Prozessor aber selbsttatig seine Maschinenbefehle und fuhrt diese selbstandig aus, wobei er nur fur Ein- und Ausgabeoperationen den Wirtsprozessor reaktiviert. Der Wirtsprozessor wird vom Scheme-Prozessor also zu einem I/O-Prozessor degradiert. Nur bei der Ausfuhrung von Scheme-Programmen, die uberwiegend 5.3. EINE NEUE SCHEME-IMPLEMENTATION 39 Fliekomma-Arithmetik treiben, wird die Aktivitat des Wirtsprozessors die des Scheme-Prozessors erreichen oder u bertreen. DB0{15 AB1{23 AS, LDS, UDS FC0, FC1, FC2 R/W, DTACK - SchemeProzessor BR, IRQ BG, BGACK CS, RESET Takte Abbildung 5.2: Der Scheme-Prozessor am 68000-Bus. Die Wahl eines Rechners, der mit dem Scheme-Prozessor versehen werden soll, el auf Rechner mit Motorola 68000 Prozessor [68000]. Diese Prozessoren unterstutzen ein Protokoll zur Busvergabe, welches auch im Scheme-Prozessor implementiert werden kann. Der Scheme-Prozessor mit den 68000-Bussignalen ist in Abbildung 5.2 gezeigt. Als erster Rechner wurde der Atari ST mit dem Scheme-Prozessor ausgerustet. Gerade dieser Rechner bot sich aufgrund der restriktiven Zeitplanung an, da der Verfasser aus fruheren Tatigkeiten als Autor des Pascalcompilers (ST Pascal Plus in Deutschland [Lohs85], Personal Pascal in den USA [Lohs86]) und Implementator eines Betriebssystems auf dem Atari ST (OS-9/68000) uber die notigen Detailkenntnisse der Hardware und Software dieses Rechners verfugt. Eine Alternative ware der Einsatz in Rechnern des Typs IBM AT, da diese in noch groerer Zahl als der Atari ST am Fachbereich Informatik der Universitat Hamburg vorhanden sind. Leider ist der Bus in IBM ATs nicht dafur ausgelegt, da Hauptspeicherzugrie ausfuhrende SchemeProzessoren hinzugefugt werden konnen. In diesen Rechnern konnen nur die CPU und die DMAEinheit von Festplatte und Diskettenlaufwerk Adressen an den Hauptspeicher anlegen. Diese Aufgabe, einen preiswerten Rechner durch eine preiswerte Zusatzhardware zu beschleunigen, ist vermutlich nicht nur an Universitaten interessant. Auch KI-Anwendungen, die in LISP erstellt werden, konnen haug nur dann auerhalb der Labore ihrer Entwickler eingesetzt werden, wenn sie auf preiswertere Hardware portiert wurden. Beispielsweise schreiben Thuy und Schnupp [ThSc89] in einer Einfuhrung in Expertensysteme: "Expertensysteme sollen Wissen verbreiten und nutzbar machen. Also gehoren sie nicht in den Elfenbeinturm. Doch da befanden sie sich Anfang bis Mitte der 80er Jahre fast ausschlielich. Der Grund war eine akademisch orientierte Forschungspolitik, die den Hochschulen zusammen mit Forschungsmitteln auch gleich die Lisp-Maschinen zur Verfugung stellte, auf denen sie ihre Systeme entwicklen sollten. Die dann naturlich niemand einsetzen konnte und wollte. Nicht nur, da diese Maschinen und die darauf laufenden Softwaresysteme 40 KAPITEL 5. KONZEPTION EINER NEUEN IMPLEMENTATION eine Zehnerpotenz teuer waren als in der Leistung vergleichbare, eingefuhrte Computer. Sie lieen sich auch in die vorhandene DV-Umgebung nicht sinnvoll einpassen. Wissensbasierte Software gehort auf Alltagsmaschinen.\ [ThSc89] Thuys und Schnupps Folgerung, da die Software auf Alltagsmaschinen gehore, ist dadurch zu erreichen, da eine Alltagsmaschine um einen preiswerten Zusatzprozessor zu erweitert wird, der wissensbasierte Software optimal unterstutzt. Der eingefuhrte, in seine DV-Umgebung eingepate Rechner wird durch den Zusatzprozessor fur KI-Anwendungen tauglich. 5.3.1 Verwandte Arbeiten In der Literatur sind Zusatz- oder Koprozessoren fur LISP zur Erganzung vorhandener Rechner kaum vertreten. Zwei ahnliche Arbeiten sollen zum Vergleich erwahnt werden. Sie zeigen insbesondere, wie verschieden die Randbedingungen ausfallen konnen. Eine ahnlich gelagerte Arbeit ist die Dissertation von Werner Eicher an der Universitat Kaiserslautern [Eich85]. Eicher beschreibt in seiner 1985 erschienenen Arbeit das Erweitern eines Rechners Mincal 621 der Firma Dietz (0,2 MIPS) um ein LISP-Werk. Der Universalrechner fuhrt Listenprimitive und die Garbage Collection aus. Das LISP-Werk wertet Ausdrucke aus, enthalt dazu vier Stacks und speichert die Propertylisten der Atome sowie die Bindungsumgebungen. Der verwendete LISP-Dialekt ist eine Teilmenge von LISP 1.5 mit dynamischer Variablenbindung. Funktionen als Parameter werden ausgeschlossen, um mit Stacks arbeiten zu konnen [Eich85]. Zur Messung der Performanz rechnet Eicher kurze, eigene Programme. Er vergleicht mit Implementationen auf anderen Rechnern und kommt zum Schlu, da seine Hardwarelosung schneller als eine nicht naher bezeichnete Symbolics mit 5 MIPS ist, wozu er die Ergebnisse aller Rechner auf eine Rechnerleistung von 1 MIPS skaliert. Die Verwendung des betagten Mincal-Rechners erklart sich vermutlich durch die aus seinem Lebenslauf ersichtliche elfjahrige Bearbeitung der Aufgabe. Eine aktuellere Aufgabe wird bei der Siemens AG gelost. Der Prozessor Colibri (Coprozessor fur LISP auf der Basis von RISC) [Hafe89] basiert auf den Erfahrungen mit SPUR und MIPS-X und ist als Mikroprozessor konzipiert, der eine LOAD/STORE-Architektur implementiert. Eine 4-stuge Pipeline wird verwendet, und 250 Register sind vorgesehen. Colibri soll zusammen mit einem Instruktionscache, einem Datencache, einer Fliekommaeinheit, einer MMU und 16 MByte Hauptspeicher einen Rechner bilden, der uber ein Businterface an einen Wirtsrechner angeschlossen wird [Hafe89]. Das Colibrisystem stellt damit einen vollstandigen Rechner dar und unterliegt damit nicht den restriktiven Randbedingungen (Vermeidung von Hardware- und Softwareaufwand), denen der in dieser Arbeit beschriebene Scheme-Prozessor genugen mu. Auch Symbolics MacIvory [West89] und TI MacExplorer [Boss87, Matt87] sind an den Apple Macintosh angepate Versionen von als eigenstandige LISP-Maschinen entwickelten Rechnern, deren Peripherie durch den Macintosh ersetzt wurde. Sie unterliegen daher anderen Randbedingungen als der hier beschriebene Prozessor. 5.4 Reprasentation der Objekte Die Reprasentation der Objekte wurde als zentrale Implementierungsentscheidung betont. Die Reprasentation der Objekte soll daher vor der Entwicklung von Architektur und Befehlssatz vorgegeben werden. Damit wird gewahrleistet, da der zu entwerfende Prozessor alle hier vorgegebenen Objekte in der hier vorgegebenen ezienten Weise unterstutzt. Architekturen wie jene bei Scheme-79 und Scheme-81 sind damit in dieser fruhen Phase schon als Losungen ausgeschlossen. Die Objekte sollen kompakt reprasentiert und ezient zugegrien werden konnen. Unter den Objekten sind hier die Daten, die Scheme dem Benutzer zur Verfugung stellt, die Bindungsum- 5.4. 41 DER OBJEKTE REPRASENTATION gebungen, die Controlframes und die Interndarstellung der Programme, der Maschinencode des Prozessors (Bytecode), zu verstehen. Es liegen folgende Implementationsentscheidungen zugrunde: Der Hauptspeicher wird als Feld von 32 Bit Worten angesehen. Kleinere Einheiten als 32 Bit Worte werden nie gelesen oder geschrieben und groere Einheiten vom Interpreter in Zugrie von 32 Bit Worten zerlegt. Die Speicherverwaltung kann Blocke beliebig vieler 32 Bit Worte liefern. Sie arbeitet als unterbrechendes Verfahren nach dem Stop-and-Copy Algorithmus [Chen70]. Der Algorithmus arbeitet mit einer geringen Zahl von Hauptspeicherzugrien und kompaktiziert den Speicher, soda Blocke beliebiger Lange zu jeder Zeit angefordert werden konnen. Eine Modikation zu einem inkrementellen Verfahren ist wunschenswert, aber aufgrund der restriktiven Zeitplanung im ersten Prototyp nicht realisiert. Listen werden CDR-kodiert [Hans69] dargestellt. Die Typen der Objekte werden im Pointer dargestellt und damit FIXNUMs und Zeichen als Datum anstelle des Pointers reprasentiert. Vektoren, Strings und der Maschinencode des Scheme-Prozessors werden als Folgen von Speicherworten reprasentiert. Symbole werden durch Zahlen dargestellt, die gleichzeitig als Index in der globalen Bindungsumgebung verwendet werden. Controlframes und Bindungsumgebungen werden soweit wie moglich im Stack alloziert. Nur wenn diese eine langere Lebensdauer als die sie erzeugende Prozedur haben, werden sie in den Heap kopiert. 5.4.1 Das Speicherwort Die Maschinenworte sind 32 Bit breit, wovon 24 Bit fur die Pointer oder fur Zeichen und ganze Zahlen, 6 Bit fur den Typ und 2 Bit fur den CDR-Code genutzt werden. Abbildung 5.3 zeigt den Aufbau eines Maschinenwortes. GC 31 30 Typ 24 Datum oder Pointer 0 Abbildung 5.3: Struktur der Speicherworte des Scheme-Prozessors. Der CDR-Code nimmt die in Tabelle 5.2 angegebenen Werte an. Der CDR-Kode hat nur in Listen die in der Tabelle beschriebene Bedeutung, bei allen anderen Objekten ist dieses Feld undeniert. In der globalen Bindungsumgebung wird der CDR-Code von der Speicherverwaltung verwendet, um nicht mehr referenzierte Symbole zu erkennen und ihre Nummer | falls sie keine globale Bindung haben | wiederzuverwenden. 42 KAPITEL 5. Normal Next Nil Indirekt KONZEPTION EINER NEUEN IMPLEMENTATION Das folgende Speicherwort enthalt den CDR. Dieser Fall ist identisch zu CONSZellen. Der CDR ist eine Liste, dessen erstes Element an der nachsten Adresse liegt. Ein Pointer auf den CDR wird daher nicht mehr reprasentiert. Letztes Element der Liste, der CDR ist NIL. Pointer auf Zelle mit CDR-Code Normal, in der CAR und CDR stehen. Tabelle 5.2: Belegungen der CDR-Codes. Objekttyp NULLT FIXNUM EOFT CHART UNBOUND PAIR SYMBOL BIGNUM FLONUM STRINGT VECTOR CODE VECTOR CLOSURE ENVT CONTROL INPUT PORT OUTPUT PORT GC FORWARD GC PROTECT Datum / Pointer 0 Wert 0 Wert undeniert Pointer Zahl Pointer Pointer Pointer Pointer Pointer Pointer Pointer Pointer hostspezisch hostspezisch Pointer Zahl Bemerkung reprasentiert () und #F End-Of-File Bindungsumgebung Controlframe, Continuation wahrend der GC verwendet Worte bleiben bei der GC unangetastet Tabelle 5.3: Vom Scheme-Prozessor unterstutzte Objekte. 5.4.2 Die Typen der Objekte Der Typ der Objekte wird in 6 Bit kodiert. Damit konnen maximal 64 unterschiedliche Objekttypen implementiert werden. Vom Prototyp des Scheme-Prozessors werden die in Tabelle 5.3 angegebenen Typen unterstutzt. Im Gegensatz zu praktisch allen anderen Implementationen von LISP-Dialekten gibt es fur die leere Liste einen eigenen Typ anstelle einer Darstellung durch der Typ PAIR mit einer fur die leere Liste reservierten Adresse (meistens 0). Dieser eigene Typ fur die leere Liste und die Konstante #F berucksichtigt, da das Pradikat pair? auch Listen von der leeren Liste unterscheiden mu. uft in dieser Implementation wie auch null? einfach den Typ. Die Identitat der leeren pair? pr Liste mit der booleschen Konstante #F erleichtert die Implementierung bedingter Verzweigungen, bei der die leere Liste und #F gleich behandelt werden mussen. 5.4. 43 DER OBJEKTE REPRASENTATION 5.4.3 Darstellung von Bindungsumgebungen Bindungsumgebungen werden in einem kontinuierlichen Speicherbereich dargestellt. Im Gegensatz zur Darstellung als Liste, die in den vorhandenen Scheme-Prozessoren Scheme-79 und Scheme-81 gewahlt wurde, konnen damit alle Argumente einer Prozedur in gleicher Zeit zugegrien werden. Eine Bindungsumgebung in Scheme besteht aus einem Verweis auf die umgebende Bindungsumgebung und den an die Variablen gebundenen Objekten. Im Gegensatz zu LISP mit seiner dynamischen Bindung sind die Namen der Variablen nicht mit zu reprasentieren, da sie in Scheme nicht zur Laufzeit durchsucht werden mussen1 . Abbildung 5.4 zeigt den Aufbau einer Bindungsumgebung fur den Aufruf einer Prozedur von drei Argumenten. - FIXNUM ENVT SYMBOL FIXNUM STRINGT 4 A 2 ange, nur im Heap - L statisch umgebende Bindung "abc" Abbildung 5.4: Bindungsumgebung nach Prozeduraufruf (f 'A 2 "abc"). Auf den i-ten Parameter kann durch Indizieren des Pointers auf die Bindungsumgebung mit 0i 0 1 zugegrien werden. Bindungsumgebungen sind in Stack und Heap fast identisch dargestellt. Im Heap haben sie zusatzlich ein Feld, das ihre Lange angibt und von der Speicherverwaltung verwendet wird. 5.4.4 Darstellung von Controlframes und Continuations Controlframes speichern den Status einer Prozedur, wahrend eine andere Prozedur aufgerufen wird. Controlframes werden immer im Stack angelegt. Nur bei der Erzeugung einer Continuation werden sie in den Heap kopiert. Wahrend eine Funktion ausgefuhrt wird, bendet sich ihr Controlframe immer auf dem Stack. Controlframes werden, wie in Abbildung 5.5 gezeigt, dargestellt. Unterhalb - FIXNUM CONTROL FIXNUM CODE VECTOR ENVT ENVT FIXNUM 5 79 42 L ange, nur im Heap -Controlframe des Aufrufers relativer PC des Aufrufers -Codevector des Aufrufers Bindungsumgebung des Aufrufers --statisch umgebende Bindung Parameter und Tempor arwerte Abbildung 5.5: Aufbau eines Controlframes. des Zeigers auf die Bindungsumgebung benden sich die Parameter bei einem Controlframe im Stack oder deren Continuation und darunter bei allen Controlframes temporare Werte, die auf dem Stack lagen. Bei Controlframes im Heap wird deren Lange fur die Speicherverwaltung abgelegt. 1 F ur Debugzwecke, Fehlermeldungen und fur die (optionalen) Standardprozeduren make-environment und access werden Variablennamen auch in Scheme benotigt. Sie werden in dieser Implementation jedoch nicht in den Bindungsumgebungen, sondern im Codevektor der zugehorigen Prozedur abgelegt. 44 KAPITEL 5. KONZEPTION EINER NEUEN IMPLEMENTATION 5.4.5 Darstellung von Codevektoren Der Maschinencode des Scheme-Prozessors wird in Codevektoren abgelegt. Der Code ist als Bytecode reprasentiert: Jeder Befehl belegt ein Byte und hat eventuell noch weitere Bytes als Argumente. Vier Bytes liegen in ein Maschinenwort gepackt im Speicher. Da damit auch das Typfeld belegt ist, darf dieser Maschinencode bei der Garbage Collection nicht interpretiert werden. Er wird daher durch ein Wort mit dem Typ GC PROTECT und der Anzahl der mit Bytecode belegten Worte gekennzeichnet. Neben dem Maschinencode enthalt ein Codevektor noch die Anzahl der Parameter und den Namen der Prozedur, dessen Code er darstellt, falls die Prozedur ein NAMED-LAMBDA [Rees86] ist. Dieser Name wird fur Fehlermeldungen und fur Debugzwecke verwendet. Fur Debugzwecke kann auch ein Vektor mit den Namen der Parameter und mit dem Quellcode der Prozedur vorhanden sein. Ferner enthalt der Codevektor Literale, die im Code abgelegt sind und der Garbage Collection unterliegen. Abbildung 5.6 zeigt des genauen Aufbau eines Codevektors. Wenn der Eintrag fur die Anzahl der Parameter im Bereich von 0 0 255 liegt, wird FIXNUM FIXNUM FIXNUM SYMBOL STRINGT SYMBOL GC PROTECT 12 7 123 42 8 2 6 F L ange des Vektors Anzahl der Parameter Abstand des Bytecodebereichs Name der Prozedur Literalbereich "abc" WRITE 2 250 19 92 49 Anzahl Worte mit Bytecode Bytecode Abbildung 5.6: Aufbau eines Codevektors. genau diese Parameteranzahl erwartet. Ist die Zahl groer als 255, so hatte die Parameterliste ein sogenanntes Restargument, an die der Rest der Parameter als Liste gebunden wird. Der in Abbildung 5.7 gezeigte Codevektor folgender Prozedur enthalt damit die Parameterzahl 256: (define (list . a) a) FIXNUM FIXNUM FIXNUM SYMBOL GC PROTECT 1 0 5 256 4 LIST 1 20 L ange des Vektors 0 Argumente + Restargument Abstand des Bytecodebereichs Name der Prozedur 1 Wort mit Bytecode PUSHLOCAL 0, RETURN Abbildung 5.7: Codevektor der Prozedur list. 5.5 Diskussion der Randbedingungen fur den Befehlssatz Fur den Entwurf eines Scheme-Prozessors wie jedes anderen Prozessors ist die Festlegung des Befehlssatzes die zentrale Aufgabe. Einerseits mu jedes Scheme-Programm in Folgen von Befehlen aus diesem Befehlssatz u bersetzt werden konnen, wobei diese Ubersetzung schnell durchfuhrbar 5.5. DEN BEFEHLSSATZ DISKUSSION DER RANDBEDINGUNGEN FUR 45 sein mu, weil sie in einer interaktiven Programmierumgebung stattnden soll. Andererseits mu der Befehlssatz von einem Prozessor ezient interpretiert werden konnen, und dieser Prozessor mu zudem als integrierte Schaltung mit den zur Verfugung stehenden Entwurfshilfsmitteln und Fertigungsmoglichkeiten realisierbar sein. Zur Festlegung des Befehlssatzes des Scheme-Prozessors mu seine Architektur bestimmt sein. Damit sind Entscheidungen verbunden wie die zwischen einer register- und einer stackorientieren Architektur. Ferner ist u ber die Anzahl der Register im Prozessor zu entscheiden. Da die Festlegung von Architektur und Befehlssatz fur den Scheme-Prozessor und Angabe der Hardwarestruktur des Scheme-Prozessors Randbedingungen, die durch die Realisierung des Scheme-Prozessors als Chip bestehen, genugen mu, sollen diese Randbedingungen im folgenden Kapitel angegeben werden. Architektur und Befehlssatz werden daran anschlieend in Kapitel 7 beschrieben. Kapitel 6 Entwurf integrierter Schaltungen Dieses Kapitel fuhrt in die Problematik der integrierten Schaltungen ein, stellt allgemein ubliche Entwurfs- und Fertigungsverfahren fur kundenspezische Schaltungen vor, beschreibt den Ablauf eines Entwurfs und beschreibt schlielich die Einschrankungen, unter denen Entwurfe von Hochschulen gefertigt werden konnen. Dieses Kapitel hat in dieser Arbeit die Aufgabe, die Randbedingungen beim Entwurf integrierter Schaltungen, diejenigen durch die hier zu verwendende Standardund Makrozellentechnik und die Randbedingungen durch die Fertigung von Hochschulchips anzugeben, um die Entwurfsentscheidungen bei Architektur und Realisierung des Scheme-Prozessors, die zum Einhalten dieser Randbedingungen getroen wurden, (Bottom-Up-Einusse) begrunden zu konnen. 6.1 Integrierte Schaltungen Die Entwicklung der integrierten Schaltungen nahm eine sehr sturmische Entwicklung. Zu Beginn dieser Entwicklung, Anfang der 60er Jahre, wurden Schaltungen mit wenigen Transistorfunktionen gefertigt. Ende 1989 gehen ICs (Speicherchips) mit uber 4 Millionen Transistorfunktionen in die Serienproduktion. Anfang 1989 wurden schon erste Labormuster von ICs mit uber 16 Millionen Transistorfunktionen vorgestellt. Nach den bisherigen Erfahrungen vervierfacht sich die Anzahl der auf einem Chip fertigbaren Transistorfunktionen alle drei Jahre [Horb86]. Unter integrierten Schaltungen (Integrated Circuits, ICs) werden hier monolithisch integrierte Schaltungen verstanden, bei denen eine Vielzahl von elektronischen Bauteilen gleichzeitig auf einer Siliziumscheibe hergestellt sind. Diese integrierten Schaltungen werden nach der Anzahl der in enthaltenen Transistorfunktionen in die Gruppen SSI, MSI, LSI und VLSI eingeteilt (Tabelle 6.1). Die Tabelle folgt der Einteilung nach [Lage87]. In der Literatur werden auch andere Zuordnungen der Transistorzahlen zu den Begrien vorgenommen. Abkurzung SSI MSI LSI VLSI Name Small Scale Integration Medium Scale Integration Large Scale Integration Very Large Scale Integration Transistorfunktionen < 100 100 { 1000 1000 { 10000 > 10000 Tabelle 6.1: Integrationsgrade integrierter Schaltungen. 6.2. INTEGRIERTE SCHALTUNGEN ENTWURFSVERFAHREN FUR 47 Als LSI- und MSI-Bausteine wurden Standard-ICs wie Gatter, Flipops, Register und ALUBausteine gefertigt, die fur digitale Steuerungen und fur die Computertechnik in groen Stuckzahlen verkauft werden konnten. Ab Anfang der 70er Jahre war es moglich und kostenezient, ICs mit einigen tausend Transistorfunktionen zu fertigen, die einem Funktionsumfang von mehreren Platinen mit SSI und MSI ICs entsprechen. Schaltungen dieser Komplexitat wurden kaum, von Ausnahmen wie etwa SpeicherICs und Taschenrechner-ICs abgesehen, in Stuckzahlen benotigt, die die Entwurfskosten fur ein LSI IC rechtfertigten. Die Halbleiterindustrie loste dieses Stuckzahlproblem durch die Erndung des Mikroprozessors, eines LSI oder VLSI ICs, das in groen Stuckzahlen produziert werden kann, weil es erst beim Kunden durch ein anwendungsspezisches Programm auf eine spezielle Aufgabe zugeschnitten wird. In den 80er Jahren wurde der Entwurf integrierter Schaltungen durch Rechnerunterstutzung soweit erleichtert, da auch fur die Anwender der Entwurf integrierter Schaltungen moglich wurde. Sehr viel Aufwand wurde in die Entwicklung von Design-Software investiert. Beispielsweise stellen die Halbleiterhersteller fertige Funktionsblocke zur Verfugung, die den bisher verwendeten ICs entsprechen, und die Design-Software unterstutzt die graphische Eingabe von Schaltplanen. Da die Anwender durch die Verwendung selbstentworfener ICs die Abmessungen und Verlustleistungen verringern sowie die Zuverlassigkeit und den Schutz gegen Nachbau durch die Konkurrenz steigern konnte, verbreiteten sich die ASICs (Application Specic Integrated Circuits). Es gibt verschiedene Entwurfs- und Fertigungsverfahren, die sich in den mit ihnen realisierbaren Schaltungen und dem Fertigungsaufwand unterscheiden. 6.2 Entwurfsverfahren fur integrierte Schaltungen In den folgenden Abschnitten werden die wichtigsten Entwurfstechniken dargestellt. 6.2.1 Der Full-Custom Entwurf Im Full-Custom Entwurf erstellen die Entwerfer alle Bausteine ihrer Chips, z. B. Gatter, Flipops, Speicher selbst und verbinden sie miteinander. Es werden alle Transistoren manuell erstellt, die daher optimal fur die Gesamtschaltung ausgelegt werden konnen, um Treiberleistung und Platzbedarf zu optimieren. Die Entwerfer konnen die Flache des Chips vollig frei in Transistoren und Verdrahtung einteilen. Da sich der Full-Custom Entwerfer mit Transistoren als unterster Betrachtungsebene beschaftigt, von denen VLSI-Chips u ber 10000 beinhalten, ist diese Entwurfstechnik sehr personalaufwendig und damit teuer. Sie wird nur dort eingesetzt, wo sehr enge Restriktionen fur Chipache oder Verarbeitungsgeschwindigkeit bestehen und die ICs in sehr groen Stuckzahlen gefertigt werden sollen. Die Verikation eines Full-Custom-Chips gestaltet sich schwierig, weil die Primitivelemente dieses Chips Transistoren sind. Es werden Schaltkreisextraktoren eingesetzt, das sind Rechnerprogramme, die aus dem entworfenen Layout eine Transistorschaltung einschlielich der Parameter jedes Transistors extrahieren. Diese Transistorschaltung kann der Entwerfer dann simulieren. Der Simulator mu Dierentialgleichungssysteme losen, um diese Simulation durchzufuhren. Diese extrem rechenzeitintensive Aufgabe kann nur fur Schaltungen bis zu einigen hundert Transistoren gelost werden, wodurch immer nur kleine Teile des entworfenen Chips simulativ veriziert werden konnen. Es sind immer mehrere Fertigungsvorgange einzuplanen, da viele Fehler erst in den Prototypen entdeckt werden. 48 KAPITEL 6. ENTWURF INTEGRIERTER SCHALTUNGEN 6.2.2 Der Semi-Custom Entwurf Die Idee beim Semi-Custom Entwurf ist, dem Entwerfer fertige Bausteine, sog. Zellen, zu liefern, fur die der Hersteller Parameter wie die logische Funktion, das Zeitverhalten und die Treiberfahigkeit der Ausgange angibt. Solche Zellen enthalten von 2 bis zu einigen hundert Transistorfunktionen, und der Hersteller garantiert fur die korrekte Funktion der Zellen. Zellen bei digitalen ICs entsprechen Gattern, Flipops und Registern. Der Entwerfer baut seinen Entwurf aus diesen Zellen auf, wodurch er wesentlich weniger Bausteine verwenden mu. Insbesondere gestaltet sich die Simulation einer Schaltung aus diesen Zellen sehr viel praktikabler als eine Transistorschaltung, weil sie als digitale Schaltung simuliert wird, wodurch problemlos auch komplette VLSI-Chips simulierbar bleiben. Als typische Produktivitat eines in Full-Custom-Technik arbeitenen Entwerfers werden in [Horb86] 300 Gatterfunktionen pro Mannjahr angegeben. Bei Semi-Custom-Entwurfen sei dieser Wert 10 bis 20 mal so hoch. 6.2.2.1 Die Gate-Array-Technik Beim Gate-Array Entwurf werden vorgefertigte integrierte Schaltungen eingesetzt, die schon alle Transistoren enthalten und nur noch durch unterschiedliche Verdrahtung der Transistoren spezialisiert werden. Ein Gate-Array ist fest in Bereiche mit Transistoren und Kanale fester Breite fur Verdrahtung eingeteilt. Die Abbildung 6.1 zeigt ein Gate-Array. Eine Zellbibliothek enthalt die Verdrahtungen fur Transistorbereiche. Auch die Peripheriezellen werden durch Verdrahtung zum Beispiel entweder zu Ein- oder zu Ausgabetreibern spezialisiert. Peripheriezelle hhhhhh PPP PPPP Transistorbereich im Kern Kanal fur Verdrahtung Abbildung 6.1: Schematischer Aufbau eines Gate-Arrays. Die Gate-Array-Technik ist durch die Verwendung vorgefertigter sogenannter Master besonders wirtschaftlich, weil die Master in groen Stuckzahlen identisch gefertigt werden. Nur die Verdrahtung ist fur den jeweiligen Entwurf unterschiedlich aufzudampfen. Damit kann sich ein Groteil der Herstellungskosten auf die Masterfertigung mit groen Stuckzahlen verteilen, und es 6.2. INTEGRIERTE SCHALTUNGEN ENTWURFSVERFAHREN FUR 49 ist im gunstigsten Fall nur eine Maske kundenspezisch zu erstellen. Zudem haben Gate-Arrays wegen des geringen kundenspezischen Aufwands auch die kurzesten Fertigungszeiten von allen hier vorgestellten Entwurfsverfahren. Die Nachteile der Gate-Arrays sind in dem Master mit seinen in Anzahl, Parametern und Anordnung festen Transistoren und den festen Verdrahtungskanalen begrundet: Die Flache kann nicht optimal genutzt werden, und Schaltungen, die als regulare Transistoranordnungen in FullCustom Technik sehr platzsparend realisiert werden konnen, wie PLAs oder Speicher, sind so gut wie unmoglich mit Gate-Arrays zu realisieren. 6.2.2.2 Die Standardzell-Technik Beim Standardzell-Entwurf wird ein Chip aus vom Halbleiterhersteller vorentworfenen Standardzellen zusammengesetzt. Diese Standardzellen haben alle die gleiche Hohe und eine unterschiedliche Breite. Abbildung 6.2 zeigt ein Standardzell-Chip. Die Abbildung zeigt deutlich, da der Peripheriezelle hhhhhh PPPP PPP Zeile aus Standardzellen Kanale fur Verdrahtung Abbildung 6.2: Schematischer Aufbau eines Standardzell-ICs. Entwurf gegenuber einem Gate-Array deutlich exibler ist: Die drei gezeigten Zeilen aus Standardzellen haben alle eine unterschiedliche Breite. Die Breite der Kanale ist variabel und kann dem tatsachlichen Bedarf angepat werden. Ferner sind die Anzahl und Lage der Peripheriezellen auf dem Rand durch den Entwerfer bestimmt. Im Detail wird ein Ausschnitt eines Standardzell-Chips in Abbildung 6.3 gezeigt: Die drei dort gezeigten Standardzellen sind alle gleich hoch und verschieden breit. Die Stromversorgung (Vss und Vdd) wird innerhalb einer Standardzellzeile parallel uber die ganze Zeile gefuhrt. Die Signalanschlusse der Standardzellen benden sich am oberen und am unteren Rand, also am Rand der Verdrahtungskanale. Lucken in den Standardzellen ermoglichen es, Signale durch Standardzellzeilen zu fuhren und damit nicht aneinander angrenzende Kanale zu verbinden. Der Preis fur diese erhohte Flexibilitat des Entwurfs gegenuber dem Gate-Array besteht darin, da keine vorgefertigten Master verwendet werden konnen. Die Fertigung eines StandardzellEntwurfs ist genauso teuer wie die eines Full-Custom-Entwurfs. Das Standardzellen-Verfahren hat seine Grenzen, wenn regulare, groachige Transistoranordnungen wie PLAs oder Speicher benotigt werden, da diese nicht in das Konzept von Zellen fester Hohe passen. 50 KAPITEL 6. ENTWURF INTEGRIERTER SCHALTUNGEN Vdd Vss Vdd 6 Anschlu 6 Raum fur Verdrahtung Abbildung 6.3: Ausschnitt aus einer Standardzellzeile. 6.2.2.3 Die Makrozell-Technik In Makrozell-Entwurfen werden Makros, das sind rechteckige Zellen beliebiger Groe, auf einem Chip verdrahtet. Solche Makros sind entweder fest, z. B. komplette Mikroprozessoren, oder sie werden von Rechnerprogrammen nach Vorgaben des Entwerfers generiert, z. B.: RAMs, nach Vorgabe von Wortbreite und Adreraum. ROMs, nach Vorgabe von Wortbreite, Adreraum und Belegung. PLAs, nach Vorgabe der Schaltfunktionen. Makros konnen zudem in Full-Custom oder Standardzellentechnik entworfen sein. Solche entworfenen Makros werden wie Chips erstellt, mit dem einzigen Unterschied, da die Ein- und Ausgange nicht an Peripheriezellen gefuhrt, sondern auf den Rand eines Rechtecks gelegt werden. Abbildung 6.4 zeigt ein Makrochip, das aus zwei generierten Makros und einem mit Standardzellen entworfenen Makro aufgebaut ist. Der Makrozellenentwurf ist die machtigste Semi-Custom Entwurfsart, da beliebige Rechteckstrukturen moglich sind. Zudem kann eine Mischform zwischen Semi-Custom und Full-Custom gewahlt werden, indem ein besonders zeitkritisches oder platzintensives Schaltungsteil als Makro in Full-Custom entworfen wird. Gegen einen Makroentwurf sprechen, wenn auch ein Gate-Array verwendet werden kann, die Fertigungskosten, die so hoch wie bei Full-Custom Chips sind. Ferner ist der Flachenbedarf von Makrochips gegenuber reinen Standardzellenchips, die auf generierte Makros verzichten konnen, groer, weil durch das Verdrahten der Rechtecke variabler Groe mehr Verdrahtungsache benotigt wird. 6.3. DER ABLAUF EINES SEMI-CUSTOM ENTWURFS 51 Standardzellenblock RAM ROM AA 1 AA 11 AA 11 1 1 1 generierte Makros Abbildung 6.4: Schematischer Aufbau eines Makrozell-ICs. 6.3 Der Ablauf eines Semi-Custom Entwurfs Hier soll der Ablauf eines Semi-Custom Entwurfs dargestellt werden, wie er mit einem zellorienterten Entwurfssystem wie VENUS-S der Siemens AG [Horb86] moglich ist. In Abbildung 6.5 ist dieser Ablauf schematisch dargestellt. In den folgenden Absatzen sollen die Teilschritte in diesem Ablauf beschrieben werden. 6.3.1 Schaltplaneingabe Bei der Schaltplaneingabe plaziert der Entwerfer Schaltsymbole, die Standardzellen entsprechen, am Bildschirm und verdrahtet diese untereinander. Die Schaltplaneingabe dient im Entwurfssystem dazu, die verwendeten Standardzellen und ihre Verbindungen ermitteln zu konnen. Eine textuelle Beschreibung der Schaltung ware alternativ moglich. Die rechnergestutzte graphische Eingabe entspricht jedoch eher den Praferenzen der Zielgruppe dieser Entwurfssysteme. Die graphischen Schaltbilder dienen auch der Dokumentation der entworfenen Schaltung, sofern sie auch geplottet werden konnen1 . Schaltplaneditoren unterstutzen die Partitionierung einer Schaltung. Sie erlauben auch die Benennung von Standardzellen und Leitungen, so da der Entwerfer die Teile der Schaltung in den folgenden Entwurfsschritten wie Simulation und Chipkonstruktion unter den von ihm gewahlten Bezeichnungen ansprechen kann. 1 F ur das Entwurfssystem VENUS-S ermoglicht ein vom Verfasser an der Universitat Hamburg entwickeltes Programm das Plotten der Schaltbilder [Lohs87]. 52 KAPITEL 6. - ENTWURF INTEGRIERTER SCHALTUNGEN ? graphische Schaltungseingabe ? Netzlistenkompilation Fehler ? Logiksimulation Fehler Stimuli Testmuster Stimuli ? Testmustergenerierung Fehlersimulation nicht testbar ? Chipkonstruktion nicht konstruierbar ? Laufzeitextraktion Resimulation Fehler ? Fertigung Abbildung 6.5: Schematischer Ablauf eines Entwurfs mit VENUS. 6.3. DER ABLAUF EINES SEMI-CUSTOM ENTWURFS 53 6.3.2 Netzlistenkompilation Nach der Eingabe einer Schaltung erfolgt eine Netzlistenkompilation, in der die zuvor eingegebene Schaltung eingelesen und auf einfache Entwurfsfehler wie oene Eingange und zusammengeschaltete Ausgange gepruft wird. Wenn keine Fehler festgestellt werden, wird als Ergebnis der Netzlistenkompilation eine Netzliste2 geschrieben. Diese Netzliste beschreibt die Standardzellen und ihre Verbindungen untereinander. Sie enthalt keinerlei Informationen mehr wie die Lage der Bauteile im Schaltplan oder die Aufteilung in Teilschaltplane. Diese Netzliste ist die Schaltungsbeschreibung, auf der alle folgenden Entwurfsprogramme aufsetzen. Zusatzlich zu dieser Netzliste werden bei der Netzlistenkompilation in VENUS-S noch Statistiken uber die verwendeten Standardzellen sowie Abschatzungen der Signallaufzeiten aufgrund der Belastungen der Ausgange durch die Kapazitaten der Eingange erstellt. 6.3.3 Logiksimulation In der Logiksimulation wird die entworfene Schaltung simulativ veriziert. Der Entwerfer erstellt Stimuli, die die an die Schaltungseingange anzulegenden Daten als Funktion der Zeit darstellen, und er kann als Ergebnis seiner Simulation die logischen Pegel an den Ausgangen und beliebigen internen Schaltungspunkten betrachten. Die Logiksimulation berucksichtigt die Verzogerungszeiten der Standardzellen und die vom Netzlistencompiler ermittelten Verzogerungszeiten durch die Belastung der Standardzellausgange. Die durch die Leitungskapazitaten auf dem Chip entstehenden Verzogerungszeiten sind erst nach der Plazierung und Verdrahtung der Standardzellen bekannt; sie konnen daher hier noch nicht berucksichtigt werden. Diese erste Simulation dient dem fruhzeitigen Finden von Entwurfsfehlern. Sie soll verhindern, da die weiteren sehr rechenzeit- und arbeitsintensiven Entwurfsschritte fur eine fehlerhafte Schaltung gemacht werden. Die Logiksimulation kann nicht nur fur ein Gesamtchip, sondern auch fur Teilschaltungen durchgefuhrt werden. Diese Moglichkeit ist besonders wichtig, weil das Aufspuren von Fehlern eine mit der Groe der Schaltung uberproportional steigende Arbeitszeit beansprucht. 6.3.4 Testmustergenerierung oder Fehlersimulation Bei der Fertigung integrierter Schaltungen wird ein bestimmter Prozentsatz der Schaltungen fehlerhaft gefertigt. Um nach der Fertigung die defekten Chips von den korrekten zu unterscheiden, werden die entstandenen Chips einzeln getestet und nur die korrekt arbeitenden Chips in (teure) Gehause eingebaut und dem Kunden geliefert. Der Kunde, der eine integrierte Schaltung entwirft, mu dem Halbleiterhersteller also neben den eigentlichen Fertigungsdaten Testmuster liefern, mit denen nach der Produktion defekte von gelungenen Chips getrennt werden konnen. Fertigungsfehler werden durch angenommene Kurzschlusse eines jeden Knoten in der Schaltung mit logisch 0 und logisch 1 modelliert (stuck-at-Fehlermodell). Dieses ursprunglich fur TTL-Schaltungen entwickelte Fehlermodell ist fur CMOS-Schaltungen, in denen Leitungsunterbrechungen (stuck-open-Fehler) vorkommen, kombinatorische zu sequentiellen Schaltungen machen konnen [Abra86, Will86], zwar nicht optimal; es wird aber von den meisten Designsystemen, wie auch VENUS-S, verwendet. Algorithmen fur die automatische Generierung von Testmustern existieren nur fur kombinatorische Schaltungen. Der Test sequentieller Schaltungen kann auf den kombinatorischer Schaltungen zuruckgefuhrt werden, wenn die Schaltung in einen Testmode gebracht werden kann, in dem alle speichernden Elemente geladen und ausgelesen werden konnen (scan-path-Verfahren). Wenn keine 2 Eine Besonderheit von VENUS-S gegen uber anderen Entwurfssystemen ist, da zwei unterschiedliche Netzlisten fur Simulator (SBS-Datei) und Chipkonstruktion (CALBUS-Datei) generiert werden. Der Grund dafur liegt im Entstehen dieser Teilprogramme in verschiedenen Abteilungen des Konzerns. 54 KAPITEL 6. ENTWURF INTEGRIERTER SCHALTUNGEN rein kombinatorische oder Scan-path-Schaltung entworfen wurde, mu der Entwerfer seine Testmuster manuell erstellen. Ein Fehlersimulator, ein Programm, das die Schaltung mit den Testmustern simuliert, ermittelt die durch die Testmuster noch nicht gefundenen Stuck-at-Fehler sowie die Fehlerabdeckung, das Verhaltnis der mit den Testmuster entdeckten zu allen angenommenen Fehlern. Der Fehlersimulator ist das rechenzeitintensivste Rechnerprogramm innerhalb eines Entwurfsablaufs, und das Erstellen von Testmustern, die eine ausreichende Fehlerabdeckung (>95%) erreichen, erweist sich fur VLSI-Schaltungen sehr haug als unmoglich, wenn die Testbarkeit nicht schon beim Entwurf der Schaltung als Ziel berucksichtigt wurde. 6.3.5 Chipkonstruktion Der Chipkonstruktion fallt die Aufgabe zu, die Netzliste einer Schaltung in eine geometrische Darstellung eines Chips zu transformieren, die als Eingabe fur die Fertigung dient. Die Chipkonstruktion, die versucht, Positionen fur alle Zellen und Leitungen zu nden, die eine minimale Gesamtleitungslange und minimale Chipache ergeben, wird in die Teilschritte Plazierung und Verdrahtung zerlegt. Auch diese beiden Teilprobleme sind ebenso wie das Gesamtproblem NP-vollstandig [Ullm84]. Bei der Plazierung der Standardzellen eines Standardzellchips oder Standardzellblocks innerhalb eines Makrochips werden den Standardzellen auf Zeilen und Positionen innerhalb der Zeilen verteilt, wobei versucht wird, die Gesamtlange der Verdrahtung zu minimieren. Die Plazierungsprogramme enthalten Heuristiken fur die Plazierung und erlauben Plazierungsvorgaben durch den Entwerfer. Die Peripheriezellen werden ebenfalls durch Heuristiken oder manuelle Plazierung auf Positionen am Rand verteilt. In VENUS-S werden die Standardzellen durch eine Heuristik einmal auf die Zeilen verteilt, und der Entwerfer kann die Zellen innerhalb dieser Zeilen permutieren und manuell vertauschen. Fur Makrozellen erfolgt auch eine Plazierung durch eine Heuristik, die dann manuell verbessert werden kann. Die Verdrahtung plazierter Standard- oder Makrozellen wird in zwei Teilschritte zerlegt: Die Verdrahtung beginnt mit der globalen Verdrahtung, bei der fur jede Leitung eine stuckweise Aufteilung in Verdrahtungskanale durch eine Heuristik ermittelt wird, die die Leitungslange kurz zu halten versucht. Anschlieend werden die Leitungsstucke innerhalb der Kanale verdrahtet, wozu der schnelle Kanalverdrahtungsalgorithmus [Ullm84] eingesetzt wird. VENUS-S kann nicht immer alle Leitungen legen. Der Entwerfer mu von den Programmen nicht verdrahtete Leitungen manuell vervollstandigen. Bei dieser interaktiven Nacharbeit ist es auch moglich, automatisch gelegte Leitungen manuell zu verlegen, wenn besonders zeitkritische Signale zu lang geraten sind. Nach Plazierung und Verdrahtung steht eine geometrische Beschreibung des Chips zur Verfugung, aus der zusammen mit der Netzliste die Verzogerungszeiten der Signale durch die kapazitive Belastung durch die Verdrahtung errechnet wird (Laufzeitextraktion). Die Chipkonstruktion wird bei kommerziellen Entwurfen in den meisten Fallen dem Hersteller uberlassen. Die Chipkonstruktion erfordert sehr viel Erfahrung, wenn ein gutes Ergebnis erzielt werden soll. Ein ublicher Entwurfsablauf ist daher, da der Anwender seine Netzliste beim Hersteller abliefert, der Hersteller die Chipkonstruktion durchfuhrt und dem Anwender das Ergebnis der Laufzeitextraktion ubergibt. 6.3.6 Resimulation mit Leitungslaufzeiten Aus der im Rahmen der Chipkonstruktion erfolgen Laufzeitextraktion liegen Verzogerungszeiten fur das Chip vor, die das nach der Fertigung zu erwartende Verhalten gut approximiert. Eine erneute Simulation der Schaltung unter Berucksichtigung dieser Leitungslaufzeiten entscheidet 6.4. FUR HOCHSCHULEN FERTIGUNGSMOGLICHKEITEN 55 daruber, ob das Chip den Spezikationen genugt. Wenn die Simulationsergebnisse den Spezikationen des Entwerfers entsprechen, kann das Chip gefertigt werden. Sollten die Spezikationen nicht eingehalten werden, ist zu entscheiden, ob eine erneute Chipkonstruktion unter Berucksichtigung der in dieser Resimulation aufgedeckten kritischen Pfade erfolgen soll, oder ob die Schaltung zum Beispiel durch Einbau von Treibern fur lange Leitungen modiziert werden soll. 6.4 Fertigungsmoglichkeiten fur Hochschulen Das Entwurfssystem VENUS-S wurde von der Siemens AG an 20 bundesdeutschen Hochschulen installiert. Dazu erhielten die Hochschulen einen Minirechner mit dem Betriebssystem BS2000, der etwa 0,7 MIPS leistet. Auf diesem Rechner laufen die Entwurfsphasen Logiksimulation, Testmustergenerierung, Fehlersimulation, Chipkonstruktion, Laufzeitextraktion und Resimulation ab. Die Schaltplaneingabe und die Netzlistenkompilation erfolgen auf Workstations der Firma Apollo. Die Siemens AG ubernahm die Kosten fur den BS2000-Rechner und die System- und Entwurfssoftware auf diesem Rechner und ermoglicht den Hochschulen den Betrieb des Rechners durch Einraumen reduzierter Wartungskosten fur die Dauer von drei Jahren. Die Hochschulen erhielten von Siemens die Zellbibliotheken fur je zwei Gate-Array- und Standardzell-Prozesse. Fertigungsmoglichkeiten bestehen fur die Hochschulen jedoch nur fur Standardzell- und Makrozellentwurfe mit dem Proze ACMOS3 von Siemens, einem 2 CMOSProze mit zwei Metallebenen fur Verdrahtung. Wenn mit VENUS-S entworfene Chips von Hochschulen fur Forschungszwecke gefertigt werden sollen, u bernimmt das Bundesministerium fur Forschung und Technologie (BMFT) die Fertigungskosten. Diese Finanzierung besteht bis 1992. Zur Verringerung der Fertigungskosten werden je nach Groe zwei bis neun Hochschulchips zusammengefat und als ein groes Chip (Reticle) in die Fertigung gegeben (Shared-ReticleVerfahren). Nach der Fertigung werden diese Reticles zersagt und die Chips in Fassungen montiert. Jede Hochschule erhalt 20 ICs, die sie selbst auf Fertigungsfehler untersuchen mu. Dieses Verfahren fuhrt dazu, da ein von einer Hochschule abgegebenes Chip erst dann gefertigt werden kann, wenn sich alle (bis zu neun!) Entwurfe fur ein Reticle angesammelt haben. Ferner mussen die Entwurfe der Hochschulen ganz bestimmte Abmessungen haben, um zu diesen Reticles kombiniert werden zu konnen. Es sind daher nur Chips mit den vier in Tabelle 6.2 gezeigten Groen erlaubt. Die dort angegebenen maximalen Transistorzahlen sind [Stei88] entnommen. Chipgroe Chips pro Reticle 4,538 mm 2 4,538 mm 9 5,388 mm 2 5,368 mm 6 6,898 mm 2 6,898 mm 4 8,828 mm 2 8,758 mm 2 max. Transistorzahl 8000 19200 24000 36000 Tabelle 6.2: Mogliche Chipgroen fur Hochschulentwurfe. Die Zellbibliothek zum Proze ACMOS3 enthalt Standardzellen, die alle eine Hohe von 134 m haben. Die Breite der Zellen variiert zwischen 24,6 m fur AND-, NAND-, NOR- und OR-Gatter mit zwei Eingangen und 926,6 m fur acht 4:1-Multiplexer in einer einzigen Standardzelle [Siem88]. Die Zellbibliothek bietet Gatter mit 2, 4, 6 und 8 Eingangen, Multiplexer 2:1, 4:1 und 8:1, Inverter und Treiber in drei Treiberstarken sowie Encoder und Decoder. Auch tri-state-Busse sind moglich. Als speichernde Elemente sind Latches, Flipops, Schieberegister und Zahler enthalten. An arithmetischen Elementen werden Komparatoren und Addierer geboten. 56 KAPITEL 6. ENTWURF INTEGRIERTER SCHALTUNGEN Makrozellen konnen, wie in Abbildung 6.4 dargestellt, aus Standardzellenblocken und aus generierten Makros aufgebaut werden. VENUS-S enthalt Makrogeneratoren fur RAMs, ROMs und PLAs. Die generierbaren Makros sind wie folgt eingeschrankt: ROM ROMs konnen mit einer Wortbreite zwischen 1 und 64 sowie mit einer Anzahl von Worten, die eine Zweierpotenz sein mu, zwischen 32 und 16384 generiert werden. Das Produkt aus der Wortbreite und der Anzahl der Worte mu ferner zwischen 128 und 65536 liegen. Das ROM ist intern dynamisch aufgebaut: Es benotigt einen Takt, nach dessen negativer Flanke die Daten am Ausgang anliegen. Wenn der Takteingang logisch 1 ist, ist der Ausgang des ROMs hochohmig. RAM Bei RAMs darf die Wortbreite zwischen 1 und 32 liegen und die Anzahl der Worte zwischen 16 und 16384 betragen. Das Produkt aus Wortbreite und Anzahl der Worte mu zudem zwischen 64 und 16384 liegen. Die generierten RAMs haben genau einen bidirektionalen Port. Der RAM-Generator enthalt in der Version, die an die Hochschulen abgegeben wurde, einen Programmfehler, der ihn immer mit einer Fehlermeldung abbrechen lat. Dieser Fehler kann durch Eingri in Kommandodateien umgangen werden. PLA PLAs konnen fur 2 bis 50 Eingange, 3 bis 50 Ausgange und 2 bis 75 Terme generiert werden. Die an die Hochschulen abgegebene Version des PLA-Generators enthalt jedoch einen Programmfehler, der dazu fuhrt, da mit einer geraden Anzahl von Termen generierte PLAs einen Kurzschlu enthalten. Es konnen daher nur PLAs mit ungerader Termanzahl generiert werden. 6.5 Folgerungen fur den Entwurf des Scheme-Prozessors Die zur Verfugung stehende Technologie von 2 m CMOS mit der maximalen Chipgroe von 77,3 mm2 erlaubt verglichen mit dem Full-Custom-Entwurf Scheme-81, dessen Flache 85 mm2 bei 2 m NMOS betragt, nur ein weniger komplexes Chip, da CMOS fur die gleiche Funktion mehr Transistoren als NMOS erfordert, die zur Verfugung stehende Flache kleiner ist und durch die Beschrankung auf Standardzelltechnik diese Flache auch nicht optimal genutzt werden kann. Im Jahre 1990 lauft der Wartungsvertrag zu erschwinglichen Bedingungen fur den BS2000Rechner an der Universitat Hamburg aus. Danach muten jahrlich 120000 DM dafur aufgebracht werden. Es kann nicht davon ausgegangen werden, da das erste gefertigte Chip voll funktionsfahig ist, weil die Funktion der Schaltung innerhalb des Designprozesses nur simulativ uberpruft werden kann. Mit Simulation kann man nur die Anwesenheit von Fehlern zeigen, nicht aber deren Abwesenheit. Nach aller Erfahrung, auch der mit Scheme-79 und Scheme-81, werden beim Entwurf Fehler gemacht, die erst nach Prototypfertigungen aufgedeckt werden. Die Dauer von der Abgabe des letzten Entwurfs fur ein Reticle bis zum Erhalt der gefertigten Chips betragt nach den bisherigen Erfahrungen 6 bis 8 Monate. Fur den Scheme-Prozessor folgt, da er schnell bis zum ersten Prototyp zu entwerfen war, damit der Fertigungstermin im April 1989 wahrgenommen werden konnte. Wenn man von einem fehlerhaften Prototypen ausgeht, ist dann noch eine Modikation und eine erneute Fertigung Ende 1989 oder Anfang 1990 moglich. Die Arbeiten an diesem Projekt wurden im Mai 1989 aufgenommen. Daher standen von der Erstellung einer Scheme-Implementation bis zur Abgabe eines fertig realisierten Chips nur elf Monate zur Verfugung. Kapitel 7 Festlegung von Architektur und Befehlssatz In den Kapiteln zuvor wurde beschrieben, da ein Prozessor zu entwerfen war, der einen Schemespezischen Bytecode ausfuhrt. Die begrenzte Chipgroe, die Moglichkeiten und Grenzen eines Standardzellentwurfs und die restriktive Zeitplanung wurden erlautert. In diesen Kapitel sollen die gefundenen Losungen und die Grunde fur die Wahl dieser Losungen dargelegt werden. Die Reprasentationen der Objekte und die Speicherverwaltung werden hauptsachlich von der Programmiersprache Scheme bestimmt, sie werden unabhangig vom Befehlssatzes festgelegt und so gewahlt, da alle Objekte (Daten, Bindungsumgebungen und Controlframes) kompakt reprasentiert und ezient zugegrien werden konnen. Die Reprasentation der Objekte wurde in Kapitel 5.4 beschrieben. 7.1 Register- oder Stackarchitektur Eine Registerarchitektur verwendet einen Maschinenbefehlssatz, in dem die Befehle Operationen mit Quellen und Resultaten in Registern bezeichnen. Bei einer Stackarchitektur sind die Quellen der Operationen immer auf dem Stack, und auch das Resultat wird auf dem Stack abgelegt. Die Wahl einer registerorientierten Architektur fur Scheme wird von den Autoren von PC Scheme favorisiert, die einen registerorientierten Befehlssatz fur 64 Universalregister ihrer virtuellen Maschine zugrunde gelegt haben [BaJe86]. PC Scheme ubergibt alle Parameter bei Aufruf einer Funktion in diesen Registern. Die relativ groe Geschwindigkeit des Compilers verdankt PC Scheme nach [BaJe86] besonders der Tatsache, da wegen dieser groen Zahl von Registern keine rechenzeitintensive Berechnung der optimalen Nutzung einer kleinen Zahl von Registern erfolgen mu. Auch ein RISC-Prozessor fur Smalltalk wurde von Ungar [Pend86] in Berkeley als Full-Custom-Chip mit 72 Universalregistern entworfen. Der in dieser Arbeit beschriebene Scheme-Prozessor implementiert eine Stackarchitektur. Die Grunde fur diese Entscheidung liegen in Beschrankungen des Entwurfssystems VENUS-S, das nur eine sehr geringe Anzahl von Registern zulat. Diese Problematik wird im folgenden erlautert. 7.1.1 Register mit VENUS-S Die Entscheidung, ob ein mit VENUS-S entworfener Prozessor viele Register enthalten kann, mu berucksichtigen, da es zwei Moglichkeiten zur Realisierung von Registern gibt: Es kann mit 58 KAPITEL 7. FESTLEGUNG VON ARCHITEKTUR UND BEFEHLSSATZ dem RAM-Generator eine Registerbank als RAM erzeugt werden, und es lassen sich Register aus Standardzellen aufbauen. Ein mit VENUS-S generiertes RAM hat den gravierenden Nachteil, da es nur einen Port hat: Es kann zum gleichen Zeitpunkt nur unter genau einer Adresse entweder gelesen oder geschrieben werden. Ein Rechner mit Universalregistern hingegen mu aus zwei beliebigen Registern Operanden holen, diese verknupfen und in ein drittes beliebiges Register schreiben. Fur eine solche Operation werden Registerbanke mit zwei oder drei Ports eingesetzt, damit mindestens die beiden Operanden gleichzeitig zur Verknupfung zur Verfugung stehen konnen. Mit dem Ein-Port-RAM von VENUS-S mute eine solche Operation sequentiell mit drei RAM-Zugrien erfolgen. Ob eine solche Losung gewahlt werden kann, hangt von der Zykluszeit des RAMs und seinem Platzbedarf ab. Die von VENUS-S generierten RAMs erwiesen sich als zu langsam und auch zu gro. Die Verwendung mehrerer RAMs, in denen unterschiedliche Register, abhangig von den Operationen zwischen den Registern, allokiert werden, erwies sich aufgrund der restriktiven Chipgroe nicht als gangbarer Losungsweg. Jedes RAM ist ein Makro, das bei der Chipkonstruktion durch zusatzliche Kanale zu viel Flache belegt. Aus Standardzellen zusammengesetzte Register haben den Nachteil, da sie wesentlich mehr Flache belegen als ein generiertes RAM, sie haben aber den Vorteil, da sich wegen des manuellen Erstellens beliebige Register erstellen lassen. Abschatzungen aus der Flache der Standardzellen und Verdrahtungsache ergeben, da eine Registerbank mit zwei Leseports und einem Schreibport aus Standardzellen bis zu etwa 12 bis 15 Registern realisierbar ist und auch die Geschwindigkeit in der Groenordnung eines einzigen RAM-Zugris liegt. 7.1.2 Wahl einer Stackarchitektur Da die Registerbank aus Standardzellen zusammengesetzt sein mu und nur maximal 15 Register zur Verfugung stehen werden, gilt es, zu entscheiden, ob Universalregistern oder Stack der Vorzug gegeben werden soll. Es ist zu beachten, da nicht alle 12 bis 15 Register als Universalregister verwendbar sind, weil neben den Universalregistern auch noch Register unabhangig von der gewahlten Architektur fur Programmzahler, Stackzeiger, Zeiger auf Ende des Stacks, Environmentzeiger, Zeiger auf den Codevektor, Zeiger auf globale Bindungen, Register fur Adresse und Datum bei Hauptspeicherzugrien sowie Register fur die Speicherverwaltung vorzusehen sind. Alle diese Register werden so haug verwendet, da eine Auslagerung in den Hauptspeicher nicht sinnvoll ist. Wegen der viel zu geringen Zahl von verbleibenden moglichen Universalregistern wurde eine Stackarchitektur gewahlt. Eine Stackarchitektur kommt mit einer relativ geringen Anzahl von Registern aus. Ein weiterer Vorteil einer Stackarchitektur ist, da ein Compiler, der stackorientierten Code erzeugt, einfacher zu erstellen und zu warten ist als einer, der registerorientierten Code erzeugt. Diese Vereinfachung des Compilers war bei der LISP-Maschine Symbolics 3600 das entscheidende Argument fur die Wahl einer Stackarchitektur [Moon85]. 7.2 Denition und Implementation eines Befehlssatzes Ein stackorientierter Befehlssatz mu aus Grunden der Realisierbarkeit mit VENUS-S gewahlt werden. Es verbleibt noch die Festlegung aller Befehle, die der Befehlssatz enthalten soll. Zuvor sollen aber die Register fur den stackorientierten Befehlssatz angegeben werden. 7.2. DEFINITION UND IMPLEMENTATION EINES BEFEHLSSATZES 59 7.2.1 Die Prozessorregister Die Register des Scheme-Prozessors sind in der Tabelle 7.1 zusammengestellt. Im folgenden werden sie genau einzeln erklart. Die Breite eines Registers (1, 4, 24 oder 32 Bit) hangt von der Verwendung des jeweiligen Registers ab. Das Flag tos valid ist nur ein Bit breit, die Zeiger sind 24 Bit breit, und Register, die wie mdr oder tos ein ganzes Wort aufnehmen, belegen die volle Breite von 32 Bit. 7.2.1.1 Der Stack Der Stack wird uber einen Stackzeiger sp zugegrien. Der Stackzeiger ist ein Register, das auf das erste belegte Wort im Stack zeigt. Der Stack ist ein kontinuierlicher Speicherbereich, in dem alle Parameter bei Funktionsaufrufen ubergeben sowie alle Controlframes und Bindungsumgebungen angelegt werden. Controlframes und Bindungsumgebungen werden bei Bedarf in den Heap kopiert. Der Stackbereich unterliegt nicht der Speicherverwaltung. Bei der Garbage Collection werden lediglich Referenzen aus dem Stack in den Heap auf neue Adressen abgeandert. Fur die Garbage Collection und zum Kopieren einer Continuation in den Heap mu auch die Anfangsadresse des Stacks bekannt sein, sie ist wegen des relativ seltenen Zugris kein Prozessorregister, sondern liegt im Hauptspeicher. Der Bytecode des Scheme-Prozessors ist stackorientiert; alle Befehle beziehen sich auf das oberste Objekt auf dem Stack. Um Hauptspeicherzugrie zu sparen, wird das oberste Objekt auf dem Stack daher in einem Register, dem Register tos, gespeichert. Ein weiteres Register | tos valid | gibt an, ob das oberste Stackobjekt im Register tos steht oder ob es sich im Hauptspeicher bendet. 7.2.1.2 Die Environmentzeiger Der Prozessor halt die Adressen der globalen Bindungsumgebung im Register glo. Sein Register env enthalt immer die Adresse der Bindungsumgebung der gerade ausgef uhrten Funktion. 7.2.1.3 Der Controlframezeiger Der Controlframezeiger ctrl zeigt immer auf den aktuellen Controlframe. Der aktuelle Controlframe bendet sind immer im Stack und ist der Controlframe, der bei dem nachsten Funktionsaufruf oder der nachsten Ruckkehr von einer Funktion verwendet wird. 7.2.1.4 Der Funktionszeiger Der Funktionszeiger func zeigt immer auf den Codevektor der Funktion, die gerade ausgefuhrt wird. Er wird indiziert, um Literale aus dem Codevektor auf den Stack zu laden. Func wird bei Aufrufen anderer Funktionen im Controlframe gespeichert, da Codevektoren bei der Garbage Collection verschoben werden. 7.2.1.5 Der Programmzahler Der Programmzahler pc zeigt auf den nachsten auszufuhrenden Bytecodebefehl in den Codevektor der ausgefuhrten Funktion. Die beiden niedrigwertigsten Bits geben das Byte an, die restlichen Bits die Adresse des Wortes, das den Bytebefehl, und noch drei weitere, enthalt. Wenn der pc in einem Controlframe gesichert wird, steht in den hochstwertigsten 22 Bits nicht die absolute Adresse, sondern die Adresse relativ zum Codevektor. Nur diese relative Adresse bleibt bei Garbage Collections unverandert. 60 KAPITEL 7. FESTLEGUNG VON ARCHITEKTUR UND BEFEHLSSATZ Register Breite mdr 32 bit mar 24 bit tos 32 bit tos valid 1 bit sp 24 bit env 24 bit glo 24 bit ctrl 24 bit func 24 bit pc 24 bit instr cache 32 bit instr addr 24 bit free 24 bit mem end 24 bit csr 4 bit | 32 bit | 24 bit Erlauterung Memory Data Register Memory Address Register Top Of Stack Top Of Stack Flag Stackzeiger Environmentzeiger Zeiger auf globales Environment Zeiger auf Controlframe Zeiger auf Codevektor Zeiger auf Maschinenbefehl 4 Bytes Code Adresse des Codes in instr cache Zeiger auf Freispeicherbereich zur Prufung auf Freispeicheruberlauf Control and Status Register 2 Temporarregister 3 Temporarregister Tabelle 7.1: Die Register des Scheme-Prozessors. 7.2.1.6 Die Register der Speicherverwaltung Die Speicherverwaltung verwendet die Register free und mem end. Das Register free zeigt auf den Anfang des zu vergebenden Speicherbereichs. Bei einer Speicheranforderung wird free als Adresse des vergebenen Speichers zuruckgegeben und anschlieend um die Anzahl der angeforderten Speicherworte erhoht. Wenn nicht genug freier Speicher vorhanden ist | das ist daran erkennbar, da free nach dieser Erhohung groer als mem end ist | erfolgt eine Garbage Collection. Fur die Garbage Collection werden Daten wie Groe und Adressen der Speicherbereiche benotigt, die im Hauptspeicher abgelegt sind. 7.2.1.7 Die Register fur Speicherzugrie Ein Speicherzugri erfolgt immer zwischen dem Hauptspeicher und dem Register mdr. Das Register mar enthalt dabei die Hauptspeicheradresse. 7.2.1.8 Der Instructioncache Der Prozessor liest seinen Maschinencode in Worten von 32 Bits. Da der Maschinencode byteorientiert ist, werden mit jedem Hauptspeicherzugri vier Befehle und Operandenbytes gelesen. Um die Anzahl der Hauptspeicherzugrie moglichst gering zu halten, wird ein Wort im Register instr cache gespeichert. Das Register instr addr enthalt die Hauptspeicheradresse, von der instr cache gelesen wurde. Vor einem erneuten Lesen eines Wortes mit Bytecode wird instr addr mit der Adresse, unter der gelesen werden soll, verglichen und das Lesen bei Gleichheit der Adressen nicht ausgefuhrt. 7.2. 61 DEFINITION UND IMPLEMENTATION EINES BEFEHLSSATZES 7.2.1.9 Weitere Register Neben den oben beschriebenen Registern enthalt der Prozessor noch temporare Register, die wahrend der Garbage Collection und wahrend des Abarbeitens eines Maschinenbefehls benotigt werden. Temporare Register sind eingefuhrt, um wahrend des Abarbeitens eines Maschinenbefehls auf das Auslagern und spatere Restaurieren von Registerinhalten in den Hauptspeicher verzichten zu konnen. Ferner enthalt der Prozessor das Register csr, das zum Auslosen eines Hauptspeicherzugris oder Hostprozessorinterrupts sowie zur Abfrage, ob ein Hauptspeicherzugri beendet wurde, eingesetzt wird. 7.2.1.10 Verwendung der Register Die Abbildung 7.1 zeigt die Verwendung der wichtigsten Register nach einem Aufruf einer Funktion f mit drei Parametern, die ihre Bindungsumgebung auf dem Stack halt. Ferner wird die Verschachtelung der Bindungsumgebung in den Controlframe deutlich. Es ist auch erkennbar, da nur das Register pc auf ein Byte zeigt, wahrend alle anderen Register auf ein Wort zeigen. Prozessorregister func pc ctrl env sp - Codevektor einer Funktion f FIXNUM FIXNUM FIXNUM SYMBOL GC PROTECT 1 0 1 2 176 1 34 34 - Stack 1 176 34 20 8 3 4 F 4 1 0 34 Controlframe ctrl des Aufrufers CONTROL (relativer) pc des Aufrufers FIXNUM func des Aufrufers CODE VECTOR env des Aufrufers ENVT statisch umgebende Bindung ENVT 1. Parameter FIXNUM 2. Parameter FIXNUM 3. Parameter FIXNUM 6 6 ?? Bindungsumgebung (Environmentframe) Abbildung 7.1: Die Register nach Aufruf einer Funktion mit drei Parametern. 62 KAPITEL 7. FESTLEGUNG VON ARCHITEKTUR UND BEFEHLSSATZ 7.2.2 Wahl der Befehle Der stackorienterte Befehlssatz fur den Scheme-Prozessor mu bestimmte Befehle aufweisen, die fur das Abarbeiten von Scheme-Programmen unverzichtbar sind. Dazu zahlen folgende Befehlsklassen: Befehle, die die Bindungen von Parametern auf den Stack laden und Befehle, die die Bindung von Parametern durch ein Datum vom Stack ersetzen. Diese Befehle entsprechen dem Lesen und Schreiben von Variableninhalten in imperativen Programmiersprachen. Befehle zum Aufrufen von Closures. Der Aufruf bei Endrekursion mu dabei anders als ein Aufruf innerhalb einer Sequenz von Ausdrucken behandelt werden. Bedingte Sprungbefehle, um die Sprachkonstrukte if und cond ubersetzen zu konnen. Befehle, um eine Closure zu erzeugen. Ein solcher Befehl mu einen Codevektor mit der Bindungsumgebung der gerade ausgefuhrten Funktion zu einem neuen Objekt vom Typ Closure zusammenfassen. Der Befehl wird zur Implementierung eines -Ausdrucks benotigt. Befehle, um Standardprozeduren zu implementieren. Dazu gehoren beispielsweise die Prozeduren cons, car und cdr ebenso wie Vektorprozeduren, arithmetische Prozeduren, String-, Char- sowie Ein-/Ausgabeprozeduren. Eine wichtige Entscheidung war, wie komplex die einzelnen Befehle des Scheme-Prozessors sein sollen. Einerseits konnte fur jede Standardprozedur ein Befehl vorgesehen sein, ein anderes Extrem waren einige wenige, relativ primitive Befehle. Aus Folgen dieser primitiven Befehle waren alle benotigten Standardprozeduren zusammenzusetzen. Eine Entscheidung zwischen diesen Moglichkeiten ist die Entscheidung zwischen CISC (Complex Instruction Set Computer) und RISC (Reduced Instruction Set Computer) [Patt85]. In Pattersons Beitrag u ber RISC in den "Communications of the ACM\ [Patt85] werden folgende Grunde fur RISC-Prozessoren genannt: Von den Befehlen und Adressierungsarten eines CISC-Prozessors werden relativ wenige sehr haug genutzt. Eine Optimierung des Prozessors auf diese wenigen Befehle erlaubt eine wesentlich schnellere Ausfuhrung dieser Befehle. Die entfallenen Befehle sind dann als Unterprogramme zu realisieren. Die schnellere Ausfuhrung einiger weniger Befehle wird durch ein festverdrahteten Steuerwerks anstelle eines mikroprogrammierten, durch ein festes Instruktionsformat sowie durch die Verringerung der Speicherzugriszeiten durch einen Cache erreicht. Eine Befehlspipeline bewirkt in RISC- und CISC-Prozessoren eine parallele Abarbeitung der Phasen Befehl holen, Befehl dekodieren, Operanden holen, Operation ausfuhren und Ergebnis speichern. Mehrere Befehle werden gleichzeitig in dieser Pipeline abgearbeitet, so da jede dieser Phasen gleichzeitig fur unterschiedliche Befehle erfolgt. Pipelining erlaubt eine Performanzsteigerung durch die bestmogliche Ausnutzung der vorhandenen Hardwareresourcen. Jedoch mu ein Prozessor verschiedene Konktfalle erkennen und behandeln konnen: Nach einem Sprungbefehl durfen keine Befehle in der Pipeline ausgefuhrt werden, bevor die Sprungadresse errechnet und damit bekannt ist, woher weitere Befehle zu holen sind. Ferner mussen Datenabhangigkeiten zwischen den Befehlen in der Pipeline berucksichtigt werden. In dem Beispiel R0 := R1 + R2; R4 := R0 - R7; 7.2. DEFINITION UND IMPLEMENTATION EINES BEFEHLSSATZES 63 darf die Rechnung R0 0 R7 entweder erst nach Abschlu der Berechnung von R0 begonnen werden, oder der Prozessor erkennt den Konikt und holt den Operanden statt aus R0 dorther (aus einem Temporarregister, ALU-Ausgangsregister oder Pipelineregister), wo das Ergebnis der Addition R1 + R2 steht. In RISC-Prozessoren wird die Erkennung und Behandlung von diesen Koniktfallen den Hochsprachencompilern uberlassen1 . Der Befehl nach einem Sprungbefehl wird immer aufgefuhrt, und der Compiler hat die Aufgabe, dort notfalls einen wirkungslosen Befehl (NOOP) einzusetzen. In der u berwiegenden Anzahl der Falle kann der Compiler durch Umgruppierung von Instruktionen auch die Befehle nach Sprungen und bei Datenabhangigkeiten nutzen. Der Prozessor kann fur eine nie zu unterbrechenden Pipeline ausgelegt und dabei eine kurzere Taktzykluszeit erzielt werden. RISC-Prozessoren gehen davon aus, da die Maschinenprogramme heutiger Rechner in virtuellem Speicher liegen. Die Lange der Programme ist daher kein zu minimierender Parameter mehr. RISC-Prozessoren verwenden einen registerorientierten Befehlssatz, bei dem alle Operationen Register als Operanden haben und es LOAD- und STORE-Befehle zum Transfer der Registerinhalte vom und zum Hauptspeicher gibt. Die Registertransfers werden vom Compiler minimiert. Der Nachteil dieser stark genutzten Register besteht darin, da die Registerinhalte bei Prozeduraufrufen zu retten sind. Dazu gibt es Hardware- und Softwarelosungen: Die RISC-Prozessoren aus Berkeley verwenden einen Fenstermechanismus, bei dem der Prozessor mehrere Registersatze enthalt, von denen bei Prozeduraufrufen ein Fenster auf einen neuen Registersatz verschoben wird [ChHe87, Milu87, SiMi87]. Diese Fenster uberlappen sich, damit Parameter in Registern ubergeben werden konnen. Solange die Verschachtelungstiefe der Prozeduren die Anzahl der Registerfenster nicht u berschreitet, sind daher keine Registerinhalte in den Hauptspeicher zu retten. Softwarelosungen reduzieren Prozeduraufrufe, indem der Compiler globale Registeroptimierungen vornimmt oder (wo das sinnvoll ist) aufzurufende Prozeduren an der Aufrufstelle in den Code einkopiert (Inline-Expansion). Eine Verlagerung von haug vorkommenden Maschinenbefehlsfolgen in ein Mikroprogramm wird von RISC-Befurwortern abgelehnt, weil fast jeder Befehl eines RISC-Rechners in einem Taktzyklus und damit genauso schnell wie eine Mikroinstruktion eines mikroprogrammierten Rechners ausgefuhrt wird. Ein Zeitunterschied des Faktors 10 zwischen einer Mikroinstruktion und einem Hauptspeicherzugri besteht bei RISC-Prozessoren nicht mehr, da der Hauptspeicher aus Halbleiterspeichern statt Kernspeicher aufgebaut ist, die weitaus meisten Operanden in Registern stehen und die meisten Befehle im Cache angetroen werden. Fur den Scheme-Prozessor wurde eine Realisierung als CISC-Prozessor gewahlt. Viele der fur RISC sprechenden Grunde sind hier nicht stichhaltig. Die Hauptgrunde dafur liegen im geforderten Einsatz des Prozessors in einen 68000-Rechner und in den Randbedingungen durch das Entwurfssystem. Da ein RISC-Befehlssatz fur Scheme allgemein nicht sinnvoll ist, sollte daraus nicht geschlossen werden. Ein Hauptspeicherzugri des Scheme-Prozessors besteht im Lesen oder Schreiben eines Wortes von 32 Bit. Der Hostrechner kann nur 16 Bit breite Daten vom oder zum Hauptspeicher transferieren. Daher mu der Scheme-Prozessor fur jeden Speicherzugri zwei Hostspeicherzugrie ausfuhren. Ferner mu er noch die Berechtigung anfordern, auf den Speicher zugreifen zu 1 Praktisch alle RISC-Prozessoren f uhren noch Befehle nach Branchinstruktionen aus. Es gibt aber sowohl RISCProzessoren, die Datenabhangigkeiten in der Pipeline behandeln (IBM 801, Berkeley RISC I und II) als auch solche, die diese Aufgabe dem Compiler uberlassen (Stanford MIPS) [ChHe87, Milu87, SiMi87]. 64 KAPITEL 7. FESTLEGUNG VON ARCHITEKTUR UND BEFEHLSSATZ durfen. Insgesamt dauert ein Hauptspeicherzugri des Koprozessors etwa eine Mikrosekunde. Eine Taktfrequenz von etwa 10 MHz wird beim Prozessorentwurf angestrebt, so da ein Hauptspeicherzugri mindestens 10 Taktzyklen beansprucht. Die in RISC-Prozessoren angewandten Techniken zur Reduktion von Hauptspeicherzugrien | groe Registerbanke fur die Daten und Cache fur die Instruktionen | sind beim Scheme-Prozessor nicht anwendbar. Die Anzahl der moglichen Register ist durch die Moglichkeiten des Entwurfssystems sehr beschrankt, wie am Anfang dieses Kapitels dargestellt ist. Zudem ist die Lange eines Bytecodeprogramms im Gegensatz zu den Programmen von RISCProzessoren sehr kritisch. Es mu kompakt sein, weil der Mikrorechner keinen virtuellen und nur einen sehr begrenzten Speicher hat. Auch bei der Garbage Collection sind jeweils alle Codevektoren umzukopieren. Kompakter Bytecode beschleunigt also auch die Garbage Collection. Daher wird ein Befehlssatz gewahlt, der aus vielen, sehr machtigen Befehlen besteht. Da die sehr langsamen Speicherzugrie bevorzugt zu minimieren sind, werden damit nur relativ selten Befehle geholt. Der Prozessor wird mikroprogrammiert realisiert, und es werden so viele Primitivfunktionen wie moglich in das Mikroprogramm verlagert. Die beim Scheme-Prozessor im Mikroprogramm realisierten Standardprozeduren sind in Tabelle 7.2 gezeigt. Listenfunktionen cons car cdr set-car! set-cdr! list Numerische Funktionen 01+ 1+ + 0 Vektorfunktionen make-vector vector-set! vector-ref vector-length vector make-codevector codevector-set! * / quotient remainder = < <= > >= negative? zero? Stringfunktionen make-string string-length? string-ref string-set! Sonstige Funktionen eq? not unbound? call-with-current-continuation Typpradikate null? pair? number? symbol? char? vector? string? input-port? output-port? eof-object? procedure? continuation? Charfunktionen char=? char<? char<=? char>? char>=? char!integer integer!char Tabelle 7.2: Im Mikroprogramm realisierte Standardprozeduren. 7.3. FUR LISP-DIALEKTE BEFEHLSSATZE LITERATUR UBER 65 7.3 Literatur uber Befehlssatze fur LISP-Dialekte Einige Befehlssatze fur LISP-Dialekte sind veroentlicht: Deutsch [Deut80] implementierte einen stackorientierten Befehlssatz fur Interlisp [Teit74] auf einem mikroprogrammierbaren Minirechner. Deutsch beschreibt sowohl seinen Befehlssatz in [Deut80] als auch die statische und relative Haugkeit der ausgefuhren Befehle. Zudem haben Masinter und Deutsch lokale Optimierungen ihres Compilers, der den Bytecode erzeugt, beschrieben [MaDe80]. Wholey und Fahlman implementierten einen stackorientierten Befehlssatz fur Common Lisp [Stee84] auf einem mikroprogrammierbaren Mikrorechner [WhFa84]. Sie erweiterten ihren Befehlssatz spater allerdings um registerorientierte Befehle [WhFa84]. 7.3.1 Der Befehlsatz von Schooler und Stamos Die einzige detaillierte Beschreibung eines stackorientierten Bytebefehlssatzes fur Scheme stammt von Schooler und Stamos [ScSt84]. Ihr "Vorschlag fur eine Implementierung\ hat eine Implementierung mit einem Bytecodeinterpreter auf einem Apple Macintosh zum Ziel, die allerdings nie vollendet wurde [BaJe86]. Schooler und Stamos legen eine Maschine zugrunde, die Register fur den Programmzahler, einen Zeiger auf die Bindungsumgebung, einen Zeiger auf den Literalbereich der gerade ausgefuhrten Prozedur und einen Stackzeiger hat. Sie legen alle Controlframes im Stack an und unterstutzen Bindungsumgebungen in Stack und Heap. Die Ubernahme der Implementation von Schooler und Stamos kommt aus den folgenden Grunden nicht in Betracht: Continuations konnen damit nicht implementiert werden, da alle Controlframes auf dem Stack alloziert werden. Continuations konnen uber die Ruckkehr einer Prozedur hinaus lebendig sein und mussen deshalb im Heap alloziert werden. Um alle noch zugreifbaren Objekte bei der Garbage Collection ermitteln zu konnen, mussen weitere Register vorgesehen sein. Zum Beispiel ist nur aus dem PC, der in einen Bereich von Bytecode zeigt, nicht der Anfang und die Lange des Bytecodebereichs zu ermitteln. Die dort vorgeschlagenen Befehle GetWord und SetWord sollen car und cdr sowie Referenzen auf Vektorelemente implementieren. Dieses Vorgehen lat die erforderlichen Typprufungen auer acht. Die hier beschriebene Implementation unterstutzt Controlframes im Heap, wodurch die Befehle zum Aufruf und zur Ruckkehr von Prozeduren komplizierter werden: Eine Continuation ist wie eine Prozedur ein Objekt erster Klasse, erst zur Laufzeit mussen die Objekte unterschiedlich behandelt werden. Denn der Compiler kann im allgemeinen Fall nicht entscheiden, ob eine Continuation oder eine Closure an einen bestimmten Bezeichner zur Laufzeit gebunden sein wird. Das Register func erlaubt der Garbage Collection, in der Ausfuhrung oder in Continuations bendliche Codevektoren zu ermitteln. Ferner enthalten alle Objekte variabler Lange (Bindungsumgebungen, Controlframes, Vektoren, Strings, : : : ) eine Kennzeichnung ihrer Lange, wenn sie im Heap alloziert sind. Es sind alle noch zugreifbaren Objekte ermittelbar. Car und cdr werden wie Vektorreferenzen durch mikroprogrammierte Standardprozeduren implementiert, die alle Typprufungen vornehmen. Das Register ctrl vereinfacht den Aufruf und das Verlassen von Prozeduren. Beispielsweise brauchen hier die Befehle zum Aufruf die Anzahl der Parameter der aufgerufenen Prozedur im Gegensatz zu Schooler und Stamos [ScSt84] nicht mehr als Argument ubergeben, die Anzahl der Parameter ergibt sich aus ctrl und sp. Es sind auch keine unterschiedlichen Befehle zur Ruckkehr 66 KAPITEL 7. FESTLEGUNG VON ARCHITEKTUR UND BEFEHLSSATZ von einer Prozedur notig, die sich darin unterscheiden, ob die Prozedur ihre Bindungsumgebung auf dem Stack oder im Heap alloziert hatte. 7.4 Der Befehlssatz des Scheme-Prozessors Die grundlegenden Uberlegungen bei der Festlegung des Befehlssatzes fur den Scheme-Prozessor werden auf den folgenden Seiten angegeben. Der vollstandige Befehlssatz ist tabellarisch im Anhang A dargestellt. 7.4.1 Zugri auf Variable und Konstante Der Zugri auf Variablen erfolgt fur lokale Variablen, globale Variablen und Variablen auf dazwischenliegenden Ebenen durch unterschiedliche Befehle. Der Befehlssatz unterstutzt 16 Ebenen zwischen den lokalen und globalen Variablen. Jede Stackarchitektur benotigt Befehle, die Konstante auf den Stack bringen. Umfangreiche Untersuchungen ergaben, da die in Scheme am haugsten benotigten Konstanten die leere Liste, kleine Integerzahlen und die Boole'schen Konstanten sind. Daher werden in dem hier implementierten Befehlssatz diese haug benotigten Konstanten nicht im Literalbereich des Codevektors abgelegt, sondern durch eigene Befehle auf den Stack gebracht. 7.4.2 Sprungbefehle und Verzweigungen Die Sprungbefehle enthalten eine 12 Bit breite relative Adresse als Operanden. Sie konnen daher im Bereich 02048 bis 2047 springen. Die hochstwertigsten vier Bits der Adresse stehen im Bytecodebefehl, das restliche Byte folgt nach dem Befehl (Abbildung 7.2). Befehlsbyte Bit 7 1 0 0 0 BRANCH d - Argumentbyte 0 Bit 7 d d d d d d d d d relative Adresse (Displacement) 0 d d - Abbildung 7.2: Format der Verzweigungsbefehle. 7.4.3 Aufruf und Ruckkehr von Prozeduren Der Aufruf von Prozeduren spielt eine zentrale Rolle in funktionalen Sprachen, weil der Funktionsaufruf nicht nur konzeptionell eine grundlegende Kontrollstruktur ist, sondern auch bei der Ausfuhrung von Programmen besonders haug erfolgt. In Scheme mu der endrekursive Aufruf bei der Implementierung bei konstantem Speicherbedarf abgearbeitet werden [Rees86]. Ein Aufruf einer Prozedur erfolgt in dieser Implementation in vier Schritten: 1. Anlegen eines Controlframes mit dem Befehl PUSHCONTROL. Die Abbildung 7.3 zeigt den Stack, der in der Abbildung 7.1 auf Seite 61 angegeben wurde, nach Anlegen eines Controlframes. 7.4. 67 DER BEFEHLSSATZ DES SCHEME-PROZESSORS 2. Evaluieren der Argumente. Alle Argumente werden auf dem Stack ubergeben, daher entsteht nach Evaluierung der Parameter in der Reihenfolge von links nach rechts eine Bindungsumgebung im Stack. 3. Evaluieren der Prozedur. Die Prozedur mu zu einer Closure oder zu einer Continuation evaluieren. In Abbildung 7.4 wurden zwei Parameter und die Closure einer Prozedur g evaluiert. 4. Sicherung des alten Zustandes im in Punkt 1 angelegten Controlframe und Einsprung in den Codevektor der aufzurufenden Prozedur. Die aufgerufene Prozedur u berpruft die Anzahl der ubergebenen Parameter und kopiert ihre Bindungsumgebung bei Bedarf in den Heap. In der Abbildung 7.5 wurde der alte Zustand im Controlframe gesichert, und die Prozedur g wird ausgefuhrt. Wenn der auszufuhrende Prozeduraufruf unmittelbar vor der Ruckkehr von einer Prozedur erfolgt (Endrekursion), entfallt das Anlegen eines Controlframes und das Sichern des alten Zustandes. Das Anlegen eines Controlframes vor der Ablage der Parameter steht im Gegensatz den den bei der Implementierung von imperativen Programmiersprachen ublichen Gepogenheiten. Diese Verfahrensweise erlaubt in Scheme einen endrekursiven Aufruf, bei dem die Anzahl der Parameter des Aufrufers und des Aufgerufenen unterschiedlich sein kann, ohne da der Controlframe im Speicher verschoben werden mu. Der Befehlssatz unterstutzt den Prozeduraufruf durch Befehle zum Anlegen eines Controlframes und durch verschiedene Befehle (endrekursiv, nicht endrekursiv, Bindungsumgebung in Stack oder Heap) zum Aufruf einer Prozedur (vergl. Anhang A). Stack Prozessorregister env ctrl sp ctrl des Aufrufers CONTROL (relativer) pc des Aufrufers FIXNUM func des Aufrufers CODE VECTOR env des Aufrufers ENVT statisch umgebende Bindung ENVT 1. Parameter FIXNUM 2. Parameter FIXNUM 3. Parameter FIXNUM CONTROL 0 NULLT 0 NULLT 0 NULLT 0 NULLT Abbildung 7.3: Der Stack nach Anlegen eines Controlframes. 68 KAPITEL 7. FESTLEGUNG VON ARCHITEKTUR UND BEFEHLSSATZ Stack Prozessorregister env ctrl sp ctrl des Aufrufers CONTROL (relativer) pc des Aufrufers FIXNUM func des Aufrufers CODE VECTOR env des Aufrufers ENVT statisch umgebende Bindung ENVT 1. Parameter FIXNUM 2. Parameter FIXNUM 3. Parameter FIXNUM CONTROL 0 NULLT 0 NULLT 0 NULLT 0 NULLT 1. Parameter SYMBOL 2. Parameter SYMBOL CLOSURE - Codevektor von g CODE VECTOR stat. umgeb. Bindung von g ENVT Abbildung 7.4: Der Stack nach Evaluieren von Parametern und Prozedur g. 7.4. 69 DER BEFEHLSSATZ DES SCHEME-PROZESSORS Stack Prozessorregister ctrl env sp ctrl des Aufrufers CONTROL (relativer) pc des Aufrufers FIXNUM func des Aufrufers CODE VECTOR env des Aufrufers ENVT statisch umgebende Bindung ENVT 1. Parameter FIXNUM 2. Parameter FIXNUM 3. Parameter FIXNUM CONTROL (relativer) pc in f FIXNUM Codevektor von f CODE VECTOR ENVT stat. umgeb. Bindung von g ENVT 1. Parameter SYMBOL 2. Parameter SYMBOL Abbildung 7.5: Der Stack nach Aufruf der Prozedur. 7.4.4 Typprufungen und Vergleiche Fur Typprufungen und Vergleiche wurde je ein Befehl gewahlt, der den Typ und die Vergleichsoperation im Befehlsbyte enthalt. Der Vergleichsbefehl bestimmt ferner, ob er die Typen der Operanden auf Zahlen oder Zeichen prufen soll. Wenn zu vergleichende Zahlen nicht vom Typ FIXNUM sind, wird der Wirtsprozessor aufgerufen. 7.4.5 Befehle fur Listen- und Vektoroperationen Der Prozessor stellt Befehle fur Listen- und Vektoroperationen bereit, die alle Typenprufungen beinhalten und die CDR-Kodierung von Listen unterstutzen. Bei allen Zugrien auf Vektorelemente wird zudem gepruft, ob der Indexausdruck im Bereich des Vektors liegt. Von den Standardprozeduren list und vector sind je zwei Varianten implementiert: Eine Variante erlaubt bis zu 255 Argumente. Die anderen Variante erlaubt beliebig viele Argumente und auch eine erst zur Laufzeit errechnete Anzahl von Argumenten. Der Reader nutzt diese zweite Variante. Zusatzlich zu den Befehlen fur Vektoren sind auch Befehle fur die Konstruktion und Modikation von Codevektoren enthalten. Diese Befehle werden vom Bytecode-Compiler genutzt. 7.4.6 Numerische Befehle Die numerischen Befehle arbeiten derzeit nur mit Zahlen des Typs FIXNUM. Alle anderen Typen fuhren zu einer Fehlerbehandlung durch den Hostprozessor. Dieser kann daher Rechnungen mit Zahlen der Typen REAL und BIGNUM u bernehmen, ohne da dazu eine Erweiterung des SchemeProzessors notig ist. 70 KAPITEL 7. FESTLEGUNG VON ARCHITEKTUR UND BEFEHLSSATZ 7.4.7 Zeichen- und zeichenkettenorientierte Befehle Die zeichenorientierten Befehle erlauben die Wandlung zwischen den Typen FIXNUM und CHART. Alle Vergleiche werden mit COMPARE vorgenommen. Die zeichenkettenorientierten Befehle arbeiten mit Objekten des des Typs STRINGT. Alle anderen Typen fuhren zu einer Fehlerbehandlung durch den Hostprozessor. Auch beim Zugri auf Elemente in Zeichenketten wird der Wert des Indexausdrucks gepruft. 7.5 Reprasentation der Befehle Die zuvor beschriebenen Bytecodebefehle sind wie folgt aufgebaut: Ein Byte enthalt den Befehl. Optional ist in diesem Befehlsbyte ein Argument enthalten. Weitere Argumente stehen in den folgenden Bytes. Es sind zwei Formate vorgesehen: Format A Das Format A ist dadurch gekennzeichnet, da das hochstwertigste Bit eines Befehlsbytes geloscht ist. Die restlichen 7 Bits wahlen einen aus 128 moglichen Befehlen aus. Format B Im Format B ist das das hochstwertigste Bit eines Befehlsbytes gesetzt. Die Bits 0 bis 3 enthalten ein vier Bit breites Argument, und mit den Bits 4 bis 6 wird einer aus acht moglichen Befehlen ausgewahlt. Diese Befehlsformate werden in der Abbildung 7.6 dargestellt. Befehle im Format B sind BRANCH, BRANCHF , BRANCHT, PUSHVAR, STOREVAR, COMPARE und TYPECHK. Alle anderen Befehle sind im Format A reprasentiert. Bit 7 0 0 b b b b b b b Format A: Nur Befehl im Befehlsbyte Bit 7 1 0 b b b a a a a Format B: Befehl und Argument im Befehlsbyte Abbildung 7.6: Die Befehlsformate des Scheme-Prozessors. 7.6 Beispiele fur Programme in Bytecode Der Befehlssatz mu sich einerseits fur die Realisierung in einem Prozessor eignen. Andererseits mussen alle Scheme-Programme in Folgen von Bytecodebefehlen u bersetzen lassen. Hier soll die Bytecodereprasentation fur einige Scheme-Programme beispielhaft angegeben werden. 7.6. PROGRAMME IN BYTECODE BEISPIELE FUR 71 Eine einfache Prozedur, die selbst nur die Standardprozedur fur die Multiplikation aufruft, ist die Prozedur square: (define (square x) (* x x)) Der Bytecode fur square berucksichtigt, da der Befehl duplicate einen Hauptspeicherzugri weniger ausfuhrt als der Befehl pushlocal , mit dem der gleiche Eekt zu erzielen ware: pushlocal 0 duplicate mul return ; ; ; ; Parameter x verdopple Parameter (* x x) zuruck zum Aufrufer Die folgende Prozedur zeigt eine bedingte Anweisung und die Darstellung in Bytecode: (define (nonneg x) (if (minus? x) 0 x)) lab1: pushlocal 0 minusp branchf lab1 pushpint 0 return pushlocal 0 return ; ; ; ; ; ; ; Parameter x (minus? x) nein, -> Konstante 0 Funktionswert ist 0 x Funktionswert ist x Einen Aufruf einer Prozedur zeigt das nachste Beispiel: (define (test) (+ (f 1 2 3) 7)) pushcontrol pushpint 1 pushpint 2 pushpint 3 pushglobal f call pushpint 7 add return ; ; ; ; ; ; ; ; ; Anlegen eines Controlframes Konstante 1 Konstante 2 Konstante 3 f Aufruf der Prozedur Konstante 7 addiere 7 fertig 72 KAPITEL 7. FESTLEGUNG VON ARCHITEKTUR UND BEFEHLSSATZ Der Aufruf konnte auch endrekursiv sein. Es entfallt das Anlegen des Controlframes: (define (test) (f 1 2 3)) pushpint 1 pushpint 2 pushpint 3 pushglobal f stacktrcall ; ; ; ; ; Konstante 1 Konstante 2 Konstante 3 f endrekursiver Aufruf der Prozedur Ein letztes Beispiel zeigt eine Prozedur, die ihre Bindungsumgebung in den Heap kopiert: (define (test x) (lambda (y) (* x y))) heapcontext 1 ; kopiere Bindungsumgebung in den Heap pushclosure 0 ; (lambda (y) (* x y)) ist Codevektor im Literalbereich return Kapitel 8 Entwurf und Realisierung des Prozessors Im vorherigen Kapitel wurde der Befehlssatz des Scheme-Prozessors und seine Register angegeben. In diesem Kapitel soll der Entwurf des Prozessors beschrieben werden. Dazu werden die verschiedenen Entwurfs- und Beschreibungsebenen, auf denen der Prozessor entworfen wird, dargestellt. Ferner wird fur jede Ebene auf die gewahlte Beschreibung und Simulation der beschriebenen Schaltung eingegangen. 8.1 Entwurfsebenen Ein Hardwarenentwurf beinhaltet verschiedene Sichten von Spezikation und Entwurfsergebnissen. Diese Sichten umfaen: Verhalten Struktur physische Schaltung (Layout bei ICs) Die Struktur ist dabei eine Modellierung der physischen Schaltung. Die Sichten werden in verschiedene Abstraktionsebenen unterteilt: Architekturebene Algorithmenebene Funktionsblockebene (Registertransfer-Ebene) Logikebene Schaltkreisebene Geometrieebene Diese Gliederung wird im Y-Diagramm von Gajski und Kuhn ubersichtlich dargestellt [GeKu83, WaTh85]. Die Abbildung 8.1 zeigt ein Y-Diagramm. Im Y-Diagramm wird ein Entwurfsproze durch Pfeile symbolisiert, welche sich dem Mittelpunkt der Abbildung nahern. Die Abbildung 8.2 74 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS zeigt die mit VENUS-S erzielbare Entwurfsunterstutzung im Y-Diagramm. VENUS-S geht von einer Strukturbeschreibung auf Logikebene aus. Durch die fur die Standardzellen enthaltenen Simulationsmodelle steht uber eine Simulation eine Verhaltensbeschreibung auf Logikebene zur Verfugung. Ferner wird durch die Chipkonstruktion eine Transformation der Struktur auf der Logikebene in die Geometrieebene einer physischen Schaltung erreicht. Verhalten Struktur Architekturebene 0CPUs, Speicher [email protected]@ 0 Algorithmenebene Subsysteme Algorithmen @ Funktionsblockebene 00 Register, ALU, MUX [email protected] Logikebene @ 0 Gatter, Flipops Boolesche Gleichungen @ Schaltkreisebene 0 Transistoren 0 [email protected] @@ @ 0 00 Maskendaten Zellen Flurplane Cluster Partitionierung Layout Abbildung 8.1: Sichten und Abstraktionsebenen bei Spezikation und Entwurf (Y-Diagramm). Architekturebene Algorithmenebene Funktionsblockebene Logikebene Schaltkreisebene Verhalten Systemspezikation Algorithmen Registertransfers Boolesche Gleichungen Dierentialgleichungen Struktur CPUs und Speicher Subsysteme Register, ALUs, Mux Gatter, Flipops Transistoren Physische Realisierung Paritionierung Cluster Flurplane Zellen Geometrie Tabelle 8.1: Tabellarische Form des Y-Diagramms. Der durch VENUS-S im Entwurfsproze abgedeckte Anteil besteht in einer Transformation von der Strukturbeschreibung auf Logikebene in geometrische Maskendaten. Oberhalb der Logikebene erforderliche Entwurfsschritte werden nicht unterstutzt. Tabelle 8.1 stellt das allgemeine Y-Diagramm in tabellarischer Form dar. In Tabelle 8.2 wird diese Tabelle auf den speziellen Fall | den Entwurf des Scheme-Prozessors | angepat. Die 8.1. 75 ENTWURFSEBENEN Schaltkreisebene ist dabei entfallen, da diese bei einem Semicustom-Entwurfssystem nur beim Entwurf der Zellen durch den Hersteller, nicht aber beim Entwurf durch den Anwender zu berucksichtigen ist. Das Gesamtsystem ist hier der 68000-Rechner mit eingesetztem Scheme-Prozessor. Der 68000-Rechner mit seinem Speicher und seiner Ein-/Ausgabeeinheit ist bereits fertig; zu entwerfen bleibt der Scheme-Prozessor, dessen Verhalten auf der Algorithmenebene durch den Befehlssatz und die Speicherverwaltung speziziert ist. Die nachst niedrigere Ebene, die Registertransferebene, geht von einer Struktur aus Multiplexern, ALUs und Registern aus und beschreibt das Verhalten durch die Registerinhalte und ALU-Operationen und durch Multiplexer ausgewahlte Datenpfade. Das Verhalten ist bei einer mikroprogrammierten Struktur durch ein Mikroprogramm, das die Datenpfade auswahlt, gegeben. Die unterste Entwurfsebene bei einem Semicustomentwurf ist die Logikebene. Die Struktur wird aus Standardzellen und Makrozellen gebildet, und das Verhalten ist durch Simulation der eingegebenen Struktur erkennbar. Diese Struktur auf Logikebene wird mit dem Entwurfssystem in eine physische Struktur, ein gefertigtes Chip, transformiert. Verhalten Struktur Architekturebene 0CPUs, Speicher [email protected]@ 0 Algorithmenebene Subsysteme Algorithmen @ 0 Funktionsblockebene Register, ALU, MUX 0 [email protected] Logikebene @ 0 Gatter, Flipops Boolesche Gleichungen @ Schaltkreisebene 0 Transistoren [email protected] @ 00 @@ 00 Maskendaten Zellen 6 Flurplane Cluster Partitionierung Layout Abbildung 8.2: Beitrag von VENUS-S zum Entwurfsproze als Y-Diagramm. Mehr um diesen Entwurf zentriert zeigt die Abbildung 8.3 das Vorgehen beim Entwurf des Scheme-Prozessors: Das gewunschte Verhalten wird durch den Befehlssatz speziziert. Dieser Befehlssatz mu nicht nur vom zu entwerfenden Chip auszufuhren sein, er mu auch die Implementation von Scheme ezient und vollstandig ermoglichen. Daher ist das Verhalten des Prozessors im Rahmen einer Scheme-Implementation simulativ auf seine Eignung zu untersuchen. Dieser Simulator ist auch ein Hilfsmittel, um Software fur den Scheme-Prozessor vor Ende seiner Fertigung erstellen zu konnen. Auf der nachsten Entwurfsebene wird eine Registertransfer-Struktur fur den Scheme-Prozessor entwickelt und das Mikroprogramm, das das gewunschte Verhalten mit dieser Struktur ermoglicht, 76 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS erstellt. Simulativ wird das Verhalten von Mikroprogramm und RT-Struktur mit dem spezizierten Verhalten verglichen. Diese Simulation gestattet auch eine erste Geschwindigkeitsabschatzung des Scheme-Prozessors, da die Laufzeit von Programmen als Vielfache von Taktzyklen ermittelt werden kann. Architekturebene Algorithmenebene Funktionsblockebene Logikebene Verhalten 68000-Rechner mit Scheme-Prozessor Befehlssatz u. Speicherverwaltung Registertransfers, Mikroprogramm VENUSSimulation Struktur 68000, Speicher, Scheme-Prozessor Steuerwerk, Operationswerk Register, ALUs, MUX Standardzellen, ROM Physische Realisierung Paritionierung auf Platinen u. ICs Plazierung der Makros Flurplane Standardzellen, generiertes ROM Tabelle 8.2: Tabellarische Form des Y-Diagramms beim Entwurf des Scheme-Prozessors. Auf der Logikebene entsteht eine Strukturbeschreibung durch die Eingabe der Schaltung in ein Semicustom-Entwurfssystem. Das Verhalten der Schaltung ist durch den Simulator des Entwurfssystems zuganglich. Wieder ist das Verhalten der Struktur auf dieser Ebene mit dem zuvor spezizierten Verhalten zu vergleichen. Ferner ist das Zeitverhalten zu ermitteln, und es konnen Aussagen u ber kritische Pfade und die maximale Taktfrequenz getroen werden. Die simulierte Schaltung dient auch der Fehlersimulation und Chipkonstruktion als Eingabe. Verhaltenssimulation Bewertung des Befehlssatzes Erstellen von Compiler, Editor, ... 6Uberpr ufung auf Registertransfer-Simulation Logiksimulation identisches Verhalten Bewertung der Hardwarestruktur Entwicklung des Mikroprogramms 6Uberpr ufung auf identisches Verhalten Bewertung der Geschwindigkeit Generierung von Testmustern Chipkonstruktion Abbildung 8.3: Die Entwurfsebenen des Prozessors. 8.2 Verhaltensbeschreibung des Scheme-Prozessors Eine Verhaltensbeschreibung eines Prozessors besteht hauptsachlich in der Beschreibung der Wirkung seiner Befehle. Die Wirkung der Befehle ist die der Veranderung der Inhalte von Prozessorregistern und Hauptspeicher. Neben der Wirkung der Befehle werden das Holen der Befehle und die Interruptbearbeitung beschrieben. 8.2. VERHALTENSBESCHREIBUNG DES SCHEME-PROZESSORS 77 Die Beschreibung des Verhaltens kann in dafur entworfenen Beschreibungssprachen erfolgen, fur die es Compiler gibt, welche aus der Verhaltensbeschreibung einen Simulator erzeugen. Als Beschreibungssprachen fur das Verhalten einer Hardware stehen an der Universitat Hamburg ISPS, "Instruction Set Processor Specication\ von der Carnegie-Mellon University [Barb81] und Mimola von der Universitat Kiel [Marw86] zur Verfugung. Eine Beschreibung des Prozessors in Mimola erschien sehr attraktiv, da Mimola nicht nur einen Simulator fur das beschriebene Verhalten bereitstellt, sondern auch automatisch eine mikroprogrammierte Hardwarestruktur generiert. Versuche mit Mimola ergaben, da die zur Verfugung stehende Version von Mimola noch sehr unzulanglich war. Zudem wird das Mikroprogramm nur fur eine Hardware ohne Pipelineing und Residuumkontrolle erstellt. Da Pipelining eine groere Geschwindigkeit und Residuumkontrolle eine Verkleinerung des Mikroprogramms bewirken, sollte auf diese beiden Verfahren nicht grundsatzlich verzichtet werden, gerade weil die resultierenden Vorteile gravierend waren. Eine Beschreibung des Verhaltens wurde mit ISPS erstellt. Damit war der Befehlssatz beschrieben und konnte simuliert werden. Es war ein vorrangiges Ziel, einen Compiler von Scheme in diesen Befehlssatz zu erstellen, um sicherstellen zu konnen, da jedes Scheme-Programm in diesem Befehlssatz reprasentierbar ist. Der durch ISPS generierte Simulator erwies sich allerdings als sehr inezient und unbequem. Insbesondere erlaubt der Simulator das Laden des Hauptspeichers und der Register nur mit als Zahlen darzustellenden Werten. Ein Scheme-System arbeitet mit Zeigern auf Objekte, wobei diese bei jeder Garbage Collection ihre Position im Speicher andern. Es wurde ein Simulator benotigt, der mehr auf Scheme zugeschnitten war. Als praktikablere Beschreibungssprache auf Befehlssatzebene hat sich Pascal erwiesen. Der Befehlssatz wurde durch ein Pascal-Programm beschrieben. Ferner enthalt dieses Programm Funktionen wie die Ein- und Ausgabe, die nach Fertigstellung des Prozessors vom Wirtsprozessor bereitgestellt werden. Der in Pascal erstellte Simulator ladt eine Datei, die den in Bytecode ubersetzten Scheme-Compiler sowie einige haug benotigste Standardfunktionen enthalt und arbeitet dann als compilierende Scheme-Implementation wie z. B. PC Scheme, indem ein Ausdruck vom Benutzer eingelesen wird, dieser erst in Bytecode u bersetzt und dann ausgefuhrt wird. Der Simulator dient dazu, den im vorherigen Kapitel angegebenen Befehlssatz nebst dem zugehorigen Compiler zu entwickeln. Ferner wird er in einem vom Verfasser veranstalteten Programmierprojekt, in dem Studenten Software wie einen bildschirmorientierten Editor, einen Debugger und alle im Sprachstandard geforderten Funktionen fur den Scheme-Prozessor erstellen, eingesetzt. Der Simulator ist ein Programm von etwa 4200 Zeilen Lange, das ursprunglich vom Verfasser auf einem Atari ST erstellt wurde, spater fur den Einsatz in der Lehre aber auch nach VAX/VMS portiert wurde. Die Verteilung der Zeilen auf die Bestandteile des Simulators zeigt Tabelle 8.3. Die Summe der Prozentzahlen ist kleiner als 100 %, weil Teile des Programms, insbesondere Deklarationen und Kommentare, nicht eindeutig einem der Bestandteile zugeordnet werden konnten. Der Compiler und die Standardfunktionen wurden vom Verfasser in Scheme implementiert und haben eine Lange von 1100 Zeilen. Der Bootstrap des Schemeanteils erfolgte mit PC Scheme. Bestandteil Quellzeilen Bytecodeinterpreter 47 % Initialisierung mit Urlader 11 % Hostfunktionen 8% Debugger 7% Tabelle 8.3: Bestandteile des Verhaltenssimulators. 78 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS 8.2.1 Analyse der Verhaltensbeschreibung Fur die Angabe der Struktur des Scheme-Prozessors wird die Verhaltensbeschreibung analysiert. Dazu werden die in dieser Beschreibung vorkommenden Kontrollstrukturen und Ausdrucke ermittelt. Die vorkommenden Ausdrucke bestimmen Anforderungen an die Hardwarestruktur, namlich von einer ALU oder mehreren ALUs bereitzustellende Operationen. Ferner ist bei Operationen, die nur selten vorkommen, ein Ersetzen durch eine Folge von anderen, hauger vorkommenenden Operationen vorzusehen. Beispielsweise enthalt die Verhaltensbeschreibung nur einmal eine Division durch vier. Diese Division erfolgt bei der Implementierung der Funktion make-string, wenn aus der Lange des Strings die Anzahl der zu allozierenden Speicherworte errechnet wird. Da diese Funktion nach fundierten Abschatzungen einerseits nicht sehr haug ausgefuhrt wird und andererseits auch nicht besonders zeitkritisch ist, wird diese einzige Division durch vier durch zwei Divisionen durch zwei ersetzt. Weitere Analysen betreen die Anzahl der Operanden der vorkommenden Ausdrucke und ob diese Operanden Variablen oder Konstanten sind. Ferner sind die Variablen zusammengesetzte Daten (Records) mit den Feldern CDR-Code, Typ und Datum. Daher wird auch analysiert, ob Ausdrucke fast ausschlielich das gleiche Feld zugreifen oder ob sie unterschiedliche Teilfelder beinhalten. Auch bei diesen Analysen der Register und Felder werden auch Ausnahmen wie im obigen Beispiel mit der Division durch Folgen haug vorkommenender Ausdrucke ersetzt. Ferner sind haug ausgefuhrte Folgen von Anweisungen zu ermitteln, um diese besonders ezient in Hardware zu implementieren. Die Analysen haben folgende Ergebnisse: 1. Kontrollstrukturen sind IF-THEN-ELSE , IF-THEN und CASE. Bei dem CASE-Statement wird nach 4 und 72 Zielen verzweigt. Diese Mehrfachverzweigungen erfolgen anhand des Bytebefehls und bei den Listenoperation und in der Garbage Collection anhand des CDR-Codes. Sie sind daher zeitkritisch und sollten nicht serialisiert werden. Zudem sind Unterprogrammtechniken in der Verhaltensbeschreibung stark genutzt, Rekursion tritt nicht auf, die grote Verschachtelungstiefe betragt 5. Bedingten Sprungen folgt haug der Aufruf einer Prozedur und die Ruckkehr von einer Prozedur. 2. Ausdrucke beinhalten haug zwei Variablenreferenzen. Auch Konstanten sind haug in Ausdrucken vertreten. Alle Ausdrucke A lassen sich in der EBNF nach Wirth [Wirt81] durch in in Tabelle 8.4 gezeigte Grammatik beschreiben, in der Schlusselworte durch Fettdruck hervorgehoben sind. Auch alle Vergleiche konnen durch diese Ausdrucke und Vergleich mit null realisiert werden. Die Konstanten liegen im Bereich 0 0 31. A L R R1 = = = = L j L+R [ + 1 ] j L0R [ 0 1] V ariable j 0 R1 j 256 3 R1 j R1 MOD 16 j R1 DIV 2 V ariable j Konstante Tabelle 8.4: Grammatik in der Verhaltensbeschreibung vorkommender Ausdrucke A. 3. Verschiedene Felder der Variablen treten im gleichen Ausdruck auf. Das Ergebnis einer Zuweisung verandert sehr haug nur ein Feld einer Variablen. 4. Besonders haug auftretende Folgen von Anweisungen sind Abfragen der Variable tos valid mit anschlieendem Loschen oder Setzen von tos valid, da sehr viele Befehle das oberste 8.3. STRUKTURBESCHREIBUNG DES SCHEME-PROZESSORS AUF RT-EBENE 79 Stackobjekt laden, wenn es nicht in der Variablen tos steht oder es in den Speicher transferieren, falls tos belegt ist. Zudem sind Zugrie auf die obersten 22 Bit von pc sehr haug, da das die Wortadresse des Bytecodebefehls bildet. Insbesondere nden haug Vergleiche mit instr addr statt. Ferner ist auch ein Zugri auf ein Byte aus instr cache haug, da es sich dabei um Befehle und Operanden handelt. Diese Ergebnisse der Analyse der Verhaltensbeschreibung sollen dem Entwurf der Struktur als Grundlage dienen. 8.3 Strukturbeschreibung des Scheme-Prozessors auf RTEbene Auf der Registertransfer-Ebene (RT-Ebene) wird die Struktur des Prozessors, die das in der Verhaltensbeschreibung spezizierte Verhalten realisieren soll, auf einer relativ hohen Ebene beschrieben. Die Struktur wird aus Speichern, Registern, Multiplexern und ALUs erstellt, wobei die Realisierung dieser Strukturelemente erst auf einer niedrigeren Ebene, der Logikebene, erfolgt. Die RTEbene erlaubt das Beschreiben verschiedener Hardwarestrukturen fur ein gefordertes Verhalten, da die Anzahl der vom Entwerfer und Simulator zu betrachtenden Strukturelemente wesentlich kleiner als auf der Logikebene ist. DB0{15 AB1{23 AS, LDS, UDS FC0, FC1, FC2 R/W, DTACK BR BG, BGACK CS, RESET Takte Takte Operationswerk 15 Bit - Steuerwerk 25 Bit 66 RESET Abbildung 8.4: Operationswerk und Steuerwerk des Scheme-Prozessors. Eine Struktur wird fur ein vorgegebenes Verhalten weitgehend intuitiv, unter Ruckgri auf den Entwerfern bekannte Strukturen, gefunden. Van Cleemput [Clee79] schreibt dazu: 80 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS ": : : many designers base their designs on an library of examples. These examples may originate from previous design experience, from the literature, or from classroom exposure.\ Dieses Zitat von 1979 trit auch auf die heutige Situation zu. Darum soll das Problem hier systematischer angegangen werden. Zusatzlich mu bei der Angabe einer Struktur auf hoher Ebene auch berucksichtigt werden, da die Strukturelemente durch die niedrigeren Ebenen bereitgestellt werden konnen. Die Analyseergebnisse der Verhaltensbeschreibung sollen als Entscheidungskriterien fur die Wahl zwischen unterschiedlichen Entwurfsmoglichkeiten beim Entwurf einer RT-Struktur dienen. Zusatzlich ist auch die Realisierbarkeit auf der Logikebene durch das Entwurfssystem zu berucksichtigen. Ein komplexes Schaltwerk, wie es ein Prozessor darstellt, wird klassisch in Steuerwerk und Operationswerk aufgeteilt. Dieser in Abbildung 8.4 gezeigten Aufteilung folgend soll die Hardwarestruktur des Scheme-Prozessors in den folgenden Abschnitten entwickelt werden. AB1 6 ? 68000-Kontrollbus 6 ? Buszugrismodul ? Addr Out1 - Addr Out2 - Addr In - 6 OUT1 -A ALU Registerbank OUT2 IN ""21 ? AB2-22 ""16 ""65 ""616 ? AB2-6DB0-15 DB0-15 -B - Status 6 Operation Abbildung 8.5: Schematische Struktur des Operationswerks. 8.3.1 Das Operationswerk Die Struktur des Operationswerks wird schematisch in der Abbildung 8.5 dargestellt. Das Operationswerk besteht aus folgenden Subsystemen: 8.3. STRUKTURBESCHREIBUNG DES SCHEME-PROZESSORS AUF RT-EBENE 81 Eine Registerbank enthalt alle Register des Prozessors. Diese Register unfassen auch solche, die fur Hauptspeicherzugrie eingesetzt werden (mar und mdr). Daher ist die Registerbank auch mit dem Adre- und Datenbus des 68000-Rechners verbunden (Anschlusse unten links in der Abbildung 8.5). der Eine ALU nimmt die eigentliche Verarbeitung aller Daten einschlielich der Ubertragung Daten zwischen verschiedenen Registern in der Registerbank vor. Ein Buszugrismodul wickelt Hauptspeicherzugrie des Scheme-Prozessors ab und ermoglicht dem Hostprozessor Zugrie auf die Register des Scheme-Prozessors. Der Buszugrismodul ist daher mit dem 68000-Kontrollbus und der Registerbank verbunden. In der Registerbank steuert er beispielsweise Ubernahmen vom 68000-Datenbus in das Register mdr. Der Buszugrismodul arbeitet parallel zu Registerbank und ALU. Damit kann die fur Hauptspeicherzugrie benotigte Zeit genutzt werden, um Operationen und Typprufungen vorzunehmen. Die Strukturen dieser drei Subsysteme des Operationswerks werden im folgenden dargestellt. Mit der genauen Kenntnis dieser Subsysteme wird anschlieend die Operationswerksstruktur detaillierter entwickelt und dabei auch auf die Verbindungen zum Steuerwerk und die Testbarkeit eingegangen. 8.3.1.1 Die Registerbank Die Analyse der Verhaltensbeschreibung ergibt, da Ausdrucke sehr haug zwei Variablen enthalten. In der Hardware benden sich die Variablen in einer Registerbank. Wenn die Registerbank nur einen Ausgang hat, sind jeweils zwei Auslesevorgange notwendig, bevor beide Operanden fur einen Ausdruck vorliegen. Um Leseoperationen aus der Registerbank nicht zum Engpa des Prozessors werden zu lassen, mu daher eine Registerbank mit zwei Ausgangen verwendet werden. 8.3.1.1.1 Auswahl einzelner Felder der Register Die Verhaltensbeschreibung verlangt, da die Felder der Register ausgewahlt werden konnen. Das Auswahlen der Felder fur eine Operation soll in der Registerbank erfolgen, womit die Adressierung der Register durch geordnete Paare bestehend aus der Adresse des Registers und dem Feld innerhalb des Registers erfolgt. Zusatzlich zu den drei Feldern CDR-Code, Typ und Datum kann auch das gesamte Register ausgewahlt werden. Das gesamte Register wird fur Zuweisungen zum Beispiel zwischen mdr und tos gebraucht. Beim Schreiben in die Registerbank wird haug nur ein Feld des gesamten Registers verandert. Es soll daher eine Registerbank entworfen werden, die auch Schreiboperationen durch ein Paar (Registeradresse, Feld) implementiert. Ohne einen solchen Mechanismus mute zur Modikation eines Feldes das gesamte Register gelesen, dann das Feld modiziert und anschlieend der neue gesamte Registerinhalt zuruckgeschrieben werden. Dieser Zeitaufwand wird durch die hier angegebene spezielle Registerbank vermieden. 8.3.1.1.2 Signale der Registerbank Abbildung 8.6 zeigt alle Signale der Registerbank. Links sind die Adressen und Feldauswahlsignale fur die drei Ports dargestellt. Jede Adresse eines Registers ist 5 Bit breit, da Tabelle 7.1 auf Seite 60 insgesamt 20 Register beinhaltet, zu denen unten noch Pseudoregister hinzukommen werden. Tabelle 8.5 zeigt die Belegung der Feldauswahlsignale. Rechts werden der Eingangsport IN und die beiden Ausgangsports OUT1 und OUT2 gezeigt. Der Port OUT2 hat nur eine Breite von 24 Bit. Die anderen beiden Ports sind 32 Bit breit. 82 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS LATCHH CONTROL A1 LATCHL STATUS XDIR BUSMODE XTRN Addr Out1 Range Out1 Addr Out2 Range Out2 Addr In Range In 5 2 6 ""4 ? ? ?? ??? OUT1 OUT2 Registerbank IN RSC ""21 ? AB2-22 ""16 ""65 ""616 ? AB2-6 DB0-15 DB0-15 Abbildung 8.6: Die Signale der Registerbank. Belegung 00 01 10 11 Bitbereich 31{0 23{0 29{24 31{30 Feld ganzes Wort Datum, Pointer Typ CDR-Kode Tabelle 8.5: Operationen der Feldauswahl. 32 24 32 3 - 8.3. STRUKTURBESCHREIBUNG DES SCHEME-PROZESSORS AUF RT-EBENE 83 Die unten an der Registerbank dargestellen Signale dienen der Kommunikation des SchemeProzessors mit dem Wirtsrechner. Da die Registerbank die Register mar und mdr beinhaltet, die Adresse und Datum fur Hauptspeicherzugrie enthalten, mussen die Inhalte dieser Register an die Anschlusse des Prozessorchips gelangen: Der Inhalt des Registers mar wird als AB2-22 herausgefuhrt und bildet die Adresse bei Hauptspeicherzugrien des aktiven Scheme-Prozessors. Der Inhalt des Registers mdr kann von den Anschlussen DB0-15 geladen und nach DB0-15 ausgegeben werden. Zusatzlich werden die Signale AB2-6 in die Registerbank hinein gefuhrt. Diese Signale bilden eine Registeradresse, um die Register des inaktiven Scheme-Prozessors durch den Hostprozessor laden und auslesen zu konnen. Oben an der Registerbank sind Steuerleitungen dargestellt. A1 steuert, ob die oberen oder die unteren 16 Bits des Registers mdr von DB0-15 ubernommen oder dorthin ausgegeben werden. Fur einen Zugri des Hostprozessors auf die Register in der Registerbank werden die Leitungen XDIR und XTRN benotigt. Ein solcher Zugri berucksichtigt, da durch das Register mdr direkt vom Hostprozessor gelesen und geschrieben werden kann. Es mu zusatzlich ein Datentransfer zwischen mdr und dem Register, das der Hostprozessor zugreifen will, erfolgen. XTRN bewirkt einen solchen Datentransfer, und XDIR gibt an, ob der Inhalt von mdr in das vom Hostprozessor durch AB2-6 ausgewahlte Register geschrieben werden soll oder ob mdr aus diesem Register geladen werden soll. Die verbleibenen Register steuern die Ubernahme in das Register mdr: LATCHH und LATCHL bewirken, da die obere bwz. untere Halfte von mdr aus DB0-15 geladen wird. BUSMODE schaltet die Quelle von mdr zwischen IN mit der Adresse von mdr auf DB0-15 um. Einige Registerinhalte sind fur spater erauterte interne Zwecke des Prozessors aus der Registerbank herauszufuhren: CONTROL ist mit dem zuletzt in das Register csr geschriebenen Datum belegt. Die Belegung STATUS wird beim Lesen von csr als Ergebnis geliefert. RSC sind die untersten drei Bits des gerade ausgefuhrten Befehls. 8.3.1.1.3 Ausgabe von Konstanten Der Ausgang OUT1 soll der Produktion fur L und der Ausgang OUT2 der Produktion fur R1 der Tabelle 8.4 entsprechen. In dieser Tabelle auf Seite 78 sind alle in der Verhaltensbeschreibung vorkommenden Ausdrucke dargestellt. Es fehlt noch eine Losung, um die in diesen Produktionen angegebenen Konstanten an die ALU ausgeben zu konnen. Fur die Null der Produktion L mu die Registerbank eine Null am Ausgang OUT1 liefern konnen. Da die 20 Register nicht alle 32 moglichen Adressen belegen, kann eine Registeradresse speziziert werden, die die Ausgabe einer Null an OUT1 bewirkt. Die Produktion R1 verlangt die Ausgabe einer Konstanten zwischen 0 und 31 am Ausgang OUT2 der Registerbank. Eine zusatzliche Spezikation fur die Registerbank ermoglicht auch dies ohne die Einfuhrung zusatzlicher Steuerleitungen: Da der Ausgang OUT2 nur 24 Bit breit ist, kann er kein volles 32 Bit Wort ausgeben. Der Feldauswahlcode fur ein volles Wort soll an Range Out2 bewirken, da die Adresse Addr Out2 als Konstante auf 24 Bit erweitert an OUT2 ausgegeben wird. Damit kann die Registerbank auch alle benotigten Konstanten bereitstellen. 8.3.1.1.4 Einfuhrung von Pseudoregistern Die Analyse der Verhaltensbeschreibung zeigt, da einige besonders haug auftretende Folgen von Anweisungen auftreten, die durch die Hardware besonders beschleunigt werden sollen: Abfragen der Variablen tos valid mit anschlieendem Loschen oder Setzen von tos valid. Lesen und Schreiben der obersten 22 Bits von pc. Das sind Zugrie auf die Wortadresse des Bytecodebefehls und deren Operanden. Zugri auf ein Byte aus instr cache. Lesender Zugri fur Bytecodebefehls und deren Operanden, schreibender Zugri bei der Funktion string-set! . 84 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS Auch diese Operationen konnen mit geringem Implementierungsaufwand in die Registerbank verlagert werden: Es werden Pseudoregister eingefuhrt, die keine zusatzlichen speichernden Elemente der Registerbank darstellen, sondern Teile schon vorhandener Register auslesen oder modizieren. Folgende Pseudoregister werden den schon vorhandenen Registern hinzugefugt: test and set Dieses Pseudoregister kann nur gelesen werden. Es gibt den Inhalt von tos valid aus und uberschreibt ihn mit logisch eins. test and clear Dieses Pseudoregister kann nur gelesen werden. Es gibt den Inhalt von tos valid aus und uberschreibt ihn mit logisch null. pc4 Dieses Pseudoregister kann gelesen und geschrieben werden. Beim Lesen werden die obersten 22 Bits von pc ausgegeben. Beim Schreiben werden nur die obersten 22 Bits von pc modiziert; die untereren beiden Bits bleiben erhalten. cur byte Dieses Pseudoregister kann gelesen und geschrieben werden. Beim Lesen wird eines der vier Bytes aus instr cache ausgegeben. Das auszugebende Byte wird durch die untersten beiden Bits von pc ausgewahlt. Beim Schreiben wird das durch die untersten beiden Bits aus pc ausgewahlte Byte aus instr cache uberschrieben. Damit ist die Registerbank vollstandig speziziert. Tabelle 8.6 fuhrt alle Register und Pseudoregister mit ihren Adressen auf. 8.3.1.2 Die ALU Die ALU nimmt die eigentliche Datenmaniputation vor. Die ALU mu alle Operationen bereitstellen, deren Grammatik in Tabelle 8.4 auf Seite 78 angegeben ist. Die Operationen sind Addition und Subtraktion mit einem optionalen Ubertrag, wobei der zweite Operand zuvor den dort in der Produktion fur R angegebenen Schiebe- und Maskierungsoperationen zu unterziehen ist. Eine Hardwarerealisierung besteht daher aus einem Shifter, der die Schiebe- und Maskierungsoperationen ausfuhrt, einem Komplementer, der zusammen mit dem Addierer eine Subtraktion ermoglicht, und einem Addierer. Abbildung 8.7 zeigt den Aufbau dieser ALU. Die steuerbaren Operationen von Addierer und Komplementer sind in Tabelle 8.7, die des Shifters in Tabelle 8.8 angegeben. Die Statusleitungen zero, negative und overflow ermoglichen Vergleiche und die Uberlauferkennung. 8.3.1.3 Der Buszugrismodul Der Buszugrismodul wickelt die Buszugrie des Scheme-Prozessors (bzw. der Registerbank) auf den 68000-Bus ab. Es ist ein autonomes Schaltwerk, das parallel zum dem Steuerwerk des Scheme-Prozessors arbeitet. Der Buszugrismodul wickelt einerseits von Steuerwerk des SchemeProzessors angestoene Buszugrie ab; andererseits ist der Scheme-Prozessor aus der Sicht des Hostprozessors ein Peripheriebaustein, dessen Register vom Hostprozessor wie Speicher gelesen und geschrieben werden konnen. Auch diese Lese- und Schreibzugrie des Hostprozessors werden vom Buszugrismodul abgewickelt. Der Buszugrismodul ist mit den Steuerleitungen des 68000-Busses [68000], die an den SchemeProzessor gefuhrt werden mussen (in Abbildung 5.2 auf Seite 39 gezeigt) und mit Steuerleitungen der Registerbank (in Abbildung 8.6 gezeigt) verbunden. Der Buszugrismodul wird mit seinen Verbindungen mit der Registerbank und mit der Auenwelt in Abbildung 8.8 gezeigt. Auch die Verbindungen der Registerbank mit der Auenwelt sind dort dargestellt. 8.3. STRUKTURBESCHREIBUNG DES SCHEME-PROZESSORS AUF RT-EBENE Adresse 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Register Konstante 0 Breite 24 bit tos 32 bit | 32 bit | 32 bit mdr 32 bit instr cache 32 bit cur byte 8 bit pc4 22 bit pc 24 bit tos valid 1 bit mar 24 bit test and set 1 bit test and clear 1 bit csr 4 bit mem end 24 bit instr addr 24 bit free 24 bit env 24 bit glo 24 bit | 24 bit | 24 bit | 24 bit sp 24 bit ctrl 24 bit func 24 bit Erlauterung fur Ausgang OUT1 Top Of Stack Temporarregister Temporarregister Memory Data Register 4 Bytes Code Pseudoregister Pseudoregister Pointer auf Maschinenbefehl Top Of Stack Flag Memory Address Register Pseudoregister Pseudoregister Control and Status Register zur Prufung auf Freispeicheruberlauf Adresse des Codes in instr cache Pointer auf Freispeicherbereich Environmentpointer Pointer auf globales Environment Temporarregister Temporarregister Temporarregister Stackpointer Pointer auf Controlframe Pointer auf Codevektor Tabelle 8.6: Register und Pseudoregister in der Registerbank. Negate 0 0 1 1 Carry 0 1 0 1 Operation a+b a+b+1 a0b01 a0b Tabelle 8.7: Operationen von Addierer und Komplementer. Belegung 00 01 10 11 Operation identische Op. DIV 2 MOD 16 2 256 Tabelle 8.8: Operationen des Shifters. 85 86 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS -A "24" A "24" - SHIFTER - B 66 | -B 6 6 OPERATION NEGATE 6 "24"- zero - negative - overow CARRYIN Abbildung 8.7: Struktur der ALU. Die dargestellten Signale des 68000-Busprotokolls werden in dieser Arbeit nicht weiter erlautert. Diese sind in der Literatur u ber den 68000-Prozessor detailliert beschrieben [68000]. Hier noch zu erlautern sind die Signale CONTROL und STATUS zwischen Buszugrismodul und Registerbank: CONTROL ist mit dem Inhalt des Registers csr belegt, von dessen 4 Bits eines den Interruptpin des Scheme-Prozessors, mit dem er den Hostprozessor unterbrechen kann, steuert. Zwei Bits steuern, wie in Abbildung 8.8 gezeigt, den Buszugrismodul. Sie geben Start (S) und Richtung (D) fur einen Buszugri an. Das vierte Bit bewirkt ein Anhalten des Steuerwerks, es hat daher in dieser Abbildung keine Funktion. STATUS gibt an, ob der Buszugrismodul beschaftigt ist, oder ob er mit einem neuen Buszugri beauftragt werden kann. 8.3.1.4 Das gesamte Operationswerk Das Operationswerk besteht aus den zuvor vorgestellten Moduln Registerbank, ALU und Buszugrismodul. Abbildung 8.9 zeigt alle diese Moduln und ihre Verbindungen untereinander. In dieser Abbildung sind gegenuber Abbildung 8.6 die Bitbreiten der Busse OUT1 und IN von 32 auf 24 verringert. Die hochstwertigsten 8 Bits dieser beiden Signale sind miteinander zu verbinden. Diese Verbindung ist in dieser Abbildung in die Registerbank verlagert worden, wo sie auch bei der Realisierung als Chip erfolgen wird. Eine Zuweisung eines 32 Bit Registers in ein anderes ist weiterhin in einer Operation moglich: Die ALU addiert eine Null auf die unteren 24 Bits, und die oberen 8 Bits sind direkt verbunden. 8.3.1.4.1 Verbindungen zum Steuerwerk Das Operationswerk ist bereits diskutiert. Zusammen mit dem Steuerwerk ist es in Abbildung 8.4 auf der Seite 79 dargestellt. Das Steuerwerk erhalt 15 Statusleitungen vom Operationswerk, und es steuert 25 Leitungen des Operationswerks. Die 25 Leitungen, die das Operationswerk steuern, sind die in Abbildung 8.9 links an der Registerbank dargestellen 21 Eingange sowie die vier Steuerleitungen der ALU, die in der gleichen Abbildung unterhalb der ALU gezeigt werden. Das 8.3. STRUKTURBESCHREIBUNG DES SCHEME-PROZESSORS AUF RT-EBENE IRQ AB1 6 6 ? DTACK UDS LDS R/W AS 6 ? FC0 FC1 FC2 BR 6 87 RESET BGACK BG CS ? Buszugrismodul D S 1 66 LATCHH CONTROL A1 LATCHL STATUS XDIR BUSMODE XTRN 6 ""4 ? ? ? ? ??? Registerbank ""21 ? AB2-22 ""16 ""65 ""616 ? AB2-6 DB0-15 DB0-15 Abbildung 8.8: Buszugrismodul und Registerbank sowie die Verbindungen des Scheme-Prozessors zur Auenwelt. 88 KAPITEL 8. DTACK UDS LDS R/W AS AB1 IRQ 6 6 ? ENTWURF UND REALISIERUNG DES PROZESSORS FC0 FC1 FC2 BR RESET BGACK BG CS 6 6 ? ? Buszugrismodul 6 6 6 "" ? ??? ??? Addr Out1 Range Out1 "" Addr Out2 6 Range Out2 Registerbank -{ Addr In """" Range In -"" "" 66 6 RSC "" 6 "" "" ""6 ""6 ? ? AB2-6 AB2-22 D S 1 CONTROL LATCHH A1 STATUS LATCHL XDIR XTRN BUSMODE 4 OUT1 A 24 OUT2 B SHIFTER 24 5 IN 2 24 3 21 16 5 16 OPERATION DB0-15 NEGATE CARRYIN DB0-15 Abbildung 8.9: Das Operationswerk des Scheme-Prozessors. zero negative overflow 8.3. STRUKTURBESCHREIBUNG DES SCHEME-PROZESSORS AUF RT-EBENE 89 Steuerwerk erhalt vom Operationswerk die 3 Statusleitungen der ALU (zero, negative und overow), den 3 Bit breiten Bus RSC aus der Registerbank, die Leitung HALT aus dem Bus CONTROL sowie die untersten 8 Bits des Busses OUT2 fur Befehle und Mehrfachverzeigungen. 8.3.1.4.2 Testbarkeit des Operationswerks Die Testbarkeit des Operationswerks lat sich ermitteln, indem die Testbarkeit seiner Teilstrukturen gezeigt wird und u berpruft wird, ob Testmuster an diese Teilstrukturen angelegt werden konnen und die Ausgaben dieser Teilstrukturen an die Ausgange des Operationswerk propagiert werden konnen. Die Registerbank kann vollstandig getestet werden: Unter Nutzung des Buszugrismoduls ist das Register mdr steuerbar und beobachtbar im Sinne der Testbarkeit. Ferner kann der Inhalt des Registers mdr in jedes andere Register geschrieben und mdr von jedem anderen Register geladen werden. Die Feldauswahllogik kann fur beide Ports beim Auslesen und Leiten des Ergebnisses uber die ALU getestet werden. Beim Einschreiben in ein beliebiges Register ist sie ohnehin testbar, weil die Registerinhalte beobachtbar sind. Die ALU ist testbar, da beliebige Belegungen an die Eingange angelegt werden konnen und das Ergebnis einer ALU-Operation in ein Register eingeschrieben werden kann und damit beobachtbar ist. Es ist auf dieser hohen Entwurfsebene noch nicht zu entscheiden, ob der Buszugrismodul testbar ist. Der Buszugrismodul ist ein Schaltwerk, das autonom arbeitet. Der Zustand ist anhand der erzeugten Signale erkennbar und Zustandswechsel erfolgen abhangig von Eingangssignalen des 68000-Kontrollbusses. Inwieweit es durch Steuerung und Beobachtung dieser Signale vollstandig testbar ist, kann erst nach Entwurf auf Logikebene eine Fehlersimulation erweisen. Wenn die Testbarkeit nicht ausreichend ist, konnen die speichernden Elemente des Buszugrismoduls in einen Scanpath aufgenommen und damit steuerbar und beobachtbar gemacht werden. Diese Ermitlung der Testbarkeit des Operationswerks basiert darauf, da die vom Steuerwerk kontrollierten Leitungen steuerbar und die Statusleitungen, die vom Operationswerk zum Steuerwerk fuhren, beobachtbar sind. Nochmals: Das Steuerwerk erfullt diese Voraussetzung. 8.3.2 Das Steuerwerk Eine mikroprogrammiertes Steuerwerk war schon aufgrund des komplexen Befehlssatzes zu wahlen. Aus der Analyse kommt die Forderung von Verzeigungen nach Vergleichen (in der Hardware nach Statussignalen einer ALU) und Mehrfachverzweigungen zu 4 bis 72 Zielen hinzu. Auch sind Unterprogrammtechniken in der Verhaltensbeschreibung reichlich genutzt; sie sollen auch im Mikroprogramm bis zur ermittelten Verschachtelungstiefe von funf moglich sein. Die RT-Struktur des Steuerwerks zeigt Abbildung 8.10. Das Steuerwerk enthalt ein Mikroprogramm-ROM mit 1024 Worten von 39 Bit Breite. Eine solches mit dem ROM-Generator aus VENUS-S generiertes ROM ergibt eine Groe von 7,77 mm 2 . Da insgesamt eine Chipache von 77,3 mm2 zur Verfugung steht, belegt es nur etwa 10% der gesamten Chipache und ist damit fur eine CISC-CPU recht klein. Das liegt aber auch daran, da diverse Techniken zur Minimierung verwendet werden. Die Ausgange des ROMs werden alle auf Register gefuhrt, weil die in VENUS-S generierten ROMs getaktet sind, und die Daten in den Registern zwischengespeichert werden sollen, sobald die ROM-Ausgange mit der steigenden Taktanke hochohmig werden. Von den Ausgangen des ROMs fuhren 25 Leitungen zum Operationswerk, 10 Leitungen stellen eine mogliche Sprungadresse dar, und 4 Leitungen steuern die Folgeadresse des Mikroprogramms. Fur die Folgeadresse gibt es 4 Quellen: Sie kann die inkrementierte aktuelle Mikroprogrammadresse sein, vom Mikroprogrammstack geladen werden, aus dem Sprungadrefeld der aktuellen Mikroinstruktion kommen und fur Mehrfachverzweigungen das Sprungadrefeld mit einem 7-Bit 90 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS ...... ...... ...... ...... ...... . . . . .. ...... ...... ............. ...... ...... ......... Stack _ . ..... .. .. ... ..... ...... ...... .......... ...... ...... ...... .... . . .. .. .. .. .. .. ... . . .... ... ... ...... .. .. ...... .. .. .. .. . . .. .. I D OUT2 7 C 8 . .... .... ... ... .... ...... ...... ....... .............. ...... ...... ...... ...... ...... . .. .. ... . . .. .. .... . .... .... .... .... .... .... . .. . .... .. .. .... . .. .... ... .... .. .............. ... . .... Mux 4:1, 10 Bit INCR . .... .... HALT RESET ...... ... .. ... .... ... ... .... ... ... .... ... ... .... ... ... ... .... ... ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....... .. . ... .... ... ... .... ... ... .... ... ... .... ... ... ... .... ... ... ...... .. ... .... ... ... .... ... ... .... ... ... .... ... ... ... .... ... ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. ... .... ... ... .... ... ... .... ... ... .... ... ... ... .... ... ... ............. .. ... .... ... ... .... ... ... .... ... ... .... ... ... ... .... ... ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PC .... .... .... .... ... 10 INH CLR ..... ... . Code ROM .. ... ... ... ... .... 10 ROM 1024239 (7.77 mm2 ) ... .... .... .... .... 29 . ... . ..... . ... . ... . ... . . . ..... . ... . ... . ... . . . ..... . ... . ... . ... . . . ..... . ... . . . ..... . . . . ... .... .... .... .... .... ........ 25 4 . ... ... ... .... .... ...... ..... .... ... .... .... ... 2 . .... ... ... .... ... 2 Folgeadresteuerung . .... ..... . ... .... . ... .... . . . . . ..... ...... . . . . = scan path . .... .. .. . ..... . ... . ... . ... . . . ..... . ... . ... . ... zero negative 3 overow 3 RSC .. .... .... ... ... ... . .... ... .... .... ... Abbildung 8.10: Das Steuerwerk des Scheme-Prozessors. 8.3. STRUKTURBESCHREIBUNG DES SCHEME-PROZESSORS AUF RT-EBENE 91 FUNC idc [6..0] (regbank_out2[7..0]); BEGIN idc[6..0] .= IF regbank_out2[7] (* >= 128 ? *) THEN '1000 . regbank_out2[6..4] (* 64 + opcode *) ELSE regbank_out2[6..0] END; Abbildung 8.11: RT-Spezikation des Befehlsdekoders in Karl II. Wort bitvektoriell disjunktiv verkupft sein. Dieses 7-Bit Wort kommt vom Ausgang OUT2 der Registerbank und wird im Steuerwerk durch den Befehlsdekoder IDC auf 7-Bit Worte abgebildet. Der Mikroprogrammzahler PC ist nicht als Zahler ausgefuhrt, sondern entgegen seinem Namen nur ein Register, dessen inkrementierter Inhalt allerdings als Folgeadresse eingeschrieben werden kann. Diese Ausfuhrung wird zur Umgehung eines Fehlers in den Zahlerzellen des VENUS-Systems gewahlt: Die Simulationsmodelle dieser Zellen sind fehlerhaft: sie melden ungerechtfertigterweise Haltezeitverletzungen, sobald man die Zellen kaskadiert. Schon die Struktur auf RT-Ebene mu auf Gatterebene bestehende Einschrankungen berucksichtigen. Ein Eingang RESET dient dazu, eine Anfangsbedingung einzustellen: An der Adresse null beginnt das Mikroprogramm. Durch RESET wird der Mikroprogrammzahler mit null initialisiert. 8.3.2.1 Der Befehlsdekoder Die Bytecodebefehle sind, wie in Kapitel 7.5 beschrieben, durch je ein Byte codiert, das bei einigen Befehlen ein optionales Argument von 4 Bit enthalt. Befehle ohne dieses Argument werden durch Zahlen zwischen 0 und 127 codiert, Befehle mit Argument durch Zahlen zwischen 128 und 255. Beim Dekodieren der Befehle verzweigt das Steuerwerk uber eine Sprungtabelle. Diese Sprungtabelle konnte einen Eintrag fur jedes Byte enthalten, sie belegte dann 256 Worte im Mikroprogramm. Da ein Mikroprogrammspeicher eine knappe Ressource ist | er ist platzintensiv, und seine Zugriszeit wachst mit der Kapazitat | mu diese Sprungtabelle klein gehalten werden. Es sind Befehle im Bereich von 0 bis 54, sowie 8 Befehle mit einem Argument in den unteren 4 Bits zu implementieren. Es soll daher eine Losung gewahlt werden, die die 8 moglichen Befehle mit einem Argument im Opcode auf die Zahlen von 64 bis 71 abbildet. Die Anfangsadresse 64 der Befehle mit Argument wird gewahlt, weil diese Zahl eine Zweierpotenz ist, die eine Realisierung des Befehlsdekoders sehr einfach und damit platzsparend und schnell macht. Ferner konnen noch bis zu neun weitere Befehle im Bereich von 55 bis 63 deniert werden, ohne da eine Modikation des Befehlsdekoders erfolgen mu. Zudem ermoglicht dieser Befehlsdekoder, der alle Zahlen unter 64 unverandert weiterleitet, da auch anhand der Typen und CDR-Codes uber Sprungtabellen verzweigt werden kann. Ein Befehlsdekoder, der die beschriebene Abbildung vornimmt, kann sehr einfach aufgebaut werden und verringert die Groe der benotigten Sprungtabelle von 256 auf 72 Worte. Die RTSpezikation des Befehlsdekoders IDC, in der RT-Sprache Karl II [LiSc82] angegeben, wird in Abbildung 8.11 gezeigt. 8.3.2.2 Die Folgeadresteuerung Die Folgeadresteuerung im Steuerwerk ist ein Schaltnetz, das einen Folgeadrebefehl aus dem Mikroprogramm ausfuhrt, indem es uber den Multiplexer eine der vier moglichen Folgeadressen auswahlt. Ferner steuert es den Stack. 92 KAPITEL 8. Mikrobefehl inc pc jump jump case return eq call return call eq call ne jump eq jump neq jump lss jump leq jump gtr jump geq jump ov jump res ENTWURF UND REALISIERUNG DES PROZESSORS Belegung 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111 Erklarung inkrementiere Mikroprogrammzahler unbedingter Sprung Mehrfachverzweigung bedingte Unterprogrammruckkehr unbedingter Unterprogrammsprung unbedingte Unterprogrammruckkehr bedingter Unterprogrammsprung bedingter Unterprogrammsprung bedingter Sprung bedingter Sprung bedingter Sprung bedingter Sprung bedingter Sprung bedingter Sprung bedingter Sprung bei Uberlauf residuumgesteuerer Sprung Tabelle 8.9: Mikrobefehle fur die Folgeadrebestimmung. Es sind 16 Folgeadremikrobefehle vorgesehen, die auch abhangig von den 6 Statussignalen vom Operationswerk verschiedene Folgeadreoperationen bewirken. Tabelle 8.9 zeigt alle diese Mikrobefehle. Es sind die Mikrobefehle enthalten, die nach der Analyse der Verhaltensbeschreibung tatsachlich benotigt werden (z.B. ist return eq enthalten, nicht aber return ne). Die Bedingungen fur die bedingten Sprunge gehen aus dem Namen des Mikobefehls hervor. Der Mikrobefehl jump res ist ein bedingter Sprung, bei dem der Folgeadremikrobefehl in einem Residuumregister in der Registerbank steht. Die Befehl wird durch die 3-Bit Leitung RSC an das Steuerwerk ubergeben; das vierte Bit des Folgeadremikrobefehls hat bei allen bedingten Sprungen einen festen Wert. 8.3.2.3 Gewahrleistung der Testbarkeit Dieses Steuerwerk ist ohne zusatzliche schaltungstechnische Manahmen nicht testbar. Testmuster konnen an die Strukturelemente des Steuerwerks weder angelegt werden noch sind die Ausgange dieser Stukturelemente beobachtbar. Um eine Testbarkeit des Steuerwerks und des gesamten Prozessors zu erreichen, sind die in Abbildung 8.10 gefullt dargestellten Register als Scan-Path-Register ausgefuhrt: In dem durch einen Eingang am Prozessor wahlbaren Testmodus arbeiten sie als ein Schieberegister, in das von auen Daten hineingeschoben werden und aus dem die in den Registern enthaltenen Daten herausgeschoben werden. Im Betriebsmodus arbeiten sie als normale (Pipeline-)Register. Wahrend des Testens wird u ber diesen Scanpath das Mikroprogramm-ROM ausgelesen, sowie alle Strukturelemente des Steuerwerks wie Inkrementer, Stack, Befehlsdekoder, ODER-Logik und (indirekt) die Folgeadresteuerung getestet. Ferner dient der Scanpath auch dem Test des Operationswerks, weil unter Verwendung dieses Scanpathes die Statussignale des Operationswerks beobachtet und seine Steuerleitungen stimuliert werden konnen. 8.3. STRUKTURBESCHREIBUNG DES SCHEME-PROZESSORS AUF RT-EBENE 93 8.3.2.4 Zeitbedingungen zwischen Operationswerk und Steuerwerk Das Steuerwerk belegt die Steuerleitungen des Operationswerks mit Mikrobefehlen, die das Operationswerk ausfuhrt. Das Operationswerk belegt nach der Ausfuhrung der Mikrobefehle seine Statusleitungen mit Werten, die dem Steuerwerk fur Verzweigungen dienen. Die einfachste Form der Zusammenarbeit zwischen Steuerwerk und Operationswerk besteht darin, da das Steuerwerk jeweils wartet, bis die Statussignale vom Operationswerk vorliegen und dann eine neue Mikroinstruktion holt. Die erreichbare Zykluszeit fur das Ausfuhren der Mikrobefehle ist dann die Summe der von Steuerwerk und Operationswerk beanspruchten Ausfuhrungszeiten. In Tabelle 8.10 wird Steuerwerk Operationswerk 1. Periode Mikroinstruktion n holen 2. Periode Mikroinstruktion n ausfuhren Tabelle 8.10: Mikroinstruktionsabarbeitung ohne Pipelining. diese Form der Mikroprogrammausfuhrung gezeigt. Dabei wird davon ausgegangen, da Operationswerk und Steuerwerk jeweils eine Periode eines Taktes benotigen. Es fallt auf, da jeweils nur entweder das Operationswerk oder das Steuerwerk aktiv ist, das jeweils andere mu warten. Zur Steigerung des Durchsatzes wird eine 2-stuge Pipeline eingefuhrt: Steuerwerk und Operationswerk arbeiten parallel. Wahrend das Operationswerk eine Mikroinstruktion ausfuhrt, holt das Steuerwerk schon die nachste Mikroinstruktion. Die erreichbare Zykluszeit sinkt gegenuber der Version ohne Pipeline von der Summe der Ausfuhrungszeiten von Steuerwerk und Operationswerk auf das Maximum dieser Zeiten. Tabelle 8.11 zeigt die Mikroinstruktionsabarbeitung mit der Steuerwerk Operationswerk 1. Periode 2. Periode Mikroinstruktion n holen Mikroinstruktion n + 1 holen Mikroinstruktion n 0 1 ausfuhren Mikroinstruktion n ausfuhren Tabelle 8.11: Mikroinstruktionsabarbeitung mit Pipelining. Pipeline. Da davon ausgegangen wird, da Operationswerk und Steuerwerk jeweils eine Periode eines Taktes benotigen, verdoppelt sich der Durchsatz. Der Preis fur die Geschwindigkeitssteigerung ergibt sich daraus, da die Statussignale fur die vom Steuerwerk ausgefuhrten Verzeigungen eine Periode zuvor errechnet werden mussen. Eine Losung ware das Anhalten des Steuerwerks bei bedingten Sprungen fur eine Periode, um das Statussignal abzuwarten. Auf ein Anhalten wird hier aber verzichtet und nach Errechnung der Verzweigungsbedingung noch eine Mikroinstruktion ausgefuhrt (delayed branch). Dadurch wird zwar die Mikroprogrammierung erschwert, aber fur die Falle, in denen eine Instruktion gefunden werden kann, die gleichzeitig mit der Verzweigung ausfuhrbar ist, der Durchsatz gegenuber einem Anhalten des Steuerwerks erhoht. Wenn keine solche Instruktion gefunden werden kann, wird eine wirkungslose Instruktion (NOP) ausgefuhrt. Die 2-stuge Pipeline wird in der Hardware durch die Register unterstutzt, die die Statussignale vom Operationswerk und die aktuelle Mikroinstruktion zwischenspeichern. Diese Register dienen beim Test als Scanpath und im normalen Betrieb als Pipelineregister. 94 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS 8.4 Erstellung des Mikroprogramms Die RT-Struktur des Prozessors beinhaltet alle benotigten Informationen, um das Mikroprogramm zu erstellen. Eine Mikroinstruktion besteht aus den in Tabelle 8.12 aufgefuhrten Mikrobefehlen (Feldern). Das Mikroprogramm des Scheme-Prozessors soll zusammen mit der RT-Struktur das gleiche Verhalten wie in der Verhaltensbeschreibung dargestellt aufweisen. Ein platz- und ausfuhrungszeitoptimales Mikroprogramm kann nur manuell erstellt werden. Der enge Zeitrahmen fur den Entwurf des Scheme-Prozessors lat jedoch keinen Raum fur diese zeitintensive manuelle Mikroprogrammierung. Das Mikroprogramm mute daher automatisch aus der Verhaltensbeschreibung generiert werden. Mikrobefehl (Feld) Komplementer- und Addierer-Operation Shifter-Operation Registeradresse IN Feldadresse IN Registeradresse OUT1 Feldadresse OUT1 Registeradresse OUT2, Konstante Feldadresse OUT2 Folgeadremikrobefehl Folgeadresse Bitbreite 2 2 5 2 5 2 5 2 4 10 Wertebereich siehe Tabelle 8.7 siehe Tabelle 8.8 siehe Tabelle 8.6 siehe Tabelle 8.5 siehe Tabelle 8.6 siehe Tabelle 8.5 siehe Tabelle 8.6, 0 bis 31 siehe Tabelle 8.5 siehe Tabelle 8.9 0 bis 1023 Tabelle 8.12: Mikrobefehle einer Mikroinstruktion. 8.4.1 Veroentlichungen uber automatische Mikroprogrammgenerierung Nach der Vorstellung des Konzeptes der Mikroprogrammierung durch Wilkes [Wilk51] 1951 fand der erste kommerzielle Einsatz in den 60er Jahren in Rechnern der Serie 360 von IBM statt. Ende der 70er, Anfang der 80er Jahre war die Technologie so weit fortgeschritten, da die Mikroprogrammierung nicht mehr nur durch den Rechnerhersteller, sondern fur den Anwender propagiert wurde. Die Technologie erlaubte groe und auch schreibbare Mikroprogrammspeicher, und der Anwender sollte seine Programme durch Verlagerung ins Mikroprogramm beschleunigen [Davi78, Davi83]. Es wurden hohere Programmiersprachen, Ubersetzer und Verikationswerkzeuge fur die Mikroprogrammierung erforscht [Muel84, Raus87]. Die Erndung des RISC-Prozessors, der die derzeitige VLSI-Technologie besser zu nutzen scheint als mikroprogrammierte Systeme, hat sich inzwischen weitgehend durchgesetzt. Die Mikroprogrammierung durch den Anwender bleibt weiterhin Spezialaufgaben vorbehalten. Mikroprogramme sind uberwiegend fest und bestimmen den Befehlssatz eines Prozessors. Um eine schnelle Abarbeitung der Maschinenbefehle zu erreichen, werden Mikroprogramme manuell erstellt. Mikroprogrammcompiler, die aus einer hoheren Beschreibung ein Mikroprogramm erzeugen, sind selten und auf Spezialrechner beschrankt. In der VLSI-Technologie werden Mikroprogramme in PLAs und ROMs gespeichert, da diese Speicher wesentlich weniger Transistoren enthalten und Flache belegen als die fur ladbare Mikroprogramme benotigten RAMs1 . 1 Mit VENUS-S generierte ROMs enthalten einen Transistor pro Bit, generierte RAMs sechs. 8.4. ERSTELLUNG DES MIKROPROGRAMMS 95 Der Scheme-Prozessor soll ein Mikroprogramm erhalten, das automatisch aus der in Pascal abgefaten Verhaltensbeschreibung generiert ist. Eine verwandte Aufgabe ist in der Dissertation von Nowak [Nowa86] 1986 in Kiel bearbeitet worden: Darin ist der mikroprogrammierbare Rechner SAMP entworfen und realisiert worden, dessen Mikroprogramme durch Mimola [Marw86] aus einer Pascal-ahnlichen Verhaltensbeschreibung u bersetzt werden. SAMP ist ein Rechner, der mehrere Zuweisungen an Variablen im Hauptspeicher parallel ausfuhren soll, was durch einen Hauptspeicher mit funf bidirektionalen Ports erreicht wird. Die Mikroprogramme werden in einen Speicher mit 4096 Worten von 142 Bit Breite geladen. SAMP wurde in TTL-Technologie aus 1463 ICs aufgebaut. Wegen der schon erwahnten Einschrankungen in Mimola | keine Residuumkontrolle und kein Pipelining | kann Mimola zur Generierung der Mikroprogramme fur den Scheme-Prozessor nicht eingesetzt werden. 8.4.2 Mikroprogrammgenerierung fur den Scheme-Prozessor Das Mikroprogramm fur den Scheme-Prozessor soll automatisch generiert werden. Da kein geeigneter Compiler zur Verfugung steht, mu ein Mikroprogrammcompiler, der die in der Verhaltensbeschreigung genutzten Pascal-Konstrukte in ein binares Mikroprogramm ubersetzt, erstellt werden (Abbildung 8.12). Der zu erstellende Compiler braucht nicht retargierbar zu sein, d.h. er mu nicht fur unterschiedliche Zielhardware Mikroprogramme generieren konnen, er soll nur ein Mikroprogramm fur die zuvor vorgestellte RT-Struktur generieren. An das erzeugte Mikroprogramm ist als Hauptanforderung zu stellen, da es maximal 1024 Worte belegt, da der ROM-Generator in VENUS-S weder ein ROM mit mehr als 1024 Worten bei einer Breite von 39-Bit erzeugen kann noch mehrere ROMs auf dem Chip untergebracht werden konnen. Zudem soll das Mikroprogramm die Moglichkeiten der Hardware vollstandig nutzen und verzogerte Sprunge (delayed branches) sowie Residuumkontrolle verwenden. Verhaltensbeschreibung Datei SCHEME.PAS ? Mikroprogrammcompiler ? Mikroprogramm Datei SCHEME.BIN Abbildung 8.12: Generierung des Mikroprogramms. Der Mikroprogrammcompiler liest ein Pascalprogramm ein und ubersetzt es in ein Mikroprogramm. Die Hardware, fur die das Mikroprogramm bestimmt ist, ist fest im Mikroprogrammcompiler vorgegeben. Ferner sind im Mikroprogrammcompiler alle Variablen mit ihrer Bitbreite und Adresse in der Registerbank vordeniert. Der Mikroprogrammcompiler pruft die Realisierbarkeit der Quellstatements durch die vorgegenene Hardware. Auch bei Konstanten wird u berpruft, ob die Hardware sie bereitstellen kann. Der Mikroprogrammcompiler ist als Single-Pass-Pascalcompiler ausgefuhrt, der seinen Code fur das ganze Programm in einem Feld ablegt. Der Fixup | das nachtragliche Eintragen der 96 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS Argumente von Vorwartssprungen in den erzeugten Code | wird durch dieses Feld vereinfacht. Der Mikroprogrammcompiler erzeugt ein Protokoll, in dem neben der Pascalquelle und eventuellen Fehlermeldungen auch die erzeugten Mikroinstruktionen mit ihren Adressen aufgefuhrt sind. ufung den Compilers und erlaubt eine Ruckverfolgung von MiDieses Protokoll dient der Uberpr kroprogrammadressen in die Pascalquelle, die erfolgen mu, wenn bei der spateren Simulation des Mikrocodes Fehler festgestellt werden. Der Ubersetzung des gesamten Mikroprogramms folgt eine Optimierungsphase, fur die das erzeugte Mikroprogramm in eine bidirektional verkettete Liste von Labels und Mikroinstruktionen ubersetzt wird. Auf dieser neuen Datenstruktur arbeitet dann der Mikroprogrammoptimierer regelgesteuert: Es wurde eine Reihe von Regeln entwickelt, die kompaktizierende und beschleunigende Modikationen am erzeugten Code beschreiben. Der Mikroprogrammoptimierer pruft der Reihe nach die Anwendbarkeit dieser Regeln und wendet sie auf den erzeugten Code an. Die Reihenfolge der Anwendung der Regeln wurde experimentell so ermittelt, da das optimierte Mikroprogramm kurz und schnell wird. Die Optimierung terminiert, wenn keine der Regeln mehr anwendbar ist. Zusatzlich zur Anwendung der Regeln berucksichtigt der Optimierer die geforderte Einhaltung der Zeitbedingungen fur das Pipelining. Es sind folgende Regeln enthalten: Zusammenfassen von Mikroinstruktionen. Da in den Mikroinstruktionen beliebige Belegungen der Steuerleitungen mit beliebigen Folgeadrebefehlen kombiniert werden konnen, konnen viele Sprungbefehle und Unterprogrammaufrufe mit ihrer Vorgangerinstruktion zusammengefat werden. Beispiel: mdr := tos JUMP L2 wird ersetzt durch mdr := tos, JUMP L2 ; sequentiell ; parallel sind wirNutzung der verzogerten Sprunge (delayed branches). In der Ubersetzungsphase kungslose Operationen (NOPs) eingefuhrt worden. In dieser Optimierung wird versucht, diese NOPs durch sinnvolle Mikrobefehle zu ersetzen. Beispiel: tos := mdr tos.type = 7 JUMP_EQ L2 ; Zuweisung ; Vergleich ; bedingter Sprung wird ersetzt durch mdr.type = 7 ; Vergleich tos := mdr, JUMP_EQ L2 ; Zuweisung parallel mit bedingtem Sprung Loschen nicht erreichbarer Mikroinstruktionen. Nach RETURN und unbedingten Sprungen wird (auer in Sprungtabellen) der Code bis zum nachsten Label geloscht. 8.4. ERSTELLUNG DES MIKROPROGRAMMS Beispiel: L1: 97 RETURN pc := mdr.cdr_code + 4 tos := mdr JUMP L2 wird ersetzt durch L1: RETURN JUMP L2 Auosung von Sprungbefehlen, die auf Sprungbefehle fuhren (branch chains). Beispiel: ... L1: JUMP L1 JUMP L2 wird ersetzt durch ... L1: JUMP L2 JUMP L2 Sprunge zu RETURN werden durch RETURN ersetzt. Beispiel: ... L1: JUMP L1 RETURN wird ersetzt durch ... L1: RETURN RETURN Optimierung von Endrekursion im Mikroprogramm. Beispiel: CALL L1 RETURN wird ersetzt durch JUMP L1 Bedingter Unterprogrammaufruf und bedingte Unterprogrammruckkehr wird ermittelt und durch die dafur vorgesehenen Folgeadremikrobefehle (call ne, call eq, return eq) realisiert. 98 KAPITEL 8. Beispiel: L2: ENTWURF UND REALISIERUNG DES PROZESSORS JUMP_EQ L2 CALL L1 wird ersetzt durch CALL_NE L1 Sprungbefehle werden zur Vermeidung gleicher Folgen von Mikroinstruktionen eingefuhrt (cross-jumping). Beispiel: ... mdr := tos mar := pc4 func := ctrl JUMP L1 mdr := tos mar := pc4 func := ctrl JUMP L1 wird ersetzt durch ... L2: JUMP L2 mdr := tos mar := pc4 func := ctrl JUMP L1 Neben der fur die Mikroprogrammierung moglichen Zusammenfassung von Mikroinstruktionen und der von RISC-Architekturen her bekannten Optimierungen verzogerter Sprunge [GrHe82] sind diese Regeln Peephole-Optimierungen, wie sie bei Wulf [Wulf75] beschrieben sind. Der Mikroprogrammcompiler ist ein vom Verfasser auf dem Atari ST erstelltes PascalProgramm von 2900 Zeilen. Abbildung 8.13 zeigt das Protokoll eines Compilerlaufes: Bei der Ubersetzung entstanden 1554 Mikroinstruktionen, die durch die Optimierungen auf 1024 Mikroinstruktionen reduziert wurden. Da genau die maximal mogliche Zahl von Mikroinstruktionen generiert wird, ist darauf zuruckzufuhren, da soviele Standardprozeduren wie moglich in in den Mikrocode verlagert wurden, bis auch das letzte Wort im Mikroprogrammspeicher ausgenutzt wurde. In Abbildung 8.14 wird ein Ausschnitt aus dem erzeugten binaren Mikroprogramm gezeigt. Die Mikrobefehle sind dort in der gleichen Reihenfolge wie in Tabelle 8.12 angegeben. Ein wichtiger Vorteil eines automatisch erzeugten Mikroprogramms ist, da es weniger fehlerbehaftet ist als ein manuell erstelltes. Da aber die Korrektheit des Mikroprogrammcompilers nicht vorausgesetzt werden kann, mu das generierte Mikroprogramm zusammen mit der Hardware simulativ auf gleiches Verhalten uberpruft werden. 8.5 Validierung von RT-Struktur und Mikroprogramm Es liegt eine Verhaltensbeschreibung in Pascal, eine Hardwarestruktur auf hoher Ebene und ein Mikroprogramm vor. Es mu jetzt uberpruft werden, ob die Hardwarestruktur zusammen mit dem 8.5. VALIDIERUNG VON RT-STRUKTUR UND MIKROPROGRAMM Mikroprogrammcompiler V3.1 fuer Pipeline-Hardware, JL 15-Mar-89. 1554 717 292 1 10 5 105 116 439 7 61 4 46 Mikroinstruktionen address references different labels calls expanded passes branches to RETURN replaced branch chains resolved unreachable instructions deleted control instructions merged tail recursion optimizations conditional CALLs conditional RETURNs pipeline merges 1024 Mikroinstruktionen geschrieben Abbildung 8.13: Protokoll eines Mikroprogrammcompilerlaufes. 0: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: AU 11 00 00 11 00 XX 00 XX 11 XX 00 11 SH 00 00 00 00 00 XX 00 XX 00 XX 00 00 AIN 00000 00011 01010 00000 00000 00000 00100 00000 00000 00000 10011 00000 RI XX 00 01 XX XX XX 11 XX XX XX 01 XX AOUT1 00100 00100 00100 00100 00100 XXXXX 00000 XXXXX 00100 XXXXX 00000 00100 R1 10 00 01 10 11 XX 01 XX 10 XX 01 10 AOUT2 00110 00000 00000 00100 00000 XXXXX 00001 XXXXX 01110 XXXXX 11110 01101 R2 00 00 00 00 00 XX 00 XX 00 XX 00 00 CONT 1010 1001 0100 0000 1001 1001 0001 0101 0000 1011 0001 0000 ADDRESS 00011110100 00001111001 00001010100 XXXXXXXXXXX 00001111000 00011110100 00001011011 XXXXXXXXXXX XXXXXXXXXXX 00001111100 00001101101 XXXXXXXXXXX ( ( ( ( ( ( ( ( ( ( ( ( 124) 127) 128) 130) 131) 133) 134) 136) 137) 138) 139) 142) Abbildung 8.14: Ausschnitt aus dem erzeugten binaren Mikroprogramm. 99 100 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS Mikroprogramm das gleiche Verhalten realisiert, das auch die Verhaltensbeschreibung beschreibt. Ein solcher Vergleich zweier Verhalten erfolgt im Entwurfsproze simulativ: Wenn beide Modelle fur sinnvoll ausgewahlte Folgen von Eingaben (Simulationsstimuli) die gleichen Reaktionen aufweisen, wird das Verhalten der Modelle als gleich angesehen. Fur eine Simulation des Scheme-Prozessors sind daher geeignete Stimuli zu benennen. Es ist ein Simulator fur Hardwarestruktur und Mikroprogramm zu erstellen und zu entscheiden, wie die Reaktionen zu vergleichen sind. Es sollten auf dieser Simulationsebene umfangreiche Simulationen vorgenommen werden konnen. Es sollten insbesondere Compilerlaufe simuliert werden. Das Ubersetzen des Scheme Compilers durch sich selbst (Compiler-Bootstrap) wurde zuvor bei der Uberpr ufung der Verhaltensbeschreibung als eine Anwendung, bei der viele Fehler, auch solche in der Garbage Collection, aufgedeckt wurden, identiziert. Ein Compiler-Bootstrap hat mit der Verhaltensbeschreibung eine Laufzeit von 1 3/4 Stunden auf dem Atari ST. Damit eine Simulation dieses komplexen Verhaltens auch von Mikroprogramm und Hardwarestruktur moglich ist, wurde der Simulator fur die RT-Struktur und das Mikroprogramm auch als Pascalprogramm realisiert. Der RT-Simulator beinhaltet das Verhalten der Strukturelemente in Pascal programmiert. Er liest das vom Mikroprogrammcompiler erzeugte Mikroprogramm ein und interpretiert es. Die Verhaltensbeschreibung wurde so erweitert, da sie bei jedem Hauptspeicherzugri und vor der Ausfuhrung jeder Bytecodeinstruktion den Inhalt aller Scheme-Prozessorregister ausgibt. Bei Lesezugrien auf den Hauptspeicher wird auch das gelesene Datum mit ausgegeben. Dem RT-Simulator dienen diese Ausgaben der Verhaltensbeschreibung sowohl als Stimuli als auch als Beschreibung der korrekten Reaktionen. Der RT-Simulator fuhrt die Mikroinstruktionen aus. Bei Hauptspeicherzugrien und vor der Ausfuhrung jeder Bytecodeinstruktion vergleicht er die Inhalte seiner Register mit den Registerinhalten, die die Verhaltensbeschreibung ausgegeben hatte. Bei Abweichungen meldet der Simulator einen Fehler und gibt seine sowie die erwarteten Registerinhalte zusammen mit den Adressen der letzten 16 ausgefuhrten Mikroinstruktionen aus. Wenn keine Abweichung vorliegt, ladt der Simulator bei Lesezugrien sein Register mdr mit der Ausgabe der Verhaltensbeschreibung. Der RT-Simulator ist als Koroutine in der Verhaltensbeschreibung realisiert. Fruhere Versionen kommunizierten uber Dateien und unter VMS als parallele Prozesse u ber VMS-Mailboxen. Verhaltensbeschreibung und Simulator wurden vom Verfasser auf dem Atari ST entwickelt und fur umfangreichere Simulationen nach VAX/VMS portiert. Die Verhaltensbeschreibung mit dem Simulator als Koroutine wurde erstellt, um auch sehr groe Simulationen zu ermoglichen. Beispielsweise wurden Compiler-Bootstraps simuliert. Derartig umfangreiche Simulationen fanden unter VAX/VMS auf einer VAX-8550 mit 7 MIPS statt und beanspruchten bis zu 8 CPU-Stunden. Gegenuber vorhandenen Simulatoren ermoglicht das gewahlte Vorgehen mit einem neu erstellten Simulator nicht nur die Simulation, sondern auch den Vergleich der Reaktionen gleichzeitig mit der Verhaltenssimulation. Damit ist auch die Auswertung der Simulationsergebnisse durch den erstellten Simulator automatisiert worden. Die Verwendung der Koroutinen vermeidet das Speichern der sehr groen Datenmengen fur Stimuli und Simulationsergebnisse, die besonders bei der Simulationsauswertung das ungeloste Hauptproblem darstellen [BuLa87]. Abbildung 8.15 zeigt den Simulator und seine Einbindung in die zuvor vorgestellten Programme. Insbesondere die Verhaltensbeschreibung wird dort in ihren beiden Eigenschaften dargestellt: Sie ist sowohl Datum (Eingabe fur den Mikroprogrammcompiler) als auch Operator (Verhaltenssimulator und Generator von Stimuli und Erwartungswerten). Uber die Uberpr ufung von RT-Struktur und Mikroprogramm hinaus liefert der Simulator statistische Informationen. Es wird die Anzahl der ausgefuhrten Mikroinstruktionen, die Anzahl der Lese- und Schreibzugrie auf den Hauptspeicher und auf jedes Prozessorregister sowie die Anzahl der Ausfuhrungen jeder Mikroinstruktion ermittelt. Diese Werte dienen der Optimierung der Hard- 8.5. VALIDIERUNG VON RT-STRUKTUR UND MIKROPROGRAMM 101 Stimuli, Verhaltensbeschreibung - Simulator Datei erwartete Reaktionen 6 SCHEME.PAS ? Mikroprogrammcompiler ? Mikroprogramm Datei SCHEME.BIN Abbildung 8.15: Einbindung des RT-Simulators in die Entwurfsprogramme. ware. Wenig genutzte Register konnen in den Hauptspeicher verlagert werden, nicht ausgefuhrte Mikroinstruktionen durch Erweiterung der Stimuli mitsimuliert werden. Die Anzahl der ausgefuhrten Mikroinstruktionen entspricht der Anzahl der Taktzyklen und erlaubt eine Abschatzung der Geschwindigkeit des Scheme-Prozessors. 102 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS 8.6 Realisierung des Scheme-Prozessors mit VENUS-S Es liegt sowohl eine RT-Struktur als auch das dazugehorige Mikroprogramm vor. Beide sind bereits simulativ validiert. Die sich anschlieende Phase ist die Verfeinerung der RT-Struktur auf Logikebene. Dabei werden die Elemente der RT-Ebene aus Standardzellen zusammengesetzt und miteinander verbunden, bis der Scheme-Prozessor fertig ist. Bei dieser Verfeinerung auf eine niedrigere Entwurfsebene sind Entscheidungen zu fallen, die die folgende Chipkonstruktion berucksichtigen: Es sind bei mehreren Realisierungsmoglichkeiten nicht nur die weniger platzaufwendigen zu bevorzugen, vielmehr wird die Konstruierbarkeit des Chips durch den fur Verdrahtung benotigten Platz bestimmt. Es sind Realisierungsmoglichkeiten zu nden, die wenig Verdrahtungsache benotigen. Auch die aus Standardzellen gebildeten Schaltungen (Elemente auf RT-Ebene, Steuerwerk, Operationswerk, ganzes Chip) sind simulativ zu validieren, wobei der Generierung der Stimuli und dem Vergleich mit den erwarteten Reaktionen Aufmerksamkeit zu schenken ist. Die Realisierung ist ein Bottom-Up-Vorgang: Eine Struktur auf hoherer Hierarchieebene wird aus ihren Bestandteilen (bereits realisierten Subsystemen) zusammengesetzt. Die Beschreibung der Realiserungen erfolgt daher von kleinsten zu den groeren Einheiten, von Buszugrismodul und ALU uber Operationswerk und Steuerwerk bis hin zum gesamten Prozessor. 8.6.1 Realisierung des Buszugrismoduls Der Buszugrismodul wird durch die Beschreibung als RT-Element und durch die Busspezikation des 68000 in [68000] speziziert. Ausgehend von diesen Spezikationen ist der Buszugrismodul als synchrones Schaltwerk mit JK-Flipops im August 1988 mit VENUS-S realisiert und simuliert worden. Da der Buszugrismodul im gesamten Prozessor der Modul ist, der unbedingt funktionieren mu, um nach der Fertigung des Prozessors alle anderen Moduln auf Entwurfsfehler hin uberprufen zu konnen, wurde der Buszugrismodul vorab gefertigt. Er sollte vor der Fertigstellung des Scheme-Prozessors getestet werden. Das Layout des Buszugrismoduls ist im Oktober 1988 zur Fertigung eingereicht worden. Leider lag er bis zur Abgabe des kompletten Scheme-Prozessors im April 1989 noch nicht vor. 8.6.2 Realisierung der ALU Vordringliches Ziel bei der Realisierung der ALU ist das Erzielen einer kurzen Verarbeitungszeit. Alle Operationen verwenden die ALU, auch ein Register-Register-Transfer erfolgt immer uber die ALU. Die ALU besteht aus Shifter, Negierer und Addierer. Der Shifter wird als Schaltnetz aus Multiplexern und Gatter gebildet. Der Komplementer entsteht aus EXOR-Gattern, und der Addierer ist in Carry-Look-Ahead-Technik realisiert. Der Shifter benotigt mehr Flache, als wenn er ein Schieberegister enthielte, und der Addierer ist auch achenintensiver als ein Ripple-CarryAddierer. Die gewahlten Realisierungen erzielen aber eine hohere Verarbeitungsgeschwindigkeit der ALU. 8.6.3 Realisierung der Registerbank Bei der Realisierung der Registerbank mit einem Eingangsport und zwei Ausgangsports gibt es verschiedene Moglichkeiten. Es ist eine Realisierung mit Multiplexern (Abbildung 8.16) und eine mit Tri-State-Bussen (Abbildung 8.17) moglich. Die Abbildungen zeigen schematisch eine Registerbank mit vier als Flipops (FF1 bis FF4) dargestellten Registern. 8.6. 103 REALISIERUNG DES SCHEME-PROZESSORS MIT VENUS-S IN FF1 A AA FF2 MUX1 AA A 11 111 FF3 1 A AA AA A OUT1 FF4 MUX2 111 11 OUT2 Abbildung 8.16: Realisierung der Registerbank mit Multiplexern. IN FF1 SS SS OUT1 FF2 SS SS FF3 FF4 SS SS SS SS OUT2 Abbildung 8.17: Realisierung der Registerbank mit Tri-State-Bussen. 1 104 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS Eine Abwagung zwischen den beiden Realisierungsmoglichkeiten erfolgt durch Vergleich der durch die Standardzellen belegten Flache und durch den Verdrahtungsaufwand. Ein 4:1Multiplexer hat eine Breite von 82 m, ein Tri-State-Treiber ist 41 m breit. Die Breiten sind proportional zur Flache, weil alle Standardzellen die gleiche Hohe (hier 134 m) aufweisen. Eine Abschatzung der Flache spricht fur eine Realisierung mit Multiplexern, da vier Tri-State-Treiber die doppelte Flache eines 4:1-Multiplexers belegen. Die Realisierung mit Multiplexern fuhrt dazu, da sehr viele Leitungen zu den Multiplexern zu fuhren sind. Ein interessantes und bemerkenswertes Ergebnis des Entwurfs war, da Leitungen in VLSI-Schaltungen eine groere Flache belegen als die Zellen selber. Der Verfasser hat sich fur die Realisierung mit Tri-State-Bussen entschieden und eine Plazierung der Standardzellen entwickelt, in der diese Busse nur Kanale u berqueren und somit nicht zur Verbreiterung der Kanale beitragen. Die Registerbank stellt das umfangreichste Schaltungsteil des gesamten Prozessors dar. Ein geschickter Entwurf der Registerbank ist der Schlussel zu einem Prozessor, der auf der sehr begrenzten Chipache Platz ndet. Abbildung 8.18 zeigt die durch die Tri-State-Busse mogliche Plazierung der Registerbank: Jede Standardzellzeile enthalt ein Register zusammen mit den Tri-State-Treibern fur beide Ausgange. Wie in der Abbildung gezeigt, konnen damit alle Busse senkrecht durch die Standardzellzeilen verlaufen, ohne die Kanalbreite zu beeinuen. Die drei Busse umfassen insgesamt 96 Leitungen, die damit sehr platzsparend verlegbar sind. Die Plazierung nutzt die Tatsache, da die Standardzellen oben und unten elektrisch aquivalente Anschlusse haben oder eine Moglichkeit aufweisen, Leitungen senkrecht u ber die Zellen zu fuhren. Die Breite der Zellen ist in der Abbildung mastabsgerecht gezeigt, die Latches weisen die achtfache Breite der Tri-State-Treiber auf. Latches (pegelgesteuerte Flipops) werden verwendet, weil sie die kleinsten speichernden Zellen sind. Die platzsparendste Ausfuhrung enthalt 8 Latches in einer Standardzelle; diese Ausfuhrung wird in der Abbildung gezeigt. OUT1 OUT2 IN OUT1 OUT2 Latch Latch Abbildung 8.18: Plazierung der Standardzellen in der Registerbank. 8.6. REALISIERUNG DES SCHEME-PROZESSORS MIT VENUS-S 105 8.6.3.1 Funktionseinheiten der Registerbank In die Registerbank sind beim Entwurf der RT-Struktur viele Aufgaben verlagert worden: Eine Feldauswahl erlaubt das Lesen und Schreiben einzelner Felder, Konstanten konnen generiert werden, und diverse Register haben Spezialfunktionen. Da die Registerbank aus Standardzellen manuell aufzubauen ist, konnen solche Spezikationen erfullt werden. Die Registerbank umfat ins gesamt 1600 Standardzellen und kann daher nur im Uberblick beschrieben werden. Der Uberblick soll die Einteilung der Registerbank in verschiedene Funktionseinheiten und deren Realisierung schildern. Die Registerbank enthalt als Kern die Register und ihre drei Busse. Zusatzlich mussen Adredekoder die Adressierung der Register ermoglichen, mu die Feldauswahl erfolgen und mussen die Register mit Spezialfunktionen wie Ein- und Ausgabe (mdr, mar, csr), Seiteneekte (test and set, test and clear) sowie die Pseudoregister (cur byte, pc4) entworfen werden. Abgesehen von den Spezialregistern mit Breiten von 1, 4, 8 und 22 Bit sind Register mit 24 und mit 32 Bit Breite vorhanden. Abbildung 8.19 zeigt die Struktur der Registerbank, bestehend aus den oben erwahnten Funktionseinheiten. Den Kern bilden die eigentlichen Register, die aus Latches und Tri-State-Treibern bestehen. Ferner fuhren zu diesem Kern auch die in dieser Abbildung nicht gezeigten Verbindungen mit der Auenwelt und dem Buszugrismodul. Die Latches haben Takteingange, die mit negativem Pegel das Datum von dem Eingangsbus ubernehmen. Da keine Latches mit Takt- und Enableeingang zur Verfugung stehen, mu der Takt durch ein Schaltnetz ausgeblendet werden: Der in Abbildung 8.19 rechts gezeigte Block "Schreibtakt\, erhalt den Takt "ClockWrite\ sowie die Register- und Feldadresse des zu schreibenden Registers. Jedes Register erhalt separate Takte fur seine drei Felder. Der Block "Schreibtakt\ schaltet den Takt nur auf das durch die Registeradresse ausgewahlte Register und auch nur auf das zu schreibende Feld dieses Registers. Nur wenn in das gesamte Register geschrieben werden soll, werden alle Takte geschaltet. Zusatzlich mussen, abhangig von den zu schreibenden Feldern, die Daten vom Eingang "IN\ auf die Eingange der Latches geschaltet werden. Der Block "Feldauswahl IN\ ubernimmt diese Aufgabe: Wenn das ganze Wort oder nur das Datenfeld geschrieben werden soll, lat er die Daten unmodiziert durch. Beim Schreiben in das Typfeld bzw. CDR-Codefeld werden die unteren sechs bzw. zwei Bits auf die Leitungen dieser Felder geschaltet. Der Block "Schreibtakt\ ist aus Dekodern ausgebaut, "Feldauswahl IN\ besteht aus zwei Multiplexern. Das Auslesen der Registerbank erfolgt folgendermaen: Die Tri-State-Treiber genau eines Registers pro Ausgangsbus werden durchgeschaltet. Die in der Abbildung links gezeigten Adredekoder steuern diese Treiber an. Der ausgelesene Registerinhalt wird in den Blocken "Feldauswahl OUTn\ zu einer mit "ReadClock\ bestimmten Zeit in Latches ubernommen. Das Zwischenspeichern der ausgelesenen Werte berucksichtigt, da die Ausgange der Registerbank u ber die ALU wieder auf den Eingang gefuhrt werden. Mit nur einem Latch in dieser Schleife wurde das Operationswerk zu einem asynchronen Schaltwerk. Die Hauptaufgabe der Blocke "Feldauswahl OUTn\ besteht darin, aus dem ausgelesenen Register die auszugebenden Felder auszuwahlen. "Feldauswahl OUT2\ kann zudem Konstanten generieren: "Addr Out2\ kann als Konstante, um fuhrende Nullen erweitert, ausgegeben werden. Die Adredekoder bestehen aus Dekodern, und die Feldauswahlbloocke sind aus Multiplexern, Gattern und Pullup-Zellen aufgebaut. Die Pullup-Zellen sorgen fur ein deniertes Potential auf den Tri-State-Bussen, wenn keiner der Treiber auf den Bus geschaltet ist. Diese Manahme ist bei MOS-Technologien erforderlich. 8.6.3.2 Realisierung der Spezialregister Die Register mit 24-Bit und 32-Bit Breite in der Registerbank sind wie in Abbildung 8.18 gezeigt realisiert. Uber diese Register hinaus enthalt die Registerbank noch Register mit Spezialfunktio- 106 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS IN ""24 ""?32 "8" Feldauswahl IN Adredekoder ""24 ""6 ? ? Daten Typen Addr Out1 ""5 "25"- Treiber OUT1 Addr Out2 ""5 "25"- Treiber OUT2 - ReadClock Feldauswahl OUT2 Range Out2 ""2 Range In ? S Takt " c Daten "22 h r e Takt " Register Typen " 5 i b t a Takt Cdr-Code "" 5 k t ""32 ? 6 "6"2 ""2 ? Cdr-Codes ""24 ? OUT2 ""32 ? Feldauswahl OUT1 6 ""62 ""32 " "8 Range Out1 "" 24 ? OUT1 Abbildung 8.19: Die Struktur der Registerbank. ""5 Addr In ClockWrite 8.6. REALISIERUNG DES SCHEME-PROZESSORS MIT VENUS-S 107 nen, die separat zu entwerfen und in drei Gruppen einteilbar sind: Pseudoregister, die Teile anderer Register reprasentieren. Die Register pc, pc4, cur byte und instr cache fallen in diese Gruppe. pc4 reprasentiert die hochstwertigen 24 Bits von pc, und cur byte reprasentiert eines von vier Bytes aus instr cache. Register mit Seiteneekten. Die Register tos valid, test and set und test and clear bilden diese Gruppe. Das Auslesen der Pseudoregister test and set und test and clear liest tatsachlich tos valid aus und modiziert es anschlieend. Register mit Ein- und Ausgabefunktionen. Die Register mar, mdr und csr haben diese Funktionen. Das Register mar halt die Hauptspeicheradressen. mdr ist das Ziel bzw. die Quelle beim Lesen bzw. Schreiben des Hauptspeichers. csr kann zum Abfragen des Status des Buszugrismoduls gelesen werden. Durch Schreiben in csr werden Buszugrie, Interrupts des Hostprozessors und Start sowie Beendigung der Aktivitat des Scheme-Prozessors initiiert. Die Realisierung dieser Register erfordert Multiplexer, die einzuschreibende Daten aus mehreren Quellen auswahlen und Taktausblendungen, die ein Einschreiben in Teile eines Registers ermoglichen (mdr, pc4, cur byte). Beim Auslesen werden Registerinhalte um vorstehende Nullen erweitert (csr, tos valid, pc4, cur byte), und es werden Teile der Register durch Multiplexer ausgewahlt (pc4, cur byte, mdr). Der Entwurf einer Struktur auf Gatterebene fur diese Spezialregister war sehr zeitintensiv. Die Strukturen sind sehr umfangreich, weshalb sie hier auch nicht schematisch durch eine Abbildung angegeben werden. Ferner durchbrechen diese Spezialregister das Plazierungsschema aus Abbildung 8.18, da sie auer Latches und Tri-State-Treibern auch Gatter und Multiplexer enthalten. Eine Plazierung unter Beibehaltung der Leitungsfuhrung fur die Busse wurde durch Aufteilung der Spezialregister auf mehrere Standardzellzeilen erreicht. 8.6.4 Realisierung des Operationswerks Das Operationswerk, in Abbildung 8.9 auf Seite 88 gezeigt, besteht aus Registerbank, ALU und Buszugrismodul. Das Operationswerk wurde als ein Makro aus Standardzellen aufgebaut. Ein 32-Bit Register bestimmt die Breite einer Standardzellenzeile. Da die Mehrzahl der Register nur 24 Bit breit sind, werden Buszugrismodul, Adredekoder und Generator fur die Schreibtakte auf den durch die fehlenden oberen 8 Bits freien Platz aufgeteilt. Abbildung 8.20 zeigt die Plazierung des Operationswerks. Auch bei der Plazierung des Operationswerks fuhrten Uberlegungen u ber die Leitungsfuhrung zu einer platzsparenden Realisierung. Der Kern wird von den 24-Bit und 32-Bit Registern gebildet. Zwischen diesen beiden Bereichen sind die Spezialregister angeordnet, da diese sowohl 24-Bit als auch 32-Bit Register beinhalten. Die Feldauswahllogiken benotigen alle drei 32-Bit Busse und sind daher unterhalb der 32-Bit Register angeordnet. An die Feldauswahllogiken ist die ALU angeschlossen, die sich auch in der Plazierung eine Zeile darunter anschliet. Neben den 24-Bit Registern wird der nicht benotigte Platz fur die obersten 8 Bits durch den Buszugrismodul, die Adredekoder und den Schreibtaktgenerator eingenommen. Insgesamt belegt das Operationswerk 25 Standardzellenzeilen, von denen die ALU und die Feldauswahllogik je zwei Zeilen und jedes 24-Bit und 32-Bit Register eine Zeile einnimmt. Der Platzbedarf der Spezialregister fallt sehr unterschiedlich aus: Das Register mdr belegt beispielsweise zwei Zeilen, wahrend sich die Register mar und tos valid eine Zeile teilen. Das Operationswerk besteht, wie in Tabelle 8.13 angegeben, aus genau 1796 Standardzellen, die mit 1360 Leitungen untereinander verbunden sind. Ursprunglich war geplant, das Operationswerk 108 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS Buszugrismodul 24-Bit Register Adredekoder Schreibtaktgenerator Spezialregister 32-Bit Register Feldauswahl IN, OUT1, OUT2 ALU Abbildung 8.20: Plazierung des Operationswerks. 8.6. REALISIERUNG DES SCHEME-PROZESSORS MIT VENUS-S 109 auf mehrere Standardzellenblocke aufzuteilen. Aber durch den Platzbedarf fur die Verdrahtung zwischen diesen Blocken waren die geforderte Chipabmessungen nicht einzuhalten. Nicht einmal der Buszugrismodul als separater Standardzellenblock erwies sich als vertretbar. Das Entwufssystem VENUS-S ist nicht fur Schaltungen dieses Umfangs ausgelegt. Es entstanden abnorm lange Programmlaufzeiten bei der Bearbeitung des Operationswerks: Die Netzlistenkompilation an der Workstation benotigte 8 Stunden. Die Chipkonstruktion erfolgte als ein Batchjob auf dem BS2000-Rechner mit mehreren Tagen Laufzeit. In beiden Fallen waren dies jeweils die einzigen Aktivitaten auf den Rechnern. Anzahl der Standardzellen Anzahl der Signale Anzahl der Transistoren Anzahl der Gatteraquivalente Flache in mm2 1796 1360 26908 6727 36,15 Tabelle 8.13: Statistik des Operationswerks. Fur die Chipkonstruktion wurden alle Standardzellen mit Positionen im Layout versehen. Das wird durch sogenannte Vorplazierungsproperties ermoglicht, die bei der Schaltplaneingabe an die Zellen vergeben werden konnen. Die meisten Zellen erhielten eine feste Position, einige Zellen wurden nur auf eine Standardzellzeile xiert, um spater bei der Chipkonstruktion eine optimale Position innerhalb der Zeile zu ermitteln. Auch die Positionen der Ein- und Ausgange des Operationswerks wurden in der Chipkonstruktion vorgegeben. 8.6.4.1 Validierung des Operationswerks Beim Entwurf der Funktionselemente Registerbank, ALU und Buszugrismodul mit VENUSS wurden diese Funktionselemente und auch die noch kleineren Einheiten jeweils mit dem in VENUS-S enthaltenen Simulator validiert. Auf diese Weise wurde eine Vielzahl von Fehlern vor der Fertigstellung des gesamten Operationswerks gefunden und korrigiert. Auch das Operationswerk wurde automatisch mit VENUS-S simuliert, wozu ein Stimulicompiler erstellt wurde, der Mikrobefehle fur das Operationswerk als Eingabe erhalt und sowohl die Stimuli fur den Simulator SMILE in VENUS-S als auch die erwartete Reaktion in der Beschreibungssprache EXPRESS fur das Programmpaket SIMUEVA [BuLa87] erstellt. Durch dieses Vorgehen konnen die Stimuli auf hoher Ebene erstellt werden, die Simulation ndet auf Gatterebene statt und die Simulationsergebnisse werden automatisch mit den erwarteten Reaktionen verglichen. Die Beschreibung auf hoher Ebene ist insbesondere notwendig, weil alle Daten durch den Buszugrismodul eingelesen und ausgegeben werden mussen, wofur ein Protokoll und Zeitbedingungen einzuhalten sind. Ferner erlaubt dieses Vorgehen auch das Erstellen der Testmuster fur den Test der Chips nach der Fertigung auf hoher Ebene. Auch diese sehr umfangreichen Muster werden durch den Stimulicompiler in Stimuli fur den Fehlersimulator ubersetzt und dann ihre Fehlerabdeckung ermittelt. Abbildung 8.21 zeigt den beschriebenen Ablauf bei der Simulation. Der Stimulicompiler ist ein vom Verfasser erstelltes Pascalprogramm von etwa 1800 Zeilen. 8.6.5 Realisierung des Steuerwerks Die Realisierung des Steuerwerks mit VENUS-S erfolgt durch zwei Makros: Das MikroprogrammROM ist ein generiertes Makro, und das Folgeadrerechenwerk ist als Standardzellblock realisiert. Beide Makros bilden zusammen das in Abbildung 8.10 auf Seite 90 dargestellte Steuerwerk. 110 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS Verhaltensbeschreibung als Mikrobefehle ? Stimulicompiler ? Stimuli ? ? erwartete Reaktionen VENUS Simulator ? Simulationsergebnisse ? SIMUEVA ? ? Simulation erfolgreich ? Abbildung 8.21: Simulation des Operationswerks auf Gatterebene. 8.6. REALISIERUNG DES SCHEME-PROZESSORS MIT VENUS-S 111 Um ein ROM zu erhalten, mu eine Steuerdatei erstellt werden, die das ROM einschlielich seines Inhaltes speziziert. Das vom Mikroprogrammcompiler erstellte binare Mikroprogramm wurde durch ein vom Verfasser erstelltes Programm in eine solche ROM-Steuerdatei fur VENUS umgesetzt. Das generierte ROM enthalt 43202 Transistoren, es belegt eine Flache von 7,77 mm 2 und weist eine Zykluszeit von 54 ns auf. Das Folgeadrerechenwerk ist auf Standardzellen aufgebaut. Es hat eine mit VENUS-S gut beherrschbare Komplexitat. Tabelle 8.14 zeigt eine Statistik des Folgeadrerechenwerks. Anzahl der Standardzellen Anzahl der Signale Anzahl der Transistoren Anzahl der Gatteraquivalente Flache in mm2 166 251 5472 1368 6,30 Tabelle 8.14: Statistik des Steuerwerks (ohne ROM). 8.6.5.1 Validierung des Steuerwerks Die Validierung des mit VENUS-S realisierten Steuerwerks durch Simulation wurde automatisiert. Der RT-Simulator wurde um eine Ausgabe von Stimuli fur den Simulator SMILE in VENUSS sowie um die Ausgabe der erwarteten Reaktionen erweitert. Da das Steuerwerk eine wenig umfangreiche Schaltung ist, konnten, verglichen mit dem Operationswerk und gesamten Chip, sehr umfangreiche Simulationen erfolgen: Simulationslaufe von zu 40000 Mikroinstruktionen erfolgten in nur 2 CPU-Stunden. Fur den Vergleich der erwarteten Reaktionen mit den Simulationsergebnissen wurde vom Verfasser ein Vergleichsprogramm im C erstellt. Das bei der Simulation des Operationswerks eingesetzte Programmpaket SIMUEVA konnte hier nicht verwendet werden, da es einerseits viel zu rechenzeitintensiv bei diesen groen Datenmengen ist und es andererseits keine Busse in den Simulationsergebnissen verarbeiten kann. Abbildung 8.22 zeigt die bei der Validierung des Steuerwerks beteiligten Programme und den Flu der Daten. 8.6.6 Realisierung des Prozessors Der Prozessor besteht aus dem Steuerwerk und dem Operationswerk. Diese beiden Bestandteile sind als Makros realisiert. Der Prozessor ist aus diesen Makros und den Padzellen, die die Verbindungen des Prozessors mit der Auenwelt ermoglichen, aufgebaut. Die in Abbildung 8.23 gezeigte Plazierung der Komponenten ermoglicht das Einhalten der Chipabmessungen. Eine Statistik des gesamten Prozessors ist in Tabelle 8.15 gezeigt. 8.6.6.1 Validierung des Prozessors Auch der gesamte Prozessor mute, wie zuvor seine Bestandteile, simulativ validiert werden. Die Erstellung der Stimuli wurde automatisiert. Der RT-Simulator wurde wiederum um eine Ausgabe von Stimuli fur den Simulator SMILE in VENUS-S erweitert. Eine Ausgabe der erwarteten Reaktionen der Simulation erfolgte nicht, da wegen des Umfangs der Schaltung keine sehr umfangreichen Simulationen moglich waren. Es galt aber die korrekte Verschaltung der Makrozellen 112 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS Verhaltensbeschreibung Stimuli, - Simulator erwartete Datei Reaktionen 6 SCHEME.PAS ? Mikroprogrammcompiler ? Mikroprogramm Datei SCHEME.BIN ? Mikroprogrammkonverter ? VENUS-Stimuli ? ROM-Gen.-Steuerdatei Datei Datei VENUS.ROM39F.INPUT VENUS.SCHEME1.SIG ? ROM-Generator ? VENUS-S Simulator SMILE ? VENUS-Simulationsergebnis Datei VENUS.SCHEME1.PRTLST Fehler ? ? 6 Vergleichsprogramm erwartete Reaktion Datei 6 SCHEME1.ERW Abbildung 8.22: Simulation des Steuerwerks auf Gatterebene. 8.6. REALISIERUNG DES SCHEME-PROZESSORS MIT VENUS-S Operationswerk MikroprogrammROM Steuerwerk Abbildung 8.23: Plazierung des Scheme-Prozessors. Anzahl der Standardzellen Anzahl der Transistoren Anzahl der Padzellen Anzahl der Gatteraquivalente (ohne ROM) Flache in mm2 1962 > 76000 82 8095 77,3 Tabelle 8.15: Statistik des Scheme-Prozessors. 113 114 KAPITEL 8. ENTWURF UND REALISIERUNG DES PROZESSORS und Padzellen und besonders ihr zeitlich korrektes Zusammenarbeiten zu verizieren. Die Simulationen umfaten wenig mehr als einhundert Taktzyklen. Der diese Simulationen begrenzende Faktor war der Plattenplatz, der belegt wurde, weil der Simulator jeden Signalwechsel eines jeden inneren Schaltungsknotens in eine Plattendatei protokolliert. 8.6.6.2 Gewahrleistung der Testbarkeit des Prozessors Zur Fertigung eines integrierten Schaltkreises sind als Entwurfsergebnisse das Layout der Schaltung und die Testmuster zu liefern. Die Testmuster erlauben dem Hersteller die Uberpr ufung jedes gefertigten ICs auf Herstellungsfehler. Beim Entwurf des Scheme-Prozessors wurde die Testbarkeit berucksichtigt. Jeder interne Schaltungsknoten kann auf einen Kurzschlu mit logisch \0" und logisch \1" uberpruft werden. Die Testbarkeit wird dadurch erreicht, da sowohl das Steuerwerk als auch das Operationswerk fur sich testbar sind und durch den in Abbildung 8.10 auf Seite 90 gezeigten Trenn-Scanpath (boundaryscan-path) zwischen Steuerwerk und Operationswerk auch die Verbindungen zwischen Steuerwerk und Operationswerk steuerbar und beobachtbar gemacht wurden. Nachdem die Testbarkeit auf hoherer Entwurfsebene durch den Scanpath prizipiell gewahrleistet wurde, verbleibt mit der Fertigstellung des Prozessors die Aufgabe, die Testmuster fur die gesamte Schaltung zu erstellen. Fur die Erstellung der Testmuster galt es, folgende Testmuster uber den Scanpath an ihr Zielmakro zu bringen und die Reaktionen an den Ausgangen dieses Zielmakros zu beobachten: Testmuster fur das Operationswerk. Diese Testmuster wurden auf der Ebene von Mikrobefehlen manuell erstellt und durch den Stimulicompiler in Stimuli fur den Logiksimulator umgesetzt. Testmuster fur das ROM. Diese Testmuster beinhalten das Auslesen des ROMs unter allen Adressen. Sie wurden durch ein Programm erstellt. Testmuster fur die Kombinatorik des Steuerwerks. Da das Steuerwerk neben PC, Mikroprogrammstack und Pipelineregistern aus umfangreichen kombinatorischen Schaltungsteilen besteht, wurden die speichernden Elemente aus einer Kopie des Steuerwerks entfernt, Testmuster fur die verbliebenen kombinatorischen Schaltungsteile automatisch generiert und diese Testmuster durch ein dafur erstelltes Programm um das Ein- und Ausschieben uber den Scanpath erweitert. Diese Muster testen das Steuerwerk mit Ausnahme von ROM und Stack. Testmuster fur den Mikroprogrammstack. Diese Testmuster wurden manuell erstellt. Ein in Pascal erstelltes Programm von etwa 450 Zeilen kombiniert die aufgezahlten Testmuster zu Testmustern fur den gesamten Scheme-Prozessor. Die dabei entstandenen Muster haben eine Lange von fast 600 KByte. Eine Fehlersimulation mit diesen Mustern konnte nicht erfolgen, da schon das Modell des ROMs fur den Fehlersimulator zu umfangreich war. Fur die Fehlersimulation erzeugt der ROM-Generator eine Ersatzschaltung aus Gattern. Aufgrund einer Unzulanglichkeit in VENUS-S sturzt der Fehlersimulator beim Einlesen des ROMs ab. Daher mute auf die Ermittlung der Testuberdeckung durch eine Fehlersimulation verzichtet werden. Kapitel 9 Die Ergebnisse In diesem Kapitel sollen die Ergebnisse des Prozessorentwurfs dargestellt werden. Ergebnisse sind auf den Chipentwurf bezogen Layout und Testmuster sowie elektrische Parameter wie die erreichbare Taktfrequenz. Auf die Implementierung der Sprache Scheme bezogen werden unter Ergebnissen Vergleiche des Scheme-Prozessors mit anderen Implementationen verstanden. Ergebnisse in Relation zu den zuvor entworfenen Scheme-Prozessoren konnen im Vergleich mit dem auf den Chips implementierten Sprachumfang, der Geschwindigkeit und der genutzten Flache erfolgen. Der Entwurf des letzten vorhergehenden Scheme-Prozessors stammt aus dem Jahre 1981. Abschlieend sollen daher neuere Architekturen fur LISP vorgestellt werden und ihre Realisierbarkeit mit den hier zur Verfugung stehenden Mitteln verglichen werden. 9.1 Das Chip Das im April 1989 neben den Testmustern zur Fertigung eingereichte Layout ist in Abbildung 9.1 gezeigt. Weil der Prozessor sogar weniger Platz als die zur Fertigung einzureichende Chipgroe belegt, wurde die freie Flache am unteren Rand und an der rechten Seite hinzugefugt. Entsprechend der schematischen Angabe in Abbildung 8.23 sind im Layout oben das Operationswerk, unten das Steuerwerk und zwar links das Mikroprogramm-ROM und rechts das Folgeadrerechenwerk plaziert. Das Layout wurde im April 1989 bei der Gesellschaft fur Mathematik und Datentechnik (GMD) in Birlinghoven eingereicht. Dort werden die Chip-Entwurfe der Hochschulen Prufungen unterzogen, zu Reticles zusammengefat und zur Fertigung an Siemens weitergeleitet. Bei diesen Prufungen an der GMD stellte sich heraus, da der Scheme-Prozessor das komplexeste jemals von einer bundesdeutschen Hochschule zur Fertigung eingereichte Chip ist [Stum89]. Fur eine dieser Prufungen, den Design-Rule-Check (DRC), eine Prufung auf das Einhalten geometrischer Regeln, mute der Prozessor sogar zerlegt werden, da das Prufprogramm von Siemens nur fur kleinere Chips konzipiert war [Stum89]. Der Scheme-Prozessor enthalt uber 76000 Transitoren, obwohl fur die verwendete Chipgroe laut Herstellerangaben nur maximal 36000 (vgl. Tabelle 6.2 auf Seite 55) erreichbar sind. Aus dem zur Fertigung eingereichten Layout wurden Leitungslaufzeiten extrahiert. Mit diesen Leitungslaufzeiten wurde eine maximale Taktfrequenz von 10,3 MHz simulativ ermittelt. Im November 1989 wurden zwanzig ungetestete Exemplare der gefertigten Scheme-Prozessoren geliefert. Die Prozessoren wurden auf Fertigungsfehler getestet und in einem Atari ST eingebaut. Die Tests ergaben elf bei 8 MHz Taktfrequenz im Atari ST funktionsfahige Prozessoren. 116 KAPITEL 9. DIE ERGEBNISSE Abbildung 9.2 zeigt einen der gefertigten Prozessoren mit geonetem Gehause, so da das Chip Abbildung 9.1: Das Layout des Scheme-Prozessors. sichtbar ist. In Abbildung 9.3 ist eine vergroerte Photographie des gefertigten Chips gezeigt. Die Softwareumgebung fur die Prozessoren wurde aus dem Verhaltenssimulator entwickelt. Im Verhaltenssimulator wurde die Hauptschleife, die den Bytecode interpretiert, durch einen Aufruf des Prozessors ersetzt. Ferner wurden Zugrie auf die Variablen, die im Simulator die Prozessorregister reprasentieren, durch Zugrie auf die Register ersetzt. Diese Softwareumgebung fur den Scheme-Prozessor verweilt die weitaus meiste Zeit in der STOP-Instruktion [68000] des 68000 und wartet auf einen Interrupt des Scheme-Prozessors, wodurch der Hauptspeicher dem SchemeProzessor fast immer exklusiv zur Verfugung steht. Die Softwareumgebung ist ein vom Verfasser erstelltes Pascalprogramm von 2200 Zeilen Lange und umfat 120 Zeilen in Assembler fur pri- 9.1. 117 DAS CHIP Abbildung 9.2: Photo des Scheme-Prozessors im geoneten Gehause. Abbildung 9.3: Photo des Chips im Gehause. 118 KAPITEL 9. DIE ERGEBNISSE vilegierte Befehle und Interruptbearbeitung. Die Softwareumgebung wurde bisher hauptsachlich genutzt, um den Scheme-Prozessor zu erproben und Benchmarks zu rechnen. 9.2 Die Implementation Um die Implementation im Vergleich zu anderen 68000-basierten Implementationen zu bewerten, wurden Vergleichsprogramme (Benchmarks) gerechnet. Gabriel hat in [Gabr85] eine Serie von Benchmarkprogrammen veroentlicht, die zum Vergleich von LISP-Programmen herangezogen werden. Diese Programme wurden auch mit dem gefertigten Scheme-Prozessor gerechnet und die Resultate zusammen mit Vergleichsdaten aus der Literatur in Tabelle 9.1 aufgefuhrt. Die Daten fur XScheme auf einem Atari ST wurden vom Verfasser ermittelt, MacScheme in Bytecode auf einem Macintosh Plus mit 512 KByte Hauptspeicher wurden [BaJe86] entnommen, und die Daten fur MacScheme in Maschinencode auf einem Macintosh SE mit 1 MByte Hauptspeicher stammen aus [Clin88]. Der angegebene Wert ist die Laufzeit in Sekunden als Mittelwert von 3 { 10 Programmlaufen direkt nach einer Garbage Collection [Gabr85]. Das Programm FIB (rekursive Fibonacci-Funktion) ist in [BaJe86] zusammen mit dem angegebenen Wert fur MacScheme veroentlicht. Die Werte fur den Scheme-Prozessor wurden auf einem Atari MegaST mit 8 MHz Taktfrequenz gemessen. Dem Scheme-Prozessor wurden dabei 250 KByte Speicher zugeordnet. Im Anhang ist die dabei verwendete externe Beschaltung fur den Scheme-Prozessor im Atari ST angegeben. Benchmark TAK FIB 20 DIV2 rekursiv DIV2 iterativ DERIV XScheme auf Atari ST 169,9 36,7 258,1 253,8 244,3 MacScheme Bytecode 72,24 22,50 143,69 60,17 243,36 MacScheme 68000-Code 10,5 8,281 52,161 36,151 112,4 Scheme-Prozessor im Atari ST 4,86 1,76 10,70 7,66 16,71 Tabelle 9.1: Vergleich des Scheme-Prozessors mit anderen 68000-Implementationen. Der Vergleich mit den 68000-Implementationen zeigt eine erhebliche Steigerung der Geschwindigkeit gegenuber den anderen Bytecode-Implementationen. Die gemessenen Werte ubersteigen sogar den ursprunglich angestrebten Faktor 10. Auch gegenuber realem 68000-Code ist der Scheme-Prozessor um etwa den Faktor 2 { 7 schneller. Besonders bedeutend ist der Geschwindigkeitsvorteil des Scheme-Prozessors im Benchmark DERIV, der symbolischen Ableitung eines Polynoms. DERIV ist | im Gegensatz zu TAK | eine Aufgabe, die sehr an LISP orientiert ist und die nicht so ezient wie TAK, das nur Prozeduraufrufe und Integer-Arithmetik beinhaltet, in Maschinencode ubersetzbar ist. Ferner ist zu berucksichti in Maschinencode mit einem gen, da die Prozessor-Implementation gegenuber einer Ubersetzung Bruchteil des Hauptspeichers fur Programme und Listen auskommt und damit bei gleicher Speichergroe wesentlich umfangreichere Systeme zulat. Speziell fur den Atari ST als Zielrechner ist die Implementation mit dem Scheme-Prozessor ein gewaltiger Fortschritt, da der Geschwindigkeitsgewinn gegenuber XScheme, der einzigen SchemeImplementation auf dem Atari ST, besonders hoch ist. 1 Dieses Ergebnis ist nicht in [Clin88] veroentlicht. Es wurde an der Universitat Oldenburg gerechnet. 9.3. 119 VERGLEICH MIT SCHEME-81 9.3 Vergleich mit Scheme-81 Ein Vergleich mit den beiden beim M.I.T. vorgenommenen Entwurfen braucht dieser SchemeProzessor nicht zu scheuen. Tabelle 9.2 zeigt einen Vergleich einiger Parameter der beiden Chips und der auf ihnen untergebrachten Funktionalitat. Der Vergleich zeigt, da beide Prozessoren mit einem 2 -Proze gefertigt wurden. Dieser Scheme-Prozessor entstand gegenuber Scheme-81 unter diversen erschwerenden Bedingungen: Er entstand in CMOS, das gegenuber NMOS fur die gleichen Funktionen mehr Transistoren benotigt. Er entstand in Standardzelltechnik, wodurch die Chipache weniger gut nutzbar war als in Full Custom. Es stand mit 77,3 mm2 weniger Chipache als die von Scheme-81 belegten 85 mm 2 zur Verfugung. Es mu den vorhandenen, nur 16 Bit breiten Hauptspeicher eines existierenden Rechners nutzen. Selbst unter diesen durch das Entwurfssystem, die Fertigung und den Einsatzbereich gegebenen Randbedingungen entstand ein Scheme-Prozessor, der einen wesentlich groeren Teil der Sprache als Scheme-81 implementiert, der Stack und Heap unterstutzt und eine Vielzahl von Standardprozeduren und Objekte implementiert. Technologie Design Flache implementierteStandardprozeduren Speicher unterstutzte Objekte Scheme-81 2 NMOS Full Custom 85 mm2 Listenprozeduren Garbage Collection Heap FIXNUM CONS-Zellen leere Liste Scheme-Prozessor 2 CMOS Standardzell 77 mm 2 Listenprozeduren Garbage Collection Vektorprozeduren Stringprozeduren numerische Prozeduren Charprozeduren Stack u. Heap FIXNUM CONS-Zellen leere Liste CDR-kodierte Listen Vektoren Strings Char Ports Controlframes Bindungsumgebungen Tabelle 9.2: Vergleich des Scheme-Prozessors mit Scheme-81. 120 KAPITEL 9. DIE ERGEBNISSE 9.4 Neuere Veroentlichungen uber Prozessorentwurfe fur Scheme und LISP uber neuere Prozessorentwurfe in der Literatur geboten werden. An dieser Stelle soll ein Uberblick Unter neueren Entwurfen sind hier solche zu verstehen, u ber die bei Einreichung des SchemeProzessors zur Fertigung noch keine Literatur vorlag. Inzwischen ist Scheme-86, ein weiterer Scheme-Prozessor vom M.I.T. [BeWu88a], beschrieben worden. Ferner wird ein LISP-Prozessor der Firma Texas Instruments stellvertretend fur den Stand der Technik bei industriellen Prozessoren vorgestellt. 9.4.1 Scheme-86 Scheme-86 [BeWu88a, BeWu88b, Wu88] ist ein weiterer Scheme-Prozessor, der am M.I.T. entworfen wurde. Scheme-86 arbeitet, wie seine Vorganger Scheme-79 [Suss81] und Scheme-81 [Bata82], einen S-Code ab. Auch bei Scheme-86 wird das Abarbeiten des S-Codes gegenuber Maschinencode als Vorteil dargestellt und der Prozessor als interpretierende Implementation beschrieben. Das Operationswerk von Scheme-86 beinhaltet eine Registerbank von 64 Registern von 32-Bit Breite mit drei Schreibports und acht Leseports. Es enthalt zwei ALUs und drei Komparatoren. Das Steuerwerk ist mikroprogrammiert. Das manuell erstellte Mikroprogramm umfat 4096 Worte von 160 Bit Breite und ist in einem RAM mit 35 ns Zugriszeit untergebracht [Wu88]. Scheme-86 wurde nie aufgebaut. Simulationen erfolgten unter Annahme der Verzogerungszeiten bei Verwendung der Advanced Schottky TTL-Technik, der schnellsten auf dem Markt erhaltlichen TTL-ICs. Eine Taktfrequenz von 6,1 MHz wurde simulativ erreicht. Mit Scheme-86 ergab der TAK-Benchmark eine Ausfuhrungszeit von 0,580 Sekunden. Das ist ein Geschwindigkeitsfaktor von 7,8 gegenuber dem in dieser Arbeit beschriebenen Prozessor. Im Vergleich mit dem in dieser Arbeit beschriebenen Scheme-Prozessor, mu berucksichtigt werden, da Scheme-86 unter anderen Randbedingungen als eine integrierte Schaltung entworfen wurde. Allein das Mikroprogramm-RAM von Scheme-86 hat die 16,4fache Kapazitat des ROMs des in dieser Arbeit beschriebenen Scheme-Prozessors. Ein ROM der zehnfachen Flache wurde schon die hier zur Verfugung stehende Chipache u bersteigen. Ein RAM weist noch einmal mindestens die sechsfache Flache eines ROMs auf. Auch eine Registerbank mit einer derartig groen Anzahl von Registern und Ports ist, wegen der benotigten Flache fur Leitungen, kaum VLSI-gerecht. Der direkte Vergleich der beiden Prozessoren ist nicht moglich, weil die Beschrankung des langsamen Hauptspeicherzugris bei Scheme-86 nicht vorliegt. Scheme-86 fuhrt in jedem Taktzyklus einen Hauptspeicherzugri aus. Er werden statische RAMs mit 45 ns Zugriszeit fur den Hauptspeicher eingesetzt. Scheme-86 ist damit ein diskret auf mehreren Platinen aufgebauter Prozessor aus den teuersten marktgangigen Standard-ICs. Ein solcher Prozessor ist nach Ansicht des Verfassers im Gegensatz zu IC-Entwurfen seit Jahren veraltet. Verglichen mit dem in dieser Arbeit beschriebenen Scheme-Prozessor ist Scheme-86 nicht VLSIgerecht entworfen. Ferner beinhaltete die Arbeit die Simulation von Scheme-86 auf allen Entwurfsebenen in Scheme und das Erstellen von Hilfssoftware in Scheme fur den Entwurf der (nicht fertiggestellten) Platinen fur Scheme-86 [Wu88]. Am Ende seiner Arbeit zieht Wu folgendes Fazit: "As a result of a lack of time, the SCode abstraction was taken wholesale from previous implementations of Scheme as instruction set for this machine. ::: Future work on this type of architecture must focus on designing an instruction set NEUERE VEROFFENTLICHUNGEN 121 that fully exploits the architecture and many known techniques of compiling Scheme.\ (Seite 34 in [Wu88]) Gerade diese Uberlegungen u ber eine eziente und (speziell fur unsere Randbedingungen) kompakte Reprasentation der Programme und die Entscheidung fur eine compilierende Implementation wurde in dieser Arbeit geleistet. Hier wurde keine Programmdarstellung gewahlt, nur weil sie vorhanden war, sondern die Reprasentation der Programme als Schlusselproblem erkannt und entsprechend ihrer Bedeutung berucksichtigt. Dafur wurde bestehende Entwurfssoftware genutzt, soweit sie vorhanden war und zusatzliche Hilfssoftware auch in Pascal und C erstellt. Es mute nicht jedes Programm in Scheme erstellt werden. Scheme behalt auch dann seine Berechtigung als Programmiersprache, wenn man es nicht fur jedes Programm einsetzt. 9.4.2 Texas Instruments' LISP-Chip Ein LISP-Prozessor von Texas Instruments soll hier zum Vergleich vorgestellt werden. Der Prozessor enthalt das Operationswerk und das Steuerwerk ohne Mikroprogrammspeicher auf einem Chip [Boss87, Matt87]. Das Chip soll eine bestehende Implementation | den TI Explorer |, der aus SSI und MSI ICs aufgebaut ist, so kompakt gestalten, da er fur militarische Anwendungen einsetzbar wird [Matt87], und mit dem LISP-Prozessor eine funache Geschwindigkeitssteigerung gegenuber dem TI Explorer erreichen [Boss87]. Abbildung 9.4 zeigt einen Teil der Struktur des LISP-Chips von TI. Die beiden Eingange (A und M) der ALU werden aus verschieden Quellen gespeist: Das A-Memory ist die einzige Quelle fur den Operanden A. Es ist ein Temporarspeicher von 1024 Worten, der dem Mikroprogrammierer zur Verfugung steht. Der ALU-Eingang M hat als eine Quelle auch einen solchen Temporarspeicher M-Memory mit 64 Worten. Eine andere Datenquelle von M ist das PDL-Memory, ein Speicher von 1024 Worten, der als Speicher fur den Stack genutzt wird. Das LISP-Chip von TI implementiert einen stackorientierten Befehlssatz, und im PDL-Memory stehen somit die Operanden der Makrobefehle. Weitere Funktionseinheiten | wie Stackpointer, Speicherdatenregister und Makrobefehlsqueue | sind in Abbildung 9.4 nicht dargestellt. Sie liefern auch Werte an den ALU-Eingang M. Den Speichern A-Memory , M-Memory und PDL-Memory ist je ein Scheibpuer von 4 Worten zugeordnet. Schreiboperationen schreiben Adresse und Datum in diesen Schreibpuer. In Taktzyklen, in denen der Speicher nicht ausgelesen wird, wird das Datum dann in den Speicher geschrieben. Wenn ein Schreibpuer u berlauft, wird der Prozessor fur eine Taktperiode angehalten und ein Datum aus dem Schreibpuer in den Speicher geschrieben. Ferner sind diese Speicher dynamisch realisiert, sie enthalten Refreshlogik und haben die Moglichkeit, den Prozessor fur einen Refresh anzuhalten. Die ALU beinhaltet einen Datenpfad uber einen Shifter und einen Masker. Shifter und Masker dienen unter anderem dem Extrahieren und Modizieren von einzelnen Feldern der Worte. Sie unterstutzen so die Einteilung der Worte in Felder. Das in der Abbildung nicht gezeigte mikroprogrammierbare Steuerwerk wird durch einen Speicher mit 2,5K Worten von 18 Bit Breite auf dem Chip unterstutzt. Dieser Speicher enthalt Sprungtabellen. Ferner sind auf dem Chip der Befehlsdekoder und der Mikroprogrammstack mit 64 Worten von 32 Bit Breite. Das Mikroprogramm ist auerhalb des Chips in einem 16K 2 64 Bit organisierten RAM abgelegt. Ein 16Kbit ROM auf dem Chip enthalt Programme fur den Selbsttest des Prozessors und zum Urladen seiner Mikroprogramme. Tabelle 9.3 zeigt einige statistische Daten des TI-LISP-Chips. Neben der Groe des Chips und der Transistorzahl fallt der sehr moderne Fertigungsproze auf. Zudem geht aus den Daten hervor, da das Chip uberwiegend aus Speicher besteht. Uber 88 % aller Transistoren sind in RAM oder ROM eingesetzt. 122 A- Write buer KAPITEL 9. - A-Memory 1K 2 32 - A-Reg - DIE ERGEBNISSE O-Bus ZALU ZZ ZMUX ZZ @ 0 M- Write buer PDL- Write buer - M-Memory 64 2 32 - - PDL Stack 1K 2 32 M-Reg Masker M-Bus Barrelshifter - Abbildung 9.4: Operationswerk des LISP-Prozessors von TI. Technologie Entwurfsart Flache Transistoren RAM Bits ROM Bits Anschlusse Taktfrequenz 1,25 CMOS Full-Custom 100 mm2 553687 114K 16K 224 33 MHz Tabelle 9.3: Statistik des LISP-Chips von TI. 9.5. BEWERTUNG DER ERGEBNISSE 123 Das TI-Chip wurde so entworfen, da er sowohl auf der Ebene seiner Maschinenbefehle als auch der seiner Makrobefehle kompatibel zum TI Explorer ist. Damit kann die vorhandene Software und Firmware weiterhin genutzt werden. Unter dieser Vorgabe wurde damit eine Architektur auf ein Chip gebracht, die als Neuentwurf sicherlich VLSI-gerechter erfolgt ware. Interessante Daten uber die Firmware, beispielsweise Angaben u ber die durchschnittliche Anzahl der in A-Memory und M-Memory tatsachlich genutzten Speicherplatze, sind leider nicht veroentlicht. 9.5 Bewertung der Ergebnisse Es wurde systematisch ein Prozessor entworfen, der auf einem Chip einen wesentlich groeren Teil der Sprache implementiert als die bisher entworfenen Scheme-Prozessoren. Alle nicht im Mikroprogramm implementierten Standardfunktionen werden durch den Wirtsprozessor oder durch Folgen von Maschinenbefehlen realisiert. Damit ist es auch der erste Scheme-Prozessor, der als Mittelpunkt einer vollstandigen Implementation der Programmiersprache Scheme dienen kann. Der Prozessor ist als Koprozessor fur vorhandene 68000-Rechner konzipiert. Dieses Konzept erlaubt eine preiswerte Beschleunigung dieser Rechner. Der Prozessor erlaubt im Vergleich mit bestehenden Softwareimplementationen eine sehr groe Geschwindigkeitssteigerung. Im Vergleich mit den vorhandenen Scheme-Prozessoren enthalt der hier beschriebene Prozessor mehr Funktionalitat auf kleinerer Flache und ist fur einen praktischen Einsatz konzipiert. Verglichen mit neueren Arbeiten (Scheme-86 und TIs LISP-Chip) ist dieser Prozessor VLSIgerecht entworfen und trotz der beschrankten Fertigungsmoglichkeiten der Hochschulen als EinChip-Prozessor realisiert. Kapitel 10 Schlussbetrachtungen Diese Schlubetrachtungen sollen einen Ausblick auf weitere Arbeiten bieten und berucksichtigungswurdige alternative Vorgehensweisen sowie die Abhangigkeit der gewahlten Losung von den Randbedingungen darstellen. 10.1 Ausblick Diese Arbeit beschreibt den Entwurf eines Prozessors, die dabei getroenen Implementierungsentscheidungen, die Randbedingungen und das erzielte Ergebnis. Im diesem Ausblick wird auf noch notige Arbeiten eingegangen, die auf dem entstandenen Prozessor aufbauend die SchemeImplementation vervollstandigen. Ferner werden auch Variationen der Randbedingungen und die daraus resultierenden Varianten im Entwurfsproze und Prozessor diskutiert. 10.1.1 Vervollstandigung der Implementation Der bis zu dieser Stelle beschriebene Prozessorentwurf resultierte in als Chip gefertigten SchemeProzessoren. Die Prozessoren wurden in einen Atari ST eingesetzt und mit einer Softwareumgebung versehen, die die Ausfuhrung von Scheme-Programmen ermoglicht. Die wichtigsten bisher ausgefuhrten Programme sind die Benchmarks (vergl. Tabelle 9.1 auf Seite 118), die den Vergleich mit anderen Scheme-Implementationen erlauben. Fur eine Implementation einer Programmiersprache ist ein schnelles und speichersparendes Ablaufen der Zielprogramme zwar ein sehr wichtiges, aber nicht alleiniges Kriterium fur einen Einsatz. Wichtig sind auch die Vollstandigkeit der Implementation, die uber den Sprachstandard hinausgehenden bereitgestellten Erweiterungen und eine benutzerfreundliche Gestaltung. Der Scheme-Prozessor und seine Softwareumgebung bieten zur Zeit: Einen Compiler, der jeden eingelesenen Ausdruck vor der Auswertung u bersetzt. Einen einfachen bildschirmorientierten Editor. Zahlreiche Standardprozeduren nach [Rees86]. Einen Debugger, der bei Aufruf und Verlassen einer Prozedur aufrufbar ist und bei Fehlern automatisch aufgerufen wird. Der Debugger erlaubt die Anzeige von Variableninhalten und eines Tracebacks sowie das Disassemblieren von Prozeduren. 10.1. AUSBLICK 125 Eine Prozedur zum Auslesen des vom Betriebssystem des Atari ST bereitgestellten 200 Hz Zahlers. Diese Prozedur wurde zur Unterstutzung der Benchmarkrechnungen hinzugefugt. Wunschenswerte Erweiterungen fallen in mehrere Klassen. Eine Klasse besteht in durch den Prozessor unterstutzten aber bisher nicht in der Softwareumgebung realisierten Erweiterungen. Solche Erweiterungen sind Zahlen der Typen FLONUM und BIGNUM. Ferner konnte die Softwareum gebung bei einem Uberlauf des Stacks den Stackinhalt in den Heap kopieren, so wie es auch der Befehl CALLCC macht und den Scheme-Prozessor anschlieend weiterarbeiten lassen (vergl. [BaJe86]). Bisher wird bei Stackuberlauf mit einer Fehlermeldung abgebrochen. Eine andere Klasse von Erweiterungen besteht im Hinzufugen von in der Softwareumgebung realisierten Prozeduren. In diese Gruppe fallen Anbindungen an die Graphiksystemkomponenten (AES, VDI) des Atari ST und an weitere Betriebssystemaufrufe (GEMDOS, BIOS, XBIOS). Insbesondere bei den Graphikaufrufen ist die Moglichkeit, den Scheme-Prozessor gleichzeitig mit der Softwareumgebung arbeiten zu lassen, eine bisher im Atari ST nicht mogliche Neuerung. Die letzte Klasse von Erweitungen ersetzt bestehende Komponenten durch verbesserte. Beispielsweise ist der Prozessor so konzipiert, da jeder Befehl und auch die Garbage Collection durch die Softwareumgebung ersetzt werden kann. Daher lat sich etwa mit einer inkrementellen Garbage Collection experimentieren und diese spater bei einer erneuten Fertigung des Prozessors in das Mikroprogramm verlagern. Ferner sollte insbesondere der Compiler durch einen neuen ersetzt werden, welcher Closure- und verbesserte Environmentanalysen vornimmt. Der bestehende Compiler ubersetzt jeden -Ausdruck in eine Closure, und er macht eine sehr pessimistische Environmentanalyse: Jede Prozedur, die einen -Ausdruck enthalt, legt ihre Bindungsumgebung im Heap an. Trotz dieses bestehenden Compilers wurden die beschriebenen Ergebnisse bei den Benchmarks erzielt. Es wird aber beispielsweise ein let-Ausdruck viel zu inezient u bersetzt, da dieser bei der Makroexpansion in den Aufruf eines -Ausdrucks u berfuhrt wird. Im Fall eines letAusdrucks mu weder eine neue Closure erzeugt noch die Bindungsumgebung grundsatzlich im Heap alloziert werden. Der neue Compiler wird bereits im Rahmen einer Diplomarbeit entwickelt. 10.1.2 Verbesserungsmoglichkeiten des Prozessors Bei jedem Programm und jeder Hardware entstehen nach der Fertigstellung Wunsche nach Erweiterungen und Verbesserungen. Der Scheme-Prozessor bildet dabei keine Ausnahme. Auch durch Erfahrungen mit dem Prozessor werden beispielsweise bestimmte Befehle als verzichtbar und andere, nicht enthaltene als wunschenswert angesehen. Verbesserungsideen des Verfassers sind: Eine inkrementelle Garbage Collection. Durch die unterbrechende Garbage Collection unterscheidet sich der Scheme-Prozessor im Atari ST von kommerziellen LISP-Maschinen. Die Erstellung einer inkrementellen Garbage Collection wurde noch vor Einreichung des Prozessors zur Fertigung in Angri genommen. Allerdings gelang es in der zur Verfugung stehenden Zeit nicht, diese soweit simulativ zu validieren, da sie in das Mikroprogramm des gefertigten Prozessors aufgenommen werden konnte. Bedingte Sprungbefehle, die das oberste Stackobjekt zwar auf die Sprungbedingung hin untersuchen, es aber auf dem Stack belassen. Solche Befehle, wie sie von Masinter und Deutsch vorgeschlagen werden [MaDe80], erlauben insbesondere eine ezientere Ubersetzung von and und or. Die Prozeduren make-code-vector und code-vector-set konnten vom 68000-Rechner ubernommen und dafur beispielsweise assq durch einen Prozessorbefehl unterstutzt werden. 126 KAPITEL 10. SCHLUSSBETRACHTUNGEN Ein Einschrittbetrieb (single-instruction mode) des Prozessors hatte beim Erproben der gefertigten Prozessoren gute Dienste geleistet. jemals realisiert werden, hangt davon ab, ob ein anderer ProOb und welche dieser Anderungsideen zessor gefertigt wird. Die Fertigung des Scheme-Prozessors hat etwa DM 150.000{200.000 gekostet. Fur relativ kleine Verbesserungen ist ein erneuter Einsatz solcher Mittel kaum zu rechtfertigen. 10.1.3 Entwurfsmoglichkeiten bei anderen Randbedingungen Der Entwurf des Scheme-Prozessors erfolgte unter vorgegebenen Randbedingungen. Zu den Randbedingungen gehorte das Entwurfssystem VENUS-S, da nur dieses zur Verfugung stand und das Bundesministerium fur Forschung und Technologie die immensen Kosten fur die Fertigung der mit VENUS-S entstandenen Chips u bernahm. Andere Randbedingungen ergeben sich auch, wenn der Scheme-Prozessor fur einen anderen Zielrechner (nicht mit 68000-Prozessor) oder als eigenstandiges System speziziert ware. 10.1.3.1 Einu eines anderen Entwurfssystems Das Entwurfssystem VENUS-S hatte insbesondere die folgenden einschrankenden Einusse auf den Prozessorentwurf: Eine Registerbank mute aus Standardzellen aufgebaut werden, und das Mikroprogramm-ROM konnte keine groere Kapazitat haben. Beide Einusse bestehen in anderen Entwurfssystemen nicht, wobei die anderen Entwurfssysteme auch einen 2 m CMOS-Proze und die Standard- und Makrozelltechnik unterstutzen. Die Standardzell-Bibliothek der Firma Texas Instruments [TI] ist nicht nur wesentlich umfangreicher als die von VENUS-S [Siem88]. Sie enthalt insbesondere Zellen, die den Entwurf des Scheme-Prozessors wesentlich erleichtert hatten: Fur eine Registerbank steht die Grundzelle ugung [TI]. Sie hatte eine weRF408LH , die bei 8 Bit Breite 3 Ports und 16 Adressen bietet, zur Verf sentlich umfangreichere, schnellere und kompaktere Registerbank ermoglicht, wodurch wesentlich mehr Register zur Verfugung gestanden hatten, die einen schnelleren Prozessor und einen registerorientierten Befehlssatz ermoglichten. Ferner sind in der Zellbibliothek auch die Zellen 2901, 2902, 2904 und 2910 enthalten. Dabei handelt es sich um zu Prozessoren kaskadierbare sogenannte Slices. Auch damit sind Prozessoren sehr einfach entwerfbar. Zusatzlich erlaubt TI den Einsatz von ROMs, deren Adrezahl keine Zweierpotenz ist. Diese ROMs konnen dann umfangreichere Mikroprogramme enthalten, deren Umfang nur durch die Chipache begrenzt ist. Die Entwurfssoftware Solo 2000 [ES2b] der Firma European Silicon Structures (ES2) ermoglicht den Entwurf einzelner Makros in Full-Custom Technik. Damit ware ein manueller Entwurf der Registerbank in Full-Custom Technik und damit auf minimale Flache optimiert moglich gewesen. Auch das hatte einen schnelleren, registerorientierten Prozessor ermoglicht. Auch bei ES2 mu das ROM keine Zweierpotenz von Adressen enthalten [ES2a]. Eine weitere Leistungssteigerung des Scheme-Prozessors ware durch einen Cache fur den Stack erreichbar. Ein solcher Cache ist in Full-Custom-Technik mit Solo 2000 realisierbar. Ferner fertigt ES2 sehr preiswert und schnell, da es mit Elektronenstrahldirektbelichtung arbeitet und somit auf die zeit- und kostenintensive Erstellung von Masken verzichten kann. 10.1.3.2 Einu eines anderen Zielrechners Der hier beschriebene Scheme-Prozessor wurde fur den Einsatz in einem 68000-Rechner konzipiert. Der Scheme-Prozessor mute den vorhandenen Hauptspeicher des 68000-Rechners nutzen. Dieses Konzept wurde im Jahre 1988 festgelegt, als Speicherchips nicht nur extrem teuer waren, sondern auch nur Kunden mit langfristigen Vertragen uberhaupt beliefert wurden. An dieser Stelle soll 10.2. ANWENDUNG AUF NEUARTIGE ENTWURFSSOFTWARE 127 untersucht werden, wie sich Konzept und Architektur unterscheiden, wenn ein anderer Zielrechner als ein 68000-System mit einem solchen Scheme-Prozessor ausgestattet werden soll. Bei einem Verzicht auf die Nutzung des vorhandenen Hauptspeichers des Zielrechners konnte ein anderes Wortformat gewahlt werden. Das beim realisierten Scheme-Prozessor gewahlte Wortformat mute die Wortbreite des vorhandenen Hauptspeichers berucksichtigen. Bei einem SchemeProzessor mit eigenem Hauptspeicher konnte das Feld fur Datum und Pointer von 24-Bit auf 32-Bit erhoht werden. Damit waren dann 32-Bit FIXMUNs und Fliekommazahlen in einem Wort darstellbar (vgl. Symbolics 3600 [Moon85] und SPUR [Kong89]), und die Wortbreite erhohte sich auf 40 Bit. Der 68000-Prozessor im Zielrechner konnte bei der Abarbeitung von Scheme-Programmen vom Scheme-Prozessor u bertroen werden, weil der Scheme-Prozessor Typenprufungen, Prozeduraufrufe und die Speicherverwaltung besser unterstutzt, aber sonst ahnliche Merkmale wie der 68000Prozessor aufweist: beide sind mikroprogrammiert, haben keinen Befehls- und Datencache, arbeiten bei gleicher Taktfrequenz, und sie enthalten eine a hnliche Zahl von Transistoren (etwa 68000 im 68000-Prozessor [DaBr85], uber 76000 im Scheme-Prozessor). Einen leistungsahigeren Prozessor wie den 68020 mit 200.000 Transistoren [DaBr85], Befehlscache und wesentlich hoherer Taktfrequenz kann dieser Scheme-Prozessor in seiner Leistung nicht ubertreen. Ein Scheme-Prozessor fur Zielrechner mit solchen leistungsfahigen Prozessoren mu auch eine entsprechend hohere Taktfrequenz zulassen und u ber einen Cache verfugen. Um einen solchen leistungsfahigeren Scheme-Prozessor zu erstellen, werden auch leistungsfahigere Entwurfssysteme und Fertigungsprozesse benotigt. 10.2 Anwendung auf neuartige Entwurfssoftware Fur des Entwurf des Scheme-Prozessors wurde ein systematisches Vorgehen eingefuhrt, das dem restriktiven Zeitplan Rechnung tragen sollte. Um systematisch eine Prozessorarchitektur entwerfen zu konnen, wurde die als Pascalprogramm vorliegende Verhaltensbeschreibung analysiert. Die erhaltenen Analyseergebnisse umfaten haug auftretende Befehlsfolgen, die Verteilung der Register und Registerfelder in Ausdrucken und Zuweisungen, die verwendete Kontrollstrukturen und eine Grammatik der enthaltenen Ausdrucke. Diese Analyseergebnisse beschreiben Anforderungen an die Hardwarearchitektur des entworfenen Prozessors: Die Haugkeit der Ausdrucke mit zwei Operanden erforderte eine Registerbank mit mindestens zwei Ausgangsports. Die bei der Analyse der Verhaltensbeschreibung ermittelten haugen Schreib- und Lesezugrie auf einzelne Felder der Register fuhrte zur Entscheidung fur eine Registerbank mit drei Ports, die neben den Portadressen auch die einzelnen Felder direkt adressieren kann. Die Spezikation der ALU wurde direkt aus der Grammatik der in der Analyse ermittelten Ausdrucke entwickelt. Die ALU kann alle diese Ausdrucke in 20 ns berechnen. Auch die Struktur des Steuerwerks wurde so entworfen, da sie sowohl den Anforderungen aus der Analyse der Verhaltensbeschreibung dient als auch den Randbedingungen des Entwurfssystems genugt: Ein mikroprogrammiertes Steuerwerk mit einem Mikroprogramm-ROM mit 39 Bit Breite und 1024 Worten, der mit dem Entwurfssystem maximal moglichen ROM-Groe, ermoglicht eine Vielzahl von aus den Kontrollstrukturen der Verhaltensbeschreibung entwickelten Folgeadressierungen. Diese Analyse und die daraus folgenden Entwurfsentscheidungen sind eine interessante Alternative zu existierenden Synthesewerkzeugen, die automatisch aus einer Verhaltensbeschreibung eine Struktur entwerfen. Solche Synthesewerkzeuge, wie Mimola [Marw86], enthalten eine Bibliothek von verwendbaren Bausteinen und deren Kosten und synthetisieren eine Struktur aus diesen Bausteinen. Diese Synthese aus den festen Bausteinen basiert auf dem traditionellen Ansatz einer diskreten Realisierung. Fur einen VLSI-Entwurf scheint der Ansatz beim Entwurf des Scheme- 128 KAPITEL 10. SCHLUSSBETRACHTUNGEN Prozessors eine berucksichtigenswerte Alternative zu sein, da aus der Verhaltensbeschreibung Daten wie eine Grammatik der verwendeten Ausdrucke oder Haugkeiten von Ausdrucken mit zwei Registeroperanden ermittelt wurden, die in Hinblick auf zukunftige, den Entwurf unterstutzende Expertensysteme auf einem Abstraktionsniveau liegen, auf dem Erklarungen und Fragen an den Entwerfer gerichtet werden konnen. Auch die beim Entwurf des Scheme-Prozessors erarbeiteten Kriterien fur Stack- oder Registerarchitektur und fur die Anzahl der Ports der Registerbank konnen als Regeln in ein solches Expertensystem eingebracht werden. Anhang A Der Befehlssatz des Scheme-Prozessors In diesem Anhang wird der vollstandige Befehlssatz angegeben, der vom Prozessor durch das Mikroprogramm ausgefuhrt wird. Zusatzliche Befehle, die bei der Assemblerprogrammierung des Prozessors zwar wie Bytecodebefehle gehandhabt werden, tatsachlich aber als Aufrufe des Wirtsprozessors implementiert sind, werden hier nicht zum Befehlssatz gerechnet. Die Befehle werden tabellarisch aufgezahlt. Die Anzahl der Argumente beschreibt die Anzahl der Bytecodeargumente; auf dem Stack ubergebene Objekte sind damit nicht gemeint. Das angegebene Befehlsformat bezieht sich auf die Darstellung in Kapitel 7.5 (Seite 70). Alle Befehle nehmen Typprufungen vor. Bei den numerischen Befehlen wird bei Argumenten aufen zum Wirtsprozessor verzweigt. Das gilt auch der Typen FLONUM und BIGNUM und bei Uberl fur den Befehl COMPARE, wenn er auf Zahlen, die nicht beide vom Typ FIXNUM sind, arbeitet. A.1 Zugrie auf Variablen Bytecodebefehl PUSHLOCAL PUSHVAR PUSHGLOBAL UNBOUNDP STORELOCAL STOREVAR STOREGLOBAL Argumente 1 2 1 0 1 2 1 Zugrie auf Variablen Format Bemerkung A Auslesen einer lokalen Variablen B Auslesen einer u bergeordneten Variablen A Auslesen einer globalen Variablen A Prufung, ob oberstes Stackobjekt Bindung hat A Zuweisung an lokale Variable B Zuweisung an ubergeordnete Variable A Zuweisung an globale Variable 130 ANHANG A. DER BEFEHLSSATZ DES SCHEME-PROZESSORS A.2 Zugrie auf Konstanten Bytecodebefehl PUSHLIT PUSHCLOSURE PUSHPINT PUSHNINT PUSHT PUSHF Argumente 1 1 1 1 0 0 Zugrie auf Konstanten Format Bemerkung A Konstante aus Literalbereich A Codevektor aus Literalbereich und die aktuelle Bindungsumgebung bilden Closure A Zahl im Bereich von 0 bis 255 A Zahl im Bereich von 0256 bis 01 A Boole'scher Wert #T A #F bzw. leere Liste A.3 Sprung- und Verzweigungsbefehle Bytecodebefehl BRANCH BRANCHF BRANCHT Sprung- und Verzweigungsbefehle Argumente Format Bemerkung 2 B unbedingter Sprung 2 B bedingter Sprung 2 B bedingter Sprung A.4 Aufruf und Ruckkehr von Prozeduren Bytecodebefehl PUSHCONTROL CALL STACKTRCALL HEAPTRCALL HEAPCONTEXT SLIDE RETURN SUBR CALLCC Aufruf und Ruckkehr von Prozeduren Argumente Format Bemerkung 0 A Anlegen eines Controlframes 0 A nicht endrekursiver Prozeduraufruf 0 A endrekursiver Prozeduraufruf, Bindungsumgebung des Aufrufers im Stack 0 A endrekursiver Prozeduraufruf, Bindungsumgebung des Aufrufers im Heap 0 A Kopieren der Bindungsumgebung in den Heap 1 A endrekursiver Aufruf der gerade aktiven Prozedur 0 A Ruckkehr von der Prozedur 1 A Aufruf des Wirtsprozessors 0 A Standardprozedur call-with-currentcontinuation A.5 Typprufungen und Vergleiche Bytecodebefehl TYPECHK EQ COMPARE Typprufungen und Vergleiche Argumente Format Bemerkung 1 B implementiert alle Typpradikate 0 A Standardprozedur eq? 1 B Vergleich von Zahlen und Zeichen A.6. LISTEN- UND VEKTORBEFEHLE A.6 Listen- und Vektorbefehle Bytecodebefehl CONS CAR CDR SETCAR SETCDR MLIST LISTN MAKEVECTOR VECTORSET VECTORREF VECTORLENGTH MAKECODEVECTOR CODEVECTORSET MVECTOR MVECTORN Argumente 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 Listen- und Vektorbefehle Format Bemerkung A Standardprozedur cons A Standardprozedur car A Standardprozedur cdr A Standardprozedur set-car! A Standardprozedur set-cdr! A Standardprozedur list, 255 Argumente A Standardprozedur list, > 255 Argumente A Standardprozedur make-vector A Standardprozedur vector-set! A Standardprozedur vector-ref A Standardprozedur vector-length A Prozedur make-codevector A Prozedur codevector-set! A Standardprozedur vector, 255 Argumente A Standardprozedur vector, > 255 Argumente A.7 Numerische Befehle Bytecodebefehl DEC INC NEG ADD SUB MUL DIVOP REM MINUSP ZEROP Argumente 0 0 0 0 0 0 0 0 0 0 Numerische Befehle Format Bemerkung A Standardprozedur -1+ A Standardprozedur 1+ A Standardprozedur - fur ein Argument A Standardprozedur + fur 2 Argumente A Standardprozedur - fur 2 Argumente A Standardprozedur * fur 2 Argumente A Standardprozedur quotient fur 2 Argumente A Standardprozedur remainder fur 2 Argumente A Standardprozedur minus? A Standardprozedur zero? A.8 Zeichen- und zeichenkettenorientierte Befehle Bytecodebefehl CHARTOINT INTTOCHAR MAKESTRING STRINGLENGTH STRINGREF STRINGSET Zeichen- und zeichenkettenorientierte Befehle Argumente Format Bemerkung 0 A Standardprozedur char!integer 0 A Standardprozedur integer!char 0 A Standardprozedur make-string 0 A Standardprozedur string-length 0 A Standardprozedur string-ref 0 A Standardprozedur string-set! 131 132 ANHANG A. DER BEFEHLSSATZ DES SCHEME-PROZESSORS A.9 Sonstige Befehle Bytecodebefehl DUPLICATE DROP STOP Argumente 0 0 0 Sonstige Befehle Format Bemerkung A Duplizieren des obersten Stackobjekts A Entfernen des obersten Stackobjekts A Anhalten des Scheme-Prozessors Anhang B Geh ause und Anschlussbelegung des Scheme-Prozessors Zwanzig gefertigte Prototypen des Scheme-Prozessors wurden im November 1989 geliefert. Sie sind in 88poligen Keramikgehausen des Typs PGA-88 montiert. Das Gehause bzw. die Anschlubelegung der Prozessoren sind in Abbildung B.1 bzw. in Tabelle B.1 angegeben. Abbildung B.1: Das Gehause PGA-88 der Scheme-Prozessors. Die im Vergleich mit industriellen Prozessoren relativ hohe Zahl von Masse- und Betriebsspannungsanschlussen ist notig, weil bei Hauptspeicherschreibzugrien dieses Prozessors die u berwiegende Zahl aller Zellen gleichzeitig als Ausgang treiben. Die Entwurfsregeln verlangen dann pro acht Treiberzellen einen Masseanschlu [Siem88]. Bei industriellen Prozessoren konnen Versorgungsspannungsbahnen auf dem Chip fur solche Falle besonders breit ausgelegt werden. In VENUS-S sind solche Eingrie durch den Benutzer nicht vorgesehen. 134 ANHANG B. Pin G1 F2 F1 E1 E2 D1 D2 C1 B1 C2 A1 B2 B3 A2 B4 A3 A4 B5 A5 B6 A6 B7 UND ANSCHLUSSBELEGUNG DES SCHEME-PROZESSORS GEHAUSE Signal A6 A7 A8 A9 A10 A11 BGACK LDS Masse +5 V | | UDS | CS BGIN BR IRQ WAIT2 +5 V ROMCLK | Pin A7 B8 A8 A9 B9 A10 B10 A11 A12 B11 A13 B12 C12 B13 D12 C13 D13 E12 E13 F12 F13 G12 Signal LTEST SCANCLK | Masse FC0 FC1 FC2 SCANOUT RESET SCANIN | | Masse STKCLK UPCCLK A23 A22 +5 V +5 V A21 A20 | Pin G13 H12 H13 J13 J12 K13 K12 L13 M13 L12 N13 M12 M11 N12 M10 N11 N10 M9 N9 M8 N8 M7 Signal A19 A18 A17 A16 A15 A14 A13 A12 Masse | | D15 D14 D13 D12 D11 D10 Masse CLKREAD +5 V D9 D8 Pin N7 M6 N6 N5 M5 N4 M4 N3 N2 M3 N1 M2 L2 M1 K2 L1 K1 J2 J1 H2 H1 G2 Signal D7 D6 Masse CLKWRITE +5 V D5 D4 D3 D2 D1 D0 DTACK AS R/W Masse BUSCLK +5 V A1 A2 A3 A4 A5 Tabelle B.1: Die Anschlubelegung der Scheme-Prozessors. Anhang C Externe Beschaltung des Scheme-Prozessors Der Scheme-Prozessor ist fur den Einsatz in 68000-Rechnern entworfen. Er generiert alle benotigten Signale und wird ohne zusatzliche Logik direkt an den 68000-Bus angeschlossen. Der SchemeProzessor enthalt Treiberzellen, die 5.5 mA Dauerstrom aufnehmen (bei logisch 0) und 3 mA Dauerstrom liefern (bei logisch 1). Kurzzeitig durfen beide Strome bis zu 9 mA betragen. Diese Treiberleistungen erlauben es, den Scheme-Prozessor direkt in vorhandene 68000-Rechner einzusetzen. Externe Treiber sind daher nicht notig. C.1 Der Taktgenerator Der Scheme-Prozessor wird mit mehreren Takten versorgt: Im Operationswerk erhalt der autonom arbeitende Buszugrismodul einen Takt, der nur zum Takt des 68000-Rechners synchron sein mu. Alle anderen Takte fur das Operations- und das Steuerwerk mussen in einem festen zeitlichen Verhaltnis zueinander stehen. Das Operationswerk erhalt die Takte CLKREAD und CLKWRITE , die als ReadClock und WriteClock in Abbildung 8.19 auf Seite 106 dargestellt wurden. Das Steuerwerk (Abbildung 8.10 auf Seite 90) erhalt vier Takte: ROMCLK steuert das ROM, dessen Daten nach der negativen Flanke ausgelesen werden konnen. UPCCLK und STKCLK ubernehmen mit der steigenden Flanke in den Mikroprogrammzahler bzw. in den Mikroprogrammstack. Mit der steigenden Flanke von SCANCLK werden Daten in die Scanpath- und Pipelineregister ubernommen. Diese Takte sind aus zwei Grunden einzeln extern anzulegen: Einerseits mussen sie zum Test der Prozessoren auf Fertigungsfehler separat steuerbar sein. So werden im Betrieb zum Beispiel UPCCLK und STKCLK immer miteinander verbunden. Wahrend des Testens darf aber beim Einschieben in den Scanpath, wobei UPCCLK verwendet wird, nicht der Mikroprogrammstack verandert werden, da er sonst nicht mehr testbar ware. Andererseits konnen durch die einzeln zuganglichen Takte Verzogerungszeiten auf den gefertigten Chips gemessen werden, und es konnen Taktfrequenzen fur die tatsachlichen Timingbedingungen und nicht fur den ganzen Bereich der vom Hersteller garantierten Bedingungen ausgelegt werden. Im hier verwendeten Proze ACMOS3 von Siemens streuen die Verzogerungszeiten nach der Fertigung im Bereich der Faktoren 0,6 bis 1,6 um den "typischen\ Wert, der im Simulationsmodell von VENUS-S eingetragen ist [Siem88]. Der Betrieb des Scheme-Prozessors erfolgt im Atari ST mit den in Abbildung C.1 angegebenen Takten. Der Takt ROMCLK konnte mit UPCCLK und STKCLK zusammengefat werden, weil beide Takte mit unterschiedlichen Flanken ubernehmen. In der Abbildung wird ein Takt von 8 MHz 136 ANHANG C. EXTERNE BESCHALTUNG DES SCHEME-PROZESSORS erzeugt, weil er sich besonders einfach aus den im Atari vorhanden 32 MHz ableiten lat. Zur Erzeugung der Takte aus dem 32 MHz-Takt dient im Atari ST die in Abbildung C.2 angegebene Schaltung. ROMCLK UPCCLK STKCLK SCANCLK CLKREAD CLKWRITE 125 ns - Abbildung C.1: Die Takte des Scheme-Prozessors. Abbildung C.2: Der Taktgenerator fur den Scheme-Prozessor im Atari ST. C.2. DIE CHIPSELECTLOGIK 137 C.2 Die Chipselectlogik Eine externe Beschaltung der Prototypen wird benotigt, um das Bausteinauswahlsignal (Chipselect CS) zu generieren, das den Registern des Scheme-Prozessors Adressen fur Zugrie durch den 68000Rechner zuordnet. Diese Adressen sind vom verwendeten Rechner abhangig; die Chipselectlogik ist daher immer rechnerspezisch. Im Atari ST werden die Register des Scheme-Prozessors an die Adresse $F00000 gelegt, da diese noch unbelegt ist und mit geringem Beuteileaufwand dekodiert werden kann. Abbildung C.3 zeigt den Chipselektdekoder fur den Atari ST, der die Adressen $F00000 bis $F7FFFF dekodiert, welche alle im Atari ST nicht verwendet werden. Abbildung C.3: Die Chipselectlogik fur den Scheme-Prozessor im Atari ST. Die gezeigte Halfte des Dekoderbausteins 74LS139 wird in der Chipselectlogik als Oder-Gatter eingesetzt, da dieser Baustein im Taktgenerator nicht vollstandig genutzt wird und auf diese Weise ein weiteres Standard-IC eingespart werden kann. Taktgenerator und Chipselectlogik bestehen zusammen aus nur drei Standard-ICs. Die externe Logik wird derzeit in ein PAL verlagert, so da auer dem Scheme-Prozessor nur noch ein zusatzlicher Baustein auf der Platine sein wird. Mit dem PAL werden dann auch genau die in Abbildung C.1 angegebenen Takte erzeugt; im derzeitigen diskreten Aufbau weichen die Takte durch aufgrund der unterschiedlichen Verzogerungszeiten von der Abbildung ab. Anhang D Test der gefertigten Prozessoren Der Test der gefertigten Prozessoren erfolgt auf Fertigungsfehler. Prinzipiell werden die beim IC-Entwurf fur den Fertigungstest entworfenen Testmuster durch einen Testmustergenerator an jedes der gefertigten Chips angelegt und die Ausgange des Chips durch einen Analysator mit den erwarteten (simulierten) Reaktionen verglichen. Beim Scheme-Prozessor bestand das Problem, da die zur Verfugung stehenden Testgerate nicht fur die groe Anzahl von Anschlussen der Scheme-Prozessoren ausgelegt waren. Die Testgerate sind nur fur Chips mit maximal einem Viertel der Anschlusse des Scheme-Prozessors geeignet. Ein fur den Fertigungstest bei Mikroprozessoren eingesetztes Verfahren besteht im Auslesen des Mikroprogramms in einem speziellen Testmodus. Wenn das Mikroprogramm korrekt ist, wird der Mikroprozessor durch das Ausfuhren von Befehlen getestet. Auf diese Weise wird auch der 68000-Prozessor getestet [DaBr85]. Der Test des Scheme-Prozessors erfolgt auch in zwei Schritten und berucksichtigt die Einschrankung der Testgerate: 1. Testen des Steuerwerks mit den Testgeraten. Das Mikroprogramm-ROM wird ausgelesen, und die Folgeadrelogik wird getestet. Da diese Operationen den Scanpath verwenden, werden nur wenige Prozessoranschlusse benotigt. 2. Testen des Operationswerks durch Betreiben im Atari ST. Durch Diagnoseprogramme werden Registerbank und ALU getestet. Die Diagnoseprogramme umfassen sowohl Programme auf dem Atari ST (Lesen und Schreiben der SchemeProzessor-Register) als auch Programme in Bytecode, die der Scheme-Prozessor ausfuhrt. Ferner wird auch die Stromaufnahme der Pruinge gemessen, um Hinweise auf mogliches fehlerhaftes elektrisches Verhalten (z.B. interne Kurzschlusse) zu erhalten. 138 139 Chip 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Operationswerk Steuerwerk Strom Fehler Fehler o.k. o.k. Fehler o.k. o.k. Fehler Fehler Fehler o.k. o.k. o.k. o.k. o.k. o.k. o.k. o.k. o.k. o.k. o.k. 10,0 mA 10,1 mA 10,5 mA 9,5 mA 9,4 mA 11,2 mA 7,1 mA 6.5 mA 10,5 mA 7,5 mA 8,0 mA 11,5 mA 7,5 mA 11,0 mA 8,1 mA 7,0 mA 8,5 mA 11,1 mA 8,1 mA o.k. o.k. o.k. o.k. o.k. o.k. Fehler o.k. o.k. Fehler o.k. o.k. o.k. Erklarung Bonddrahte defekt Bit #31 in Registerbank falsch Registerbank defekt 4886 Fehler im Mikroprogramm-ROM 44 Fehler im Mikroprogramm-ROM 10 Fehler im Mikroprogramm-ROM 1 Fehler im Mikroprogramm-ROM Register cur byte und tos defekt Registerbank defekt Tabelle D.1: Ergebnisse des Tests der Prozessoren. Literaturverzeichnis [TI] 2 m CMOS Standard Cell Data Book. Texas Instruments Incorporated, 1986. [68000] MC68000 16-bit Microprocessor User's Manual. Motorola, Inc., Second Edition, January 1980. [AbSu85] Harold Abelson and Gerald Jay Sussman with Julie Sussman. Structure and Interpretation of Computer Programs. MIT Press, Cambridge, Mass., 1985. [AbSu88] Harold Abelson and Gerald Jay Sussman. Lisp: A Language for Stratied Design. Byte Magazin, McGraw Hill, New York, 207{218, February 1988. [Abra86] Jacob A. Abraham. Fault Modeling in VLSI. In T. W. Williams, VLSI Testing, North-Holland, 1986. [Aho89] Alfred V. Aho, Ravi Sethi, Jerey D. Ullman. Compilerbau. Addison-Wesley Deutschland, 1989. [Alle78] John Allen. Anatomy of LISP. McGraw Hill, New York, 1978. [BaJe86] David H. Bartley and John C. Jensen. The Implementation of PC Scheme. Proceedings of the 1986 ACM Conference on Lisp and Functional Programming, 86{93, 1986. [Bake78] Henry G. Baker, Jr. List processing in real time on a serial computer. Communications of the ACM, 21(4):280{294, 1978. [Barb81] Mario R. Barbacci. Instruction Set Processor Specications (ISPS): The Notation and Its Applications. IEEE Transactions on Computers. Vol C-30, No 1, January 1981. [Bata82] John Batali, Edmund Goodhue, Chris Hanson, Howie Shrobe, Richard M. Stallman, and Gerald Jay Sussman. The Scheme-81 Architecture - System and Chip. Proceedings, Conference on Advanced Research in VLSI, 69{77, 1982. [BeWu88a] Andrew A. Berlin and Henry M. Wu. Scheme86: A System for Interpreting Scheme. Proceedings of the 1988 ACM Conference on Lisp and Functional Programming, 116{ 123, 1988. [BeWu88b] Andrew A. Berlin and Henry M. Wu. Scheme86: A System for Interpreting Scheme. AI Memo No. 1040, M.I.T., Cambridge, Mass., April 1988. [Betz89] David M. Betz. XScheme: An Object-oriented Scheme. Version 0.16 Manual, January 1989. LITERATURVERZEICHNIS 141 [Boss87] Patrick W. Bosshart, C. Robert Hewes, Michael D. Ales, Mi-Chang Chang, Kwog Kit Chau, Kingsley Fasham, Charles C. Hoac, Theodore W. Houston, Vibhu Kalyan, Stephen L. Lusky, Shivaling S. Mahant-Shetti, Douglas J. Matzke, Kamalesh N. Ruparel, Joe F. Sexton, Ching-Hao Shaw, Thirumalai Sridhar, Donald Stark, and Ah Lyan Lee. A 553K-Transistor LISP Processor Chip. IEEE Journal of Solid-State Circuits. Vol. sc-22, No. 5, October 1987. [BrGa84] Rodney A. Brooks and Richard P. Gabriel. A Critique of Common Lisp. Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, 1{8, 1984. [Broo84] Rodney A. Brooks. Trading Data Space for Reduced Time and Code Space in RealTime Garbage Collection on Stock Hardware. Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, 256{262, 1984. [BuLa87] Rainer Buschke, Klaus Lagemann. SIMUEVA: A CAD Program Package for Ecient Analysis of Simulation Results. Proceedings of COMPEURO 1987, Hamburg, 451{454, 1987. [CSch84] MIT Scheme Manual, Seventh Edition. Cambridge, Mass., September 1984. [ChHe87] Paul Chow and John Hennessy. Reduced Instruction Set Computer Architectures. In Veljko M. Milutinovic, Computer Architecture, North-Holland, New York, 1987. [Chai84] Jer^ome Chailloux, Matthieu Devin, and Jean-Marie Hullot. LeLisp, a Portable and Ecient LISP System. Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, 113{122, 1984. [Chen70] C. J. Cheney. A Nonrecursive List Compacting Algorithm. Communications of the ACM, 13(11):677{678, 1970. [Chur41] Alonzo Church. The Calculi of Cambda-Conversion. Princeton University Press, Princeton, N. J., 1941. [Clee79] M. W. van Cleemput. Hierarchical Design for VLSI | Problems and Advantages. Proceedings of the CALTECH Conference on VLSI, 259{274, January 1979. [Clin84] William Clinger. The Scheme 311 compiler: An Exercise in Denotational Semantics. Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, 356{364, 1984. [Clin85] William Clinger, editor. The revised revised report on Scheme, or an uncommon Lisp. MIT Articial Intelligence Memo 848, August 1985. [Clin88] William D. Clinger, Anne H. Hartheimer, and Eric M. Ost. Implementation Strategies for Continuations. Proceedings of the 1988 ACM Conference on Lisp and Functional Programming, 124{131, 1988. [DaBr85] R. Gary Daniels and William C. Bruce. Built-In Self-Test Trends in Motorola Microprocessors. IEEE Design & Test, 64{71, April 1985. [Davi78] Scott Davidson and Bruce D. Shriver. An Overview of Firmware Engineering. IEEE Computer, 21{33, Vol. 11, No. 5, May 1978. [Davi83] Scott Davidson. High Level Mikroprogramming | Current Usage, Future Prospects. ACM SIGMICRO, 193{200, Vol. 14, No. 4, December 1983. 142 LITERATURVERZEICHNIS [Deut80] L. Peter Deutsch. ByteLisp and its Alto Implementation. Conference Record of the 1980 Lisp Conference. 231{242, 1980. [Dybv87] R. Kent Dybvig. The Scheme Programming Language. Prentice-Hall, Inc., Englewood Clis, New Jersey, 1987. [ES2a] ES2 ROM Generator. European Silicon Structures, 1989. [ES2b] ES2 Solo 2030 Family. European Silicon Structures, 1989. [Eich85] Werner Eicher. Ein hardware-unterstutzter LISP-Interpreter. Dissertation, Universitat Kaiserslautern, 1985. [Eise88] Michael Eisenberg. Programming In Scheme. Scientic Press, Redwood City, CA, 1988. [FeYo69] Robert R. Fenichel, and Jerome C. Yochelson. A Lisp garbage collector for virtual memory computer systems. Communications of the ACM, 12(11):611{612, 1969. [Feel86] Marc Feeley. Deux Approches a L'implementation du Language Scheme. M.Sc. Thesis, Departement d'Informatique et de Recherche Operationelle, University of Montreal, May 1986 [Fell83] Carol Fessenden, William Clinger, Daniel P. Friedman, and Christopher T. Haynes. Scheme 311 version 4 Reference Manual. Bloomington, Indiana, February 1983. [Frie85] Daniel P. Friedman, Christopher T. Haynes, Eugene E. Kohlbecker, and Mitchell Wand. Scheme 84 Interim Reference Manual. Bloomington, Indiana, January 1985. [Gabr85] Richard P. Gabriel. Performance and Evaluation of LISP Systems. MIT Press, Cambridge, Mass, 1985. [Gabr87] Richard P. Gabriel. Memory Management in LISP. AI Expert, (2):32{38, 1987. [GeKu83] D. D. Gajski, R. H. Kuhn. Guest Editor's introduction: New VLSI tools. Computer, 16(12):11{14, December 1983. [Gilo83] Wolfgang K. Giloi and Bruce D. Shriver (Ed.). Methodoligies for Computer System Design. Proceedings of IFIP WG 10.1 Working Conference, Elsevier Science Publishers, Amsterdam, 1983. [GrHe82] T. R. Gross, J. L. Hennesey. Optimizing Delayed Branches. Proceedings of 15th Annual Workshop on Microprogramming, ACM, October 1982, 114. [Gree77] Richard Greenblatt. LISP Machine Progress Report. AI Memo No. 444, M.I.T., Cambridge, Mass., August 1977. [HaFr84] Christopher T. Haynes and Daniel P. Friedman. Engines Build Process Abstractions. Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, 18{24, 1984. [Hafe89] Christian Hafer. COLIBRI-Architektur. In Jurgen Ebert, Alternative Konzepte fur Sprachen und Rechner, Bericht 6/89, EWH Koblenz. [Hans69] Wilfred J. Hansen. Compact List Representation: Denition, Garbage Collection, and System Implementation. Communications of the ACM, 12(9):499{507, 1969. LITERATURVERZEICHNIS 143 [Hayn84] Christopher T. Haynes, Daniel P. Friedman, and Mitchell Wand. Continuations and Coroutines. Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, 293{298, 1984. [Hayn86] Christopher T. Haynes, Daniel P. Friedman, and Mitchell Wand. Obtaining Coroutines With Continuations. Journal of Computer Languages, 11(3/4):143{153, 1986. [Hend80] Peter Henderson. Functional Programming: Application and Implementation. Prentice-Hall International, London, 1980. [Ho83] Rolf Homann. Rechenwerke und Mikroprogrammierung. R. Oldenbourg, Munchen, 1983. [Holl80] Jack Holloway, Guy Lewis Steele, Jr., Gerald Jay Sussman, and Alan Bell. The SCHEME-79 Chip. AI Memo No. 559, M.I.T., Cambridge, Mass., 1980. [Horb86] Egon Horbst, Martin Nett und Heinz Schwartzel. VENUS | Entwurf von VLSISchaltungen. Springer Verlag, Berlin, 1986. [JeWi78] Kathleen Jensen and Niklaus Wirth. PASCAL User Manual and Report. SpringerVerlag, New York, 1978. [KeRi78] Brian W. Kernighan, Dennis M. Ritchie. The C Programming Language. Prentice-Hall International, Englewood Clis, 1978. [Knut68] Donald E. Knuth. The Art of Computer Programming Vol. 1 Fundamental Algorithms. Addison-Wesly, Reading, Mass., 1968. [Kong89] Shing I. Kong, David D. Lee, Randy H. Katz, David A. Hodges, and David A. Patterson. From Chip To System: The SPUR CPU Experience. Proceedings of the VLSI'89 Conference, IFIP, 55{64, Munich, August 16{18, 1989. [Kran86] David Kranz, Richard Kelsey, Jonathan Rees, Paul Hudak, James Philbin, and Norman Adams. ORBIT: An Optimizing Compiler for Scheme. Proceedings of the SIGPLAN '86 Symposium on Compiler Construction. 219{233. ACM June 1986. [Kran88] David Andrew Kranz. ORBIT: An Optimizing Compiler for Scheme. PhD thesis, Yale University, May 1988. [Lage87] Klaus Lagemann. Rechnerstrukturen. Springer-Verlag, Berlin Heidelberg, 1987. [Laub76] Joachim Laubsch, Dieter Krause, Klaus Hess, Werner Schatz. TR440 MacLisp Handbuch. Institut fur Informatik der Universitat Stuttgart, 1976. [LiHe83] Henry Lieberman and Carl Hewitt. A Real-Time Garbage Collector based on the Lifetimes of Objects. Communications of the ACM, 26(6):419{429, June 1983. [LiSc82] P. Liell, E. Schaaf. Die Hardwarebeschreibungssprache Karl II | Sprachbeschreibung. 2. Auage, Universitat Kaiserslautern, April 1982. [LoRa89a] Jorg Lohse, Reinhard Rauscher. A Scheme-Coprocessor for Cheap Microcomputers. Proceedings Intern. AMSE Conference \Signals & Systems", AMSE Press, Vol. 3, p. 103{110, Brighton (U.K.), July 12{14, 1989. 144 LITERATURVERZEICHNIS [LoRa89b] Jorg Lohse, Reinhard Rauscher. A VLSI Coprocessor Implementing the Programming Language Scheme. Proceedings of the VLSI'89 Conference, IFIP, 275{284, Munich, August 16{18, 1989. [Lohs85] Jorg Lohse. ST Pascal. CCD, Eltville, 1985. [Lohs86] Jorg Lohse. Personal Pascal. Optimized System Software, San Jose, CA, 1986. [Lohs87] Jorg Lohse. Ein Plotprogramm fur SIGRED-Schaltungen. Mitteilung 2/87 des Arbeitsbereich TECH, September 1987. Erhaltlich von: Gesellschaft fur Mathematik und Datentechnik, Projekt E.I.S., Birlinghoven. [Lohs88] Jorg Lohse. Architektur, Befehlssatz und Entwurfswerkzeuge des ersten Hamburger Scheme-Prozessors. Mitteilung des Fachbereichs Informatik FBI-HH-M-162/88, Universitat Hamburg, September 1988. [Lohs89] Jorg Lohse, Reinhard Rauscher, Bernd Schutz. A Coprocessor for Implementing the LISP-Dialect Scheme. Proceedings of the EUROMICRO'89 Conference, 355{363, Cologne, September 1989. [MaDe80] Larry M. Masinter and L. Peter Deutsch. Local Optimization in a Compiler for Stackbased Lisp Machines. Conference Record of the 1980 Lisp Conference. 223{230, 1980. [MaWi89] Dieter Maurer, Reinhard Wilhelm. MaMa | eine Abstrakte Maschine zur Implementierung funktionaler Programmiersprachen. Informatik Forschung und Entwicklung. Springer Verlag, Heidelberg, 67{88, April 1989. [Marw86] Peter Marwedel. Ein Software-System zur Sythese von Rechnerstrukturen und zur Erzeugung von Mikrocode. Habilitation, Universitat Kiel, 1986. [Matt87] Gene Matthews, Robert Hewes, and Steve Krueger. Single-chip processor runs Lisp environments. Computer Design. 69{76, May 1987. [McCa60] John McCarthy. Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I. Communications of the ACM, 184{195, April 1960. [McDe80] Drew McDermott. An Ecient Environment Allocation Scheme in an Interpreter for a Lexically-scoped LISP. Conference Record of the 1980 Lisp Conference. 154{162, 1980. [MeCo80] Carver A. Mead and Lynn A. Conway. Introduction to VLSI Systems. Addison-Wesley Publishing Co., Reading, Mass, 1980. [Milu87] Veljko M. Milutinovic (Ed.). Computer Architecture. North-Holland, New York, 1987. [Moon84] David A. Moon. Garbage Collection in Large Lisp Systems. Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, 235{246, 1984. [Moon85] David A. Moon. Architecture of the Symbolics 3600. Proceedings of the 12th Annual International Symposium on Computer Architecture, 76{83, 1985. [Much80] Steven S. Muchnick and Uwe F. Pleban. A Semantic Comparison of Lisp and Scheme. Conference Record of the 1980 Lisp Conference, 56{65, 1980. LITERATURVERZEICHNIS 145 [Muel84] Robert A. Mueller. Automated Microcode Synthesis. UMI Research Press, Ann Arbor, 1984. [Myer87] Glenford J. Myers. Advances in Computer Architecture. John Wiley & Sons, New York, 1987. [Naur63] Peter Naur et al. Revised report on the algorithmic language Algol 60. Communications of the ACM 6(1):1{17, January 1963. [Nowa86] Lothar Nowak. SAMP: Entwurf und Realisierung eines neuartigen Rechnerkonzeptes. Dissertation und Bericht Nr. 8615, Universitat Kiel, November 1986. [Padg86] Julian Padget, Jer^ome Chailloux, Thomas Christaller, Ramon DeMantaras, Je Dulton, John Fitch, Timm Krumnack, Eugen Neidl, Eric Papon, Stephen Pope, Christian Queinnec, Luc Steels, and Herbert Stoyan. Desiderata for the standardisation of LISP. Proceedings of the 1986 ACM Conference on Lisp and Functional Programming, 54{66, 1986. [Patt85] David A. Patterson. Reduced Instruction Set Computers. Communications of the ACM, 28(1):8{21, 1985. [Paye89] Michael Payer. Graphentheoretische Ansatze fur CAD-Werkzeuge in der CMOSTechnik. Dissertation, Universitat Hamburg, Juli 1989. [Pend86] Joan M. Pendleton, Shing I. Kong, Emil W. Brown, Frank Dunlap, Christopher Marino, David M. Ungar, David A. Patterson, and David A. Hodges. A 32-bit Microprocessor for Smalltalk. IEEE Journal of Solid State Circuits. Vol. 21, No 5, October 1986. [Peyt87] Simon L. Peyton Jones. The Implementation of Functional Programming Languages. Prentice-Hall International, Englewood Clis, 1987. [PlTh87] Andrew R. Pleszkun, Matthew J. Thazhuthaveetil. The Architecture of Lisp Machines. IEEE Computer, Vol. 20, No. 3, 35{44, IEEE, March 1987. [PrWi86] Franklin P. Prosser and David E. Winkel. The Art of Digital Design. Prentice-Hall International, Englewood Clis, 1986. [Prat75] Terrence W. Pratt. Programming Languages: Design and Implementation. PrenticeHall International, Englewood Clis, 1975. [Raus87] Reinhard Rauscher. Ein praktikables Verfahren zur interaktiven Mikroprogrammtransformation und deren formaler automatischer Verikation. Dissertation, Universitat Hamburg, 1987. [Rees84] Jonathan A. Rees, Norman I. Adams, and James R. Meehan. The T manual, fourth edition. Yale University, January 1984. [Rees86] Jonathan A. Rees and William Clinger (editors). Revised3 Report on the Algorithmic Language Scheme. ACM Sigplan Notices, 21(12), December 1986. [Rowa80] William Rowan. A Lisp Compiler producing Compact Code. Conference Record of the 1980 Lisp Conference. 216{222, 1980. 146 LITERATURVERZEICHNIS [Roza84] Guillermo J. Rozas. Liar, an Algol-like Compiler for Scheme. S. B. Thesis, MIT Department of Electrical Engineering and Computer Science, January 1984. [SaJa84] Emanuell Saint-James. Recursion is More Ecient than Iteration. Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming 228{234, 1984. [ScSt84] Richard Schooler and James W. Stamos. Proposal for a Small Scheme Implementation. MIT/LCS/TM-267, M.I.T., Cambridge, Mass., 1984. [ScWa67] H. Schorr and W. M. Waite. An Ecient Machine-Independent Procedure for Garbage Collection in Various List Structures. Communications of the ACM, 10(8):501{506, 1967. [Sem87] MacScheme+Toolsmith User's Guide. Version 1.5, Semantic Microsystems, Beaverton, Oregon, 1987. [Shep87] Susan J. Shepard. LISP on a Micro. AI Expert, (2):73{76, 1987. [SiMi87] Alexander A. Silbey and Veljko M. Milutinovic. Advanced Microprocessors and HighLevel Language Processor Architectures. In Veljko M. Milutinovic, Computer Architecture, North-Holland, New York, 1987. [Siem88] Zellenkatalog Standardzellen ACMOS3. Stand VENUS-S3.3E2. Siemens AG, Abteilung ZTI PPM 13, Munchen, Juli 1988. [Smit88] Jerry Smith. Introduction to Scheme. Prentice-Hall, Inc., Englewood Clis, New Jersey, 1988. [StHe88] Peter Steenkiste and John Hennessy. Lisp on a Reduced-Instruction-Set Processor: Characterization and Optimization. IEEE Computer, Vol. 21, No. 7, 34{45, IEEE, July 1988. [StSu76] Guy Lewis Steele, Jr. and Gerald Jay Sussman. Lambda, the Ultimate Imperative. AI Memo No. 353, M.I.T., Cambridge, Mass., March 1976. [StSu78] Guy Lewis Steele, Jr. and Gerald Jay Sussman. The revised report on Scheme, a dialect of Lisp. MIT Articial Intelligence Memo 452, January 1978. [StSu80a] Guy Lewis Steele, Jr. and Gerald Jay Sussman. Design of a Lisp-based Processor. Communications of the ACM, 23(11):628{645, November 1980. [StSu80b] Guy Lewis Steele, Jr. and Gerald Jay Sussman. The Dream of a Lifetime: a Lazy Variable Extent Mechanism. Conference Record of the 1980 Lisp Conference, 163{172, 1980. [Stee76] Guy Lewis Steele, Jr. Lambda, the Ultimate Declarative. AI Memo 379, M.I.T., Cambridge, Mass., November 1976. [Stee77] Guy Lewis Steele, Jr. Macaroni is Better than Spaghetti. Proceedings of the Symposium on Articial Intelligence and Programming Languages. 60{66, August 1977 [Stee78] Guy Lewis Steele, Jr. Rabbit: a Compiler for Scheme. Technical Report AI-TR-474, M.I.T., Cambridge, Mass., May 1978. LITERATURVERZEICHNIS 147 [Stee80] Guy Lewis Steele, Jr. Destructive Reordering of CDR-Coded Lists. AI Memo 587, M.I.T., Cambridge, Mass., August 1980. [Stee84] Guy Lewis Steele, Jr. Common Lisp the Language. Digital Press, 1984. [Stei88] Uwe Steinhausen. VENUS Compendium. Gesellschaft fur Mathematik und Datentechnik, Projekt E.I.S., Birlinghoven, November 1988. [Stum89] Hans Stumper. Beobachtungen bei DRC und ERC des Hamburger Scheme-Chips. Personliche Mitteilung. Gesellschaft fur Mathematik und Datentechnik, Projekt E.I.S., Birlinghoven, Juni 1989. [SuSt75] Gerald Jay Sussman and Guy Lewis Steele, Jr. Scheme: an Interpreter for Extended Lambda Calculus. AI Memo No. 349, M.I.T., Cambridge, Mass., December 1975. [Suss81] Gerald Jay Sussman, Jack Holloway, Guy Lewis Steele, Jr., and Alan Bell. Scheme-79 - Lisp on a Chip. IEEE Computer, 14(7):10{21, July 1981. [Suss88] Gerald Jay Sussman. Scheme-81. Personliche Mitteilung, E-mail, 11. Oktober 1988. [Teit74] W. Teitelman. Interlisp Reference Manual. Xerox Palo Alto Research Center, 1974. [ThSc89] Nguyen Huu Chau Thuy, Peter Schnupp. Wissensverarbeitung und Expertensysteme. R. Oldenbourg Verlag, Munchen Wien, 1989. [Ullm84] Jerey D. Ullman. Computational Aspects of VLSI. Computer Science Press, Rockville, Maryland, 1984. [WG89] IEEE/MSC/P1178 Working Group on Scheme. Unapproved Minutes of the Third Meeting. MIT, Cambridge, MA, 7 July 1989. [WaTh85] R. A. Walker, D. E. Thomas. A model of design representation and synthesis. Proceedings of the 22nd Design Automation Conference, 453{459, June 1985. [Wads71] C. P. Wadsworth. Semantics and Pracmatics of the lambda calculus. PhD thesis, Oxford, 1971. [West89] Neil West. The Ivory Lisp Processor Project | Some Experiences with Big VLSI. Proceedings of the VLSI'89 Conference, IFIP, 67{78, Munich, August 16{18, 1989. [WhFa84] Skef Wholey and Scott E. Fahlman. The Design of an Instruction Set for Common Lisp. Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, 150{158, 1984. [Wilk51] Maurice V. Wilkes. The Best Way to Design an Automatic Machine. Proceedings Manchester University Computer Inaugural Conference. Ferrante, London, July 1951. [Will86] Thomas W. Williams (Ed.). VLSI Testing. North-Holland, 1986. [Wirt81] Niklaus Wirth. Compilerbau. 2. Auage, Teubner, Stuttgart, 1981. [Wu88] Henry M. Wu. Scheme86: An Architecture for Microcoding a Scheme Interpreter. AI Memo No. 953, M.I.T., Cambridge, Mass., August 1988. [Wulf75] William Wulf, Richard K. Johnsson, Charles B. Weinstock, Steven O. Hobbs, and Charles M. Geschke. The Design of an Optimizing Compiler . American Elsevier, New York, 1975. 148 Eidesstattliche Erkl arung Hiermit erklare ich an Eides Statt, da ich diese Dissertation selbst verfat habe und keine anderen als die angegebenen Hilfsmittel benutzt habe. Hamburg, den 27. November 1990 (Jorg Lohse) 149 Lebenslauf 7. 3. 1960 geboren in Hamburg als erstes Kind des Poliers Klaus Lohse und der Buchhalterin Gerda Lohse, geb. Jacobsen 1967 bis 1971 Besuch der Hauptschule Franzosenkoppel in Hamburg 1971 bis 1980 Besuch des naturwissenschaftlichen und neusprachlichen Gymnasiums Rispenweg in Hamburg 1980 Abitur am Gymnasium Rispenweg 1980 Beginn eines Studiums der Physik an der Universitat Hamburg 1982 Aufnahme eines Studiums der Informatik an der Universitat Hamburg 1984 Vordiplom in Informatik mit Nebenfach Physik an der Universitat Hamburg 1986 Diplom in Informatik mit Nebenfach Physik an der Universitat Hamburg seit 1986 tatig als wissenschaftlicher Mitarbeiter am Fachbereich Informatik der Universitat Hamburg
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project
advertisement