1. In NIL eingeführte Grundbegriffe
1.1 Ziel von NIL
Die beiden Hauptziele von NIL sind:
-
die Umgebung zu beschreiben, in der ein Programm ausgeführt wird (ihr Komplement ); dies umfasst die Beschreibung von:
- Datenformaten und Datenstrukturen
- Austauschvorgängen mit Ein- und Ausgabegeräten und den von ihnen erwarteten Eigenschaften
- der Schnittstelle zum Betriebssystem
-
den Front-End-Teil eines interaktiven Systems auszudrücken:
Der Datenfluss durch ein interaktives System nimmt im Allgemeinen ab, je näher die Daten dem Kern des Systems kommen: Es wird angenommen, dass es in vielen interaktiven Systemen ein abtrennbares Modul gibt oder definiert werden kann, das eine große Menge an mit dem Benutzer ausgetauschten Daten und eine viel geringere mit dem übrigen System ausgetauschte Datenmenge umfasst. Dieses Modul wird Front-End genannt. Es ist wichtig, dass die Antwortzeit des Systems so wenig wie möglich durch zusätzliche Übertragungsverzögerungen beeinträchtigt wird. Außerdem ist es wünschenswert, die Datenraten im Netz so niedrig wie möglich zu halten.
Es wird angenommen, dass die Übertragung eines Front-Ends nicht voraussetzt, das gesamte Problem der Programmübertragbarkeit zu lösen.
1.2 Unterteilung von NIL
Wie S. Volansky [ ] hervorgehoben hat, ist es zweckmäßig, Sprachen in mehrere Teilsprachen entsprechend ihren Hauptfunktionen zu unterteilen. NIL wird daher unterteilt in:
- eine Steuerungs-Teilsprache
- eine Operations-Teilsprache
- eine Datendeklarations-Teilsprache
- eine Umgebungs-Teilsprache
1.2.1 Steuerungs-Teilsprache
Die Steuerungs-Teilsprache legt fest, WANN eine Berechnung durchgeführt wird: Sie beschreibt den Kontrollfluss bzw. die Reihenfolge der Berechnungen. Mit einigen Informationen aus den anderen Abschnitten der Sprache legt sie auch fest, WO die Berechnungen ausgeführt werden sollen.
Da ein Rechnernetz lose Verbindungen zwischen mehreren Systemen einführt, sollte die Steuerungssprache der Netzmaschine,in einer ausgearbeiteten Version,in der Lage sein, Berechnungen verfügbaren Prozessoren zuzuweisen und dabei die damit verbundenen Zeitverzögerungen und Probleme der Ressourcenzuteilung zu berücksichtigen. Es ist derzeit nicht unsere Absicht, diese Ebene zu betrachten.
1.2.2 Operations-Teilsprache
Die Operations-Teilsprache beschreibt die an den Daten durchzuführenden Operationen ohne Angabe der Reihenfolge zwischen den Operationen; sie beantwortet die Frage, WIE eine Operation durchgeführt wird. Die Operationen werden in zwei Gruppen unterteilt.
- eine Berechnungsgruppe
- eine Datenmanipulationsgruppe
Letztere ist der wichtigste Teil von NIL, da dessen Hauptzweck die Transformation von Datenstrukturen und -mustern ist.
1.2.3 Datendeklarations-Teilsprache
Die Datendeklarations-Teilsprache ist notwendig, um die Variablen und Datenstrukturen zu deklarieren, auf denen Operationen durchgeführt werden.
Es wird die Möglichkeit gegeben, Strukturen aus atomaren Elementen, sogenannten Perlen, aufzubauen. NIL stellt einen Standardsatz von Perlen bereit, der im „Standardmodus“ verwendet wird; im „erweiterten Modus“ kann ein Benutzer neue Perlen und neue Strukturen aus ihnen definieren.
1.2.4 Umgebungs-Teilsprache
Die Umgebungs-Teilsprache drückt den Kontext aus, in dem ein Programm zu arbeiten erwartet; die erwarteten Eigenschaften der Peripheriegeräte, die Semantik der Austauschvorgänge mit der Außenwelt über ein bestimmtes Betriebssystem.
Somit wird ein vollständiger „Programmdeskriptor“ vier getrennte Abschnitte enthalten:
- Umgebungsabschnitt
- Datendeklarationsabschnitt
- Steuerungsabschnitt
- Operationsabschnitt
Der Identifikationsabschnitt entfällt, da er dem Anmelde- und Socket-Belegungsteil der Initialisierungsprozedur entspricht.
1.3 Die Netzmaschine
Ein grundlegendes Konzept in NIL ist das einer abstrakten Netzmaschine, die folgende Eigenschaften hat:
-
ein unendlicher Speicher: In dieser Maschine gibt es kein Problem der Speicherzuteilung oder der Speicherbereinigung. Da ein Element jedoch zugänglich sein muss, muss es dennoch eine Adresse haben.
-
variable Wortlänge: Ein Wort kann als das kleinste verständliche und adressierbare Datenelement betrachtet werden. Das atomare Element namens Perle ist in Wirklichkeit das Maschinenwort. Struktur und Länge jedes Perlentyps werden in der Datendefinitions-Teilsprache ausgedrückt.
Wie in Abbildung 1.3.1 dargestellt, kommuniziert ein HOST nur mit einer Netzmaschine, die in zwei Modi arbeiten kann.
Network
+--------+ Machine
| HOST | <----------------------------------(
+--------+
Abbildung 1.3.1
-
Standardmodus, in dem die Perlen, ihre Strukturen,und die an ihnen zulässigen Transformationen standardisiert sind und nicht neu definiert werden müssen: Standardperlen und -strukturen sind jedem HOST bekannt
-
erweiterter Modus, in dem ein HOST zusätzlich zu oder anstelle der Standard-Datendefinitionen und -manipulationen neue Perlen, Strukturen und Transformationen festlegen kann. Der erweiterte Modus erlaubt es dem Benutzer, seine eigene Maschine als die Netzmaschine zu definieren. Dies entspricht dann den Modi MY LOCAL, YOUR LOCAL, die in RFC #42 von Ancona vorgeschlagen wurden. Wurde die Definition eines Namens nicht geändert, wird die Standarddefinition angenommen.
Die Datendefinitions-Teilsprache wird ebenso zur Dokumentation des Satzes der Standardperlen verwendet.
Der Befehlssatz der Netzmaschine steht auf einer hohen Ebene und erlaubt globale Transformationen von Datenstrukturen.
Die Umgebung der Netzmaschine wird durch die Teilmenge der Umgebung des Server-HOSTs bestimmt, die vom ausgeführten Programm verwendet wird; das System HOST-Netzmaschine kann zwei Hauptkonfigurationen annehmen, die in Abbildung 1.3.2 gezeigt sind.
+----------+ / Network
| user | <------------------( Machine
| HOST | \ (server)
+----------+
Network +------------+
Machine (user) ---------------( | server |
| HOST |
+------------+
-
Die Netzmaschine steht für den Benutzer eines vom HOST (Server-HOST) bereitgestellten Programms
-
Die HOST-Maschine ist der Benutzer eines von der Netzmaschine bereitgestellten Programms.
Die Server-Maschine weist der Benutzer-Maschine ihre Hardware-Umgebung zu. Diese Wahl wird getroffen, damit Programme aus der Ferne benutzt werden können, ohne verändert zu werden; es ist Sache des Benutzers eines entfernten Programms, sich selbst und seine eigene Umgebung anzupassen.
Wenn also die Netzmaschine der Server ist, definiert sie die Abschnitte Datendefinition und Umgebung.
Abbildung 1.3.2
1.4 Implementierung
Die Teilsprachen zur Daten- und Umgebungsdefinition sollten Umgebung und Daten in HOSTs ebenso beschreiben können wie Daten in der Netzmaschine. Im Grenzfall sollten sie es zwei in verschiedenen Sprachen geschriebenen Programmen ermöglichen, miteinander zu kommunizieren, sofern die von ihnen verwendete Datendarstellung in der Datenbeschreibungs-Teilsprache ausdrückbar ist.
In jedem HOST wird ein „Generator“ implementiert, der Regeln entgegennimmt, welche die Datenstrukturen und die Umgebung des HOSTs beschreiben, und einen geeigneten Übersetzer erzeugt, um diese in das Format der Netzmaschine zu übersetzen, wie in Abbildung 1.4.1 gezeigt.
HOST description Network Machine
(description
non standard mode) +---------------------+
| Network Machine |
| standard mode |
+---------------------+
| |
v |
+-------------+ |
| GENERATOR | |
+-------------+ |
| |
v |
Data in +--------------+ Data is |
HOST | TRANSLATOR | Network Machine |
format +--------------+ format |
| |
+-------------------------------------------------+
Abbildung 1.4.1
Sobald die Standards der Netzmaschine festgelegt sind, scheint es lohnend, über die Emulation des Übersetzers durch eine mikroprogrammierte Einheit nachzudenken, die entweder dem Host oder eher dem IMP" hinzugefügt würde, wodurch die Last einer Übersetzung vermieden würde, die langwierige Operationen auf Bitebene erfordern kann - (Abbildung 1.4.2.)
+--------+ +--------+ / Network
| HOST | <----------| HOST | <-------------( Machine
+--------+ +--------+ \
Abbildung 1.4.2