Configurable applications for graphics employing satellites (CAGES)

This paper reports on CAGES, a programming system which substantially simplifies the process of writing interactive graphics application programs for use in a distributed processing, satellite-host configuration. It allows programs written in a PL/I subset to be configurable: program modules . (main program, subroutines) and data can be easily reassigned from the host to the satellite, or vice versa. That is, the division of labor between the two computers is readily modified.The CAGES system supplements the operating system services normally provided on the host or satellite computers by providing the illusion that the application is executing in a single computer memory with dual CPUs. In reality the application is distributed between the memories of the host and satellite computers. To maintain this illusion CAGES provides three types of services:Inter-computer subroutine CALLs and RETURNs. A subroutine call executed on one computer and targeted to a subroutine resident on the other computer is known as a remote procedure call. It is supported just as one would expect. A message containing the subroutine's name and parameters is sent to the computer where the subroutine is to be executed. Following its execution, a message containing results (modified parameters) is sent back, and the calling routine continues its execution.(2) Inter-computer CONDITIONs. A SIGNAL statement or interrupts on one computer raising a CONDITION for which there is an enabled ON-BLOCK in the other computer is much like a parameterless remote procedure call. It is supported in essentially the same manner as a remote calls.(3) GLOBAL data references. Variables with EXTERNAL scope which may be referenced from subroutines in both computers are known as GLOBAL variables. If, when referenced, a GLOBAL variable is not located in the memory of the referencing computer, the reference is said to be a remote reference.The CAGES system handles such references by obtaining the needed data from the remote computer and placing a local copy of it in the memory of the referencing computer. The program is then allowed to access this copy.Figure 1 illustrates the over-all structure of CAGES. Application programs are written as if they were going to be resident on only one computer. The programmer then adds extended declarations specifying GLOBAL variables and the desired configuration of the application program. These declarations and the source code are input to the CAGES preprocessor. The preprocessor slightly changes the declarations of the GLOBAL variables in the source code, generates some additional procedures, and outputs three files. One file contains procedures destined for the host (IBM 360/75), one contains procedures destined for the satellite (PDP-11/45), and one contains symbol table entries for GLOBAL variables. The (modified) source procedures are then compiled by either the PL/I-F compiler (host procedures) or the PLCD[1,2] compiler (satellite procedures). Finally, the link-editors of each computer combine CAGES run-time routines with the object modules produced by the previous compile steps to produce two executable load modules,one for each computer. Although the implementation at U.N.C. is based on PL/I, other languages which can be compiled for both host and satellite could be used with this approach.It should be clear that CAGES is not a graphics package in the usual sense. Indeed, any graphics subroutines or other graphics support used by the application program appears to the CAGES system as part of the application, as figure 2 shows. Thus CAGES does not require or provide for any particular type of graphic data structure. In fact, the CAGES system is equally useful to non-graphics programs which must for some reason be distributed in the memories of a two computer network.