Homepage

 

 

 

 

Die ReAl-Computerarchitektur

 

 

 

 

ReAl = Ressourcen-Algebra 

 

 

 

 

 

 

 

 Neuigkeiten

 Home

 Wirkprinzipien

 Theorie

 Entwicklungsgeschichte

 Die Seite auf Englisch

 Mikrocontroller und PCs

 Impressum

 Kontakt

 

 

 

 

 

 

 

 

 

 

 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...