1. Basic concepts introduced in NIL
1.1 Aim of NIL
The two main objectives of NIL are:
-
to describe the environment in which a program is executed (its complement ); this involves the description of:
- data formats and data structures
- exchanges with input and output devices and characteristics expected from them
- interface with operating system
-
to express the front end part of an interactive system:
The data flow through an interactive system generally decreases as the data reaches the kernel of the system: it is assumed that in many interactive systems a separable module exists or can be defined which involves a great amount of data exchanged with the user, and much less exchanged with the rest of the system. This module is called Front-End. It is important that the response time of the system is affected as little as possible by additional transmission delays. Also, it is desirable to keep the data rates as low as possible on the network.
It is assumed that the transfer of a Front End does not imply to solve the whole problem of program transferability.
1.2 NIL subcategorization
As pointed out by S. Volansky [ ] it is convenient to divide languages in several sublanguages corresponding to their main functions. NIL is thus subdivided in:
- a control sublanguage
- an operation sublanguage
- a data declaration sublanguage
- an environment sublanguage
1.2.1 Control sublanguage
The control sublanguage states WHEN a computation is done: It describes the flow of control or ordering of the computations. With some information contained from the other sections of the language, it also states WHERE the computations are to be executed.
As a computer network introduces loose connections between several systems, the control language of the Network Machine should be able,in an elaborate version,of assigning computations to available processors, taking into account the time delays and resource allocation problems involved. It is not our purpose to consider this level at the moment.
1.2.2 Operation sublanguage
The operation sublanguage describes the operations to be performed on the data without indication of the sequencing between operations, it answers to the question of HOW an operation is performed. The operations are subdivided into two groups.
- a computation group
- a data manipulation group
The later is the most important part of NIL since its main purpose is the transformation of data structures and patterns.
1.2.3 Data declaration sublanguage
The data declaration sublanguage is necessary to declare the variables and data structures on which operations are performed.
The possibility is given to build structures of atomic elements called beads. NIL provides a standard set of beads used in the "standard mode" ; in the "extended mode" a user may define new beads and new structures of them.
1.2.4 Environment sublanguage
The environment sublanguage expresses the context in which a program expects to operate; expected characteristics of the peripherals, semantics of the exchanges with the outside world through a particular operating system.
Thus a complete "program descriptor" will contain four distinct sections:
- environment section
- data declaration section
- control section
- operation section
The identification section is omitted because it corresponds to the log in and socket grabbing part of the initialization procedure.
1.3 The Network Machine
One fundamental concept in NIL is that of an abstract Network Machine which has the following characteristics:
-
an infinite memory: there is no problem of memory allocation or garbage collection in this machine. But as an item must be accessible, it must still have an address.
-
variable word length: a word may be considered as the smallest intelligible and addressable item of data. The atomic element called bead is in fact the machine word. The structure and length of each type of beads are expressed in the data definition sublanguage.
As presented on figure 1.3.1, one HOST only communicates with a Network Machine which may operate in two modes.
Network
+--------+ Machine
| HOST | <----------------------------------(
+--------+
Figure 1.3.1
-
standard mode where the beads, their structures,and the allowed transformations on them are standard and need not to be redefined: standard beads and structures are known of every HOST
-
extended mode where in addition to or instead of the standard data definitions and manipulation, a HOST may specify new beads structures and transformations. The extended mode allows the user to define his own machine as the Network Machine. This is then equivalent to the modes MY LOCAL, YOUR LOCAL, proposed in RFC #42 by Ancona. If the definition of a name has not been altered the standard definition is assumed.
The data definition sublanguage is as well used for the purpose of documenting the set of standard beads.
The instruction set of the Network Machine stands at a high level permitting global transformations of data structures.
The environment of the Network Machine is determined by the subset of the environment of the server's HOST which is used by the program in execution; the system HOST-Network Machine can take two main configurations shown in figure 1.3.2.
+----------+ / Network
| user | <------------------( Machine
| HOST | \ (server)
+----------+
Network +------------+
Machine (user) ---------------( | server |
| HOST |
+------------+
-
The Network Machine stands for the user of a program provided by the HOST (server HOST)
-
The HOST machine is the user of a program provided by the Network Machine.
The server machine assigns its hardware environment to the user machine. This choice is made so that programs can be remotely used without being modified; it is up to the user of a remote program to adapt himself and his own environment.
Thus, when the Network Machine is server, it defines the Data Definition and Environment sections.
Figure 1.3.2
1.4 Implementation
The data and environment definition sublanguages should be able to describe as well environment and data in HOSTs as data in Network Machine. At the limit it should enable two programs written in different languages to communicate, as long as the data representation they use are expressible in the data description sublanguage.
In each HOST will be implemented a "generator" which will accept rules describing the HOST data structures and environment and will generate an adequate translator to translate them in Network Machine format, as shown in the figure 1.4.1.
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 |
| |
+-------------------------------------------------+
Figure 1.4.1
Once the network machine standards will be settled it seems valuable to think about emulating the translator using a microprogramed unit which would be either added to the Host or rather to the IMP" thus avoiding the load of a translation which may involve lengthy operations on the bit level - (figure 1.4.2.)
+--------+ +--------+ / Network
| HOST | <----------| HOST | <-------------( Machine
+--------+ +--------+ \
Figure 1.4.2