Konzeption, Entwurf und Realisierung eines Prozessors f ur die

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
Systemspezikation@@
0
Algorithmenebene
Subsysteme
Algorithmen @
Funktionsblockebene 00
Register, ALU, MUX
Registertransfers@
Logikebene
@
0
Gatter, Flipops
Boolesche Gleichungen @
Schaltkreisebene 0
Transistoren
0
Dierentialgleichungen@
@@
@
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
Systemspezikation@@
0
Algorithmenebene
Subsysteme
Algorithmen @
0
Funktionsblockebene
Register,
ALU, MUX
0
Registertransfers@
Logikebene
@
0
Gatter, Flipops
Boolesche Gleichungen @
Schaltkreisebene 0
Transistoren
Dierentialgleichungen@
@
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