GYVE(ID:809/gyv001)Concurrent SETL dialectOS programming language, highly modular, PASCAL-like "The GYVE language is intended for applications involving mutually suspicious processes. It provides a high degree of protection, explicit scheduling, and a very flexible scheme for creating virtual machine interfaces" Memory is divided into Accounts pointers said by Wand to be more flexible than Modula's Related languages
References: in ACM SIGOPS Operating Systems Review 12(01) January 1978 view details in ACM SIGOPS Operating Systems Review 12(01) January 1978 view details in ACM SIGOPS Operating Systems Review 12(01) January 1978 view details Extract: GYVE GYVE The GYVE language is intended for applications involving mutually suspicious processes. It provides a high degree of protection, explicit scheduling, and a very flexible scheme for creating virtual machine interfaces. GYVE programs consist of a series of modules each containing a series of procedure, mode, and monitor definitions. Modes are templates which are used to dynamically define new monitors. They are also used as the basic data abstraction mechanism in the language. A module can contain global types and constants, but it cannot contain global variables. Global variables can only be declared inside a monitor, and can only be accessed by mutually exclusive procedures. Mcdules can be compiled dynamically, and can import procedures and monitors defined in previously compiled modules. GYVE views memory as a large heap which is divided into areas known as ACCOUNTS. When the system is initialized there is a single master account which represents all of memory. This account can be used to create smaller accounts using a PASCAL-like NEW function. The NEW function takes two arguments, a type and an account. It causes an exception if the account is out of space. The ACCOUNT mechanism can be used by an operating system to limit the amount of space available to various processes, users, and subsystems. GYVE views processes as instances of a builtin mode called PROCESS. The process mode takes two parameters which are supplied when a process is created. There parameters are the name of a procedure which is to serve as the 'main program' for the process and an integer which indicates the amount of space to be reserved for the process. Each process contains an invocation stack and a private heap. The private heap is used to allocate plex structures which are local to the process. GYVE pointers can be declared with extremely powerful constraints. For example: VAR p: | queue (add) ; declares P to be a pointer to a instance of the mode QUEUE, and indicates that P can only be used to access the queue's ADD procedure. GYVE's scheduling mechanisms are completely explicit. Each CPU is viewed as an abstract machine which is capable of executing GYVE processes. Processes can in turn execute other processes. This ability to execute processes is quite general. It allows a CPU to execute a top level process, which in turn executes another process, which executes a still lower level process, etc. Scheduling is thus heirarchical, with each process scheduling a set of lower level processes. A process PSi can execute another process PS2 using the statement execute (ps2, time=t, prio=5, port=pt) ; This statement indicates that PS1 is to execute PS2 for a maximum of T time units. The PORT parameter points to a message buffer. Any messages arriving at this buffer with a priority greater than 5 will interrupt PS2 and return control to PSi. Ports are general message buffers which can be manipulated using SEND and WAIT primitives. A process cannot tell whether it is running on a bare machine or whether it is running under another process. Furthermore, it cannot tell whether an account represents all of memory or just a part of it. This means that a GYVE program which was meant to be run on a bare machine using the laaster account can be run under a host operating system using a virtual master account. This virtual machine facility is a very powerful debugging tool. Abstract: Is One Language Enough? Each of the languages we have looked at has advantages for certain applications. GYVE provides the most protection, but is inconvenient for applications involving cooperative processes. ADA, CPASCAL, and MODULA are reasonable for applications involving cooperative processes. However they enforce a standard scheduling algorithms and treat interrupts on a level which is sometimes unnecessarily abstract. The very low level features of C are sometimes useful. It seems undesireable to have several unrelated languages, each for a different application area. The alternative is to have one language with several dialects. Some dialects would be relatively low level and unprotected, while others would be high level and strongly protected. I am currently investigating the idea of two dialects for GYVE. The 'privileged' dialect would be similar to the language described above. One of the interesting features of GYVE is that processes, ports, and accounts are all abstract data types which are defined in a standard prelude. Primitives such as execute, send, and wait are also defined in the prelude. The only concurrency primitives which are actually built into the language are 'seize a monitor' and 'release a monitor'. These primitives are called implicitly but are defined in the standard prelude. The important point is that the standard prelude is written in the privileged dialect, and can be redefined by the user. GYVE programs will consist of privileged and non-privileged modules. Privileged modul~s must be loaded when the system is initialized, while non-privileged modules can be loaded dynamic~lly. Privileged modules can contain primitives such as test-and-set, enable-disable, and load and store context. They can access memory directly, do unsafe type conversions, and set interrupt vectors. They will also be able to redefine types and procedures defined in the standard prelude. The two dialect approach provides great power for specifying low level operations while-retaining the protection of the original language. Extract: Is One Language Enough? Is One Language Enough? Each of the languages we have looked at has advantages for certain applications. GYVE provides the most protection, but is inconvenient for applications involving cooperative processes. ADA, CPASCAL, and MODULA are reasonable for applications involving cooperative processes. However they enforce a standard scheduling algorithms and treat interrupts on a level which is sometimes unnecessarily abstract. The very low level features of C are sometimes useful. It seems undesireable to have several unrelated languages, each for a different application area. The alternative is to have one language with several dialects. Some dialects would be relatively low level and unprotected, while others would be high level and strongly protected. I am currently investigating the idea of two dialects for GYVE. The 'privileged' dialect would be similar to the language described above. One of the interesting features of GYVE is that processes, ports, and accounts are all abstract data types which are defined in a standard prelude. Primitives such as execute, send, and wait are also defined in the prelude. The only concurrency primitives which are actually built into the language are 'seize a monitor' and 'release a monitor'. These primitives are called implicitly but are defined in the standard prelude. The important point is that the standard prelude is written in the privileged dialect, and can be redefined by the user. GYVE programs will consist of privileged and non-privileged modules. Privileged modul~s must be loaded when the system is initialized, while non-privileged modules can be loaded dynamic~lly. Privileged modules can contain primitives such as test-and-set, enable-disable, and load and store context. They can access memory directly, do unsafe type conversions, and set interrupt vectors. They will also be able to redefine types and procedures defined in the standard prelude. The two dialect approach provides great power for specifying low level operations while-retaining the protection of the original language. in [ACM] Proceedings of the 1979 ACM annual conference view details in [ACM] Proceedings of the 1979 ACM annual conference view details MODULA is a simple programming language proposed by Wirth (1977a) for use in programming areas still dominated by Assembly code, such as process control, computerised laboratory equipment and input/output device drivers. Coding exercises in MODULA by Wirth (1977b) and others (Holden and Wand, 1978) have shown that the language is quite successful in these areas of application and is particularly good for the expressioh of single programs that will run on dedicated computing equipment. However the language does have a number of drawbacks if it is to be used for the coding of operating systems kernels or for the writing of any software component where supervision plays an important part. In particular these difficulties centre upon (a) a process supervising other processes (b) a storage allocation process and (c) the general handling of error conditions at both the process and module level. It is interesting to note that these are all requirements of the so-called 'Ironman' language (1977). This paper examines extensions to MODULA which attempt to overcome these drawbacks. A new storage mechanism is proposed based upon a declared type called a region which is very similar to the implicit heap in PASCAL. For references into such storage, PASCAL-like pointers are proposed. In addition it is proposed that processes and their storage must be allocated within a region, although it is not suggested that device processes should be included in this new mechanism. Thereafter references to ordinary processes must be made via pointers, and, furthermore, when a process is run it can be executed for a given number of signal occurrences (usually originating from a device process) under the supervision of a parent process. By this mechanism supervisory processes can be constructed which can then make sure that a process can only run for a limited period and can subsequently terminate that process if necessary. An exception mechanism is proposed for transmitting error conditions; however the mechanism can be used quite generally. We suggest that these extensions will cause moderate complications in the language definition and in the compiler. The major run time complication is in the storage allocation mechanism which implies a PASCAL-like heap within every region, although with the simplification that any region is allocated within the storage space of the parent process. In conclusion we suggest that the facilities proposed will enable a MODULA-like language to be used for the coding of basic operating system components. Extract: Modula vs GYVE vs EUCLID Note that this proposal certainly lacks the flexibility of GYVE pointers (Schwartz and Shaw, 1976) or the completeness of the Euclid (Lampson et al., 1977) visibility rules. However it is suggested that the simple rules of MODULA, together with the modification suggested here, will deal with the majority of practical cases. in The Computer Journal 23(2) 1980 view details |