External Program Linkage

A design objective of this scheme is that the code of programs should be protected from accidental or deliberate overwriting and that code should be shared between users whenever possible, with consequent savings of main memory and disc space.

Program File Format and Virtual Memory Layout



The standard program file format is shown above. Program files are shareable and while being executed are normally connected in virtual memory in read or read-shared mode. The first four words constitute a 'file header'. This provides the length of the file and the start of the Code area, the GLAP (General Linkage Area Pattern) and Linkage data area, each relative to the start of the file.

The code area must be invariant so that the code can be run in read or read-shared mode..

The GLAP contains the information needed for linking this program file to any file it may require, including other program files. When a program is loaded the actual program file is left unaltered and the nececsary changes to establish external linkage are made to a copy of the GLAP, referred to as the GLA (General Linkage Area). This approach was suggested by Arden, Galler, O'Brien and Westervelt (1966). Any initialised data to be used by the program may be set up in the GLAP.

A particular program file may contain several separately compiled routines, each of which will have a block of code and a block of GLAP within the appropriate areas of the file. Information required by the Program Loader is provided in linked lists, the heads of which are stored at the front of the linkage data area.

Linkage Data Lists

When the loading process is complete the code and GLA areas of a program are in different segments of the virtual memory. The code is in one or more segments which are connected in read mode, while the GLA is in a write-unshared file. The same physical copy of the code may be in use by several other users who have the program loaded at the same time, though not necessarily at the same virtual memory address. It can be seen that the shareable part of a program file must not contain any 'absolute' virtual memory addresses. With the exception of the external references satisfied by the loader all virtual memory addresses have to be established by the program at run-time.

External Program Calling Conventions



Before entry to an external routine, the three addresses, code block, GLA block and entry point, inserted into the external reference item for the called routine by the loader, are loaded into three (consecutive) registers. One of the general purpose registers contains the address of the start of the free space on a common stack which all programs are constrained to use for the entry sequence to external routines. The calling routine may copy its registers on to the stack in the 16 words immediately ahead of the stack free space pointer. These are restored on return by the called routine. Any parameters to the call are set up beyond the register save area according to standard conventions. Control is then transferred to the entry point address with the return address in another register. In practice this sequence usually requires only three hardware instructions.

Dynamic Loading

In the case of a routine which is to be loaded dynamically this entry sequence, together with the loader action defined above, results in entry to the dynamic load sequence. This sequence finds the program file containing the routine (if it exists), loads it, and overwrites the relevant three words in the GLA of the calling routine with the addresses of the code block, the GLA block and the entry point of the called routine. Control is transferred to the entry point. The overwriting of the three words enables the program to use the same code sequence to jump directly to the external routine on any subsequent call.

The actual instruction sequences used in a real implementation of this method are given on the diagram (above) and in Appendix 1 (below).

Reference

G.E. Millard, D.J.Rees and H.Whitfield (1975). The Standard EMAS Subsystem, The Computer Journal, Vol. 18, No. 3, pp 213-219.

Appendix 1

The use of registers in the EMAS standard subsystem external routine entry sequence was as follows:
RO-R3   Scratch registers - not saved
R4-R14  Environment registers - saved and restored
R15     Return address
The following had special uses:
R11     Stack free space pointer
R12     Code base register
R13     GLA base register
R14     Entry Point Address register
The following were typical call and return sequences:
CALLING ROUTINE
                    Store parameters (if any) beyond the save area

STM 4,14,16(11)     Store R4-R14 in the save area on the stack

LM 12,14,EPREF(13)  Load code, GLA and Entry Point addresses of the called
                    routine from an entry point reference in the GLA of the
                    calling program.
                    
BALR 15,14          Enter the called routine leaving the return address in R15.

CALLED ROUTINE

ST 15,60(11)        It was usual to save the return address on the stack

LR base,11          Load the local base register

LM 4,15,16(base)    Restore R4-R14 and pick up the return address

BR 15               Return to calling routine
This ensured that R13 had been reset to its entry value if the called routine had changed it (which it generally had).

The called routine could set its own code base by using a BALR 12,0 instruction and subtracting some fixed offset. However, the reset sequence was more general and more efficient. The restoring of the registers from the save area could take place on return to the calling routine with a LM 4,14,16(11) instruction but the present scheme was more efficient because the called routine usually stored the return address in memory to make R15 available for other uses, and the present scheme reloaded R15 at negligible cost. Because we had chosen not to save R0-R3 and R15, the corresponding positions in the save area could be used for other purposes (e.g. a dynamic or static environment chain in an ALGOL type language). However, it is obvious that this was by no means necessary and a more general scbeme could have used the whole save area.


harry.whitfield@ncl.ac.uk               20 March 1998 ...