TR4(ID:7281/tr:001)Extensible compiler generator system for the Telefunken TR4 ComputerExtensible compiler generator system for the Telefunken TR4 Computer Related languages
References: CL-II System Environment The CL-II Programming System has been developed for the Air Battle Analysis Center, now a part of Directorate of Studies and Analyses, Headquarters, United States Air Force, in response to the software requirements imposed by the development and operation of large scale simulation and data management programs. The development of CL-II has been in progress for several years. A first and experimental version of the system, in operation approximately two years ago, was used only by the developers for testing and evaluating the basic system functions. Since that time the system has been torn apart, reconstructed and extended with compilers, data facilities and monitors. This version of the system is the initial production version and is now in operation. Extract: General Description General Description. CL-II has been implemented on an IBM-7094 computer having two data channels with eight tapes per channel, a card reader and printer, a one-sixtieth of a second interval clock timer, and an externM signal interrupt facility. The system operates in conjunction with area files (carried as tape files) as the repositories of code and data. All programming is performed in the context of adding entities to or using entities on an areafile. The entities carried on an area file are: routines (source and compiled forms), data descriptions and data instances (source and binary forms), and prepared routines. A routine is the basic unit of filed coding in the system. A data description is a set of information that "defines" (specifies name, type, conversion, size, etc.) the elements in an array of data elements and describes their structure externally (i.e., on cards) and their structure internally (i.e., memory image). A data instance is a filed internal representation of a set of values for the elements defined in a data description. There may, of course, exist many data instances all described by the same data description. Routines may reference data instances and other routines. That is, within the source language version of a routine there can exist statements that access elements of a data instance by name and statements that are "calls" on other routines. Indeed, the intent is that programs will be written and presented to the system piecemeal and that the pieces will necessarily reference one another. A routine then includes in addition to the code body a set of declarations about the data instances and other routines referenced. These declarations both identify the entities referenced and also indicate how the entities are referenced. Program entities are identified by name and are used either dependently (akin to locally) or independently (akin to globally) (these terms will be explained further below). A routine is "defined" to the system when it is compiled and filed in "compiled" or relocatable machine code form. A prepared routine is a compiled routine that has been conjoined or linked to its set of dependent entities: this is the from of a program piece that can be loaded and executed. The linkage of prepared routines to their independent entities occurs during loading and execution. Programming in CL-II then consists of defining routines and data, inputting data instances and preparing routines, and finally executing prepared routines. Extract: Control Structure Control Structure. CL-II receives as input a stream of jobs. A job is a sequence of requests for the execution of various prepared routines. Some requests are for system programs that do the work of defining and preparing other programs; others are for user programs that are being tested or used on a production basis. A job monitor translates these requests and causes the designated programs to be set up and executed. Control-wise the system views a job during its execution as a set of tasks. A task is a prepared routine that is "active" (i.e., contained in the set of programs being executed). Tasks may be executed in parallel with each other. Each task has one or more paths or sequences of code to be executed (in parallel) within the task. The system operates through selecting and executing paths. The paths interact with the system and each other through Calls on system functions to: (1) make I/O requests, (2) establish new programs, (3) execute paths or tasks, (4) await I/O, path or task completion, (5) end a path, and so on. As paths are initiated, completed, postponed for an await condition, or interrupted from I/O completions or timer signals, the status of the system changes and different paths are executed until programs are completed. The linkage mechanisms to be examined are those that provide for the preparation of routines and the dynamic connection of prepared routines with their independent entities. In Section 3 these facilities are discussed in relation to bookkeeping for the description and manipulation of program structures. Extract: CL-II Linkage Mechanisms CL-II Linkage Mechanisms The CL-II system associates with each job a unit of bookkeeping called the job element. In addition to other control information, the job element contains a priority specification and a pointer to a chain of task elements associated with the tasks of that job. The task element, in turn, points to a chain of path elements for the paths of that task. In addition, all of the task elements of all jobs are chained together in order of descending priority, where task priority is a function of both job priority and time of task initiation. The CL-II system selects paths for execution by stepping through the path elements of the task elements in the task chain, looking for an enterable (i.e., "ready") path. The first enterable path found is given control. Calls on system functions are effected by treating the functions allocated as paths of the calling task. The functions are equipped with "locking code" as required to resolve any problems of multiple entry. Thus, the priority for performance of a given system function is dependent on the priority of the job for which the function is required. Extract: Program Structure Program Structure. The task is the unit of allocation, loading and binding, and the task element points to books which reflect the resources allocated to that task. In addition, for each global data set (defined below) of the task, there exists a data element which describes the allocation of the current instance of the data set in the task, the current location of that data instance (e.g., "at home," "dumped," etc.), and the relation of that data instance to the task (see below). The path is the unit of execution, and the path element contains register values and control information (e.g., enterable, awaiting I/O) for the code which constitutes the path. It should be noted that two paths of a task may share code, but any synchronization of paths required to enable this sharing must be provided by the programmer. A path may call for the independent execution of a routine. The system then assumes responsibility for: (1) allocating and loading the called routine, performing dumping of other routines as required to accomplish these functions; (2) passing arguments of call and specified data instances to the routine; (3) establishing the appropriate system books for the new routine (task and path elements); and (4) making the enterability of the calling path dependent on the completion of the called routine. Data instances that are passed to accomplish routine-to-routine communication are defined to be global, i.e., to be received from or passed to another routine. Thus, independent data instances are global, and dependent data instances are local and not passed between routines. Correspondingly, dependent routines reside within a prepared routhm and are not involved in the passing of global data instances. Independent routines are, in fact, prepared routines, executed as tasks, and do communicate with each other through the passing of global data. In the CL-II system, the definable relations between a task and the global data sets in its ken are three, namely: initialization, responsibility, and custody. (1) "Task A is initialized by a data instance X" means that the values of a global data set referred to by A are set to the values of X at load time for the task. (2) "Task A has responsibility for data instance X" means that instance X leaves the ken of the system when task A terminates. (3) "Task A has custody of data instance X" means that if A is not responsible for X, then, when A terminates, the values of a global data set referred to by A are used to replace the values of X. A task is responsible for its own instances of global data sets. The "name" by which the system refers to such an instance is composed of the name of the data description of the set and the name of the responsible routine, with a special delimiter to divide the two names. Thus, the global data instance referred to by task A and described via data description SAM is named SAM/A. Initially, a task A has custody of all those data instances for which it is responsible. However, upon calling a task B, the task A may pass custody of any global data instance SAM/A for which A is custodian to the called task B. The called task B may, in turn, pass custody, and so on, until some task X terminates with custody of SAM/A but not responsibility for SAM/A, at which time the instance of SAM for which X is responsible, i.e., SAM/X, is used to establish new values for SAM/A, and custody of SAM/A reverts to the responsible task, A. Since X is telzninating, SAM/X then leaves the ken of the system. The initialization of a global instance SAM/B by the instance SAM/A may be specified, independent of custody passage, at the time task A calls task B. Thus the values of a data instance in task A may be used to drive task B without the terminal values of B affecting A. Each task element points to a chain of data elements for those global instances for which the task is responsible and a chain of data elements for those global instances of which the task has custody. These data elements are units of bookkeeping for global data instances. They specify the location of the values required to accomplish the "global" data set passage specified at task call time. A "global" data instance may be initialized by an instance of a data set on an area file as opposed to an instance belonging to the calling routine. If such an initialization is specified by the calling routine, the system locates the required instance on the specified area file and performs the initialization. In the initial CL-II system, a routine may be passed custody of only its father's (i.e., caller's) instance of a data set; in this case it is initialized by that instance However, books and system functions for the specification at call time of which instance is to be passed and/or used for initialization have been designed and are being incorporated. When these facilities are incorporated, run time declarations concerning data passage will override prepare time declarations, and a routine may be initialized by any of its ancestors' instances of a data set. In addition, custody will be passable from father to son to progeny and so on, until some progenitor terminates with custody. Extract: Program Structure Argument Passage. In the CL-II system, arguments of call are gathered at routine call time and made available to the called routine at its execution time. Argument specifications are quite flexible in scope, namely: (1) literal--the argument specification's value may be passed. (2) word--the value of a specified word may be passed. (3) string--a formal CL-II string may be passed. (4) vector--a collection of N consecutive word values may be passed, where N is either specified in the argument specification or given as the value of a specific word. (5) reference--a reference is an argument specification to be passed. It points to a collection of N consecutive words, each of which is an argument specification to be passed. In turn, each of these argument specifications points to an argument to be passed. (6) substitution--a substitution is the same as a reference except that the substitute specification itself is not passed. The distinction between a reference and a substitution is subtle but significant. A reference must be recognized as such by the called routine and agreed upon as a part of its calling sequence. A substitution is interpreted by the CL-II argument passage machinery as if the collection of arguments to which it points had occurred at the point in the argument specification set where the substitute occurred and, consequently, need not be prearranged with the called routine. Argument specifications are of two types: direct (i.e., those appearing or seemingly appearing "in line"), and indirect (i.e., those "pointed" to by the in-line argument reference). A substitute may not be used as an indirect argument. At the time the execution of a prepared routine is requested the argument specifications associated with the call are interpreted and two tables are produced: the direct argument table and the indirect argument table. The direct argument table is composed of those arguments specified directly, with substitutions being performed beforehand; the indirect argument table is composed of those argument values and indirect argument specifications which were indirectly pointed to or referred to by the calling sequence. The pointer values of the direct arguments are bound to the relative locations of the appropriate values in the indirect table. Similarily, all indirect argument specifications are bound relative to the values to which they point. The direct and indirect argument tables are treated by the system as instances of a system-defined data set for which the called routine is responsible and of which it has custody. The global data set passage machinery is subsequently used to establish these values in the called prepared routine. In addition, the pointers in the argument specifications are bound relative to the location allocated by the system to the indirect argument set, and the direct argument set is surrounded by system-generated coding to provide an executable direct call on the prepared routine. This "fixing" of entry and exit points by the system allows routines to use exactly the same coding for picking up arguments of call whether they are called as independent routines or as dependent routines co-resident with the caller, without, in the latter case, paying the price for system interpretation and data passage. That is, in the case of independent prepared routines, argument specifications and the values of arguments are collected from the calling routine and are so bound and positioned with respect to a system-generated "pseudo call", that, to the routine being called, the methods used for accessing arguments are the same as if it were a dependent routine of the caller. This same mechanism can be used to transmit argument specifications and values to a routine that is called via a timeshared console or a job level statement. In these cases also the called routine need not be aware of the source of the arguments. Extract: Operations of Linking Mechanisms Operations of Linking Mechanisms. At the time that a routine is defined to the system via a compiler or assembler, certain linkage statements are required. A list of the routines dependent on or directly called (i.e., called via direct transfer of control) by the routine being defined and a list of all data sets accessed by the routine are required. The system, where required, utilizes data descriptions to generate code for the accessing of elements in the specified data sets. At routine preparation time, the compiled versions of all directly referenced routines, together with their directly referenced routines, and so on, are gathered and bound together as a single entity. In addition, a relative allocation is made for each data set referenced by any routine of this collection. Data sets may at this time be declared to be global and may be characterized as received, assigned or input. A data set is said to be received if its values are to be initialized at routine call time. It is assigned if initialization is not required at either prepare time or call time (e.g., the prepared routine to which it belongs generates an instance). A data set is said to be input if values are to be initialized at prepare time by an instance on an area file. The prepare function generates: (1) an estate table which describes the named entities (programs and data sets) which comprise the routine being prepared; and (2) a collection of corpus tables which comprises the coding of the prepared routine together with necessary binding information. The estate and corpus tables are used in the subsequent allocation, loading, and binding of the prepared routine. At the time a routine is called for execution, specified arguments of call are gathered into a table. This table, together with the data instances required for initializing global data sets, are incorporated into the routine at load time. Those system books necessary for controlling the routine's execution and subsequent return to the caller are established; and custody and responsibility chains for data elements are set up. in [ACM] CACM 9(03) March 1966 includes proceedings of the ACM Programming Languages and Pragmatics Conference, San Dimas, California, August 1965 view details |