|
|
|
|
Entwicklungsgeschichte
Was war der Ausgangspunkt?
Die Grundlagenforschung
auf dem Gebiet der Recherarchitektur. Will man nicht
sklavisch nachbauen oder gar nur kaufen oder herunterladen,
ergeben sich Fragen, die es durchaus in sich haben:
- Wie kann man Architekturentscheidungen
wissenschaftlich, also objektiv und verifizierbar,
begründen und rechtfertigen?
- Was einbauen und
was nicht?
- Weshalb ausgerechnet
soundso viele Register?
- Weshalb diese Befehlswirkungen,
diese Adressierungsverfahren und keine anderen?
- Usw.
Die heutzutage vorherrschenden
Architekturen sind im Grunde mehrere Jahrzehnte alt.
Sie beruhen auf seinerzeitigen Erfahrungsgrundlagen,
Anwendungserfordernissen und Gefühlsentscheidungen,
vor allem aber auf den Grenzen, die die damals
verfügbare Technologie gesetzt hat.
Heutzutage ist es nicht
mehr erforderlich, bei den Transistoren und der
Speicherkapazität um jeden Preis zu sparen. Deshalb
können wir uns einen alternativen Ansatz leisten.
Er beruht darauf, von üblichen Maschinenbefehlen
und Prozessorkernen abzugehen und der Anwendungsprogrammierung
eine beliebige Anzahl frei verfügbarer Ressourcen
zur Verfügung zu stellen.
1982 ... 1986
Entwurf von Spezialprozessoren.
Schaltungen ausdenken, die irgendwelche vorgegebene
Algorithmen ausführen -- das ist eigentlich nichts
Besonderes. Was aber kennzeichnet eine wirklich
überlegene -- optimale -- Spezialmaschine?
Der Grundgedanke: Am besten wäre es, alles
auf einen Schlag zu erledigen (also durch unmittelbare
Zuordnung). So dicke Funktionszuordner kann
man aber nicht bauen. Es muß also in mehreren
Schritten getan werden. Natürlich sollten
es so wenige wie möglich sein. Maschinenbefehle,
abzuspeichernde und wieder zu holende Zwischenergebnisse usw. stören
eigentlich nur. Wichtig sind allein die Daten
des Anwendungsproblems. Am besten wäre
es doch, wenn alle Bits der Anwendungsaufgabe
(Operanden und Ergebnisse) nur jeweils einmal
durch die Maschine laufen müßten.
Dann würde jeder Maschinenzyklus gemäß
der jeweiligen Verarbeitungsbreite zum Ergebnis
beitragen. ABER: gelingt das überhaupt?
-- Es ist offensichtlich nicht in erster Line
eine Eigenschaft der Hardware. Denn diese kann
man ja -- als Spezialmaschine -- so auslegen,
wie es jeweils zweckmäßig ist.
Es ist vielmehr vor allem eine Eigenschaft des
Algorithmus: erfordert er es, auf Bits, die
bereits verarbeitet worden sind, nochmals zuzugreifen
oder nicht? Diese Eigenschaft wird in einer
Kennzahl ausgedrückt: in der Implementierungseffizienz.
Auszug
aus der Dissertationsschrift Spezielle
Hardware zur Verarbeitung von Ternärvektorlisten
(1987).
Die vollständige
Dissertationsschrift.
System .008. Vorläufige Architekturbeschreibung.
1988 bis 1990
Jetzt geht es um die Universalmaschine.
Aber möglichst nicht so eine Art ewiger
Wiederkunft des Gleichen (CISC, RISC usw.).
Also vollkommen von Frischem anfangen. Wie
sollte ein wirklich optimaler Einzelprozessor
aussehen? -- Er sollte nicht um jedem Preis
mit irgend etwas Vorhandenem bis aufs letzte
Bit kompatibel sein -- und schon gar nicht irgendwelchen
Schlagworten entsprechen. Vielmehr sollte er
-- im Sinne eines Erwartungswertes -- für
jeden beliebige Algorithmus dem Leistungsvermögen
einer genau für den jeweiligen Algorithmus
entworfenen Spezialmaschine so nahe wie möglich
kommen.
Die gefundenen Ansätze im Überblick:
- Leistungsmessung anhand
der verarbeiteten Anwendungsdaten (Nutzbits)
je Zeiteinheit.
- Auswahl der schaltunsgtechnisch
zu
implementierenden Grundfunktionen ("Maschinenbefehle")
gemäß ihrer Implementierungseffizienz.
- Der Wirkungsgrad als
Verhältnis der Verarbeitungsleistung
der Universalmaschine zur Leistung einer
für den jeweiligen Algorithmus entworfenen
Einzweckmaschine.
- Die jeweils vorhandenen Ressourcen bestimmen
das Leistungsvermögen. Es gehört zu den wichtigsten
Zielen der Architekturentwicklung, diese Ressourcen so gut wie möglich
auszunutzen. Hierzu sind sie in jedem Maschinenzyklus
mit nützlicher (= zum angestrebten
Endergebnis beitragender) Arbeit zu beschäftigen.
- Ressourcen-Algebra: Die Menge der Ressourcen
und die Menge der zu verarbeitenden Datenstrukturen
(Datentypen) konstituieren im Grunde eine algebraische
Struktur. Die Ressourcen-Algebra ist
aber (noch) keine API, sondern lediglich eine Formalisierung, die zum abstrakten Modellieren
von Architekturkonzepten verwendet werden soll.
- Ressourcenvektor: Auf
der RTL-Ebene können die mit den kombinatorischen
Schaltnetzen direkt verbundenen Speicherrmittel
(Flipflops) als ein einziger Binärvektor
angesehen werden. Mit diesem Ansatz können
sowohl v.Neumann- als auch Datenflußmaschinen
beschrieben werden (und auch die bekannten
Auslegungen der Befehlssteuerung -- RISC,
CISC, VLIW, Mikroprogrammierung usw.).
- Ressourcenvektormaschine.
Der zur Ausführung der Adressierungs-
und Verarbeitungsabläufe vorgesehene
Ressourcenvektor ist gegeben. Die Maschinenbefehle
dienen dazu, Abschnitte des Ressourcenvektors
zu beeinflussen.
- Die API im Sinne einer herkömmlichen
Befehlsliste ist zweitranging. Sie wird je nach
Zweckmäßigkeit festgelegt. Die untersten
Ebenen sind im Grunde Steuerworte zum Beeinflussen
des Ressourcenvektors. Die eigentliche Hardware-Software-Schnittstelle
ist objektorientiert (mit anderen Worten: es
wurde etwas ähnliches angestrebt wie das AS/400, aber vor allem
als Hochleistungsrechner (weniger bescheiden:
als Supercomputer)).
Es war der erste Schritt:
Ressourcenalgebra als formales Beschreibungsmittel,
aber feste Ressourcenauswahl. Heraus kommen nach wie
vor herkömmliche Universalrechner, die aber nicht
so recht zu den Marketing-Schlagworten (RISC,
CISC, VLIW usw.) passen wollen.
Die Grundgedanken
im Überblick:
- Eine Maschine,
die ihre Befehlswirkungen erbringt, indem vergleichsweise
einfache Verarbeitungsschaltungen invielen Schritten
mehrfach durchlaufen werden, leistet weniger als
eine Maschine, die mit besonderen Verarbeitungsschaltungen
für die einzelnen Befehlswirkungen ausgerüstet
ist.
- Sinngemäß
wirken sich die Breite der Signalwege und die Komplexität
der Steuerschaltungen auf das Leistungsvermögen
aus. Ganz allgemein ausgedrückt sind es letzten
Endes die Ressourcen, die die Verarbeitungsleistung
bestimmen.
- Ressourcen der
Befehslausführung und Befehlsablaufsteuerung
sind im Grunde RTL-Strukturen. Die Speichermittel
an den Ein- und Ausgängen dieser Strukturen
fassen wir zum sog. Ressourcenvektor zusammen.
- Maschinenbefehle
sind nur Mittel zum Zweck. Sie dienen dazu, die
Nutzung der Ressourcen anzuweisen.
- Entscheidend ist
es, die Ressourcen soweit überhaupt möglich
mit nützlicher (= der Lösung des Anwendungsproblems
dienender) Arbeit zu beschäftigen.
- Das läuft
darauf hinaus, den Ressourcenvektor zu beeinflussen
(insgesamt oder abschnittsweise).
- Es konnte gezeigt
werden, daß sich die herkömmlichen Befehlsmodelle
(Formate, Prinzipien der Ablaufsteuerung usw.) in
diesem Rahmen darstellen lassen.
- Der erste Ansatz:
welche Ressourcen als Hardware gebaut werden und
wieviele davon, ist Sache der Optimierung. Es ließe
sich sogar mittels linearer Optimierung erledigen,
wenn die Anforderungen genau bekannt und quantitativ
beschrieben wären.
- Die Maschinenbefehle
werden so gestaltet, daß der jeweilige Ressourcenvektor
so zweckmäßig wie möglich kommandiert
werden kann.
- Die Befehlsformate
ähneln jenen der herkömmlichen Mikrobefehle,
aber ohne deren häßliche Einschränkungen.
- Sie sind aber nicht
maschinenunabhängig; es wäre also keine
richtige Architektur.
- Deshalb führen
wir eine maschinenunabhängige, abstrakte Programmschnittstelle
ein.
- Dieses abstrakte
Modell nennen wir Ressourcen-Algebra. Sie wird in
einer besonderen formalen Sprache beschrieben und
codiert. Das ist das Ziel der Compiler. Das eigentliche
Maschinenprogramm ergibt sich daraus durch vergleichsweise
einfache Umcodierungsabläufe.
Auszug
aus der Habilitationsschrift Leistungsoptimierte
Einzelprozessorarchitekturen digitaler Universalrechner
(1989).
Die vollständige
Habilitationsschrift.
Technische Lösungsansätze für
Rechnerarchitekturen auf Grundlage vergegenständlichter
Abstraktionen. Ein Arbeitsbericht (1989).
A Next Generation Superscalar Architecture
(1990).
System .015 Grundsätze der Architekturgestaltung
(1990).
System.015: eine Universalrechnerarchitekur für
komplexe industrielle Steuerungssysteme (1990).
System.016: Manuskriptausschnitte
(1988...90).
1995 bis 1999
Der Mikrocontroller als Meterware.
Grundsatzuntersuchungen zu Mikrocontrollern
mit variabler Architektur, die für
beliebige Verarbeitungsbreiten generiert
werden können.
Hardware
oder Software? Eine Entscheidung beim Entwerfen von Embedded Systems.
1997 als Vortrag gehalten -- aber auch heute noch aktuell ... Im Fokus:
die Implementierungseffizienz -- ein Ansatz, um solche Entscheidungen
auf möglichst exakter, objektiver Grundlage treffen zu können.
Ab 1999/2000
Das Grundkonzept der
Ressourcenalgebra ist nicht schwierig. Auch ein entsprechender
mathematischer Formalismus ist zu bewältigen, zumal
es dazu Vorarbeiten gibt. Wie aber soll eine praktisch
brauchbare Programmschnittstelle und Beschreibungssprache
aussehen?
Im Laufe dieser Untersuchungen
hat sich der Ansatz ergeben, der jetzt als ReAl Computer
Architecture bezeichnet wird:
- Weshalb sich auf
einen festen Ressourcenvorrat beschränken?
- Probieren wir es
doch einmal damit, einen unbeschränkten Ressourcenvorrat
anzunehmen und daraus so viele Ressourcen auszuwählen,
wie wir benötigen, um das jeweilige Anwendungsproblem
zu lösen...
- Es sieht auf den
ersten Blick umständlich aus, ist es aber nicht
wirklich. Man muß nur die Nerven behalten...
Die Ressourcen-Algebra wurde
somit
zur
unmittelbaren Grundlage der API. Es hat einige Zeit gebraucht,
darauf zu kommen. Unter anderem wurde viel Mühe
darauf verwendet, radikale Ansätze zu widerlegen
oder abzuwandeln und Gegenentwürfe auszuarbeiten...
|
|
|
|