1. INTRODUCTION TO GIN

GIN is a language for compiling assembly-level programs for the ICL 1900 Series. It shares its instruction set to a large extent with PLAN, but the various directives which control its operation have only enough in common with those of PLAN to make disaster almost certain if they are confused.

The reader is invited to believe, if he can, that the name GIN stands for “GEORGE INput language”. GIN was originally written to provide a language tailored to the condition that GEORGE 3 and 4 should be compiled as efficiently and conveniently as possible, and its main use is still to compile GEORGE. It makes many assumptions conducive to efficient compilation of GEORGE and inefficient compilation of lesser programs, but these assumptions can be overridden if required.

In particular, GIN was written to provide the following facilities:

1. The ability to include or exclude program segments of which several versions might exist on a source tape.
2. The ability to define identifiers either local to the segment or universal (global) to the whole compilation.
3. Controlled inclusion or exclusion of a sequence of source lines, irrespective of segment boundaries, according to some identifier value.
4. Optional identifier settings acting as a default case unless overridden by previous settings.
5. Variable listing levels.
6. An enhanced macro facility.
7. A degree of two-way communication between program and compiler.
8. Powerful program correction facilities.
9. The ability to compile and execute subsidiary (interlude) programs in order to enhance compiler facilities if needed.

Thus, by excluding certain features of the PLAN system, it has been possible to include other facilities which allow fast compilation of a very large program from source only a part of which is known to be reliable. In addition, when GEORGE requires new facilities from its compiler they can be considered, decided upon, designed and implemented within the Department which writes GEORGE, with very little consultation with or consideration of the effects on other users. In practice facilities are rarely withdrawn, and the way in which GIN is issued means that if this happens users have the opportunity of retaining older versions if they wish.

GIN is not in any sense an “official” facility : it is from time to time allowed to come into the hands of parts of ICL other than the department concerned with GEORGE, and even those of outside users, but only on the strict understanding that no help will necessarily be given except incidentally in order to make GIN more reliable for GEORGE use, or otherwise in a way directly beneficial to the GEORGE project. Other help is occasionally given, but in any conflict of priorities GEORGE comes first. In any event, this help is not the kind of support given to company-issued software, but simply friendly interest, advice and co-operation given as time and resources permit.

A special version of GIN exists for the compilation of GEORGE Executives.

GIN reads source program from one or more slow input peripherals and possibly from one or more magnetic tapes, according to directives provided by the user which form part of the source program itself. At any moment, either one slow peripheral will be in use, or GIN will be reading one magnetic tape and a slow peripheral will be ready to restart when processing of the tape is complete. Any other input peripherals will be quiescent.

During compilation GIN has a file containing the object code so far compiled, and one containing various dictionaries and similar information. Each of these files may be held independently of the other in core, on a drum file or on a direct access file.

The compiled program can be output on magnetic tape in a form that can be loaded and run. It can also be entered directly after compilation. The file containing the compiled program is available after the run has ended if it was held on backing store, although the program cannot be loaded from this file by standard software.

GIN will print a listing of the compiled program, the amount of detail given depending on the user's instructions.

It is possible to dump a compilation on magnetic tape at any convenient point by means of appropriate directives in the source stream, so that it can be re-started from that point at another time. After the dump the compilation will carry on. This facility provides security against unexpected failures, allows compilations to be interrupted and re-started, and makes it possible to correct a program conveniently without having to start again from the beginning.

Since GIN and PLAN are both assembly languages for the 1900 Series, it is hardly surprising that they are superficially similar. As a general rule it can be said that instruction formats are normally the same, but directives have different formats and meanings. However, there are a number of points where special care needs to be taken, or where a programmer who does only what PLAN would permit is missing his opportunities.

The first main difference between the two languages lies in the method of arranging compilations. For PLAN there are several different compilers having different input, output and backing-store requirements, and a distinction is drawn between steering parameters (dependent on the compiler in Use) and directives (common to all or most PLAN versions). In GIN the versions of the compiler do not differ in this way, and all the steering is done by directives. GIN exists to compile GEORGE, and unless otherwise instructed it will expect to need enough core and backing store to do so. For any other program this will lead to slow and inefficient working, and so the first few directives presented to GIN will provide information about the environment it is working in and the program to be compiled.

GIN does not produce semi-compiled output, and it does not make any use of a consolidator; consequently, there is no way of interfacing with Housekeeping, other standard software or any other program or subroutine written in any other language, except by going beyond the built-in facilities of GIN. (It is theoretically possible for the user to do this, although it would be extremely complicated to attempt it). The user is required to specify the actual core address where his program will start and the actual addresses of his data words (although in practice he need only fix one point and position everything else relative to it). He must also supply his own request slips, specifying such things as program names, program members and their priorities, and core and peripheral requirements.

So far, it will appear that a GIN compilation requires rather more work than PLAN from the user before he can get anything compiled. However, when this point is reached the extra facilities of GIN will become useful.

The macro facility in GIN is very much more extensive than that in PLAN (although less so in some ways than the PLAN Macro-generator). The number of macros is limited only by the total amount of workfile space available, and it is possible to use labels and directives in macros. The basic principle is that parameters are substituted as character strings in the appropriate places in macro definitions when the macro is called, and no syntactic analysis is carried out before this stage.

