GOGOL II(ID:3906/gog002)

Time-sharing ALGOL-60 for PDP-1 


Improved version of GOGOL running under THOR on the PDP-1, rewritten by Joh Sauter


Related languages
GOGOL => GOGOL II   Evolution of
GOGOL II => GOGOL III   Evolution of

References:
  • John Slimick "Current systems implementation languages: One user's view" view details Extract: Snippet on PASS
    The first language for the PDP-1 that I wish to discuss is a block structured assembler known as PASS , which was written by David Poole. PASS is a one and one-quarter pass assembler that generates absolute machine code where possible and fixups where impossible. In addition to the block structure, PASS has generalized operator handling, free format, conditional assembly parameters, and other features.

    Block structure is advantageous in at least two ways. The first advantage is that of variable declarations of known scope. The PS/360 assembler has only one level of visibility, which makes all variables global; FORTRAN has two levels of visibility which are those variables in COMMON and those which are not. A block structured assembler allows as many levels of visibility as the programmer wishes. If he wishes to make everything global, he can, and, if he wishes to localize references to minimize referencng errors, he can use the block structure for that. The second advantage is that of providing a convenient means of separating pieces of code; some of these pieces might be subroutines and others might be alternative paths of processing within a large piece of coding. Again, the use is up to the programmer as to whether he uses exactly one block per subroutine or whether he adds "fine structure" by blocking the different components of each larger component of the program. In practice most PASS programs had a maximum block depth of three or four.

    […]

    The most eminent use of PASS was the ZEUS time sharing system for the PDP-1. The source for ZEUS was some 24,000 lines of PASS symbolic coding. PASS required exactly three mlnutes and twenty seconds to assemble ZEUS**; the turn-around time from system death through editing for correction of bad code or insertion of monitoring code to detect pathological conditions through assembly to loading was about ten minutes. The time to assemble a similarly sized system for the IBM 360/44 is about one hour with the editor consuming another five minutes. Some observations are due at this point; first, one could not list 24,000 lines in the 200 seconds required for PASS assembly -- what was done about listings? No listing was created with an assembly, with intermittent listings being made from the source which was kept on disk at all times; updating the source was done through a cathode-ray-tube editor. This cues the second question: if listings of the system source were made only intermittently, how did people know the current storage locations of systems variables
    and how did they communicate? Simply, there were not that many programmers involved, never more than three to be precise. With intimate knowledge of the system the three rarely lost track of system labels, variables, etc. This seems to be a common feature of systems implementation languages, i.e., the language has sufficient power to reduce the number of systems programmers to a number capable of communicating with each other and  maintaining control over systems that, with larger work forces, would run away in size and complexity. A third question would be: what about cross reference listings? A separate program, "string search", for determining references was run when needed. It seems that the assembly listing - relocation indicator listing - cross reference listing cycle is valuable only in batch debugging mode where one has to decipher system deaths from large (~200K bytes) core dumps. For a small group of interacting programmers in a time
    sharing environment the cycle mentioned above is an unnecessary luxury. In assembling from disk to disk a fast assembler makes one large program look more economical than several small CSECT's. Extract: Description of GOGOL
    The best description of GOGOL is to say that it consists of the integer parts of ALGOL-60, In-line coding capability, simple string handling, and good facilities for system communication. Arrays are limited to a single dimension and there is no dynamic storage capabilities,
          in [ACM] SIGPLAN Notices 6(10) October 1971 Proceedings of the SIGPLAN symposium on Languages for system implementation 1971, Lafayette, Indiana, United States; October, 1971 view details