Das ReAl-Verarbeitungsmodell
Operatoren und Parameter
Das Verarbeitungsmodell der ReAl-Architektur ist durch folgende Abläufe gekennzeichnet (Abb. 1): 1. Ressourcen anfordern bzw. auswählen,
2. mit Parametern (Operanden) versorgen,
3. Operationen ausführen (Hardware oder Programm laufen lassen),
4. Ergebnisse abholen,
5. über weiteren Gang der Verarbeitung entscheiden,
6. Ressourcen wieder zurück- bzw. freigeben.
Abb. 1 Das grundlegende Verarbeitungsmodell: so wird eine Ressource genutzt.
Betrachtet
man nur eine einzige, in Parameterzahl und Wirkungsweise einfache
Ressource, so gibt es
keinen grundsätzlichen Unterschied zu den herkömmlichen
Rechnerarchitekturen (Abb. 2). Es ist
lediglich die Frage, ob die Vorgänge (das Heranschaffen der Operanden
usw.) implizit gesteuert werden
(Befehlsablaufsteuerung) oder ob sie von einzeln codierten
Ablaufsteuerangaben ausgelöst werden. In
diesem Sinne hat die ReAl-Achitektur eine gewisse Ähnlichkeit mit der
(vertikalen) Mikroprogrammsteuerung. Die Vorteile kommen dann zur
Wirkung, wenn man (1) mit mehr als einer Ressource arbeitet
und wenn man (2) das Prinzip auf den gesamten Programmablauf anwendet.
erkettung
Funktionseinheiten
der Hardware können zu komplexeren Anordnungen zusammengeschaltet
werden.
Eine solche (spezielle) Hardware entspricht dem Datenflußschema der
jeweiligen Informationswandlungen (Abb. 3). Sinngemäß soll es möglich
sein, Ressourcen zu solchen Datenflußschemata zu
verketten und die Verkettung wieder zu trennen.
Abb. 2 Zum Vergleich: ein elementarer Verarbeitungsablauf in einem herkömmlichen Universalrechner (hier: einer Dreiadreßmaschine).
Abb. 3 Verkettete Ressourcenanordung zum Berechnen von (A + B) * (C + D).
Die elementaren Operatoren:
1. Ressourcen auswählen = s-Operator (select)
2. mit Parametern versorgen = p-Operator (parameter)
3. Operation(en) ausführen (laufen lassen): y-Operator (yield) = umgekehrtes Lambda
4. Ergebnisse abholen = a-Operator (assign)
5. Transportieren von Parametern zwischen Ressourcen = l-Operator (link)
6. Netzlistenbeschreibung, Verkettung, Datenflußprinzip = c-Operator (connect)
7. Verkettungen trennen = d-Operator (disconnect)
8. Ressourcen wieder zurück- bzw. freigeben = r-Operator (release)
Weitere Operatoren:
1. Hinweise = h-Operator
2. metasprachliche Angaben = m-Operator
3. Verwaltungsfunktionen = u-Operator (Utility)
Parameter:
1. Eingänge (Operanden; IN-Typ)
2. Ausgänge (Ergebnisse; OUT-Typ)
3. Ein- und Ausgänge (INOUT-Typ)
Parameterübergabe
Grundsätzlich als Wert (by Value). Ist das nicht ohne weiteres möglich, sind zusätzliche Ressourcen
vorzusehen, die die Werte heranschaffen und abtransportieren.
Notation von ReAl-Verarbeitungsabläufen
Notationsweisen im Überblick:
1. Umgangssprachliche Notation. Stil “Kochbuch” (“man nehme ein Addierwerk” usw.). Zu weitschweifig.
2. ReAl-Textcode (Zeichenketten). Formalisierte Notation. Die Ressourcen, Parameter usw. werden
durchnumeriert (Ordinalzahlen). Alternativ dazu können symbolische Bezeichner angegeben
werden.
3. ReAl-Bytecode. Eine kompakte, binär codierte Darstellung; aus dem Textcode abgeleitet.
4. ReAl-Maschinencode. Binär. Maschinenspezifisch.
Wir verwenden im folgenden den ReAl-Textcode.
Kommentare:
Mit -- eingeleitet (vgl. Programmiersprache ADA).
Kennzeichnung der Parameter im Textcode
Durch einfaches Durchnumerieren: zuerst die Eingänge, dann die Ein- und Ausgänge, dann die Ausgänge (Abb. 4).
Symbolische Bezeichner
Anstelle der Ordinalzahlen können symbolische Bezeichner (Eigennamen) angegeben werden.
Abb. 4 Ressourcen mit durchnumerierten Parametern.
Kurzüberblick über die hier verwendete Syntax des Textcodes:
Ressourcentyp := Ordinalzahl oder Eigenname
Ressource := Ordinalzahl oder Eigenname
Parameter := Ordinalzahl oder Eigenname
Zuweisung := => (Pfeil symbolisiert Übertragungsrichtung)
Zuordnung eines Eigennamens := Ordinalzahl : Eigenname
Parameter einer bestimmten Ressource: Ressource . Parameter
Leerzeichen können beliebig eingefügt oder weggelassen werden.
Zuordnung von Ordinalzahlen:
• Ressourcentypen: gemäß Reihenfolge in der Ressourcentyptabelle,
• Parameter: gemäß Reihenfolge in der Parameterliste des Ressourcentyps,
• Ressourcen: gemäß Reihenfolge der Ressourcentypangaben im s-Operator oder gemäß besonderen
Zuweisungsangaben.
Hinweis zur Numerierung der Ressourcen:
Die
folgenden Beispiele beziehen sich auf eine fortlaufende
Durchnumerierung (1, 2 usw.) gemäß der
Reihenfolge in den s-Operatoren. Die hierbei vergebenen laufenden
Nummern (Ordinalzahlen) bleiben
erhalten, auch wenn zwischenzeitlich Ressourcen mit niedrigeren Nummern
zurückgegeben wurden (r-Operator).
Zuordnung von Eigennamen:
• Ressourcentypen: vorgegeben (gemäß Ressourcentyptabelle oder Systemhandbuch). Kann bedarfsweise überladen werden (u-Operatoren resource name/rename (rn, rrn)):
u_rn (Ordinalzahl : Eigenname)
u_rrn (bisheriger Eigenname : neuer Eigenname)
• Parameter: vorgegeben (gemäß Ressourcentyptabelle oder Systemhandbuch). Kann bedarfsweise
überladen werden (u-Operatoren parameter name/rename (pn/prn)).
u_pn (Ordinalzahl : Eigenname)
u_prn (bisheriger Eigenname : neuer Eigenname)
• Ressourcen: im s-Operator (Ressourcentyp : Eigenname).
Elementare Operatoren
Ressourcen auswählen: s-Operator:
s (1. Ressourcentyp, 2. Ressourcentyp usw.).
Mit dem s-Operator werden Ressourcen angefordert. Bei allgemein üblichen (generischen) Ressourcen
wird der jeweilige Typ angegeben, bei speziellen Ressourcen der jeweilige Bezeichner (Eigenname). Im
allgemeinen Fall kommen als Bezeichner auch Internet-Adressen usw. in Betracht.
Die angeforderten Ressourcen werden fortlaufend durchnumeriert. Nachfolgende Operatoren beziehen
sich dann auf die so vergebenen Ordinalzahlen bzw. Bezeichner.
In
einer weiteren Auslegung können die s-Operatoren auch explizite Angaben
der Bezeichner, Ordinalzahlen oder Adressen enthalten, die den
angeforderten Ressourcen zugewiesen werden:
s (1. Ressourcentyp => 1. Ressourcennummer, 2. Ressourcentyp => 2. Ressourcennummer usw.).
Ressourcen mit Parametern versorgen: p-Operator:
p (1. Variable => Ressource . Parameter, 2. Variable => Ressource . Parameter usw.)
Mit p-Operatoren wird angegeben, welche Variable in welche Parameterposition welcher Ressource
transportiert wird. Die Variablen werden durch Namen, Ordinalzahlen oder Adressen bezeichnet.
Anstelle von Variablen können auch Direktwerte angegeben werden.
Operation(en) ausführen: y-Operator:
y (1. Ressource, 2. Ressource usw.)
Der y-Operator löst die Verarbeitung in den angegebene Ressourcen aus. Was in den Ressourcen jeweils
geschieht, ergibt sich entweder direkt aus der Art der Ressource (falls diese nur eine einzige Funktion
ausführen kann) oder aus Parametern (Funktionscodes), die vorher einzustellen sind (z. B. mit s- oder p-Operatoren).
Ergebnisse abholen: a-Operator:
a (1. Ressource . 1. Ergebnis => 1. Ergebnisvariable, 2. Ressource . 2. Ergebnis => 2. Ergebnisvariable
usw.)
Der a-Operator weist die Inhalte der angegebenen Ergebnispositionen der angegebenen Ressourcen den
angegebenen Variablen zu. Die Variablen werden durch Namen, Ordinalzahlen oder Adressen bezeichnet.
Transportieren von Parametern (vom Ausgang zum Eingang): l-Operator:
l (1. Quell-Ressource . 1. Ergebnis => 1. Ziel-Ressource . 1. Parameter, 2. Quell-Ressource . 2. Ergebnis
=> 2. Ziel-Ressource . 2. Parameter usw.)
Der l-Operator bewirkt den Transport von Parametern zwischen verschiedenen Ressourcen.
Verkettung herstellen (vom Ausgang zum Eingang): c-Operator:
c (1. Quell-Ressource . 1. Ergebnis => 1. Ziel-Ressource . 1. Parameter, 2. Quell-Ressource . 2.
Ergebnis => 2. Ziel-Ressource . 2. Parameter usw.)
Der
c-Operator trägt Verkettungssteuerangaben in die jeweiligen Ressourcen
ein. In manchen Implementierungen (z. B. in FPGAs) kann er veranlassen,
daß die entsprechenden physischen Verbindungen hergestellt werden. Die
Ressourcen sind zu verketten, bevor die betreffenden
Verarbeitungsfunktionen ausgelöst werden (y-Operator).
Verkettung trennen: d-Operator:
d (1. Quell-Ressource . 1. Ergebnis => 1. Ziel-Ressource . 1. Parameter, 2. Quell-Ressource . 2.
Ergebnis => 2. Ziel-Ressource . 2. Parameter usw.)
Der d-Operator trennt bestehende Verkettungen. In manchen Implementierungen (z. B. in FPGAs) kann
er veranlassen, daß die entsprechenden physischen Verbindungen aufgelöst werden. Anschließend
können die Ressourcen anderweitig verkettet oder auch einzeln betrieben werden.
Ressource(n) freigeben: r-Operator:
r (1. Ressource, 2. Ressource usw.)
Die angegebenen Ressourcen werden freigegeben. Sie stehen somit für andere Verarbeitungsaufgaben
zur Verfügung
Beispiel:
• Programmierabsicht: X := (A + B) * (C + D)
• nutzbare Ressourcentypen: ADD, MULT
Abb. 5 veranschaulicht die Ressourcenanordnung. Zur Verkettung vgl. Abb. 3.
Ausführliche Notation (jeder Vorgang einzeln):
s (ADD, ADD, MULT)
p (A => 1.1)
p (B => 1.2)
p (C => 2.1)
p (D => 2.2)
y (1)
y(2)
l (1.3 => 3.1)
l (2.3 => 3.2)
r (1, 2)
y (3)
a (3. 3 => X)
r (3)
Verkürzte Notation:
s (ADD, ADD, MULT)
p (A => 1.1, B => 1.2, C => 2.1, D => 2.2)
y (1, 2)
l (1.3 => 3.1, 2.3 => 3.2)
r (1, 2)
y (3)
a (3.3 => X)
r (3)
Als Datenflußschema (Verkettung):
s (ADD, ADD, MULT)
c (1.3 => 3.1, 2.3 => 3.2)
p (A => 1.1, B => 1.2, C => 2.1, D => 2.2)
y (1, 2, 3)
a (3.3 => X)
r (1, 2, 3)
Abb. 5 Die Ressourcenanordnung des Beispiels.
ReAl und gegebene Programmiersprachen
ReAl
ist zunächst eine maschinenunabhängige Zwischensprache (ähnlich dem
bekannten Java-Bytecode). Das Ziel besteht aber nicht darin, mit
möglichst wenigen Bytes auszukommen (Code-Kompression),
sondern darin, wesentliche Feinheiten des Verarbeitungsprozesses genau
zu beschreiben. ReAl wäre in
diesem Sinne beispielsweise mit PostScript zu vergleichen. Typische
Ziele:
• Den innewohnenden (inhärenten) Parallelismus bereits in statu nascendi zu erfassen,
• so zu tun, als ob es immer genügend Hardware gäbe. Damit ist der ReAl-Code invariant gegen die
technologische Entwicklung.
• so zu tun, als könne man ohne weiteres spezielle Hardware bauen (durch Verkettung usw.). Somit
sind je nach den Kosten- und Leistungszielen und nach dem Stand der Technologie Hard- und
Software gegeneinander austauschbar.
Nutzungs-Szenarien:
• herkömmliche Programmiersprache => ReAl-Beschreibung,
• neuartige (ressourcenorientierte) Programmiersprache => ReAl-Beschreibung,
• ReAl-Beschreibung => ReAl Interpreter auf gegebener Maschine,
• ReAl-Beschreibung => compilierter Code für gegebene Maschine,
• ReAl-Beschreibung => Code für ReAl-Maschine.
Die
hier verwendeten Notationen sind an sich zur maschineninternen Nutzung
gedacht. Deshalb wird auf
Anwendungsfreundlichkeit usw. kein Wert gelegt – es geht nicht um eine
neue Programmiersprache für
Anwendungsprogrammierer. Der ReAl-Textcode soll vielmehr kurz sein, um
entsprechende Darstellungen programmtechnisch effektiv auswerten zu
können (Durchmusterung, Analyse, Wandlung,
Übersetzung usw.).
ReAl-Programme sind im Grunde Herstellungsanweisungen („man nehme ... und führe folgende Schritte
aus ...“). Sie eignen sich also nur wenig zum Erfassen von Programmierabsichten (Gleichnis aus dem
Maschinenbau: man wird eine Drehbank oder einen Verbrennungsmotor zunächst zeichnerisch darstellen
und nicht sofort – unmittelbar vom Erfindungsgedanken ausgehend – eine Fertigungsdokumentation
ausarbeiten).
Die Standardisierung von Ressourcen und einschlägigen Beschreibungsmitteln ist vor allem für die
Nutzung als universelle Metasprache von Bedeutung.
|