The #SKIP and #INCLUDE groups of directives make it possible to maintain a single source stream (usually held on magnetic tape) which can be used to compile several programs differing from one another in ways defined by the user, merely by inserting appropriate directives in the form of identifier definitions before the main source stream is read. For example, the operating systems GEORGE 3 and GEORGE 4 share the same GIN source, and only one source line is needed to determine which is compiled. The combination of SKIP and its relations with the macro facility allows the user to make consistent alterations uniformly at all the appropriate places in a program with very little effort.

The formats for source code are in general similar in GIN and PLAN, but GIN does not insist on the elements of the source line being in specific positions in it to the same extent as PLAN does. Generally, wherever PLAN formats require a specific number of spaces to be present GIN will accept one space or any greater number, provided that the maximum source line length is not exceeded. There are a few facilities in compiling instructions (the *+n facility in branches; the 2HXX form in DISP, SUSWT and DEL; forms such as CR0 in peripheral-handling instructions; literals) which GIN does not provide, but none of them is essential.

GIN does not distinguish between labels and other identifiers (the PLAN term is “symbols”), so that an arithmetic instruction can have a label as its operand. GIN also allows the use of identifiers not yet defined (forward references) in many places where PLAN would disallow it. Labels may stand on a line without an instruction following, and any identifier may be up to eleven characters long.

In PLAN, all symbols are considered to be local to a particular segment unless declared by CUE, and if storage is to be shared by segments it must be declared as COMMON and symbols for it declared in each segment. In GIN there are two classes of identifiers, locals which may be referred to only within the segment in which they are defined, and universals which are available throughout the compilation. Local identifiers start with the initials M to Z, and universals available for unrestricted use start with A to C or E to K. D and L identifiers are universals and may be referred to by the user, but may not be defined explicitly : GIN assigns them values implicitly as the backing store address and the length of a segment respectively, so that an overlaying system can use them.

GIN also has the #DUMP facility, which allows a compilation to be saved in an incomplete state, and subsequently restarted with full access to code already compiled, macro definitions, identifier values and so on. The MEND facility allows segments already compiled to be altered, and it is normal practice for GIN compilations to be dumped and for #END corrections to be inserted later to correct faults in the program discovered during testing. Since it is possible to dump again after this, programs can undergo very extensive changes between the original compilation and the finalisation of the program without it being necessary to alter or re-compile from the source text.

The GIN facility most likely to be strange to the newcomer is the ability to transfer information between the object program and the compiler. It is possible to obtain information from the compiler, to incorporate it in programs, and (with caution) to change the compiler's information and so affect its operation. What is more, code can be compiled which the compiler will transfer control to, and this can be used as required to extract further information or to insert it in the compiler's data structures.

GIN requires the use of a 1900 Series processor on which the SMO, BCT and MVCH instructions are available. It is just possible to run GIN in 13K of core, but only a fairly unsophisticated program could be so compiled, and any program but the very smallest would compile extremely slowly. For a “full-sized” program the minimum is more like 18K, so that for all practical purposes the machine used must have 32K of core. It is possible to use core up to the total of the sizes of the program file, the workfile and GIN itself.

Any run will require at least one slow peripheral, a line printer, and a magnetic tape for output, and unless enough core is available to contain the program file and workfile a direct access device  or  dru must be online. Usually, at least one magnetic tape will be uses Ior input.

The compiler operates in direct branch mode. On loading, it attempts to obtain 22-bit address mode, but if this is unsuccessful it is restricted to operating in 32K and is otherwise unaffected. For this reason, all interludes must be capable of running in either address mode.

GIN may be run under Operators  Executive, GEORGE 3 or GEORGE 4.

GIN compiles in one pass through the source text. As a general rule, it goes as far as it can to complete the processing of each source record before looking at the next one, and wherever this is not possible it keeps a note of the work that remains to be done. The main example of this is the filling in of forward references; certain references will be filled in as soon as the identifier referred to is defined, but for efficiency reasons some are kept until a stage is reached where the filling-in can no longer be delayed. This can happen several times in the course of a completion, but in such a way that work'is not duplicated.

The source text is divided up into a number of parts, the transition between parts being signalled by the occurrence of certain directives.

The first part of a compilation will consist of directives which adjust data areas within the compiler to make it use appropriate backing-store devices and compile the program which follows as efficiently as possible. The last of these directives will be #CORE.

From this point on it is possible to define identifiers and macros and to instruct the compiler to accept named segments. It is generally found convenient to do as much as possible of this before any segments are compiled. (Segments, overlays and chapters, and the relationships between them, are described more fully in Section 3.1).

The next part of the text contains at least one overlay containing one or more segments, followed possibly by chapters (segments not enclosed in overlays) and more multi-segment overlays in any convenient order if the program is overlaid.

When the end of the program is reached, and possibly at earlier stages, directives will be read from a slow peripheral to preserve the results of the compilation on magnetic tape. After this, the user may delete GIN; enter the program just compiled by #GO; or load some other program (possibly GIN itself) from a subfile on magnetic tape by #RESTORE. It is not possible to start another compilation with the same copy of GIN; a clean copy must be loaded.

The program, if it is a small one, can be input entirely from cards or paper tape. With most programs, however, the first few source lines after #CORE will be on a slow peripheral and will define identifiers and #INCLUDE segments in order to determine the program to be compiled. These statements will be followed by directives to open, position and read a magnetic tape which contains the bulk of the source. This will be subdivided into subfiles, each containing a segment or the definitions of macros and identifiers concerned with one aspect of the program. Wherever the definition of an identifier on the tape may be overridden by the user the #OPTIONAL directive will be used; in this case, the directive will take effect unless the user has contradicted it with a #DEFINE earlier in the source stream.