Control Data 3100/3200/3300/3500, 3400/3600/3800, 6400/6500/6600 Family ALGOL User Manual

 Additional copies of this manual may be obtained
from the nearest Control Data Corporation sales office.
CONTROL DATA CORPORATION
Documentation Department
December, 1967 3145 PORTER DRIVE ©1967, Control Data Corporation
Pub. No. 60214900 PALO ALTO, CALIFORNIA 94304 Printed in the United States of America
CONTENTS
CHAPTER 1
CHAPTER 2
INTRODUCTION
SAMPLE LAYOUT
ALGOL SYSTEM DESCRIPTION
HHHHHH
SU о юн
Compiler Features
Compiler Package
Compiler Structure
Library Subprograms
Operating System Interface
Machine Configuration
LANGUAGE COMPARISON WITH THE ALGOL-60 REVISED REPORT
2.1 Language Conventions
Revised Report on the Algorithmic Language ALGOL-60
Introduction
1.
2.
Structure of the Language
1.1 Formalism for syntatic description
Basic Symbols, Identifiers, Numbers, and
Strings Basic Concepts
2.1 Letters |
Digits. Logical values
Delimiters
Identifiers
Numbers
Strings
. Quantities, kinds and scopes
. Values and types
Ex
»
a
*
“
DN NBN NNN
Variables
Function designators
Arithmetic expressions
Boolean expressions
Designational expressions
Statements
4.1 Compound statements and blocks
2 Assignment statements
3 Go to statements
‚4 Dummy statements
5
6
7
2
3
4
5
6
7
8
pressions
1
2
3
4
5
Ww www
Conditional statements
For statements
Procedure statements
Cy SC OMAN SS E
-J
10
13
13
14
14
14
15
16
16
18
19
19
19
20
21
23
28
30
31
31
33
34
35
35
37
39
iii
CHAPTER 3
CHAPTER 4
iv
5. Declarations
5.1 Type declarations
5.2 Array declarations
5.3 Switch declarations
5.4 Procedure declarations
Examples of Procedure Declarations
Alphabetic Index of Definitions of Concepts and
Syntactic Units
INPUT-OUTPUT
3.1
62 0 62 03 CO D со
- »
0 410 с) сл SON
Comparison with ACM Proposal for Input-Output
A Proposal for Input-Output Conventions in ALGOL-60
A, Formats
A.1 Numbered Formats
A.2 Other Formats
A.3 Format Strings
A.4 Summary of Format Codes
A.5 "Standard" Format
B. Input and Output Procedures
1 General Characteristics.
2 Horizontal and Vertical Control
3 Layout Procedures
.4 List Procedures
5 Input and Output Calls
6 Control Procedures
.7 Other Procedures
C. Example
Additional Input-Output Procedures
Control Procedures
Hardware Function Procedures
Miscellaneous Procedures
Input-Output Errors
End-of-File
End-of-Tape
subo"
INPUT TO COMPILATION
4.1
не ен
с сл > GO N
Source Program Definition
Source Procedure Definition
Source Input Restrictions
Language Conventions
Card Conventions
Source Deck
41
42
44
45
46
52
55
58
58
59
59
59
63
68
69
69
70
70
73
75
78
79
91
92
93
96
96
97
98
99
99
99
100
100
101
102
102
103
103
CHAPTER 5
CHAPTER 6
CHAPTER 7
CHAPTER 8
CHAPTER 9
CHAPTER 10
CHAPTER 11
OUTPUTS FROM COMPILATION
5.1 Binary Output
5.2 Assembly-Language Object Code
5.3 Source Listing
ALGOL CONTROL CARD
6.1 6000 ALGOL
6.2 3000 ALGOL Excluding MASTER
6.3 Lower 3000 MASTER
CHANNEL CARDS
7.1 Channel Define Card
7.2 Channel Equate Card
7.3 Channel End Card
7.4 Duplication of Channel Numbers
7.5 Duplication of File Names
7.6 Standard ALGOL Channel Cards
7.7 Typical Channel Cards
ALGOL DIAGNOSTICS
8.1 Compiler Diagnostics
8.2 Compile-Time and Object-Time I/O Diagnostics
8.3 Object-Time Diagnostics
COMPILER DESCRIPTION
Information Flow
Language Translation
Language Analysis
Identifier (Symbol) Table
Compiler Subprogram Descriptions
Overall Compiler Flow
© OW © © © Ww
Sy сл x WN
OBJECT PROGRAM
10.1 Run-Time Supervisory Program
10.2 Object-Code Structure
10.3 Object-Code Generation
10.4 Library Subprograms
10.5 Address-Field Conventions
OBJECT-TIME STACK
11.1 Stack Structure
11.2 Stack Entries
11.3 Details of Descriptions
107
107
109
110
111
111
113
114
119
119
121
121
121
122
122
123
124
124
133
137
143
143
143
143
144
144
147
149
149
149
149
150
150
152
152
155
158
CHAPTER 12
APPENDIX A
APPENDIX B
APPENDIX C
APPENDIX D
OBJECT-TIME ABNORMAL TERMINATION DUMP
12.1 Structured Dump
12.2 Global and Environmental Information
THE ALGOL 48-CHARACTER SET
SAMPLE PROGRAM
COMPARISON: ALGOL 3000L/3000U/6000
CHARACTER REPRESENTATION OF ALGOL SYMBOLS
167
167
167
170
171
172
173
INTRODUCTION
This reference manual presents the rules and details involved in writing a program in the ALGOL
language; it includes sufficient information to prepare, compile, and execute such a program.
The ALGOL programming language and a compiler for translating ALGOL programs into machine
language for execution on the CONTROL DATA® 3100/3200/3300/3500, 3400/3600/3800, and
6400/6500/6600 computers are described. CONTROL DATA ALGOL closely conforms to the
definition of the international algorithmic language ALGOL published in The Communications of the
ACM, 1963, vol. 6 no. 1, pp. 1-17; "The Revised Report on the Algorithmic Language, ALGOL-60",
and the input-output procedures provided as additions to the language in "A Proposal for Input-Output
Conventions in ALGOL-60" published in The Communications of the ACM, vol. 7 no. 5, May 1964.
CONTROL DATA's input-output procedures incorporate many of the features recommended by the
International Organization for Standardization in its Draft Proposal on the Algorithmic Language
ALGOL, Appendix C "Proposal for Input-Output Procedures for ALGOL-60 (ACM)".
The ALGOL-60 Revised Report is presented in its entirety, and wherever Control Data's imple~
mentation of the language differs from the Report a full explanation of the differences are listed for
all systems.
The ALGOL-60 Revised Report is printed in bold type, and the explanation of the differences are in
standard type. In those instances where 3100/3200/3300/3500. and 3400/3600/3800 ALGOL differ
from 6400/6500/6600 ALGOL, the notes concerning the 3000 series appear in italics. A sample
layout is shown on page 3.
Throughout this manual, the 3100/3200/3300/3500 computers are referred to as lower 3000, the
3400/3600/3800 as upper 3000, and 6400/6500/6600 as 6000. The name ALGOL means lower and
upper 3000 or 6000 ALGOL, unless otherwise specified.
The reader is assumed to be familiar with the general characteristics of the 3000 and 6000 series
computers and the corresponding operating systems.
The reader is referred to the following publications:
64/6600 ALGOL-60 General Information Manual, Pub. No. 60173200
64/65/6600 SCOPE Reference Manual, Pub. No. 60189400A
34/36/3800 ALGOL-60 General Information Manual, Pub. No. 60173300
36/3800 Tape SCOPE Reference Manual, Pub. No. 60057800A
31/32/33/3500 ALGOL-60 General Information Manual, Pub. No. 60173100
31/32/33/3500 Mass Storage Operating System Reference Manual, Pub. No. 60173000A
31/32/33/3500 MASTER Reference Manual, Pub. No. 60176800A
31/32/33/3500 Tape SCOPE Reference Manual, Pub. No. 60171200A
The reader is also referred to the following representative bibliography:
Baumann, R., Feliciano, M., Bauer, F.L., Samelson, K. Introduction to ALGOL,
Prentice-Hall, Inc., 1964.
Dijkstra, E.W., A Primer of ALGOL-60 Programming, Academic Press, 1962.
Ekman, T., and Froberg, C.E.: Introduction to ALGOL Programming,
Oxford University Press, 1965.
McCracken, Daniel D., A guide to ALGOL Programming, John Wiley & Sons, Inc., 1962.
SAMPLE LAYOUT
This is an example of the boldface type used for “The Revised Report on the Algorithmic Language, ALGO L-60” and
for “A Proposal for Input-Output Conventions in ALGOL-60". Independent basic symbols, such as begin, end, integer
and real, are indicated by underlining.
This is an example of the standard type used to describe CONTROL DATA systems. Where CONTROL
DATA's systems differ from the ACM Report, a description of CONTROL DATA's implementation of
the language follows at the main reference in the ACM Report. Independent basic symbols such as begin,
end, integer and real are indicated by underlining.
This is an example of the italics used to indicate where the 3000 and 6000 series differ. The text in italics describes the
3000 series. Major differences are printed with the 3000 series following the 6000. Instances where lower 3000 differs
from upper 3000 are stated in the text, for example:
Variables of type Boolean are represented in 60-bit fixed-point form; only the high-order bit is
significant:
true : := high-order bit =1
false : : = high-order bit = 0
Variables of type Boolean are represented in 48-bit fixed-point form (in lower 3000, only upper 24-bits are significant)
with zero and non-zero values corresponding to false and true, respectively. In Booleans generated by the system, the
zero and non-zero values are:
Upper 3000 Lower 3000
true ::= 0000000000000001 9 true ::= 00000001 XXXXXXXX
false i= 0000000000000000g false ::= 00000000 XXXXXXXX
Minor differences are noted in parenthesis in the main body of the text.
ALGOL SYSTEM DESCRIPTION 1
1.1 COMPILER FEATURES
The ALGOL compiler for the 3000 and 6000 computers is based in design on the ALGOL compiler
developed by Regnecentralen, Copenhagen, Denmark, for the GIER computer. This design was
adopted and, to some degree, extended by CONTROL DATA to provide the most generally advantageous
features for an ALGOL compiler.
These features include:
Implementation of the complete ALGOL-60 revised language (wherever feasible and not in
conflict with other advantages)
Comprehensive input-output procedures
Extensive compile-time and object-time diagnostics
Fast compilation
Wide variety of compilation options, such as the ability to compile both ALGOL programs and
ALGOL procedures
Ability to generate and execute the object program in either segmented or non-segmented form
MEMORY USAGE
The compiler attempts to compile every source text entirely within available memory with no refer-
ence to input-output devices. All intermediate information between the passes of the compiler is
first stored in the compiler work areas. If the work areas are too small to contain all the intermediate
information, the information is written onto scratch units and read back in by the next pass.
SOURCE INPUT
Source input is normally the card deck following the control card which calls for the ALGOL com-
piler. The source may also be specified from a different device by a control card option. Source
input can consist of both ALGOL source programs and ALGOL source procedures. More than one
source program and/or source procedure. may be compiled with a single call.
COMPILE-TIME ERROR DETECTION
The compiler detects all source language infringements, and prints a diagnostic for each. The
compiler also incorporates further checking into the object program to detect program errors which
can be found only at execution time. All compilations proceed to the end of the source deck with
normal error checking regardless of the occurrence of a source language error; but object code
generation is suppressed if any errors are detected during compilation.
COMPILER OUTPUTS
Compiler output is normally printed on the standard system output file. Output also may be requested
on a different device with a control card option. The programmer may request the object code in
segmented or non-segmented form.
OBJECT PROGRAM EXECUTION
In segmented form, a program can be loaded as part of the same compilation or later by the last
pass of the compiler. In non-segmented form, a program is in standard relocatable binary format
which can be loaded either in the same compilation or later by the system loader.
Execution of the object program, segmented or non-segmented, is controlled by a supervisory
program external to the generated program.
OBJECT ERROR DETECTION
The object program includes code which detects errors not detected during compilation. An error
message is issued, a data map is printed, and the run is terminated. The data map displays current
values of declared variables in a form easily related to the source program.
1.2 COMPILER PACKAGE
The ALGOL compiler package consists of the following subprograms recorded on the system library:
The compiler: ALGOL, ALGO, ALG1, ALG2, ALG3, ALG4, and ALGS
The library subprograms which are available to object programs generated by the compiler.
1.3 COMPILER STRUCTURE
ALGOL is the internal controller of the compiler and its main function is to load and pass control to
each subprogram as required.
ALGO processes the control card options delivered by the operating system.
ALG1 through ALG5 each form one pass of the compiler. Each subprogram overlays the previous
one in a separate core-load. Each pass generates an intermediate form of the source text which
is used as input to the next pass.
ALG1, ALG2, and ALG3 perform syntactic and semantic analysis of the source text.
ALG4 produces final output from the compiler, such as the object code in segmented or
non-segmented form.
ALG5, although nominally part of the compiler, takes no part in the actual translation process;
its only function is to control execution of the object program in segmented form.
1.4 LIBRARY SUBPROGRAMS
The library subprograms contain all standard procedures which can be called without prior declara--
tion in an ALGOL source text. They also contain subprograms to perform object-time control
functions external to the generated object program.
1.5 OPERATING SYSTEM INTERFACE
The compiler is designed to run under control of SCOPE, MASTER, or MSOS operating systems.
Compilation is requested by a standard operating system control card specifying the name ALGOL.
This call results in the loading and execution of the subprogram ALGOL which controls the compila-
tion process. The compiler obtains the control card parameters from the operating system.
1.6 MACHINE CONFIGURATION
The basic machine configuration required for compilation consists of the minimum configuration
required by the operating system. In addition, when the source program generates more intermediate
information than can be held in available memory, the compiler uses two scratch files to store this
information.
The minimum number of words of available memory required by the compiler and its working
areas is approximately 10K for 6000, and 8K for 3000. With the minimum available memory, pro-
grams of a reasonable size can be compiled with no intermediate input-output. Additional available
memory will permit compilation of larger programs entirely within memory.
LANGUAGE COMPARISON WITH THE
ALGOL-60 REVISED REPORT 2
2.1 LANGUAGE CONVENTIONS
In this manual, ALGOL is described in terms of three languages: reference, hardware, and
publication language, as indicated in the introduction to the ALGOL-60 Revised Report.
The reference language is computer independent and uses the basic ALGOL symbols, such as begin
and end, to define the language syntax and semantics.
The hardware language is the representation of ALGOL symbols in characters acceptable to the
computer; this is the language used by the programmer. For example, when the reference language
calls for the basic ALGOL symbol begin, the programmer writes the seven hardware characters
'BEGIN'. The hardware representations of ALGOL symbols are shown in Table 1, Chapter 4.
Unless otherwise stated or implied, the basic ALGOL symbols (reference language) rather than their
character equivalents (hardware language) are used consistently throughout this manual. This con-
vention simplifies the explicit and implicit references to the ALGOL language as defined in the
ALGOL-60 Revised Report.
For publication purposes only, the underlining convention delineates the basic ALGOL symbols.
These symbols have no relation to the individual letters of which they are composed. Other than
this convention, the publication language is not considered in this manual.
All descriptions of language modifications are made at the main reference in the Report; when
feasible, language modifications are also noted at other points of reference. The reader should
assume that modifications apply to all references to the features, noted or otherwise. If no comments
appear at the main reference in the Report regarding language modifications to a particular section
or feature, it is implemented in full accordance with the Report.
In addition to the language descriptions in this chapter, reserved identifiers which reference input-
output procedure are described in Chapter 3.
The ALGOL-60 Revised Report as published in The Communications of the ACM, vol. 6, no. 1,
pp 1-17 follows. Wherever CONTROL DATA's implementation of the language differs from the
Report, the Report is printed first in boldface and the CONTROL DATA modification follows in
standard type. Where system differences exist between the 3000 and 6000 series, the differences
are noted in italics.
REVISED REPORT ON THE ALGORITHMIC LANGUAGE ALGOL—60T
Peter Naur (Editor)
J.W. Backus C. Katz H. Rutishauser J. H. Wegstein
F. L. Bauer J. McCarthy K. Samelson A. van Wijngaarden
J. Green A. J. Perlis B. Vauquois M. Woodger
Dedicated to the memory of William Turanski.
SUMMARY
The report gives a complete defining descrintion of the international algorithmic language ALGOL-60. This is a language
suitable for expressing a large class of numerical processes in a form sufficiently concise for direct automatic translation
into the language of programmed automatic computers.
The introduction contains an account of the preparatory work leading up to the final conference, where the language was
defined. In addition, the notions, reference language, publication language and hardware representations are explained.
In the first chapter, a survey of the basic constituents and features of the language is given, and the formal notation, by
which the syntatic structure is defined, is explained.
The second chapter lists all the basic symbols, and the syntatic units known as identifiers, numbers and strings are de-
fined. Further, some important notions such as quantity and value are defined.
The third chapter explains the rules for forming expressions and the meaning of these expressions. Three different types
of expressions exist: arithmetic, Boolean (logical) and designational.
The fourth chapter describes the operational units of the language, known as statements. The basic statements are:
assignment statements (evaluation of a formula), go to statements (explicit break of the sequence of execution of state-
ments), dummy statements, and procedure statements (call for execution of a closed process, defined by a procedure
declaration). The formation of more complex structures, having statement character, is explained. These include: con-
ditional statements, for statements, compound statements, and blocks.
In the fifth chapter, the units known as declarations, serving for defining permanent properties of the units entering
into a process described in the language, are defined.
The report ends with two detailed examples of the use of the language and an alphabetic index of definitions.
TThis report is published in The Communications of the ACM, in Numerische Mathematik, and in the
Computer Journal.
CONTENTS
Introduction
1. Structure of the Language
1.1 Formalism for syntatic description
2. Basic Symbols, Identifiers, Numbers, and Strings
Basic Concepts
2.1 Letters
2.2 Digits. Logical values
2.3 Delimiters
2.4 Identifiers
2.5 Numbers
2.6 Strings
2.7 Quantities, kinds and scopes
2.8 Values and types
3. Expressions
3.1 Variables
3.2 Function designators
3.3 Arithmetic expressions
3.4 Boolean expressions
3.5 Designational expressions
4. Statements
4.1 Compound statements and blocks
4.2 Assignment statements
4.3 Go to statements
4.4 Dummy statements
4.5 Conditional statements
4.6 For statements
4.7 Procedure statements
5, Declarations
5.1 Type declarations
5.2 Array declarations
5.3 Switch declarations
5.4 Procedure declarations
Examples of Procedure Declarations
Alphabetic Index of Definitions of Concepts and Syntatic Units
INTRODUCTION
Background
After the publication of a preliminary report on the algorithmic language ALGO LT, as prepared at a conference in Zurich
in 1958, much interest in the ALGOL language developed.
As a result of an informal meeting held at Mainz in November 19568, about forty interested persons from several Euro-
pean countries held an ALGOL implementation conference in Copenhagen in February 1959. A “hardware group” was
formed for working cooperatively right down to the level of the paper tape code. This conference also led to the publi-
cation by Regnecentralen, Copenhagen, of an ALGOL Bulletin, edited by Peter Naur, which served as a forum for further
discussion. During the June 1959 ICIP Conference in Paris several meetings, both formal and informal ones, were held.
These meetings revealed some misunderstandings as to the intent of the group which was primarily responsible for the
formulation of the language, but at the same time made it clear that there exists a wide appreciation of the effort in-
volved. As a result of the discussions it was decided to hold an international meeting in January 1960 for improving the
ALGOL language and preparing a final report. At a European ALGOL Conference in Paris in November 1959 which was
attended by about fifty people, seven European representatives were selected to attend the January 1960 Conference,
and they represented the following organizations: Association Francaise de Calcul, British Computer Society, Gesellschaft
fur Angewandte Mathematik und Mechanik, and Nederlands Rekenmachine Gennotschap. The seven representatives
held a final preparatory meeting at Mainz in December 1959.
Meanwhile, in the United States, anyone who wished to suggest changes or corrections to ALGOL was requested to send
his comments to the Communications of the ACM, where they were published. These comments then became the basis
of consideration for changes in the ALGOL language. Both the SHARE and USE organizations established ALGOL work-
ing groups, and both organizations were represented on the ACM Committee on Programming Languages. The ACM
Committee met in Washington in November 1959 and considered all comments on ALGOL. that had been sent to the
ACM Communications. Also, seven representatives were selected to attend the January 1960 international conference.
These seven representatives held a final preparatory meeting in Boston in December 1959.
January 1960 Conference
The thirteen representatives, from Denmark, England, France, Germany, Holland, Switzerland, and the United States,
conferred in Paris from January 11 to 16, 1960. Prior to this meeting a completely new draft report was worked out
from the preliminary report and the recommendations of the preparatory meetings by Peter Naur and the conference
adopted this new form as the basis for its report. The Conference then proceeded to work for agreement on each item of
the report. The present report represents the union of the Committee's concepts and the intersection of its agreements.
April 1962 Conference (Edited by M. Woodger)
A meeting of some of the authors of ALGOL-60 was held on April 2-3 1962 in Rome, Italy, through the facilities and
courtesy of the International Computation Centre.
Preliminary report — International Algebraic Language. Comm АСМ1, 12 (1958), 8.
Report on the Algorithmic Language ALGOL by the ACM Committee on Programming Languages,
edited by A.J. Perlis and K. Samelson. Num, Math. 1 (1959), 41-60.
10
The following were present:
Authors Advisers Observer
F. L. Bauer M. Paul W. L. van der Poel (Chairman IFIP TC 2.1 Working
J. Green R. Franciotti Group ALGOL)
C. Katz P. Z. Ingerman
R. Kogon
(representing J. W. Backus)
P. Naur
K. Samelson G. Seegmuiler
J. H. Wegstein R. E. Utman
A. van Wijngaarden
M. Woodger P. Landin
The purpose of the meeting was to correct known errors in, attempt to eliminate apparent ambiguities in, and otherwise
clarify the ALGOL-60 Report. Extensions to the language were not considered at the meeting. Various proposals for
correction and clarification that were submitted by interested parties in response to the Questionnaire in ALGOL Bul-
letin No. 14 were used as a guide.
(This report constitutes a supplement to the ALGOL-60 Report which should resolve a number of difficulties therein).
Not all of the questions raised concerning the original report could be resolved. Rather than risk hastily drawn conclu-
sions on a number of subtle points, which might create new ambiguities, the committee decided to report only those
points which they unanimously felt could be stated in clear and unambiguous fashion.
Questions concerned with the following areas are left for further consideration by Working Group 2.1 of IFIP, in the
expectation that current work on advanced programming languages will lead to better resolution:
1. Side effects of functions
2. The call by name concept
3. own: static or dynamic
4. For statement: static or dynamic
5. Conflict between specification and declaration
The authors of the ALGOL Report present at the Rome Conference, being aware of the formation of a Working Group
on ALGOL by IFIP, accepted that any collective responsibility which they might have with respect to the development,
specification and refinement of the ALGOL language wil! from now on be transferred to that body.
This report has been reviewed by IFIP TC 2 on Programming Languages in August 1962 and has been approved by the
Council of the International Federation for Information Processing.
As with the preliminary ALGOL report, three different levels of language are recognized, namely a Reference Language,
a Publication Language and several Hardware Representations.
REFERENCE LANGUAGE
1. It is the working language of the committee.
2. It is the defining language.
11
The characters are determined by ease of mutual understanding and not by any computer limitations, coders
notation, or pure mathematical notation.
It is the basic reference and guide for compiler builders.
It is the guide for all hardware representations.
It is the guide for transliterating from publication language to any locally appropriate hardware representations.
The main publications of the ALGOL language itself will use the reference representation.
PUBLICATION LANGUAGE
The publication language admits variations of the reference language according to usage of printing and handwrit-
ing (e.g., subscripts, spaces, exponents, Greek letters).
It is used for stating and communicating processes.
The characters to be used may be different in different countries but univocal correspondence with reference rep-
resentation must be secured.
HARDWARE REPRESENTATIONS
Each one of these is a condensation of the reference language enforced by the limited number of characters on
standard input equipment.
Each one of these uses the character set of a particular computer and is the language accepted by a translator for
that computer.
Each one of these must be accompanied by a special set of rules for transliterating from Publication or Reference
language.
For transliteration between the reference language, and a language suitable for publications, among others, the following
rules are recommended.
12
Reference Language Publication Language
Subscript bracket [ ] Lowering of the line between the brackets and removal of the brackets
Exponentiation 1 Raising of the exponent
Parentheses ( ) Any form of parentheses, brackets, braces
Basis of ten 10 Raising of the ten and of the following integral number, inserting of the intended
multiplication sign.
DESCRIPTION OF THE REFERENCE LANGUAGE
1. Structure of the Language
As stated in the introduction, the algorithmic language has three different kinds of representations—reference, hardware,
and publication—and the development described in the sequel is in terms of the reference representation. This means
that all objects defined within the language are represented by a given set of symbols—and it is only in the choice of
symbols that the other two representations may differ. Structure and content must be the same for all representations.
The purpose of the algorithmic language is to describe computational processes. The basic concept used for the descrip-
tion of calculating rules is the well-known arithmetic expression containing as constituents numbers, variables, and
functions. From such expressions are compounded, by applying rules of arithmetic composition, self-contained units of
the language—explicit formulae—called assignment statements.
To show the flow of computational processes, certain nonarithmetic statements and statement clauses are added which
may describe, e.g., alternatives, or iterative repetitions of computing statements. Since it is necessary for the function of
these statements that one statement refer to another, statements may be provided with labels. A sequence of statements
may be enclosed between the statement brackets begin and end to form a compound statement.
Statements are supported by declarations which are not themselves computing instructions but inform the translator of
the existence and certain properties of objects appearing in statements, such as the class of numbers taken on as values
by a variable, the dimension of an array of numbers, or even the set of rules defining a function. A sequence of declara-
tions followed by a sequence of statements and enclosed between begin and end constitutes a block. Every declaration
appears in a block in this way and is valid only for that block.
A program is a block or compound statement which is not contained within another statement and which makes no use
of other statements not contained within it.
In the sequel the syntax and semantics of the language will be given.
1.1 Formalism for Syntactic Description
The syntax will be described with the aid of metalinguistic formulae. + Their interpretation is best explained by an
example
<ab>:=(1[ |<ab>( ICab><d>
Sequences of characters enclosed in the brackets < > represent metalinguistic variables whose values are sequences of
symbols. The mark ::= and | (the latter with the meaning of or) are metalinguistic connectives. Any mark in a formula,
which is not a variable or a connective, denotes itself (or the class of marks which are similar to it). Juxtaposition of
marks and/or variables in a formula signifies juxtaposition of the sequences denoted. Thus the formula above gives a
a recursive rule for the formation of values of the variable < ab >. It indicates that < ab > may have the value ( or [ or
TWhenever the precision of arithmetic is stated as being in general not specified, or the outcome of a certain process is
left undefined, or said to be undefined, this is to be interpreted in the sense that a program only fully defines a com-
putational process if the accompanying information specifies the precision assumed, the kind of arithmetic assumed,
and the course of action to be taken in all such cases as may occur during the execution of the computation.
£Cf. J. W. Backus, The syntax and semantics of the proposed international algebraic language of the Zurich ACM-
GAMM conference. Proc. Internat. Conf. Inf. Proc., UNESCO, Paris, June 1959.
13
that given some legitimate value of < ab >, another may be formed by following it with the character ( or by following
it with some value of the variable < d >. If the values of < d >> are the decimal digits, some values of < ab > are:
[(((1(37(
(12345(
(0
[86
In order to facilitate the study, the symbols used for distinguishing the metalinguistic variables (i.e., the sequences of
characters appearing within the brackets < > as ab in the above example) have been chosen to be words describing
approximately the nature of the corresponding variable. Where words which have appeared in this manner are used
elsewhere in the text they will refer to the corresponding syntactic definition. In addition some formulae have been
given in more than one place.
Definition:
< empty > ::=
(i.e. the null string of symbols).
2. Basic Symbols, Identifiers, Numbers, and Strings, Basic Concepts.
The reference language is built up from the following basic symbols:
< basic symbol > ::= < letter > |< digit > |< logical value > |< delimiter >
2.1 Letters
< letter > :=albicidlelflglh!li!jIkitIminlolplgirisitiulviIwlixly |z
AIBICIDIE!FIGIHINJIKILIMINIOIPICIRISITIUIVIWIXIYIZ
This alphabet may arbitrarily be restricted, or extended with any other distinctive character (i.e., character not coinciding
with any digit, logical value or delimiter). Letters do not have individual meaning. They are used for forming identifiers
and stringsT (Cf. sections 2.4 Identifiers, 2.6 Strings).
2.1 Letters
Since there is hardware representation for upper case letters only, lower case letters have no meaning.
2.2.1 Digits
<digit > ::=0111213141516171819
Digits are used for forming numbers, identifiers, and strings.
TIt should be particularly noted that throughout the reference language underlining is used for defining independent
“ basic symbols (see sections 2.2.2 and 2.3). These are understood to have no relation to the individual letters of which
they are composed. Within the present report (not including headings) underlining will be used for no other purpose.
14
2.2.2 Logical Values
< logical value > ::= true | false
The logical values have a fixed obvious meaning.
2.3 Delimiters
< delimiter > !:= < operator >| < separator >| < bracket >| < declarator >| < specificator >
< operator > ::= < arithmetic operator >| < relational operator >>| < logical operator >|
< sequential operator >
< arithmetic operator > = +| =| X| /| +| 1
< relational operator > ::= <| <| = || >| ==
< logical operator > ::= =| I | VIA 1.
< sequential operator > = go to| if| then| else| for| do’
< separator > ::= ‚| .| 10 | :| | :=|.—| step| until| while| comment
< bracket > ::= (| )| [| ] 1*1*] begini end
< declarator > ::= own | Boolean | integer | real | array | switch | procedure
< specificator > ::= string | label | value
Delimiters have a fixed meaning which for the most part is obvious or else will be given at the appropriate place in the
sequel.
Typographical features such as blank space or change to a new line have no significance in the reference language. They
may, however, be used freely for facilitating reading. For the purpose of including text among the symbols of a program
the following “comment” conventions hold:
BE ade ms, et
The sequence of basic symbols:
is equivalent to:
; comment < any sequence not containing; > ; ’ ;
begin comment < any sequence not containing; > ; begin
end < any sequence not containing end or ; or else > end
By equivalence is here meant that any of the three structures shown in the left hand column may be replaced, in any
occurrence outside of strings, by the symbol shown on the same line in the right-hand column without any effect on the
action of the program. It is further understood that the comment structure encountered first in the text when reading
from left to right has precedence in being replaced over later structures contained in the sequence.
tdo is used in for statements. It has no relation whatsoever to the do of the preliminary report, which is not included
in ALGOL-60.
15
2.3 Delimiters
The symbol code, defined below, is added to the language to permit reference. to separately compiled
procedures (Section 5.4.6).
<code procedure body indicator>: : =code
24 Identifiers
2.4.1 Syntax
< identifier > .:= < letter >| < identifier > < letter >| < identifier > < digit >
2.4.2 Examples
q
Soup
V 17a
a34kTM Ns
MARILYN
2.4.3 Semantics
Identifiers have no inherent meaning, but serve for the identification of simple variables, arrays, labels, switches, and
procedures. They may be chosen freely (cf., however, section 3.2.4 Standard Functions).
‘The same identifier cannot be used to denote two different quantities except when these quantities have disjoint scopes
as defined by the declarations of the program (cf., section 2.7. Quantities, Kinds and Scopes, and section 5. Declarations).
2.4.3 Semantics
The maximum size of an identifier is 256 hardware characters. If a longer identifier is specified, only
the first 256 characters are used.
The maximum number of identifiers which can be handled by the compiler. without causing identifier
table overflow depends on the identifier sizes and the amount of memory available to the compiler.
The compiler itself can handle up to 3583 unique identifiers. Identifier table overflow generally occurs
before this number is reached.
2.5 Numbers
2.5.1 Syntax
< unsigned integer > ::= < digit >| < unsigned integer > < digit >
< integer > ::= < unsigned integer >| + < unsigned integer >|
- < unsigned integer >
16
< decimal fraction > :. =. < unsigned integer >
< exponent part > ..= 10 < integer >
< decimal number > ::= < unsigned integer >| < decimal fraction >|
< unsigned integer > < decimal fraction >
< unsigned number > ::=< decimal number >| < exponent part >|
< decimal number > < exponent part >
< number > ::= < unsigned number >| + < unsigned number >|
- unsigned number >
2.5.2 Examples
0 —200.084 —.08310 —02
177 +07.43108 —107
5384 9.3410+10 10-4
+0.7300 2-104 +1045
2.5.3 Semantics
Decimal numbers have their conventional meaning. The exponent part is a scale factor expressed as an integral power of 10.
2.5.3 Semantics
A number has the format
d,d,. .. а. dado . d 107% eo: . e
where the decimal point and the exponent field may or may not be explicit. MH the decimal point is not
explicit, it is assumed to follow the digit d (j=n). If the exponent field is not explicit, zero value is
assumed. If the sign of the exponent field is not explicit, a positive exponent is assumed. Thus, all
numbers are considered to have the same format and are treated identically.
If the magnitude of the exponent field exceeds 9999, the diagnostic NUMBER SIZE is issued.
A number is modified in three steps before it is converted to its final internal representation
(Section 5.1.3).
1. All leading zeros are eliminated, including any following the decimal point.
2. Beginning with the first non-zero digit, the digits following the fourteenth are discarded. The
number of digits discarded is added to the value of the exponent field.
3. The effect of the decimal point is incorporated by subtracting n-j (number of digits to the right of
the point) from the value of the exponent field.
17
These three modifications effectively produce a number of the form d.d, _... e where d, is the first
non-zero digit in the original number. If no non-zero digit is found, A number is given the internal
value O. E de 9° etc. , are the digits (zero or non-zero) immediately following d in the original
number,
The last significant digit, de is d if n<i+13 or is digg
The resultant exponent field value, e, is given by:
e=eje,...e - (n-j) + max (0,n - (i+13).
If e is greater than the maximum allowed decimal exponent, the diagnostic NUMBER SIZE is issued.
If e is smaller than the minimum allowed decimal exponent, the number is given the internal value 0.
2.5.4 Types
Integers are of type integer. All other numbers are of type real (cf, section 5.1. Type Declarations).
2.5.4 Types
During compilation, numbers are flagged as type real or integer, according to the following rules:
" Any number with an explicit decimal point and/or an explicit exponent part is flagged real.
All other numbers are flagged integer.
In addition, in the 3000 series only, because of the internal representation of type integer (Section 5.1. 3),
integer numbers with more than 14 significant digits (n>i+13) are also flagged real and the message
FLOATED INTEGER is issued.
real and integer numbers are represented internally in the same form as real and integer variables
(Section 5.1. 3).
During object code generation, the type and value of a number may be changed depending on the opera-
tion and type of operand with which it is associated in the source program (Sections 3.3.4 and 4. 3.4).
2.6 Strings
2.6.1 Syntax
< proper string >::=< any sequence of basic symbols not containing ‘ or ’>{< empty >
< open string >::=< proper string >| <open string >”|
< open string > < open string >
< string >::= “< open string >”
2.6.2 Examples
‘Bk, — [[CA=/:?Tt>
. This L] is Li à “string”
18
2.6.1 Syntax
A proper string is defined as follows:
<proper string>::=<empty> | <any sequence of basic 6-bit display BCD characters not
containing the symbols “or? or the character associated
with external BCD 00,>
2.6.3 Semantics
In order to enable the language to handle arbitrary sequences of basic symbols the string quotes ‘ and ’ are introduced.
The symbol LI denotes a space. It has no significance outside strings.
Strings are used as actual parameters of procedures (cf. sections 3.2. Function Designators and 4.7. Procedure Statements).
2.6.3 Semantics
The string quote symbols “and ” are introduced to enable the language to handle arbitrary sequences
of basic characters (not basic symbols, as defined in the Report). These symbols are represented by
the three-character sequences '(' and ')'. (Table 1, Chapter 4).
2.7 Quantities, Kinds and Scopes
The following kinds of quantities are distinguished: simple variables, arrays, labels, switches, and procedures.
The scope of a quantity is the set of statements and expressions in which the declaration of the identifier associated with
that quantity is valid. For labels see section 4.1.3.
2.8 Values and Types
A value is an ordered set of numbers (special case: a single number), an ordered set of logical values (special case: a
single logical value), or a label.
Certain of the syntactic units are said to possess values. These values will in general change during the execution of the
program. The values of expressions and their constituents are defined in section 3. The value of an array identifier is the
ordered set of values of the corresponding array of subscripted variables (cf, section 3.1.4.1).
The various “types” (integer, real, Boolean) basically denote properties of values. The types associated with syntactic
units refer to the values of these units.
3. Expressions
In the language the primary constituents of the programs describing algorithmic processes are arithmetic, Boolean, and
designational expressions. Constituents of these expressions, except for certain delimiters, are logical values, numbers,
variables, function designators, and elementary arithmetic, relational, logical, and sequential operators. Since the syn-
tactic definition of both variables and function designators contains expressions, the definition of expressions, and their
constituents, is necessarily recursive.
< expression > ::= < arithmetic expression >| < Boolean expression >| < designational expression >
19
3.1 Variables
3.1.1 Syntax
< variable identifier > :. = < identifier >
< simple variable > ::= < variable identifier >
< subscript expression > ::= < arithmetic expression >
< subscript list > ::.= < subscript expression >| < subscript list > , < subscript expression >
< array identifier > ::= < identifier >
< subscripted variable > ::= < array identifier > [ < subscript list > ]
< variable > ::= < simple variable >| © subscripted variable >
3.1.2 Examples
epsilon
detA
al7
Q [7,2]
x [sin(nXpi/2), Q [3, n, 41]
3.1.3 Semantics
A variable is a designation given to a single value. This value may be used in expressions for forming other values and may
be changed at will by means of assignment statements (section 4.2). The type of the value of a particular variable is de-
fined in the declaration for the variable itself (cf. section 5.1. Type Declarations) or for the corresponding array identifier
(cf. section 5.2 Array Declarations).
3.1.4 Subscripts
3.1.4.1 Subscripted variables designate values which are components of multidimensional arrays (cf. section 5.2 Array
Declarations). Each arithmetic expression of the subscript list occupies one subscript position of the subscripted variable,
and is called a subscript. The complete list of subscripts is enclosed in the subscript brackets [1. The array component re-
ferred to by a subscripted variable is specified by the actual numerical value of its subscripts (cf. section 3.3 Arithmetic
Expressions). | |
3.1.4.2 Each subscript position acts like a variable of type integer and the evaluation of the subscript is understood to
“be equivalent to an assignment to this fictitious variable (cf. section 4.2.4). The value of the subscripted variable is de-
fined only if the value of the subscript expression is within the subscript bounds of the array (cf. section 5.2 Array
Declarations).
20
3.1.4.2
No check is made to ensure that the value formed by assigning each subscript expression to a fictitious
integer variable (Section 4.2.4) is within the corresponding bounds of the array. However, the address
of the referenced array component (combination of all of the fictitious integer variables) is checked to
ensure that it lies within the bounds of the complete array. This array bounds check may be suppressed
throughout the object code with the control card option N (Chapter 6). In the 6000 series this check
cannot be suppressed for assignments to array elements. The final address of the referenced array
component is assumed to be a normal machine word address.
3.2 Function Designators
3.2.1 Syntax
< procedure identifier > :: = < identifier >
< actual parameter > ::= < string >| < expression >| < array identifier >|
< switch identifier >| < procedure identifier >
< letter string > ::= < letter >| < letter string > < letter >
< parameter delimiter > ::=,| ) <letter string > : (
< actual parameter list > ::= < actual parameter >|
< actual parameter list > < parameter delimiter > < actual parameter >
< actual parameter part > ::= < empty >| ( < actual parameter list > )
< function designator > :; = < procedure identifier > < actual parameter part >
3.2.2 Examples
sin (a—b)
J (v+s,n)
R
S (s-5) Temperature: (T) Pressure: (P)
Compile(* := *)Stack:(Q)
3.2.3 Semantics
Function designators define single numerical or logical values, which result through the application of given sets of rules
defined by a procedure declaration (cf. section 5.4. Procedure Declarations) to fixed sets of actual parameters. The rules
governing specification of actual parameters are given in section 4.7. Procedure Statements. Not every procedure declara-
tion defines the values of a function designator.
21
3.2.4 Standard Functions
Certain identifiers should be reserved for the standard functions of analysis, which will be expressed as procedures. lt is
recommended that this reserved list should contain:
abs(E) for the modulus (absolute value) of the value of the expression E
sign(E) for the sign of the value of E(+1 for E > 0, 0 for E=0, -1 for E<0)
sgrt(E) for the square root of the value of E
sin(E) for the sine of the value of E
cos(E) for the cosine of the value of E
arctan(E) for the principal value of the arctangent of the value of E
In(E) for the natural logarithm of the value of E
exp(E) for the exponential function of the value of E (eE).
These functions are all understood to operate indifferently on arguments both of type real and integer. They will all
yield values of type real, except for sign(E) which will have values of type integer. In a particular representation these
functions may be available without explicit declarations (cf. section 5. Declarations).
3.2.4 Standard Functions
All input-output functions (Chapter 3) are expressed as calls of standard procedures. The list of
reserved identifiers is expanded to include the names of these procedures:
IN LIST H LIM BAD DATA
OUT LIST V LIM PARITY
INPUT H END EOF
OUTPUT V END REWIND
IN REAL NO DATA UNLOAD
OUT REAL TABULATION SKIPF
IN ARRAY FORMAT SKIPB
OUT ARRAY SYSPARAM ENDFILE
IN CHARACTER EQUIV BACKSPACE
OUT CHARACTER STRING ELEMENT IOLTH
GET ARRAY CHLENGTH MODE
PUT ARRAY MANINT CONNECT
ARTHOF LW DUMP
22
Calls to all standard procedures (input-output and function) conform to the syntax of calls to declared
procedures (Section 4.7.1) and in all respects are equivalent to regular procedure calls. This spe-
cifically includes the use of a standard procedure identifier as an actual parameter in a procedure call.
If a standard procedure is not needed throughout a program, its identifier may be declared to have
another meaning at any level; the identifier assumes the new meaning rather than that of a standard
procedure.
Since all standard procedures are contained on the operating system library, they are available to any
object program (Chapter 5).
3.2.5 Transfer Functions
It is understood that transfer functions between any pair of quantities and expressions may be defined. Among the
standard functions it is recommended that there be one, namely,
entier(E),
which “transfers” an expression of real type to one of integer type, and assigns to it the value which is the largest integer
not greater than the value of E.
3.3 Arithmetic Expressions
3.3.1 Syntax
< adding operator > ::= +| -
< multiplying operator > ::= X|/| +
< primary > ::= < unsigned number >| < variable >|
< function designator >| ( < arithmetic expression >)
< factor > ::= < primary >| < factor >< primary >
< term > ::= < factor >| < term > < multiplying operator > < factor >
< simple arithmetic expression > !: = < term >|
< adding operator > < term >| < simple arithmetic expression >
< adding operator > < term >
< if clause > ::= if < Boolean expression > then
< arithmetic expression > ::= < simple arithmetic expression >|
< if clause > < simple arithmetic expression > else
< arithmetic expression >
23
3.3.2 Examples
Primaries:
7.39410-8
sum
w [i+2 8]
cos (y+zX3)
(a-3/y+vut8)
Factors:
omega
sum Î cos(y+zX3)
7.39410-8 t w[i+2,8] + (a-3/y+vu 1 8)
Terms:
U
omega Xsum ? cos(y+zX3)/7.34910-8 tw [i+2,8] +
(a-3/y+vu +8)
Simple arithmetic expression:
U-Yu+omegaXsum 1 cos(y+zX3)/7.34910-8 t w[i+2,8] 1
(a-3/y+vu + 8)
Arithmetic expressions:
wXu-Q(S+Cu) 12
if q>0 then S+3XO/A else 2XS+3Xq
if a<<0 then U+V else if aXb> 17 then U/V else ¡f k=y then V/U else 0
aXsin(omegaXt)
0.571012Xa[NX(N-1)/2,0]
(AXarctan(y)+Z) 1 (7+Q)
if q then n-1 else n
if a<O then A/B else if b = 0 then B/A else z
24
3.3.3 Semantics
An arithmetic expression is a rule for computing a numerical value. In case of simple arithmetic expressions this value
is obtained by executing the indicated arithmetic operations on the actual numerical values of the primaries of the ex-
pression, as explained in detail in section 3.3.4 below. The actual numerical value of a primary is obvious in the case of
numbers. For variables it is the current value (assigned last in the dynamic sense), and for function designators it is the
value arising from the computing rules defining the procedure (cf. section 5.4.4. Values of Function Designators) when
applied to the current values of the procedure parameters given in the expression. Finally, for arithmetic expressions
enclosed in parentheses the value must through a recursive analysis be expressed in terms of the values of primaries of
the other three kinds.
In the more general arithmetic expressions, which include if clauses, one out of several simple arithmetic expressions is
selected on the basis of the actual values of the Boolean expressions (cf. section 3.4. Boolean Expressions). This selection
is made as follows: The Boolean expressions of the if clauses are evaluated one by one in sequence from left to right until
one having the value true is found. The value of the arithmetic expression is then the value of the first arithmetic expres-
sion following this Boolean (the largest arithmetic expression found in this position is understood).
The construction:
else < simple arithmetic expression >
is equivalent to the construction:
else if true then <simple arithmetic expression >
3.3.3 Semantics
If during the evaluation of an arithmetic expression, a machine arithmetic error condition (overflow,
underflow or division fault) arises, caused for example by an attempt at division by 0, an error condi-
tion exists in the object program. If the procedure ARTHOF LW (Chapter 3) has not been called, or if a
label established by it is no longer accessible, the object program terminates abnormally with the mes-
sage ARITHMETIC OVERFLOW." If an arithmetic overflow label has been established, control passes
to it.
3.3.4 Operators and types
Apart from the Boolean expressions of if clauses, the constituents of simple arithmetic expressions must be of types
real or integer (cf. section 5.1. Type Declarations). The meaning of the basic operators and the types of the expressions
to which they lead are given by the following rules:
3.3.4.1 The operators +, —, and X have the conventional meaning (addition, subtraction, and multiplication). The type
of the expression will be integer if both of the operands are of integer type, otherwise real.
3.3.4.2 The operations < term > /< factor > and < term > + < factor > both denote division, to be understood as a
multiplication of the term by the reciprocal of the factor with due regard to the rules of precedence (cf. section 3.3.5).
Thus for example
a/bX7/(p-q) Xv/s
T ARITHMETIC OVERF LOW does not apply to lower 3000.
25
means
(aX (b-1))X7) X((p-q)-1))Xv)X(s-)
The operator / is defined for all four combinations of types real and integer and will yield results of real type in any case.
The operator ~ is defined only for two operands both of type integer and will yield a result of type integer, mathemati-
cally defined as follows:
a-b=sign (a/b) Xentier (abs(a/b))
(cf. sections 3.2.4 and 3.2.5).
3.3.4 Operators and Types
When the type of an arithmetic expression cannot be determined at compile-time, it is considered real.
For example, the parenthesized expression in the following statement is considered real if one or both
of the arithmetic expressions R and S is real:
P x (if Q then R else $)
In the evaluation of each simple arithmetic expression, the code is generated to perform the operation and to transform
operands from real to integer, or vice versa, to arrive at the correct type for the expression (Section 3.3.4.1, 2 and 3).
For example in the simple arithmetic expression involving the +, — or X operator, unless both operands are of type
integer, any integer operand is transformed into type real before the operation is performed.
If an operand is a number, transformation between types is performed at compile-time and the resulting number is
flagged accordingly (Section 2.5.4).
If both operands in a simple arithmetic expression are numbers, the transformation from type real to
integer, or integer to real, is performed at compile-time.T The type of the one resulting number is
defined according to the number types and the particular operation involved.
If the result of an expression is assigned to a variable with a different type, the compiler generates
the code to transform the result to the proper type (Section 4. 2. 4),
When the final result is a number, transformation is performed at compile-time (as in the assignment
of a simple number to a variable of a different type).
The internal representations of type real and integer values and the transformations between them are
described in Section 5.1.3.
3.3.4.3 The operation < factor > 1 < primary > denotes exponentiation, where the factor is the base and the primary
is the exponent. Thus, for example,
2tntk means (2MK
while
24(nTm) means 2(n™)
tin the upper 3000 and 6000 systems the operation itself is also performed at compile-time.
26
Writing i for a number of integer type, r for a number of real type, and a for a number of either integer or real type, the
result is given by the following rules:
ati Ifi>0, aXaX....Xa(i times), of the same type as a.
If i=0, if a+#0,1, of the same type as a.
if a = 0, undefined.
If i<0, if a #0,1/(aXaX. . .Xa) (the denominator has —i factors), of type real.
if a = 0, undefined.
aîr If a>0, exp(rXin(a)), of type real.
Ifa=0,if r>0,0.0, of type real.
if r<0, undefined.
If a<O, always undefined.
3.3.4.3
The rule for evaluating an expression of the form afi or alr is the same as defined above except when a
is of type integer and i is an integer variable with a positive value. In this case, the result is real,
whereas the Report defines it as integer. (If i is a positive integer number, however, the result is
integer as defined.)
3.3.5 Precedence of operators
The sequence of operations within one expression is generally from left to right, with the following additional rules:
3.3.5.1 According to the syntax given in section 3.3.1 the following rules of precedence hold:
first: 1
second: X/+
third: +—
3.3.5.2 The expression between a left parenthesis and the matching right parenthesis is evaluated by itself and this value
is used in subsequent calculations. Consequently the desired order of execution of operations within an expression can
always be arranged by appropriate positioning of parentheses.
3.3.6 Arithmetics of real quantities
Numbers and variables of type real must be interpreted in the sense of numerical analysis, i.e. as entities defined inher-
ently with only a finite accuracy. Similarly, the possibility of the occurrence of a finite deviation from the mathemati-
cally defined result in any arithmetic expression is explicitly understood. No exact arithmetic will be specified, however,
and it is indeed understood that different hardware representations may evaluate arithmetic expressions differently. The
control of the possible consequences of such differences must be carried out by methods of numerical analysis. This
control must be considered a part of the process to be described, and will therefore be expressed in terms of the lan-
guage itself.
27
3.4 Boolean Expressions
3.4.1 Syntax
< relational operator > ::=<|< =|>| >| £
< relation > ::= < simple arithmetic expression >
< relational operator > < simple arithmetic expression >
< Boolean primary > ::=< logical value >| < variable >|
< function designator >| < relation >| (< Boolean expression >)
< Boolean secondary > ::= < Boolean primary >| 1< Boolean primary >
< Boolean factor > ::= < Boolean secondary >|
< Boolean factor > A < Boolean secondary >
< Boolean term > ::= < Boolean factor >| < Boolean term >
V'< Boolean factor >
< implication > ::= < Boolean term >| < implication > > < Boolean term >
< simple Boolean > ::= < implication >|
< simple Boolean > = < implication >
< Boolean expression > ::= < simple Boolean >|
< if clause > < simple Boolean > else < Boolean expression >
3.4.2 Examples
х = -2
Y>VVz<q
atb > -5Az-4>qgt2
pAqVx#y
9 = la\bA lcVdVe5 If
if k <1 then s > welse h<c
——. _-_—_——-——— _-_-_-_ = — =—=———
28
3.4.3 Semantics
A Boolean expression is a rule for computing a logical value. The principles of evaluation are entirely analogous to those
given for arithmetic expressions in section 3.3.3.
3.4.4 Types
Variables and function designators entered as Boolean primaries must be declared Boolean (cf. section 5.1. Type Declara-
tions and section 5.4.4. Values of Function Designators).
3.4.5 The operators
Relations take on the value true whenever the corresponding relation is satisfied for the expressions involved, otherwise
false.
——]
The meaning of the logical operators (not), A (and), V (or), > (implies), and = (equivalent), is given by the following
function table.
b1 false false true true
b2 false true false true
1b1 true true false false
b1Ab2 false false false true
b1Vb2 false true true true
b1Db2 true true false true
— o———— ———i Di
b1=b2 true false false true
3.4.6 Precedence of operators
The sequence of operations within one expression is generally from left to right, with the following additional rules:
3.4.6.1 According to the syntax given in section 3.4.1 the following rules of precedence hold:
first: arithmetic expressions according to section 3.3.5
$есоп@: < < = 2 > +
third:
fourth: A
fifth: V
sixth: DO
seventh: =
29
3.4.6.2 The use of parentheses will be interpreted in the sense given in section 3.3.5.2,
3.5 Designational Expressions
3.5.1 Syntax
< label > ::= < identifier >| < unsigned integer >
< switch identifier >: = < identifier >
< switch designator > = < switch identifier > [ < subscript expression > ]
< simple designational expression > ::= < label >| < switch designator >|
(< designational expression > )
< designational expression > ::= < simple designational expression >|
< if clause > < simple designational expression > else
< designational expression >
3.5.2 Examples
17
p9
Choose [n-1]
Town [if y <0 then N else N+1]
if Ab <c then 17 else q [if w < 0 then 2 else n]
3.5.3 Semantics
A designational expression is a rule for obtaining a label of a statement (cf. section 4. Statements). Again the principle of
the evaluation is entirely analogous to that of arithmetic expressions (section 3.3.3). In the general case the Boolean
expressions of the if clauses will select a simple designational expression. If this is a label the desired result is already
found. A switch designator refers to the corresponding switch declaration (cf. section 5.3 Switch Declarations) and by
the actual numerical value of its subscript expression selects one of the designational expressions listed in the switch
declaration by counting these from left to right. Since the designational expression thus selected may again be a switch
designator this evaluation is obviously a recursive process.
3.5.4 The subscript expression
The evaluation of the subscript expression is analogous to that of subscripted variables (cf. section 3.1.4.2). The value
of a switch designator is defined only if the subscript expression assumes one of the positive values 1,2,3,. . . ,n, where
n is the number of entries in the switch list.
30
3.5.5 Unsigned integers as labels
Unsigned integers used as labels have the property that leading zeros do not affect their meaning, e.g. 00217 denotes the
same label as 217.
3.5.5 Unsigned Integers as Labels
Integer labels are not permitted.
4. Statements
The units of operation within the language are called statements. They will normally be executed consecutively as
written. However, this sequence of operations may be broken by go to statements, which define their successor explic-
itly, and shortened by conditional statements, which may cause certain statements to be skipped.
In order to make it possible to define a specific dynamic succession, statements may be provided with labels.
Since sequences of statements may be grouped together into compound statements and blocks the definition of state-
ment must necessarily be recursive. Also since declarations, described in section 5, enter fundamentally into the syntatic
structure, the syntatic definition of statements must suppose declarations to be already defined.
4.1 Compound Statements and Blocks
4.1.1 Syntax
< unlabelled basic statement > :. = < assignment statement >|
< go to statement >| < dummy statement >>| < procedure statement >
< basic statement > :: = < unlabelled basic statement >>| < label > : < basic statement >
< unconditional statement > ::= < basic statement >|
< compound statement >| < block >
< statement > :.=< unconditional statement >|
< conditional statement >| < for statement >
< compound tail > ::= < statement > end < statement > ;
< compound tail >
< block head > ::= begin < declaration >| < block head > ;
< declaration >
< unlabelled compound > ::= begin < compound tail >
< unlabelled block > :: = < block head > ; < compound tail >
31
< compound statement > © = < unlabelled compound >|
< label > : < compound statement >
< block > i= < unlabelled block >| < label > : < block >
< program > ::= < block >| < compound statement >
This syntax may be illustrated as follows: Denoting arbitrary statements, declarations, and labels, by the letters S, D,
and L, respectively, the basic syntactic units take the forms:
Compound statement:
L:L:...beginS ;S;...S; Send
Block:
L: L:...beginD;D;...D;S;S;...S;
S end
It should be kept in mind that each of the statements S may again be a complete compound statement or block.
4.1.2 Examples
Basic Statements:
a:=p+q
go to Naples
START: CONTINUE:W:=7.993
Compound Statement:
begin x :=0 ¡for y:=1 step 1 until n do
x :=X+A [y] ;
if x > q then go to STOP else if x > w-2 then go to S;
Aw:St:W :=x+bob end
Block:
O: begin integer ik real w;
for i : = 1 step 1 until m do
for k: = i+1 step 1 until m do
begin w : = À [ik] :
A [ik] :=Alk,i] ;
A [k,i] :=w end for i and k
end block Q
32
4.1.1 Syntax
Replace the definition of <program> with:
<program> : :=<unlabeled block> | <unlabeled compound>
4.1.3 Semantics
Every block automatically introduces a new level of nomenclature. This is realized as follows: Any identifier occurring
within the block may through a suitable declaration (cf. section 5. Declarations) be specified to be local to the block in
question. This means (a) that the entity represented by this identifier inside the block has no existence outside it, and
(b) that any entity represented by this identifier outside the block is completely inaccessible inside the block.
Identifiers (except those representing labels) occurring within a block and not being declared to this block will be non-
local to it, i.e., will represent the same entity inside the block and in the level immediately outside it. A label separated
by a colon from a statement, i.e., labelling that statement, behaves as though declared in the head of the smallest em-
bracing block, i.e. the smallest block whose brackets begin and end enclose that statement. In this context a procedure
body must be considered as if it were enclosed by begin and end and treated as a block. Since a statement of a block
may again itself be a block the concepts local and nonlocal to a block must be understood recursively. Thus an identi-
fier, which is nonlocal to a block A, may or may not be nonlocal to the block B in which A is one statement.
4,1.3 Semantics
Blocks may be nested to a maximum of 32 levels.
4.2 Assignment Statements
4.2.1 Syntax
< left part > .. = < variable > : = | < procedure identifier > : =
< left part list > ::= < left part >| < left part list > < left part >
< assignment statement > :: = < left part list > < arithmetic expression >|
< left part list > < Boolean expression >
4.2.2 Examples
s :=p [0]:=n:=n+1+s
n :=n+1
A :=B/C-v-gXS
S [v.k+2] : = 3-arctan(sXzeta)
V :=Q>YAZ
33
4.2.3 Semantics
Assignment statements serve for assigning the value of an expression to one or several variables or procedure identifiers.
Assignment to a procedure identifier may only occur within the body of a procedure defining the value of a function
designator (cf. section 5.4.4). The process will in the general case be understood to take place in three steps as follows:
4.2.3.1 Any subscript expressions occurring in the left part variables are evaluated in sequence from left to right.
4.2.3.2 The expression of the statement is evaluated.
4.2.3.3 The value of the expression is assigned to all the left part variables, with any subscript expressions having values
‘as evaluated in step 4.2.3.1.
4.2.4 Types
The type associated with all variables and procedure identifiers of a left part list must be the same. If this type is Boolean,
the expression must likewise be Boolean. If the type is real or integer, the expression must be arithmetic. If the type of
the arithmetic expression differs from that associated with the variables and procedure identifiers, appropriate transfer
functions are understood to be automatically invoked. For transfer from real to integer type, the transfer function is
understood to yield a result equivalent to
entier(E+0.5)
where E is the value of the expression. The type associated with a procedure identifier is given by the declarator which
appears as the first symbol of the corresponding procedure declaration (cf. section 5.4.4).
4.2.4 Types
If the type of an arithmetic expression (Section 3.3.4) is different from that of the variable or procedure
identifier to which it is assigned, the compiler generates the code to perform the transformation from
one type to the other.
If an expression results only in a number (Section 2.5.4), the transformation is done at compile-time,
and the resulting number is flagged according to its new type.
The internal representations of real and integer values and the transformations between them are
described in Section 5.1. 3.
i
4.3 Go To Statements
4.3.1 Syntax
< go to statement > ::= go to < designational expression >
4.3.2 Examples
go to 8
go to exit [n+1]
go to Town [if y <0 then N else N+1]
go to if Ab < c then 17 else q [if w < O then 2 else n]
34
4.3.3 Semantics
A go to statement interrupts the normal sequence of operations, defined by the write-up of statements, by defining its
successor explicitly by the value of a designational expression. Thus the next statement to be executed will be the one
having this value as its label.
4.3.4 Restriction
Since labels are inherently local, no go to statement can lead from outside into a block. A go to statement may, however,
lead from outside into a compound statement.
4.3.5 Go to an undefined switch designator
A go to statement is equivalent to a dummy statement if the designational expression is a switch designator whose value
is undefined.
4.3.5 Go to Undefined Switch Designator
When a go to statement is executed for a designational expression which is a switch with an undefined
value, the object program terminates abnormally with the message SWITCH BOUNDS ERROR.
4.4 Dummy Statements
4.4.1 Syntax
< dummy statement > I= < empty >
4.4.2 Examples
L:
begin . . . ; John: end
4.4.3 Semantics
A dummy statement executes no operation. It may serve to place a label.
45 Conditional Statements
4.5.1 Syntax
< if clause > ..= К < Boolean expression > then
< unconditional statement > ::= < basic statement >|
< compound statement >|< block >
< if statement > ::= if clause > < unconditional statement >
< conditional statement > ::= < if statement >| < if statement > else
< statement >|< if clause > < for statement >|
< label > : < conditional statement >
35
45.2 Examples
if x > 0 then n := n+1
if v > u then V: q:=n+m else go to R
ifs <O VP <Q then AA: begin if q <v thena := v/s
else y := 2Xa end
else if v > s then a :=v-q else if v > s-1
then go to $
4.5.3 Semantics
Conditional statements cause certain statements to be executed or skipped depending on the running values of specified
Boolean expressions.
4.5.3.1 If statement. The unconditional statement of an if statement will be executed if the Boolean expression of the if
clause is true. Otherwise it will be skipped and the operation will be continued with the next statement.
4.5.3.2 Conditional statement. According to the syntax two different forms of conditional statements are possible.
These may be illustrated as follows:
if B1 then S1 else if B2 then S2 else S3 ; $4
and
if B1 then S1 else if B2 then S2 else if B3 then S3 ; S4
Here B1 to B3 are Boolean expressions, while S1 to S3 are unconditional statements. S4 is the statement following the
complete conditional statement.
The execution of a conditional statement may be described as follows: The Boolean expression of the if clauses are
evaluated one after the other in sequence from left to right until one yielding the value true is found. Then the uncondi-
tional statement following this Boolean is executed. Unless this statement defines its successor explicitly the next
statement to be executed will be 84, i.e., the statement following the complete conditional statement. Thus the effect
of the delimiter else may be described by saying that it defines the successor of the statement it follows to be the state-
ment following the complete conditional statement.
The construction
else < unconditional statement >
is equivalent to
else if true then < unconditional statement >
If none of the Boolean expressions of the if clause, is true, the effect of the whole conditional statement will be equiva-
lent to that of a dummy statement.
36
For further explanation the following picture may be useful:
B1 false B2 false
4.5.4 Go to into a conditional statement
The effect of a go to statement leading into a conditional statement follows directly from the above explanation of the
effect of else.
4.6 For statements
4.6.1 Syntax
< for list element > :: = < arithmetic expression >|
< arïthmetic expression > step < arithmetic expression > until
< arithmetic expression >| < arithmetic expression > while
< Boolean expression >
< for list > ::= < for list element >| < for list > , < for list element >
< for clause > ::= for < variable > : = < for list > do
< for statement > !: = < for clause > < statement >|
< label > : < for statement >
4.6.2 Examples
for q :=1 step s until n do A [q] : =B [a]
for k : = 1, V1X2 while V1<N do
for j : = 1+G,L,1 step 1 until N,C+D do
A [k,i] : =B [ki]
4.6.3 Semantics
A for clause causes the statement S which it precedes to he repeatedly executed zero or more times. In addition, it per-
forms a sequence of assignments to its controlled variable. The process may be visualized by means of the following
picture:
+
Initialize ; test ; statement S ; advance ; successor
+ Î
| for list exhausted |
37
In this picture the word initialize means: perform the first assignment of the for clause. Advance means: perform the
next assignment for the for clause. Test determines if the last assignment has been done. If 50, the execution continues
with the successor of the for statement. If not, the statement following the for clause is executed.
4.6.3 Semantics
If, in a for statement, the controlled variable is subscripted, the same array element is used as the
control variable throughout the execution of the for statement, regardless of any changes that might
occur to the value of the subscript expressions during its execution. The element used is the one
referenced by the value of the subscript expressions on entry to the for statement.
4.6.4 The for list elements
The for list gives a rule for obtaining the values which are consecutively assigned to the controlled variable. This sequence
of values is obtained from the for list elements by taking these one by one in the order in which they are written. The
sequence of values generated by each of the three species of for list elements and the corresponding execution of the
statement S are given by the following rules:
4.6.4.1 Arithmetic expression. This element gives rise to one value, namely the value of the given arithmetic expression
as calculated immediately before the corresponding execution of the statement S.
4.6.4.2 Step-until-element. An element of the form A step B until C, where A, B, and C, are arithmetic expressions,
gives rise to an execution which may be described most concisely in terms of additional ALGOL statements as follows:
V: =A:
L1:if (V-C) Xsign (B) > O then go to element exhausted;
statements S ;
V:=V+B;
gotoll;
where V is the controlled variable of the for clause and element exhausted points to the evaluation according to the next
element in the for list, or if the step-until-element is the last of the list, to the next statement in the program.
4.6.4.3 While-element. The execution governed by a for list element of the form E while F, where E is an arithmetic and
F a Boolean expression, is most concisely described in terms of additional ALGOL statements as follows:
L3: V :=E;
if 1F then go to element exhausted ;
Statement S ;
gotoL3;
where the notation is the same as in 4.6.4.2 above.
38
4.6.5 The value of the controlled variable upon exit
Upon exit out of the statement S (supposed to be compound) through a go to statement the value of the controlled
variable will be the same as it was immediately preceding the execution of the go to statement.
If the exit is due to exhaustion of the for list, on the other hand, the value of the controlled variable is undefined after
the exit.
4.6.6 Go to leading into a for statement
The effect of a go to statement, outside a for statement, which refers to a label within the for statement, is undefined.
4,6.6 Go to Leading into a For Statement
A go to statement, executed from outside a for statement not currently being executed, which refers to
a label within the for statement, causes the object program to terminate abnormally with the message
UNDEFINED FOR LABEL. This will not happen if an exit is made from the for statement prior to its
end.
4.7 Procedure Statements
4.7.1 Syntax
< actual parameter > !! = < string >|< expression >|< array identifier >|
< switch identifier >|< procedure identifier >
< letter string > ::= < letter >|< letter string > < letter >
< parameter delimiter > ::=,|) < letter string > :(
< actual parameter list > ::= < actual parameter >|< actual parameter list >
< parameter delimiter > < actual parameter >
< actual parameter part > ::= < empty >|
( < actual parameter list > )
< procedure statement > ::= < procedure identifier >
< actual parameter part >
4.7.2 Examples
Spur (A)Order: (7) Result to: (V)
Transpose (W,v+1)
Absmax (A,N,M,Yy,|,K)
Innerproduct (A [t,P,u] ,B [P],10,P,Y)
These examples correspond to examples given in section 5.4.2.
39
4.7.3 Semantics
A procedure statement serves to invoke (call for) the execution of a procedure body (cf. section 5.4 Procedure Declara-
tions). Where the procedure body is a statement written in ALGOL the effect of this execution will be equivalent to the
effect of performing the following operations on the program at the time of execution of the procedure statement:
4.7.3.1 Value assignment (call by value)
All formal parameters quoted in the value part of the procedure declaration heading are assigned the values (cf. sec-
tion 2.8. Values and Types) of the corresponding actual parameters, these assignments being considered as being per-
formed explicitly before entering the procedure body. The effect is as though an additional block embracing the procedure
body were created in which these assignments were made to variables local to this fictitious block with types as given in
the corresponding specifications (cf. section 5.4.5). As a consequence, variables called by value are to be considered as
nonlocal to the body of the procedure, but local to the fictitious block (cf. section 5.4.3).
4.7.3.2 Name replacement (call by name)
Any formal parameter not quoted in the value list is replaced, throughout the procedure body by the corresponding
actual parameter, after enclosing this latter in parentheses wherever syntactically possible. Possible conflicts between
identifiers inserted through this process and other identifiers already present within the procedure body will be avoided
by suitable systematic changes of the formal or local identifiers involved.
4.7.3.3 Body replacement and execution
Finally the procedure body, modified as above, is inserted in place of the procedure statement and executed. If the pro-
cedure is called from a place outside the scope of any nonlocal quantity of the procedure body the conflicts between
the identifiers inserted through this process of body replacement and the identifiers whose declarations are valid at the
place of the procedure statement or function designator will be avoided through suitable systematic changes of the
latter identifiers.
4.7.4 Actual-formal correspondence
The correspondence between the actual parameters of the procedure statement and the formal parameters of the proce-
dure heading is established as follows: The actual parameter list of the procedure statement must have the same number
of entries as the formal parameter list of the procedure declaration heading. The correspondence is obtained by taking
the entries of these two lists in the same order.
4.7.5 Restrictions
For a procedure statement to be defined it is evidently necessary that the operations on the procedure body defined in
sections 4.7.3.1 and 4.7.3.2 lead to a correct ALGOL statement. This imposes the restriction on any procedure state-
ment that the kind and type of each actual parameter be compatible with the kind and type of the corresponding
formal parameter. Some important particular cases of this general rule are the following:
4.7.5.1 If a string is supplied as an actual parameter in a procedure statement or function designator, whose defining
procedure body is an ALGOL-60 statement (as opposed to non-ALGOL code, cf. section 4.7.8), then this string can
only be used within the procedure body as an actual parameter in further procedure calls. Ultimately it can only be used
by a procedure body expressed in non-ALGOL code.
4.75.2 A formal parameter which occurs as a left part variable is an assignment statement within the procedure body
and which is not called by value can only correspond to an actual parameter which is a variable (special case of expression).
40
4.7.5.3 A formal parameter which is used within the procedure body as an array identifier can only correspond to an
actual parameter which is an array identifier of an array of the same dimensions. In addition if the formal parameter is
called by value the local array created during the call will have the same subscript bounds as the actual array.
4.7.5.4 A formal parameter which is called by value cannot in general correspond to a switch identifier or a proce-
dure identifier or a string, because these latter do not possess values (the exception is the procedure identifier of a pro-
cedure declaration which has an empty formal parameter part (cf. Section 5.4.1) and which defines the value of a function
designator (cf. Section 5.4.4). This procedure identifier is in itself a complete expression).
4.7.5.5 Any tormal parameter may have restrictions on the type of the corresponding actual parameter associated with
it (these restrictions may, or may not, be given through specifications in the procedure heading). In the procedure state-
ment such restrictions must evidently be observed.
4.7.5 Restrictions
A maximum of 63 formal parameters may be included -in a procedure declaration (Section 5. 4. 3);
therefore, a maximum of 63 actual parameters may be included in a procedure call. No more than
62 constants may be used as actual parameters.
4.7.6 Deleted
4.7.7 Parameter delimiters
All parameter delimiters are understood to be equivalent. No correspondence between the parameter delimiters used in
a procedure statement and those used in the procedure heading is expected beyond their number being the same. Thus
the information conveyed by using the elaborate ones is entirely optional.
4.7.8 Procedure body expressed in code
The restrictions imposed on a procedure statement calling a procedure having its body expressed in non-ALGOL code
evidently can only be derived from the characteristics of the code used and the intent of the user and thus fall outside
the scope of the reference language.
4.7.8 Procedure Body Expressed in Code
The symbol code is included to permit reference to procedures which are compiled separately from
the program or procedure in which they are referenced (Section 5.4.6).
b. Declarations
Declarations serve to define certain properties of the quantities used in the program, and to associate them with identifiers.
A declaration of an identifier is valid for one block. Outside this block the particular identifier may be used for other
purposes (cf. section 4.1.3). Dynamically this implies the following: at the time of an entry into a block (through the
begin, since the labels inside are local and therefore inaccessible from outside) all identifiers declared for the block assume
the significance implied by the nature of the declarations given. If these identifiers had already been defined by other
declarations outside they are for the time being given a new significance. Identifiers which are not declared for the
block, on the other hand, retain their old meaning.
At the time of an exit from a block (through end, or by a go to statement) all identifiers which are declared for the block
lose their local significance.
A declaration may be marked with the additional declarator own. This has the following effect: upon a re-entry into
the block, the values of own quantities will be unchanged from their values at the last exit, while the values of declared
41
variables which are not marked as own are undefined. Apart from labels and formal parameters of procedure declarations
and with the possible exception of those for standard functions (cf. sections 3.2.4 and 3.2.5), all identifiers of a program
must be declared. No identifier may be declared more than once in any one block head.
Syntax
< declaration > :: = < type declaration >| < array declaration > | < switch declaration >| < procedure
declaration >
5.1 Type Declarations
5.1.1 Syntax
< type list > ::= < simple variable >|
< simple variable > , < type list >
< type > ::= real | integer | Boolean
< local or own type > ::= < type >| own < type >
< type declaration > ::= < local or own type > < type list >
5.1.2 Examples
integer p.q,s
own Boolean Acryl, n
5.1.3 Semantics
Type declarations serve to declare certain identifiers to represent simple variables of a given type. Real declared variables
may only assume positive or negative values including zero. Integer declared variables may only assume positive and
negative integral values including zero. Boolean declared variables may only assume the values true and false.
In arithmetic expressions any position which can be occupied by a real declared variable may be occupied by an integer
declared variable.
For the semantics of own, see the fourth paragraph of section 5 above.
5.1.3 Semantics 6000 Series
Variables of type real and integer are represented internally in a 60-bit floating-point form, with a
48-bit coefficient, sign bit, and 11-bit biased exponent, so that the range of non-zero real and integer
variables is:
3.1 * 101 (-294) = (2 148 - 1) * 2 1 (-1022)
abs(real)
abs (integer)
(2 t48 - 1) * 2 11022 = 1.3 * 10 | 322
42
Real and integer values with up to 14 (and some with 15) significant decimal digits can be represented.
A zero real or integer value is represented by 60 zero bits in fixed-point form.
Real and integer numbers (Section 2. 5. 4) have the same range of values and are represented in the
same form as real and integer variables. In the evaluation of arithmetic expressions (Section 3.3.4)
and their assignment to variables of different type (Section 4.2.4), conversion from real to integer is
performed by closed subroutines at compile-time and in line code at object-time. No conversion is
required from integer to real because of their identical internal representations.
This conversion selects from the real value an integer value according to the rule:
ENTIER (real value + 0. 5)
Variables of type Boolean are represented in 60-bit fixed-point form; only the high order bit is
significant:
true ::=high-order bit =1
false : : = high-order bit = 0
5.1.3 Semantics 3000 series
Variables of type integer are represented internally in 48-bit fixed-point form in the range:
0 <abs(integer) <2 1 47 =140, 737, 488, 355, 328
Thus, all integers with up to 14 (and some with 15) significant decimal digits can be represented. Numbers of type integer
(Section 2.5.4) are represented in the same internal form as integer variables. Only 14 significant decimal digits are con-
sidered when the number is formed. Variables of type real are represented internally in normal 48-bit floating-point form
with a 36-bit coefficient, sign bit, and 11-bit biased exponent, so that the range of non-zero real variables is
10 4 (-308) = 2 $ (-1023) < abs(real) <2 $ 1023 = 10 $ 308
All real values with up to 10 (and some with 11) significant decimal digits in the coefficient can be represented.
Numbers of type real (Section 2.5.4) are represented in the same internal form as real variables and have the same range
of values. A zero real value is represented by 48 zero bits in fixed-point form.
Conversion from type real to type integer, and vice versa, as required in the evaluation of arithmetic expressions (Sec-
tion 3.3.4) and their assignment to variables of different type (Section 4.2.4), is performed by closed subroutines both
at compile-time and at object-time.
Note: in lower 3000 only, constant expressions are not evaluated at compile-time.
A conversion from real to integer selects from the real value an integer value according to the rule
SIGN(x) * ENTIER ( ABS(x) + 0.5)
where x is the real value. The report calls for the selection of the integer according to the rule:
ENTIER (x + 0.5)
43
The two rules are identical, except when x = — mm ,n=0,1,2...(e.g. x =-0.5, —1.5, —2.5, etc.)
A conversion error arises if the result exceeds 48-bit fixed-point form. At compile-time, the diagnostic FLOAT-TO-FIX
ERROR is issued, and at object-time, the program terminates abnormally with the same diagnostic.
A conversion from integer to real changes only the representation of the value from fixed-point to floating-point form.
A loss of low order accuracy in the converted ( real) result occurs if the integer value is greater than or equal to 2 1 36.
Variables of type Boolean are represented in 48-bit fixed-point form, (in lower 3000, only upper 24-bits are significant)
with zero and non-zero values corresponding to false and true, respectively. In Booleans generated by the system, the
zero and non-zero values are:
Upper 3000 Lower 3000
true — .:=0000000000000001s true ::= 00000001 xxxxxxxx
false ::= 0000000000000000 false ::= 00000000 xxxxxxxx
The values of own variables are global to the whole program because of their assigned position in the
object program stack. They are, however, accessible only in the block in which they are declared in
the same way as any other declared variable.
5.2 Array Declarations
5.2.1 Syntax
< lower bound > ::= < arithmetic expression >
< upper bound > ::= < arithmetic expression >
< bound pair > ::= < lower bound > : < upper bound >
< bound pair list > ::= < bound рай >| < bound pair list > , < bound pair >
< array segment > :: = < array identifier > [ < bound pair list > ] |< array identifier > , < array segment >
< array list > !: = < array segment >| < array list > , < array segment >
< array declaration > ::= array < array list >| < local or own type > array < array list >
5.2.2 Examples
array a,b,c [7:n,2:m],s [-2:10]
own integer array A Lif c < O then 2 else 1:20]
real array q [-7:-1]
5.2.3 Semantics
An array declaration declares one or several identifiers to represent multidimensional arrays of subscripted variables and
gives the dimensions of the arrays, the bounds of the subscripts and the types of the variables.
44
5.2.3.1 Subscript bounds. The subscript bounds for any array are given in the first subscript bracket following the
identifier of this array in the form of a bound pair list. Each item of this list gives the lower and upper bound of a sub-
script in the form of two arithmetic expressions separated by the delimiter : The bound pair list gives the bounds of all
subscripts taken in order from left to right.
5.2.3.2 Dimensions. The dimensions are given as the number of entries in the bound pair lists.
5.2.3.3 Types. All arrays declared in one declaration are of the same quoted type. If no type declarator is given the type
real is understood.
5.2.3 Semantics
own arrays with dynamic bounds (bounds which are not constants in the program) are not permitted.
Thus, the following declaration, given as an example in Section 5.2.2, is illegal.
own integer array A if [C<0 then 2 else 1:20]
In lower 3000 only, own variables are not permitted in separately compiled procedures.
5.2.4 Lower upper bound expressions
5.2.4.1 The expressions will be evaluated in the same way as subscript expressions (cf. section 3.1.4.2).
5.2.4.2 The expressions can only depend on variables and procedures which are nonlocal to the block for which the
array declaration is valid. Consequently in the outermost block of a program only array declarations with constant
bounds may be declared.
5.2.4.3 An array is defined only when the values of all upper subscript bounds are not smaller than those of the corre-
sponding lower bounds.
5.2.4.4 The expressions will be evaluated once at each entrance into the block.
5.2.5 The identity of subscripted variables
The identity of a subscripted variable is not related to the subscript bounds given in the array declaration. However, even
if an array is declared own the values of the corresponding subscripted variables will, at any time, be defined only for
those of these variables which have subscripts within the most recently calculated subscript bounds.
5.3 Switch Declarations
5.3.1 Syntax
< switch list > :.:= < designational expression >| < switch list > , < designational expression >
< switch declaration > ::= switch < switch identifier > := < switch list >
5.3.2 Examples
switch $ := S1,52,Q [m] , if v > —5 then S3 else S4
switch Q:= p1,w
45
b.3.3 Semantics
A switch declaration defines the set of values of the corresponding switch designators. These values are given one by one
‘as the values of the designational expressions entered in the switch list. With each of these designational expressions
there is associated a positive integer, 1,2, . . ., obtained by counting the items in the list from left to right. The value of
the switch designator corresponding to a given value of the subscript expression (cf. section 3.5. Designational Expres-
sions) is the value of the designational expression in the switch list having this given value as its associated integer.
5.3.4 Evaluation of expressions in the switch list
An expression in the switch list will be evaluated every time the item of the list in which the expression occurs is referred
to, using the current values of all variables involved.
5.3.5 Influence of scopes
If a switch designator occurs outside the scope of a quantity entering into a designational expression in the switch list,
and an evaluation of this switch designator selects this designational expression, then the conflicts between the identifiers
for the quantities in this expression and the identifiers whose declarations are valid at the place of the switch designator
will be avoided through suitable systematic changes of the latter identifiers.
5.4 Procedure Declarations
5.4.1 Syntax
< formal parameter > :. = < identifier >>
< formal parameter list > ::= < formal parameter >|
< formal parameter list > < parameter delimiter >
< formal parameter >
< formal parameter part > ::= < empty >| ( < formal parameter list > )
< identifier list > ::= < identifier >| < identifier list > , < identifier >
< value part > ::= value < identifier list > ; | < empty >
< specifier > ::= string | < type >| array|< type > array| label | switch |
procedure | < type > procedure
< specification part > ::= < empty >| < specifier > < identifier list > ; |
< specification part > < specifier > < identifier list > ;
< procedure heading > ::= < procedure identifier >
< formal parameter part > ; < value part > < specification part >
< procedure body > ::= < statement >| < code >
46
< procedure declaration >::=
procedure < procedure heading >< procedure body >|
< type > procedure < procedure heading > < procedure body >
5.4.2 Examples (see also the examples at the end of the report)
procedure Spur (a) Order: (n) Result: (s) ; value n ;
array a ; integer n ; real s ;
begin integer k ;
s:=0:
for k := 1 step 1 until n do \s!:= s+a [kk]
end
procedure Transpose (a) Order:(n) ; value n ;
array a ;integer n ;
begin real w ; integer ik ;
for i := 1 step 1 until n do
for k := 1+i step 1 until n do
begin w : = a [ik];
a [i,k] :=a[k,i] :
a [k,i] := w
end
end Transpose
integer procedure Step (u) ; real u ;
Step := if OSu/Au< 1 then 1 else 0
procedure Absmax (a) size: (n,m) Result: (y) Subscripts: (i,k) ;
comment The absolute greatest element of the matrix a, of size n by m is transferred to y, and the subscripts of this
element toi and k ;
array a ; integer n,m,i,k ; real y ;
begin integer p,q ;
y:=0;
for p := 1 step 1 until n do for q := 1 step 1 until m do
if abs (a[p,q] ) >y then begin y : = abs (alp,q]) ;i:=p ;
k:=q
end end Absmax
procedure Innerproduct(a,b) Order: (k,p)Result:(y) ; value k ;
integer k,p ;realy,ab ;
begin real s ;
$:= 0;
for p := 1 step 1 until k do s :=s+aXb ;
y :=s
end Innerproduct
47
0.4.1 Syntax
The following definition of <code> is added:
<d> :: = <digit>
<code number> : : = <d> | <d><d> | <d><d> <d> |<d><d> <d><d> | <d> <d> <d> <d> <d>
<code> :: = code <code number>
b.4.3 Semantics
A procedure declaration serves to define the procedure associated with a procedure identifier. The principal constituent
of a procedure declaration is a statement or a piece of code, the procedure body, which through the use of procedure
statements and/or function designators may be activated from other parts of the block in the head of which the proce-
dure declaration appears. Associated with the body is a heading, which specifies certain identifiers occurring within the
body to represent formal parameters. Formal parameters in the procedure body will, whenever the procedure is activated
(cf. section 3.2 Function Designators and section 4.7. Procedure Statements) be assigned the values of or be replaced
by actual parameters. Identifiers in the procedure body which are not formal will be either local or nonlocal to the body
depending on whether they are declared within the body or not. Those of them which are nonlocal to the body may
well be local to the block in the head of which the procedure declaration appears. The procedure body always acts like
a block, whether it has the form of one or not. Consequently the scope of any label labelling a statement within the
body or the body itself can never extend beyond the procedure body. In addition, if the identifier of a formal parameter
is declared anew within the procedure body (including the case of its use as a label as in section 4.1.3), it is thereby given
a local significance and actual parameters which correspond to it are inaccessible throughout the scope of this inner
local quantity.
5.4.3 Semantics
The maximum number of formal parameters permitted in the declaration of a procedure is 63. A
‘source procedure (Chapter 4) may employ the same features as a procedure declared in a source pro-
gram, except it may not be formally recursive. That is, there may be no occurrence of the procedure
identifier within the body of the procedure other than as a left part in an assignment statement.
5.4.4 Values of function designators
For a procedure declaration to define the value of a function designator there must, within the procedure body, occur
one or more explicit assignment statements with the procedure identifier in a left part; at least one of these must be
executed, and the type associated with the procedure identifier must be declared through the appearance of a type dec-
larator as the very first symbol of the procedure declaration. The last value so assigned is used to continue the evaluation
of the expression in which the function designator occurs. Any occurrence of the procedure identifier within the body
of the procedure other than in a left part in an assignment statement denotes activation of the procedure.
5.4.5 Specifications
In the heading a specification part, giving information about the kinds and types of the formal parameters by means of
an obvious notation, may be included. In this part no formal parameter may occur more than once. Specifications of
formal parameters called by value (cf. section 4.7.3.1) must be supplied and specifications of formal parameters called
by name (cf. section 4.7.3.2) may be omitted.
48
5.4.5 Specifications
The last sentence should be changed to read: "...and specifications of all formal parameters, if any,
must be supplied."
5.4.6 Code as procedure body
It is understood that the procedure body may be expressed in non-ALGOL language. Since it is intended that the use of
this feature should be entirely a question of hardware representation, no further rules concerning this code language can
be given within the reference language.
5.4.6 Code as a Procedure Body
All procedures, unless standard, must be declared in the program in which they are called. In particu-
lar, when a program references a separately compiled procedure, the program must contain a declara-
tion of that procedure. This declaration simply consists of a procedure heading and a code procedure
body. |
The procedure heading has the same format as a normal procedure heading (Section 5.4.1), and the
code procedure body (defined as <code> in Section 5.4.1) consists of the symbol code followed by a
number xxxxx in the range 0-99999. This is the same number associated with the procedure when it is
compiled separately as an ALGOL source procedure (Chapter 4) and the compiler uses this number to
link the declaration with the procedure. The procedure is linked to the main program at the object-
program level. The object code does not necessarily have to be produced by the compilation of an
ALGOL source procedure; it may be generated in any way provided that it conforms to the object code
produced by the compilation of an ALGOL source procedure.
The identifying name included in the procedure heading need not be the same as the name declared in a
separately compiled procedure, as linking is done by code number. However, all references in the
program to the procedure must use the name declared in the program rather than the name declared
in the separately declared procedure.
The names of the formal parameters in the procedure heading need not be the same as those declared
when the procedure is compiled separately, but the number of parameters must be the same. The
value part, if any, and the specification part may be omitted from the procedure heading unless the
procedure is compiled separately.
The above rules also apply to a separately compiled procedure which references another separately
compiled procedure. The referencing procedure must contain a declaration for the referenced pro-
cedure as described above.
In the following examples, the procedures AVERAGE and SQUAREAVERAGE may be compiled separately
from the program in which they are referenced.
49
The following examples illustrate the use of separately compiled procedures. In the first example, the
procedures AVERAGE and SQUAREAVERAGE are compiled in the original program. |
Example 1.
begin
real procedure AVERAGE (LOWER, UPPER);
value LOWER, UPPER;
real LOWER, UPPER;
begin AVERAGE:=(LOWER+UPPER)/2;
end;
real procedure SQUAREAVERAGE (LOW, HIGH);
value LOW, HIGH;
real LOW, HIGH;
begin SQUAREAVERAGE:=SQRT (LOW 12+HIGH 12)/2;
end;
real X, Y, 8, SQ;
S := 0;
SQ : = 0;
for X : = 1 step 1 until 100 do
Y;=X+1;
S : = S + AVERAGE (X, У);
SQ : = SQ + SQUAREAVERAGE (X, Y);
end;
end
50
In the second example the first procedure body is replaced by the symbol code with the identifying
number 129. In the heading, the identifying name AVERAGE has been changed to MEAN, and the
formal parameter names to A and B. References to this procedurc are to the name MEAN. The
procedure called AVERAGE should be compiled separately with the code number 129.
The source deck (Chapter 4) for this compilation is:
code 129;
real procedure AVERAGE (LOWER, UPPER);
value LOWER, UPPER;
real LOWER, UPPER;
begin AVERAGE : = (LOWER + UPPER)/2;
end;
followed by the 'EOP' indication in columns 10 through 14 of the next card.
The second procedure body is replaced by the symbol code and the identifying number 527. The pro-
cedure heading remains the same, except that the value and specification parts are omitted. Since the
identifying name is not changed, the procedure is referenced as before. The procedure called
SQUAREAVERAGE should be compiled separately with the code number 527.
Example 2.
real procedure MEAN (A, B):
value A, B:
real A, B;
code 129;
real procedure SQUAREAVERAGE (LOW, HIGH);
code 527;
real X, Y, S, SQ;
S: = 0;
SQ = 0;
for X : =1 step 1 until 100 do
Y :=X+ 1;
5: = 5 + МЕАЦМ (x, Y);
SQ : = SQ + SQUAREAVERAGE (X, Y);
end;
end
51
Examples of Procedure Declarations:
Example 1.
procedure euler (fct, sum, eps, tim) ; value eps, tim ;
integer tim ; real procedure fct ; real sum, eps ;
comment euler computes the sum of fct(i) for i from zero up to infinity by means of a suitably refined
euler transformation. The summation is stopped as soon as tim times in succession the absolute value of the
terms of the transformed series are found to be less than eps. Hence, one should provide a function fct with
one integer argument, an upper bound eps, and an integer tim. The output is the sum sum. euler is particularly
efficient in the case of a slowly convergent or divergent alternating series ;
begin integer i,k,n,t ; array m [0:15] ; real mnmpds ;
i:=n:=t:=0 :m[0]:=fct(0) ;sum:=ml[0]/2 ;
nextterm:i: =i+1 ;mn:=fct(i) ;
for k : = O step 1 until n do
begin mp : = (mn+m [k])/2 ;m{k] := mn ;
mn :=mpend means ;
if (abs(mn)<abs(m [n] )) A (n<15) then
begin ds : = mn/2 : n :=n+1 ; mÍ[n] :=
mn end accept
else ds := mn ;
sum : = sum + ds ;
if abs(ds) <eps then t : =t+1elset:=0 ;
if t<tim then go to nextterm
end euler
Example 2.1
procedure RK(x,y,n,FKT,eps,eta,xE,yE,fi) ; value x,y ;
integer n ; Boolean fi ; real x,eps,eta,xE ; array
y.yE ; procedure FKT :
TThi - am contains some new ideas which are related to ideas of S. Gill, À process for the step-by-step integra-
e edifferonti b. Phil. Soc. 47 (1951), 96] ; and E. Froberg,
tion of differential equations in an automatic computing machine, [Proc. Cam - ” -
On the solution of ordinary differential equations with digital computing machines, [Fysiograf. Sallsk » Lund, Forhd.
20,11 (1950), 136-152] . It must be clear, however, that with respect to computing time and round-off errors it may
not be optimal, nor has it actually been tested on a computer.
52
comment: RK integrates the system Yk'= fk(X,y Yo, --. Yn) (kK=1,2,... 1) of differential equations with the
method of Runge-Kutta with automatic search for appropriate length of integration step. Parameters are: The
initial values x and y [k] for x and the unknown functions y, (x). The order n of the system. The procedure
FKT(x,y,n,z) which represents the system to be integrated, i.e. the set of functions fr The tolerance values eps
and eta which govern the accuracy of the numerical integration. The end of the integration internal xE. The output
parameter yE which represents the solution at x = xE. The Boolean variable fi, which must always be given the
value true for an isolated or first entry into RK. If however the functions y must be available at several meshpoints
X0.X4- - - - + Xp. then the procedure must be called repeatedly (with X=xXy XE=X} 11, for k=0,1,...,n-1) and then
the later calls may occur with fi=false which saves computing time. The input parameters of FKT must be x,y,n,
the output parameter z represents the set of derivatives z[k] =f (x,y[1] ,Y [2],...,y[n]) for x and the actual y's.
A procedure comp enters as a nonlocal identifier ;
begin
array z,y1,y2,y3[1:n] ; real x1,x2,x3,H ; Boolean out ;
integer k,j ; own real s,Hs ;
procedure RK1ST (x,y,h,xe,ye) ;real x,h,xe ¡array
y.ye ;
comment: RK1ST integrates one single RUNGE-KUTTA with initial values x,y[k] which yields the output param-
eters xe=x+h and ye[k], the latter being the solution at xe. Important: the parameters n, FKT, z enter RK1ST as
nonlocal entities ;
begin
array w[1:n],al1:5) ; integer k,j ;
a[1] :=a[2] := a[5] := h/2 ;a[3] := a[4] :=h ;
Xe :=x ;
for k : = 1 step 1 until n do ye[k] :=w[k] :=y[k] ;
for j:=1 step 1 until 4 do
begin
FKT(xe,w,n,z) ;
xe :=xtalj] ;
for k : = 1 step 1 until n do
53
begin
wlk}: =y[kl+aljl X z[k] ;
ye[k] :=ye[k] +a[j+1] Xz[k]/3
end k
end j
end RK1ST ;
Begin of program:
if fi then begin H : = xE-x ;s : = 0 end else H : = Hs
out := false ;
AA:if(x+2.01 XH-xE>0)=(H>0) then
begin Hs :=H ; out:=true ;H:=(xE-x)/2
end if ;
RK1ST (x,y,2XH,x1,y1) ;
BB:RK1ST (x,y,H,x2,y2) ; RK1ST (x2,y2,H,x3.y3) ;
for k : = 1 step 1 until n do
if comp(y1[k] y3[k] ,eta) >eps then go to CC ;
comment: comp(a,bc,) is a function designator, the value of which is the absolute value of the difference of the
mantissae of a and b, after the exponents of these quantities have been made equal to the largest of the exponents
of the originally given parameters a,b,c ;
x:=x3 ;if out then go to DD ;
for k : = 1 step 1 until n do y[k] : = y3[k] ;
if s=5 then begin s : =0 ;H:=2XHend if ;
CC:H:=05XH ;out:=false ;x1:=x2 ;
for k : = 1 step 1 until n do y1[k] : = y2[k]
go to BB ;
DD: for k:=1 step 1 until n do yE[k] : = y3[k]
end RK
ALPHABETIC INDEX OF DEFINITIONS OF CONCEPTS AND SYNTACTIC UNITS
All references are given through section numbers. The references are given in three groups:
def Following the abbreviation “def”, reference to the syntactic definition {if any) is given.
synt Following the abbreviation ‘’synt’’, references to the occurrences in metalinguistic formulae are given.
References already quoted in the def-group are not repeated.
text Following the word “text”, the references to definitions given in the text are given.
The basic symbols represented by signs other than underlined words have been collected at the beginning.
The examples have been ignored in compiling the index.
+, see: plus
—, See: minus
X, see: multiply
/, +, see: divide
T, see: exponentiation
<, <, =, 7, >, +, see: <relational operator >
=, 53, V,A,—, see: <logical operator >
,, See: comma
., see: decimal point
107 See: ten
:, see: colon
‚‚ see: semicolon
:=, see: colon equal
LI, see: space
( ), see: parentheses
[ ], see: subscript brackets
‘? see: string quotes
< actual parameter >, def 3.2.1, 4.7.1
< actual parameter list >, def 3.2.1, 4.7.1
< actual parameter part >, def 3.2.1, 4.7.1
< adding operator >, def 3.3.1
alphabet, text 2.1
arithmetic, text 3.3.6
< arithmetic expression >>, def 3.3.1 synt 3, 3.1.1,
3.3.1, 3.4.1, 4.2.1, 4.6.1, 5.2.1 text 3.3.3
< arithmetic operator >, def 2.3 text 3.3.4
array, synt 2.3, 5.2.1, 5.4.1
array, text 3.1.4.1
< array declaration >, def 5.2.1 synt 5 text 5.2.3
< array identifier >, def 3.1.1 synt 3.2.1, 4.7.1,
5.2.1 text 2.8
< array list >, def 5.2.1
< array segment >, def 5.2.1
< assignment statement >, def 4.2.1 synt 4.1.1
text 1, 4.2.3
< basic statement >, def 4.1.1 synt 4.5.1
< basic symbol >, def 2
begin, synt 2.3, 4.1.1
< block >, def 4.1.1 synt 4.5.1 text 1, 4.1.3, 5
< block head >, def 4.1.1
Boolean, synt 2.3, 5.1.1 text 5.1.3
< Boolean expression >, def 3.4.1 synt 3, 3.3.1, 4.2.1, 4.5.1
4.6.1 text 3.4.3
< Boolean factor >, def 3.4.1
< Boolean primary >, def 3.4.1
< Boolean secondary >, def 3.4.1
< Boolean term >, def 3.4.1
< bound pair >, def 5.2.1
< bound pair list >, def 5.2.1
< bracket >, def 2.3
,
< code >, synt 5.4.1 text 4.7.8, 5.4.6
colon : , synt 2.3, 3.2.1, 4.1.1, 4.5.1, 4.6.1, 4.7.1, 5.2.1
colon equal :=, synt 2.3, 4.2.1, 4.6.1, 5.3.1
comma, , synt 2.3, 3.1.1, 3.2.1, 4.6.1, 4.7.1, 5.1.1, 5.2.1,
5.3.1, 5.4.1
95
comment, synt 2.3
comment convention, text 2.3
< compound statement >, def 4.1.1 synt 4.5.1 text 1
< compound tail >, def 4.1.1
< conditional statement >, def 4.5.1 synt 4.1.1 text 4.5.3
< decimal fraction >, def 2.5.1
< decimal number >, def 2.5.1 text 2.5.3
decimal point ., synt 2.3, 2.5.1,
label, synt 2.3, 5.4.1
< label >, def 3.5.1 synt 4.1.1, 4.5.1, 4.6.1 text 1, 4.1.3
< left part >, def 4.2.1
< left part list >, def 4.2.1
< letter >, def 2.1 synt 2, 2.4.1, 3.2.1, 4.7.1
< letter string >, def 3.2.1, 4.7.1
local, text 4.1.3
< local or own type >, def 5.1.1 synt 5.2.1
< logical operator >, def 2.3 synt 3.4.1 text 3.4.5
< logical value >, def 2.2.2 synt 2, 3.4.1
< declaration >, def 5 synt 4.1.1 text 1, 5 (complete section) < lower bound >, def 5.2.1 text 5.2.4
< declarator >, def 2.3
< delimiter >, def 2.3 synt 2
< designational expression >, def 3.5.1 synt 3, 4.3.1., 5.3.1
text 3.5.3
< digit >, def 2.2.1 synt 2, 2.4.1, 2.5.1
dimension, text 5.2.3.2
divide / +, synt 2.3, 3.3.1 text 3.3.4.2
do, synt 2.3, 4.6.1
< dummy statement >, def 4.4.1 synt 4.1.1 text 4.4.3
else, synt 2.3, 3.3.1, 3.4.1, 3.5.1, 4.5.1 text 4.5.3.2
< empty >, def 1.1 synt 2.6.1, 3.2.1, 4.4.1, 4.7.1, 5.4.1
end, synt 2.3, 4.1.1
entier, text 3.2.5
exponentiation * , synt 2.3, 3.3.1 text 3.3.4.3
<_ exponent part >, def 2.5.1 text 2.5.3
< expression >, def 3 synt 3.2.1, 4.7.1 text 3 (complete
section)
< factor >, def 3.3.1
false, synt 2.2.2
for, for, synt 2.3, 4.6.1
< for clause >, def 4.6.1 text 4.6.3
< for list >, def 4.6.1 text 4.6.4 |
< for list element >, def 4.6.1 text 4.6.4.1, 4.6.4.2, 4.6.4.3
< formal parameter >, def 5.4.1 text 5.4.3
< formal parameter list >, def 5.4.1
< formal parameter part >, def 5.4.1
< for statement >, def 4.6.1 synt 4.1.1, 4.5.1 text 4.6
(complete section)
< function designator >, def 3.2.1 synt 3.3.1, 3.4.1
text 3.2.3, 5.4.4
go to, synt 2.3, 4.3.1
< go to statement >, def 4.3.1 synt 4.1.1 text 4.3.3
<_ identifier >, def 2.4.1 synt 3.1.1, 3.2.1, 3.5.1, 5.4.1
text 2.4.3
<_ identifier list >, def 5.4.1
if, synt 2.3, 3.3.1, 4.5.1
< if clause >, def 3.3.1, 4.5.1 synt 3.4.1, 3.5.1
text 3.3.3, 4.5.3.2
< if statement >, def 4.5.1 text 4.5.3.1
< implication >, def 3.4.1
integer, synt 2.3, 5.1.1 text 5.1.3
< integer >, def 2.5.1 text 2.5.4
minus —, synt 2.3, 2.5.1, 3.3.1 text 3.3.4.1
multiply X, synt 2.3, 3.3.1 text 3.3.4.1
< multiplying operator >, def 3.3.1
nonlocal, text 4.1.3
< number >, def 2.5.1 text 2.5.3, 2.5.4
< open string >, def 2.6.1
< operator >, def 2.3
own, synt 2.3, 5.1.1 text 5, 5.2.5
< parameter delimiter >, def 3.2.1, 4.7.1 synt 5.4.1
text 4.7.7
parentheses ( ), synt 2.3, 3.2.1, 3.3.1, 3.4.1, 3.5.1,
4.7.1, 5.4.1 text 3.3.5.2
plus + ‚ synt 2.3, 2.5.1, 3.3.1 text 3.3.4.1
< primary >, def 3.3.1
procedure, synt 2.3, 5.4.1
< procedure body >, def 5.4.1
< procedure declaration >, def 5.4.1 synt 5 text 5.4.3
< procedure heading >, def 5.4.1 text 5.4.3
< procedure identifier >, def 3.2.1 synt 3.2.1, 4.7.1,
5.4.1 text 4.7.5.4
< procedure statement >, def 4.7.1 synt 4.1.1 text 4.7.3
< program >, def 4.1.1 text 1
< proper string >, def 2.6.1
quantity, text 2.7
real, synt 2.3, 5.1.1 text 5.1.3
< relation >, def 3.4.1 text 3.4.5
< relational operator >, def 2.3, 3.4.1
scope, text 2.7
semicolon ; , synt 2.3, 4.1.1, 5.4.1
< separator >, def 2.3
< sequential operator >, def 2.3
< simple arithmetic expression >, def 3.3.1 text 3.3.3
< simple Boolean >, def 3.4.1
< simple designational expression >, def 3.5.1
< simple variable >, def 3.1.1 synt 5.1.1 text 2.4.3
space LI, synt 2.3 text 2.3, 2.6.3
< specification part >, def 5.4.1 text 5.4.5
< specificator >, def 2.3
< specifier >, def 5.4.1
standard function, text 3.2.4, 3.2.5
< statement >, def 4.1.1, synt 4.5.1, 4.6.1, 5.4.1 text 4
(complete section)
statement bracket, see: begin end
step, synt 2.3, 4.6.1 text 4.6.4.2
string, synt 2.3, 5.4.1
< string >, def 2.6.1 synt 3.2.1, 4.7.1 text 2.6.3
string quotes “ ?, synt 2.3, 2.6.1, text 2.6.3
subscript, text 3.1.4.1
subscript bound, text 5.2.3.1
subscript brackets [ ], synt 2.3, 3.1.1, 3.5.1, 5.2.1
< subscripted variable >, def 3.1.1 text 3.1.4.1
< subscript expression >, def 3.1.1 synt 3.5.1
< subscript list >, def 3.1.1
successor, text 4
switch, synt 2.3, 5.3.1, 5.4.1
< switch declaration >, def 5.3.1 synt 5 text 5.3.3
< switch designator >, def 3.5.1 text 3.5.3
< switch identifier >, def 3.5.1 synt 3.2.1, 4.7.1, 5.3.1
< switch list >, def 5.3.1
< term >, def 3.3.1
ten 10, synt 2.3, 2.5.1
then, synt 2.3, 3.3.1, 4.5.1
transfer function, text 3.2.5
true, synt 2.2.2
< type >, def 5.1.1 synt 5.4.1 text 2.8
< type declaration >, def 5.1.1 synt 5 text 5.1.3
< type list >, def 5.1.1
< unconditional statement >, def 4.1.1, 4.5.1
< unlabelled basic statement >, def 4.1.1
< unlabelled block >, def 4.1.1
< unlabelled compound >, def 4.1.1
< unsigned integer >, def 2.5.1, 3.5.1
< unsigned number >, def 2.5.1 synt 3.3.1
until, synt 2.3, 4.6.1 text 4.6.4.2
< upper bound >, def 5.2.1 text 5.2.4
value, synt 2.3, 5.4.1
value, text 2.8, 3.3.3
< value part >, def 5.4.1 text 4.7.3.1
< variable >, def 3.1.1 synt 3.3.1, 3.4.1, 4.2.1, 4.6.1
text 3.1.3
< variable identifier >, def 3.1.1
while, synt 2.3, 4.6.1 text 4.6.4.3
END OF THE REPORT
57
INPUT-OUTPUT 3
The processes of input and output deal with the mapping of basic characters onto input and output
devices under the control of format rules. Characters are grouped to form lines, and lines are
grouped to form pages. A page consists of printed lines and a line may be a printed line or card
image.
The relation between lines and pages and physical entities (such as records and blocks) depends on
formatting rules, channel specifications (B.1.1), standard operating system input-output, and the
physical device involved in the input-output process. The user need not, in general, be aware of the
details of this relationship, since the input-output process is symmetric. Given the same specifica-
tions, a file output by the system is disassembled into the same lines and pages as input by the system.
3.1 COMPARISON WITH ACM PROPOSAL FOR INPUT-OUTPUT
The following descriptions explain the differences between the input-output procedures included in
ALGOL and the procedures defined in the ACM proposal. T To facilitate cross referencing, the same
numbering system is used in this chapter as in the proposal. The ACM proposal is a continuation of
the ALGOL-60 Revised Report, and should be considered a continuation of Chapter 2 of this manual.
All descriptions of the modifications to the input-output procedures are made at the main reference in
the proposal; and wherever feasible, all other references are noted. The reader should assume, how-
ever, that such modifications apply to all references to the features, noted or otherwise.
A section or feature not mentioned in this chapter is implemented, in this version of ALGOL, in exact
accordance with the proposal,
This chapter also contains descriptions of additional input-output procedures which are not defined in
the ACM proposal, and a description of the transmission error, end-of-file, and end-of-tape functions
automatically supplied within the framework of the input-output procedures.
Tua Proposal for Input-Output Conventions in ALGOL-60", published in The Communications of the
ACM, vol. 7 no. 5, May 1964.
58
A Proposal for Input-Output Conventions in ALGOL-60
A Report of the Subcommittee on ALGOL of the ACM Programming Languages Committee
D. E. Knuth, Chairman
L. L. Bumgarner P.Z. Ingerman J.N.Merner
D. E. Hamilton M.P. Lietzke D. T. Ross
The ALGOL-60 language as first defined made no explicit reference to input and output processes. Such processes
appeared to be quite dependent on the computer used, and so it was difficult to obtain agreement on those matters. As
time has passed, a great many ALGOL compilers have come into use, and each compiler has incorporated some input-
output facilities. Experience has shown that such facilities can be introduced in a manner which is compatible and con-
sistent with the ALGOL language, and which (more importantly) is almost completely machine-independent. However,
the existing implementations have taken many different approaches to the subject, and this has hampered the inter-
change of programs between installations. The ACM ALGOL committee has carefully studied the various proposals in
an attempt to define a set of conventions for doing input and output which would be suitable for use on most computers.
The present report constitutes the recommendations of that committee.
The input-output conventions described here do not involve extensions or changes to the ALGOL-60 language. Hence
they can be incorporated into existing processors with a minimum of effort. The conventions take the form of a set of
procedures, | which are to be written in code for the various machines; this report discusses the function and use of these
procedures. The material contained in this proposal is intended to supplement the procedures in real, out real, in
symbol, out symbol which have been defined by the international ALGOL committee; the procedures described here
could, with trivial exceptions, be expressed in terms of these four.
The first part of this report describes the methods by which formats are represented; then the calls on the input and
output procedures themselves are discussed. The primary objective of the present report is to describe the proposal
concisely and precisely, rather than to give a programmer’s introduction to the input-output conventions. A simpler and
more intuitive (but less exact) description can be written to serve as a teaching tool.
Many useful ideas were suggested by input-output conventions of the compilers listed in the references below. We are
also grateful for the extremely helpful contributions of F. L. Bauer, M. Paul, H. Rutishauser, K. Samelson, G. Seegmuller,
W. L. v.d. Poel, and other members of the European computing community, as well as A. Evans, Jr., R. W. Floyd,
A. G. Grace, J. Green, G. E. Haynam, and W. C. Lynch of the USA.
A. Formats
In this section a certain type of string, which specifies the format of quantities to be input or output, is defined, and its
meaning is explained.
A.1 Number Formats (cf. ALGOL Report 2.5)
A.1.1 Syntax
Basic components:
< replicator > :: = < unsigned integer >| X
< insertion > ::= B| < replicator > B| < string >
1 Throughout this report, names of system procedures are in lower case, and names of procedures used in illustrative
examples are in upper case. (NOTE: Additional input-output procedures provided by CONTROL DATA
are in upper case.)
2 Defined at meeting IFIP/WG2.1 — ALGOL in Delft during September, 1963.
59
< insertion sequence > ::= < empty >| < insertion sequence > < insertion >
< 2 >= Z|<replicator > Z| Z < insertion sequence > C| < replicator >
Z < insertion sequence > C
<£Z part >: = < 7 >| <Z part > < Z >| < Z part > < insertion >
<D >: =D | <replicator > D| D < insertion sequence > C|
< replicator > D < insertion sequence >> C
<Dpart>:.=< D >| < D part > < D>| < D part >< insertion >
< T part > = < empty >| T < insertion sequence >
< sign part > .:= < empty >| < insertion sequence > + |
< insertion sequence > —
< integer part >: = < Z part >| < D part >| < Z part > < D part >
Format Structures:
< unsigned integer format > :: = < insertion sequence > < integer part >
< decimal fraction format > ::= . < insertion sequence > < D part >
< T part >| V < insertion sequence > < D part >< T part >
< exponent part format > ::= 10 <sign part > < unsigned integer format >
< decimal number format > ::= < unsigned integer format > < T part >|
< insertion sequence > < decimal fraction format >|
< unsigned integer format >> < decimal fraction format >
< number format > ::= < sign part > < decimal number format > |
< decimal number format > + < insertion sequence >|
< decimal number format > — < insertion sequence >|
< sign part > < decimal number format > < exponent part format >
Note. This syntax could have been described more simply, but the rather awkward constructions here have been for-
mulated so that no syntactic ambiguities (in the sense of formal language theory) will exist.
A.1.2 Examples. Examples of number formats appear in Figure 1.
60
The letter C is not implemented. All references to C in the ACM Report should be disregarded, e.g.,
<Z>::=Z |<replicator> Z | Z <insertion sequence> C | <replicator> Z <insertion sequence>C will be
implemented as follows:
<Z>::=Z | <replicator> Z
Number format
+ZZZCDDD.DD
+3ZC3D.2D
—3D2B3D.2DT
52.50 —
“integer. .part. )? —4ZV
‘,Uifraction’B3D
—5D 10+2D°. .
+ZD 102Z
+D.DDBDDBDDB 10
+DD
XB.XD 10—DDD
Result from 13.296
—013.30
—013.30
—000 013.29
13.29600—
integer part —13,
fraction 296
—.13296 10402. . .
—13
—1.32 96 00 10+01
(depends on call)
IResult from 1007.999
+1,008.00
+1,008.00
001 007.99
1007.99900
integer part 1007,
fraction 999
‚1008010+04...
+1010 2
+1.00 79 99 10 +03
{depends on call)
Figure 1
Figure 1 (depends on call) - for definition of call see A.1.3.3 Sign and Zero Suppression.
A. Formats
A format string may be a string or an array into which a string has been read, using H format (Sec-
tion A.2.3.3). When a format string can be specified either form can be used.
A.1.3- Semantics. The above syntax defines the allowable strings which can comprise a “number format.” We will first
describe the interpretation to be taken during
output.
A.1.3.1 Replicators. An unsigned integer n used as replicator means the quantity is repeated n times; thus 3B is equiva-
to BBB. The character X as replicator means a numher of times which will be specified when the format is called (see
Section B.3.1).
A.1.3.1 Replicators
A replicator of value 0 (n or X) implies the absence of the quantity to which the replicator refers. The
maximum size of a replicator is 262,142 for 6000 computers and 32, 766 for 3000 computers.
A.1.3.2 Insertions. The syntax has been set up so that strings, delimited by string quotes, may be inserted anywhere
within a number format. The corresponding information in the strings (except for the outermost string quotes) will
appear inserted in the same place with respect to the rest of the number. Similarly, the letter B may be inserted anywhere
within a number format, and it stands for a blank space.
A.1.3.3 Sign, zero, and comma suppression. The portion of a number to the left of the decimal point consists of an
optional sign, then a sequence of Z's and a sequence of D's with possible C's following a Z or a D, plus possible insertion
characters.
61
The convention on signs is the following: (a) if no sign appears, the number is assumed to be positive, and the treatment
of negative numbers is undefined: (b) if à plus sign appears, the sign will appear as + or — on the external medium; and
(c) if a minus sign appears, the sign will appear if minus, and will be suppressed if plus.
The letter Z stands for zero suppression, and the letter D stands for digit printing without zero suppression. Each Z and
D stands for a single digit position; a zero digit specified by Z will be suppressed, i.e., replaced by a blank space, when
all digits to its left are zero. A digit specified by D will always be printed. Note that the number zero printed with all Z's
in the format will give rise to all blank spaces, so at least one D should usually be given somewhere in the format. The
letter C stands for a comma. A comma following a D will always be printed; a comma following a Z will be printed except
when zero suppression takes place at that Z. Whenever zero or comma suppression takes place, the sign (if any) is printed
in place of the rightmost character suppressed.
A.1.3.3 Sign and Zero Suppression
Upper 3000 and 6000 only: On input, if no sign appears in the format and the number is negative, an
error condition exists. If the procedure BAD DATA (Section 3.3) has not been called, or if the label
established by it is no longer accessible, an error message is issued and the object program terminates
abnormally (Chapter 8). Otherwise, control is transferred to the BAD DATA label. Output uses the
standard format bounded on either side by an asterisk (Section A. 2.3.6). Comma suppression is not
implemented.
Lower 3000 only: On input, if no sign appears in the format and the number is negative, an error message is issued and
the object program terminates abnormally. Output uses the standard format bounded on either side by an asterisk (Sec-
tion A.2.3.6). Comma suppression is not implemented.
NOTE: The situation which causes the BAD DATA label on upper 3000 and 6000 issues an error message and causes
abnormal exit of the program in lower 3000 (Chapter $).
A.1.3.4 Decimal points. The position of the decimal point is indicated either by the character “.” or by the letter V. In
the former case, the decimal point appears on the external medium; in the latter case, the decimal point is “implied” i.e.,
it takes up no space on the external medium. (This feature is most commonly used to save time and space when preparing
input data). Only D's (no Z's) may appear to the right of the decimal point.
A.1.3.4 Decimal points. In an exponent part, D's and Z's may appear to the right of the decimal point.
A.1.35 Truncation. On output, nonintegral numbers are usually rounded to fit the format specified. If the letter T is
used, however, truncation takes place instead. Rounding and truncation of a number X to d decimal places are defined
as follows:
Rounding 10~Y9entier(109X +0.5)
Truncation 10-Asign (X) entier (109 abs(X))
A.1.3.5 Truncation
On output, the number of significant digits appearing for a real number will correspond to the storage
of the number in 60-bit (48-bit) floating-point form. Thus 14 or 15 (10or 11) significant digits are
output, followed by trailing zeros, if necessary (Section 5.1.3). The letter T has no meaning when
applied to an integer number and is ignored.
62
A.1.3.6 Exponent part. The number following a “10” is treated exactly the same as the portion of a number to the left
of a decimal point (Section A.1.3.3), except if the “D” part of the exponent is empty, i.e., no D's appear, and if the
exponent is zero, the “ 10” and the sign are deleted.
A.1.3.7 Two types of numeric format. Number formats are of two principal kinds: (a) Decimal number with no expo-
nent. In this case, the number is aligned according to the decimal point with the picture in the format, and it is then
truncated or rounded to the appropriate number of decimal places. The sign may precede or follow the number.
(b) Decimal number with exponent. In this case, the number is transformed into the format of the decimal number
with its most significant digit non-zero; the exponent is adjusted accordingly. If the number is zero, both the decimal
part and the exponent part are output as zero. If in case (a) the number is too large to be output in the specified form,
or if in case (b) the exponent is too large, an overflow error occurs. The action which takes place on overflow is unde-
fined; it is recommended that the number of characters used in the output be the same as if no overflow had occurred,
and that as much significant information as possible be output.
A.1.3.7 Two Types of Numeric Format
A maximum of 24 D's and Z's may appear before the exponent part in a number format; in the exponent
part, the maximum is 4. On output overflow, the standard format bounded on either side by an asterisk
is used (Section À. 2, 3. 6).
A.1.3.8 Input. A number input with a particular format specification should in general be the same as the number which
would be output with the same format, except less error checking occurs. The rules are, more precisely:
(a) leading zeros and commas may appear even though Z's are used in the format. Leading spaces may appear even if D's
are used. In other words, no distinction between Z and D is made on input.
(b) Insertions take the same amount of space in the same positions, but the characters appearing there are ignored on
input. In other words, an insertion specifies only the number of characters to ignore, when it appears in an input format.
(c) If the format specifies a sign at the left, the sign may appear in any Z,D or C position as long as it is to the left of the
number. A sign specified at the right must appear in place.
(d) The following things are checked: The positions of commas, decimal points, “ 10” and the presence of digits in place
of D or Z after the first significant digit. If an error is detected in the data, the result is undefined; it is recommended
that the input procedure attempt to reread the data as if it were in standard format (Section A.5) and also to give some
error indication compatible with the system being used. Such an error indication might be suppressed at the program-
mer's option if the data became meaningful when it was reread in standard format.
A.1.3.8 Input
If the input data does not conform to the format, an error condition exists. If the procedure BAD DATA!
was not called or if the established label is no longer accessible, an error message is issued: and the
object program terminates abnormally. Otherwise, control is transferred to the BAD DATA label. C
is not implemented.
A.2 Other formats
A.2.1 Syntax
<S>::= S| <replicator > S
< string format > ::= < insertion sequence >> < S >| < string format > < S >| < string format > < insertion >
"The BAD DATA label does not apply to lower 3000.
63
<A> ::= Al < replicator > A
< alpha format > ::= < insertion sequence > < A >| < alpha format > < A >|
< alpha format > < insertion >
< nonformat > ::= I| RI L
< Boolean part > ::= P|SF| FFFFF| F
< Boolean format > ::= < insertion sequence > < Boolean part >
< insertion sequence >
< title format > ::= < insertion >| < title format > < insertion >
- alignment mark > ::= / |t | <replicator > /| < replicator > 1
< format item 1 > ::= < number format >| < string format >|
< alpha format >|< nonformat >|< Boolean format >|< title format >|
< alignment mark > < format item 1 >
< format item > ::= < format item 1 >| < alignment mark >| < format item > < alignment mark >
A.2.2 Examples
t5Z.5D///
35="654B
AA‘=
TR
P
/‘Execution.’?
The following definitions replace the definitions in the ACM Report:
A.2 Other Formats
A.2.1 Syntax
<8>::=8 | <replicator>S
<string format> : : = <insertion sequence><S> | <string format>
<S> | <string format> <insertion>
<alpha format>::=A
<standard format>::=N
<nonformat>::=I|R|LIMIH
<Boolean part>::=P | F
<Boolean format> : : = <insertion sequence> <Boolean part> <insertion sequence>
<title format> : : = <insertion> |
<title format> <insertion>
<alignment mark>::=/| 1 |J|
<replicator>/ | <replicator> {|
<replicator> J
<format item 1>: :=<number format> |
<string format> | <alpha format>
| <nonformat> | <Boolean format> |
«title format> | <alignment mark>
<format item 1> | <standard format>
<format item> : : = format item 1> |
<alignment mark> | <format item>
<alignment mark>
The characters M and H have been added to the non-format codes.
Replicator following A is not implemented.
Alpha format is defined to be A only.
J has been added to alignment mark (Section B. 3).
A.2.3 Semantics
A.2.3.1 String format. A string format is used for output of string quantities. Each of the S-positions in the format
corresponds to a single character in the string which is output. If the string is longer than the number of S's, the leftmost
characters are transferred; if the string is shorter, Li-symbols are effectively added at the right of the string.
The word “character” as used in this report refers to one unit of information on the external input or output medium; if
ALGOL basic symbols are used in strings which do not have a single-character representation on the external medium
being used, the result is undefined.
A.2.3 Semantics
The maximum length of a format item, after expanding each quantity in it by the corresponding replica-
tor, is 136 characters; the expanded format item corresponds to.the data on the external device.
65
A.2.3.1 String Format
Because of the difference in the definition of a string (Section 2.6.1), each of the S-positions in the
format corresponds to a single basic character in the output string rather than a single basic symbol.
If the string exceeds the number of S's, the leftmost basic characters are transferred; if the string is
shorter, blank characters are filled to the right.
A.2.3.2 Alpha format. Each letter A means one character is to be transmitted: this is the same as S-format except the
ALGOL equivalent of the alphabetics is of type integer rather than a string. The translation between the external and
internal code will vary from one machine to another, and so programmers should refrain from using this feature in a
machine-dependent manner. Each implementor should specify the maximum number of characters which can be used
for a single integer variable. The following operations are undefined for quantities which have been input using alpha
format; arithmetic operations, relations except “=" and “>”, and output using a different number of A's in the output
format. If the integer is output using the same number of A's, the same string will be output as was input.
A programmer may work with these alphabetic quantities in a machine-independent manner by using the transfer func-
tion equiv(S) where S is a string; the value of equiv(S) is of type integer, and it is defined to have exactly the same value
as if the string S had been input using alpha format. For example, one may write
if X = equiv( ALPHA”) then go to PROCESS ALPHA;
where the value of X has been input using the format “AAAAA”.
A. 2.3.2 Alpha Format
Because of the difference in the definition of a string (Section 2.6.1), the letter A indicates one basic
character rather than one basic symbol is to be transmitted. This is the same as S-format, except
the ALGOL equivalent of the basic character is of type integer rather than a string.
Similarly, the transfer function EQUIV(S) is an integer procedure, the value of which is the internal
representation (Appendix A) of the first basic character in the string S. Thus, it has the same value
as if the string S were input in alpha format. The example would, therefore, be as follows:
if X = EQUIV (‘A’) then go to PROCESS ALPHA
where the value of X has been input using the format A.
A.2.3.3 Nonformat. An |, R or L is used to indicate that the value of a single variable of integer, real, or Boolean type,
respectively, is to be input or output from or to an external medium, using the internal machine representation. If a
value of type integer is output with R-format or if a value of type real is input with |-format, the appropriate transfer
function is invoked. The precise behavior of this format, and particularly its interaction with other formats, is unde-
fined in general.
A. 2.3.3 Nonformat
The M code added to the nonformat codes indicates that the value of a single variable of any type is to
be input or output in the exact form in which it appears on the external device or in memory.
The nonformat codes I, R, L and M each input or output 20 (16) consecutive (6-bit) display (BCD) ckar-
acters, and map them to or from the 20 (16) consecutive octal (3-bit) digits which constitute one
variable internally (Section 5.1.3).
66
The H code added to the nonformat codes indicates that 8 consecutive display (BCD) characters are to
be input or output to or from a single integer variable.
A.2.3.4 Boolean format. When Boolean quantities are input or output, the format P, F, 5F or FFFFF must be used.
The correspondence is defined as follows:
Internal to ALGOL P F 5F = FFFFF
true 1 T TRUEL!
false 0 F FALSE
On input, anything failing to be in the proper form is undefined.
A.2.3.4 Boolean format. When Boolean quantities are input or output, the format P, F, must be used.
The correspondence is defined as follows (Section A.2.1):
Internal to ALGOL P F
true 1
false 0 F
External representations in F format are t and f rather than true or false.
On input, incorrect forms cause an error condition. If the procedure BAD DATA! was not called or if
the established label is no longer accessible, an error message is issued and the object program
terminates abnormally.
A.2.3.5 Title format. All formats discussed so far have given a correspondence between a single ALGOL real, integer,
Boolean, or string quantity and a number of characters in the input or output. A title format item consists entirely of
insertions and alignment marks, and so it does not require a corresponding ALGOL quantity. On input, it merely causes
skipping of the characters, and on output it causes emission of the insertion characters it contains. (If titles are to be
input, alpha format should be used: see Section A.2.3.2).
A.2.3.6 Alignment marks. The characters “/” and “1” in a format item indicate line and page control actions. The pre-
cise definition of these actions will be given later (see Section B.5); they have the following intuitive interpretation:
(a) “/” means go to the next line, in a manner similar to the “carriage return” operation on a typewriter. (b) “1” means
do a /-operation and then skip to the top of the nexi page. |
Two or more alignment marks indicates the number of times the operations are to be performed; for example, “//” on
output means the current line is completed and the next line is effectively set to all blanks. Alignment marks at the left
of a format item cause actions to take place before the regular format operation, and if they are at the right they take
place afterwards.
Note. On machines which do not have the character 1 in their character set, it is recommended that some convenient
character such as an asterisk be substituted for 1 in format strings.
tThe BAD DATA label does not apply to lower 3000 (Section A. 1.3, 3).
67
A.2.3.6 Alignment marks. The character J has been added to indicate character control action in a
format item. J means skip the character pointer to the next tabulation position; similar to the tab
operation on a typewriter.
An asterisk has been substituted for | in format strings.
A.3 Format Strings
The format items mentioned above are combined into format strings according to the rules in this section.
A3.1 Syntax
< format primary > ::= < format item >|
< replicator > (< format secondary >) | (< format secondary >)
< format secondary > ::= < format primary >|
< format secondary > , < format primary >
< format string > ::= * < format secondary > | ”
A.3.2 Examples
‘4 (15ZD) //
4
“5D 10+D,X (2(20B.8D10+D) ,108) >
“... This LI is LJ a LJ peculiar LI ‘format LI string’ ”
A.3.3 Semantics. A format string is simply a list of format items, which are to be interpreted from left to right. The
construction “ <replicator > ( < format secondary > ) ” is simply an abbreviation for “replicator” repetitions of the
parenthesized quantity (see Section A.1.3.1). The construction * (< format secondary > ) “ is used to specify an infinite
repetition of the parenthesized quantity.
All spaces within a format string except those which are part of insertion substrings are irrelevant.
It is recommended that the ALGOL compiler check the syntax of strings which (from their context) are known to be
format strings as the program is compiled. In most cases it will also be possibie for the compiler to translate format
strings into an intermediate code designed for highly efficient input-output processing by the other procedures.
A.3.3 Semantics
The infinite repetition of the parenthesized quantity is defined as meaning 262,142 repetitions.
68
A.4 Summary of Format Codes
A
n U OO W
L
Р
В
S
T
V
The following items have been added to format codes:
J
N
M
H
alphabetic character
represented as integer
Z
blank space
+
comma
digit
Boolean TRUE or FALSE 10
integer untranslated ()
Boolean untranslated
Boolean bit
real untranslated 1
1
string character
truncation
implied decimal point
character alignment
standard format
variable of any type
integer variable;
and C has been deleted.
Ab “Standard” Format
arbitrary replicator
zero suppression
print the sign
print the sign if
it is minus
exponent part indicator
delimiters of replicated
format secondaries
separates format items
line alignment
page alignment
delimiters of inserted string
decimal point
There is a format available without specifications (cf. Section B.5) which has the following characteristics.
(a) On input, any number written according tc the ALGOL syntax for < number > is accepted with the conventional
meaning. These are of arbitrary length, and they are delimited at the right by the following conventions: (i) A letter or
character other than a decimal point, sign, digit, or “10” is a delimiter. (ii) A sequence of k or more blank spaces serves
as a delimiter as in (i); a sequence of less than k blank spaces is ignored. This number k > is specified by the implementor
(and the implementor may choose to let the programmer specify k on a control card of some sort). (iii) If the number
contains a decimal point, sign, digit, or “10” on the line where the number begins, the right-hand margin of that line
serves as a delimiter of the number. However, if the first line of a field contains no such characters, the number is deter-
mined by reading several lines until finding a delimiter of type (i) or (ii). In other words, a number is not usually split
across more than one line, unless its first line contains nothing but spaces or characters which do not enter into the
number itself. (See Section B.5 for further discussion of standard input format.)
(b) On output, a number is given in the form of a decimal number with an exponent. This decimal number has the
amount of significant figures which the machine can represent; it is suitable for reading by the standard input format.
Standard output format takes a fixed number of characters on the output medium; this size is specified by each ALGOL
installation. Standard output format can also be used for the output of strings, and in this case the number of characters
is equal to the length of the string.
69
A.5 Standard Format
Standard format may be invoked by the format item N, through the exhaustion of the format string, or
by specifying an empty format string. The standard format of both integer and real variables is
+D. 13D, ,+3D. When the given format is incorrect, the modified standard format is **” +D. 13D +30 °*’
(Sections A.1.3.3 and A.1.3.7).
The standard format for output is +D.9D 10*3D for real values and +15ZD for integer values. When the given format is
incorrect, the modified standard output formats are *” +D. 9D 10*3D * for real values and “*’ +16D ‘* for integer
values. (Section A.1.3.3 and A.1.3.7).
The number of blank characters, k, serving as a delimiter between numbers in standard format may be
specified on the channel card (Chapter 7). If not specified, two is assumed.
String parameters can be output under standard format, nS, where n is the length of the string.
B. Input and Output Procedures
B.1 General Characteristics
The over-all approach to input and output which is provided by the procedures of this report will be introduced here by
means of a few examples, and the precise definition of the procedures will be given later.
Consider first a typical case, in which we want to print a line containing the values of the integer variables N and M, each
of which is nonnegative, with at most five digits; also the value of X [M] , in the form of a signed number with a single
nonzero digit to the left of the decimal point, and with an exponent indicated; and finally the value of cos(t), using a
format with a fixed decimal point and no exponent. The following might be written for this case:
output 4(6,°2(BBBZZZZD) ,38+D.DDDDDD 10+DDD ЗВ,
~-Z.DDDDBDDDD/’ NM, X[M] ‚cos (t)).
This example has the following significance. (a) The “4” in output 4 means four values are being output. (b) The
“6” means that output is to go to unit 6.
This is the logical unit number, i.e., the programmer’s number for that unit, and it does not necessarily mean physical
unit number 6. See Section B.1.1, for further discussion of unit numbers. (c) The next parameter, 2(BBB ... DDDD/?,
is the format string which specifies a format for outputting the four values. (d) The last four parameters are the values
being printed. If N = 500, M = 0, X[0] = 18061579, and t = 3.1415926536, we obtain the line _”
LHJUILILISOOLILJLLLILLIOL LIL S+1.806158 10+007 L1L1L1—-1.0000L10000
as output.
Notice the “/” used in the above format; this symbol signifies the end of a line. If it had not been-present, more humbers
could have been placed on the same line in a future output statement. The programmer may build the contents of a
line in several steps, as his algorithm proceeds, without automatically starting a new line each time output is called. For
example, the above could have been written
output 1(6/BBBZZZZD' N);
output 1(6,BBBZZZZD' M);
70
output 2(6,3B+D.DDDDDD 10 +DDD,3B,-Z.DDDDBDDDD',
X[M] ,cos(t)) ;
output 0(6,7);
with equivalent results.
In the example above a line of 48 characters was output. If for some reason these output statements are used with a
device incapable of printing 48 characters on a single line, the output would actually have been recorded on two or more
lines, according to a rule which automatically keeps from breaking numbers between two consecutive lines wherever
possible. (The exact rule appears in Section B.5)
Now let us go to a slightly more complicated example:
the real array A [1:n,1:n] is to be printed, starting on a new page. Supposing each element is printed with the format
“BB-ZZZZ.DD”, which uses ten characters per item, we could write the following program:
output 0 (6,‘1);
for i := 1 step 1 until n do
begin for j := 1 step 1 until n do output 1(6,BB-ZZZZ.DD”,
Ali,jl); output 0(6,//’) end.
If 10n characters will fit on one line, this little program will print n lines, double spaced, with n values per line; other-
wise n groups of k lines separated by blank lines are praduced, where k lines are necessary for the printing of n values.
For example, if n = 10 and if the printer has 120 character positions, 10 double-spaced lines are produced. If, however,
a 72-character printer is being used, 7 values are printed on the first line, 3 on the next, the third is blank, then 7 more
values are printed, etc.
There is another way to achieve the above output and to obtain more control over the page format as well. The subject
of page format will be discussed further in Section B.2, and we will indicate here the manner in which the above opera-
tion can be done conveniently using a single output statement. The procedures output 0, output 1, etc. mentioned
above provide only for the common cases of output, and they are essentially a special abbreviation for certain calls on
the more general procedure out list. This more general procedure could be used for the above problem in the
following manner: |
out list (6, LAYOUT,LIST)
Here LAYOUT and LIST are the names of procedures which appear below. The first parameter of out list is the
logical unit number as described above. The second parameter is the name of a so-called “layout procedure”; general
layout procedures are discussed in Section B.3. The third parameter of out list is the name of a so-called “list
procedure”; general list procedures are discussed in Section B.4. In general, a layout procedure specifies the format con-
trol of the input or output. For the case we are considering, we could write a simple layout procedure (named
“LAYOUT”) as follows:
procedure LAYOUT; format 1 (1, (X(BB-ZZZZ.DD) ,//)”,n)
The 1 in format 1 means a format string containing one X is given.
The format string is 1,
(X(BB-ZZZZ.DD),//)
71
which means skip to a new page, then repeat the format X(BB-ZZZZ.DD),// until the last value is output. The latter
format means that BB-ZZZZ.DD is to be used X times, then skip to a new line. Finally, format 1 is a procedure
which effectively inserts the value of n for the letter X appearing in the format string.
À list procedure serves to specify a list of quantities. For the problem under consideration, we could write a simple list
procedure (named “LIST”) as follows:
procedure LIST(ITEM); for i : = step 1 until n do
for j : = 1 step 1 until n do ITEM(A[ij1 )
Here “ITEM Ali,j] ” means that Ali,j] is the next item of the list. The procedure ITEM is a formal parameter which
might have been given a different name such as PIECE or CHUNK: list procedures are discussed in more detail in Sec-
tion B.4.
The declarations of LAYOUT and LIST above, together with the procedure statement out list(6 LAYOUT, LIST),
accomplish the-desired output of the array A.
Input is done in a manner dual to output, in such a way that it is the exact inverse of the output process wherever
possible. The. procedures in list and input n correspond to out list and outputn (n=0,1,...). Two
other procedures, get and put, are introduced to facilitate storage of intermediate data on external devices.
For example, the statement put (100,LIST) would cause the values specified in the list procedure named LIST to be
recorded in the external medium with an identification number of 100. The subsequent statement get (100,LIST)
would restore these values. The external medium might be a disk file, a drum, a magnetic tape, etc.; the type of device
and the format in which data is stored there is of no concern to the programmer.
B.1.1 Unit numbers. The first parameter of input and output procedures is the logical unit number, i.e., some number
which the programmer has chosen to identify some input or output device. The connection between logical unit numbers
and the actual physical unit numbers is specified by the programmer outside of the ALGOL language, by means of
“control cards” preceding or following his program, or in some other way provided by the ALGOL implementor. The
situation which arises if the same physical unit is being used for two different logical numbers, or if the same physical
unit is used both for input and for output, is undefined in general.
It is recommended that the internal computer memory (e.g. the core memory) be available as an “input-output device”,
so that data may be edited by means of input and output statements.
B.1.1 Unit Numbers
Wherever the term unit number appears in the ACM Report, channel number applies. This channel
number is synonymous with unit number in the ACM Report.
A channel is defined as all the specifications the I/O system needs to perform operations on a particular
data file. A channel may be thought of as the set of descriptive information by which one reaches or
knows of a data file. A channel number is the name of this set of descriptive information as well as the
internal, indirect reference name of the data file accessed via this information.
The channel contains the following specifications about a data file:
1. Physical device description — device name, logical address, read or write mode
2. Status of physical device — binary or BCD, device position, error conditions
72
3. Data file description — file name, read or write mode, blocking information
4, Data file status — file position, error conditions
5. Description of formatting area — buffer area from or to which data in a file is moved
6. List of labels to which control will be given if errors occur.
Channels are established by means of channel cards (Chapter 7).
B.2 Horizontal and Vertical Control
This section deals with the way in which the sequence of characters, described by the rules of formats in Section A, is
mapped onto input and output devices. This is done in a manner which is essentially independent of the device being
used, in the sense that with these specifications the programmer can anticipate how the input or output data will appear
on virtually any device. Some of the features of this description will, of course, be more appropriately used on certain
devices than on others. |
We will begin by assuming we are doing output to a printer. This is essentially the most difficult case to handle, and we
will discuss the manner in which other devices fit into the same general framework. The page format is controlled by
specifying the horizontal and the vertical layout. Horizontal layout is controlled essentially in the same manner as vertical
layout, and this symmetry between the horizontal and vertical dimensions should be kept in mind for easier understanding
of the concepts of this section.
Refer to Figure 2; the horizontal format is described in terms of three parameters (L,R,P), and the vertical format has
corresponding parameters (L',R',P'). The parameters L, L' and R, R' indicate left and right margins, respectively: Fig-
ure 2 shows a case where L = L'= 4 and R = R' = 12. Only positions L through R of a horizontal line are used, and only
lines L' and R' of the page are used; we require that 1 <L<R and 1<L'<R'. The parameter P is the number of charac-
ters per line, and P' is the number of lines per page. Although L, R, L' and R' are chosen by the programmer, the values
of P and P' are characteristics of the device and they are usually out of the programmer's control. For those devices on
Which P and P' can vary (for example, some printers have two settings, one on which there are 66 lines per page, and
another on which there are 88), the values are specified to the system in some manner external to the ALGOL program,
e.g. on control cards. For certain devices, values P or P” might be essentially infinite.
B.2 Horizontal and Vertical Control
The values are specified to the system by a suitable call on the procedure SYSPARAM (Section B. 6) or
with channel cards.
The initial value of P on the channel card (Chapter 7) defines the maximum size of the line to be read
or written. P may be changed during program execution, but it may never exceed its initial setting.
The initial value of P’ on the channel card defines the number of lines per page; the value of this
parameter may be changed to exceed its initial setting.
Although Figure 2 shows a case where P=R and P'>R/, it is of course quite possible that P<R or P'<<R’ (or both) might
occur, since P and P' are in general unknown to the programmer. In such cases, the algorithm described in Section B.5
is used to break up logical lines which are too wide to fit on a physical line, and to break up logical pages which are too
large to fit a physical page. On the other hand, the conditions L <P and L'<P' are insured by setting L or L' equal to 1
automatically if they happen to be greater than P or P', respectively.
73
Characters determined by the output values are put onto a horizontal line; there are three conditions which cause a
transfer to the next line: (a) normal line alignment, specified by a ''/” in the format; (b) R-overflow, which occurs when
a group of characters is to be transmitted which would pass position R; and (c) P-overflow, which occurs when a group
of characters is to be transmitted which would not cause R-overflow but would pass position P. When any of these three
things occurs, control is transferred to a procedure specified by the programmer in case special action is desired (e.g. a
change of margins in case of overflow; see Section B.3.3).
° |
& a di dee e 2
= = = N or *
+
/ _/
M2 32 56 7 8 9 10111213 14 15 16 17 18!
di
© © ч © SS W N —
=
—
o
—
==
—
62
x
">
N
— — uch
Oo N A
—
=~]
7
Figure 2.
Similarly, there are three conditions which cause a transfer to the next page: (a') normal page alignment, specified by a
"4 in the format; (b') R'-overflow, which occurs when a group of characters is to be transmitted which would appear
on line R'+1; and (c') P'-overflow, which occurs when a group of characters is to be transmitted which would appear on
line P'+1<R'+1. The programmer may indicate special procedures to be executed at this time if he wishes, e.g. to insert
a page heading, etc.
Further details concerning pages and lines will be given later. Now we will consider how devices other than printers can
be thought of in terms of the ideas above.
A typewriter is, of course, very much like a printer and it requires no further comment.
Punched cards with, say, 80 columns, have P = 80 and P' = oo, Vertical control would appear to have little meaning for
punched cards, although the implementor might choose to interpret 1” to mean the insertion of a coded or blank card.
With paper tape, we might again say that vertical control has little or no meaning; in this case, P could be the number of
characters read or written at a time.
On magnetic tape capable of writing arbitrarily long blocks, we have P = P’ = co, We might think of each page as being a
“record”, i.e., an amount of contiguous information on the tape which is read or written at once. The lines are subdivi-
sions of a record, and R' lines form a record; R characters are in each line. In this way we can specify so-called “blocking
of record.” Other interpretations might be more appropriate for magnetic tapes at certain installations, e.g. a format
which would correspond exactly to printer format for future offline listing, etc.
These examples are given merely to indicate how the concepts described above for printers can be applied to other
devices. Each implementor will decide what method is most appropriate for his particular devices, and if there are
74
choices to be made they can be given by the programmer by means of control cards. (channel cards) The manner in
which this is done is of no concern in this report; our procedures are defined solely in terms of P and Р'.
B.3 Layout Procedures
Whenever input or output is done, certain “standard” operations are assumed to take place, unless otherwise specified
by the programmer. Therefore one of the parameters of the input or output procedure is a so-called “layout” procedure,
which specifies all of the nonstandard operations desired. This is achieved by using any or all of the six “descriptive
procedures” format, h end, v end, h lim, v lim, no data described in this section.
The precise action of these procedures can be described in terms of the mythical concept of six “hidden variables,”
H1, H2, H3, H4, H5, HG. The effect of each descriptive procedure is to set one of these variables to a certain value; and
as a matter of fact, that may be regarded as the sum total of the effect of a descriptive procedure. The programmer
normally has no other access to these hidden variables (see, however, Section B.7). The hidden variables have a scope
which is local to in list and to out list.
B.3 A seventh descriptive procedure, TABULATION, has been added with its corresponding hidden
variable H7 (Section B. 3. 3).
Tabulation is controlled by a J in the format. This causes the character pointer to be advanced to the
next "TAB" position with intermediate positions being filled with blanks. The tabulation spacing for
the device may be specified external to the ALGOL system, or through a suitable call on SYSPARAM
(Section B. 6).
If the tabulation spacing is N, then the first character of tabulation fields would be:
L, L+N, L+2N, . . . , L+KN where L+KN =min (P, R).
If any of the procedures FORMAT, H END, V END, H LIM, V LIM, TABULATION, or NO DATA are
called when neither IN LIST nor OUT LIST is active, they have the effect of a dummy procedure; a
procedure call is made and the procedure is exited immediately.
B.3.1 Format Procedures. The descriptive procedure call
format (string)
has the effect of setting the hidden variable H1 to indicate the string parameter. This parameter may either be a string
explicitly written, or a formal parameter; but in any event, the string it refers to must be a format string, which satisfies
the syntax of Section A.3, and it must have no “X” replicators.
The procedure format is just one of a class of procedures which have the names formatn,(n=0,1,...). The
name format is equivalent to format 0. In general, the procedure formatn is used with format strings
which have exactly n X-replicators. The call is
format n (string, X4,X9, . . - Xn)
where each X; is an integer parameter called by value. The effect is to replace each X of the format string by one of the
X;, with the correspondence defined from left to right. Each X; must be nonnegative.
For example,
format 2 (‘XB . XD 10+DD’, 5,10)
75
is equivalent to
format (‘5B . 10D 10+DD”).
B.3.1 Format Procedures
The single procedure with call:
FORMAT (string, X,, X ,... >)
1 2
replaces the n+1 procedures defined in the proposal with call:
ORMAT n (string, Xx xo ‚X.
The number of X; variables included in the call to FORMAT defines the equivalent n+1 procedure
defined in the proposal. For example:
FORMAT (string, X,, X9) is equivalent to
FORMAT 2 (string, X-, X9) defined in the proposal.
À call to FORMAT may include 0-30 variables. The number depends on the parenthesized structure
of the string.
B.3.2 Limits. The descriptive procedure call
h lim (LR)
has the effect of setting the hidden variable H2 to indicate the two parameters L and R. Similarly,
v lim (L’,R’)
sets H3 to indicate L' and R'. These parameters have the significance described in Section B.2. If hlim and v lim
are not used, L = L'=1andR = R'=œ.
B.3.2 Limits
Since the first character of each record is used by the system to control skipping when paging is
requested, the H LIM procedure increases the values of the L and R parameters by 1 to overcome
the loss of this character. Any attempt to set the L and R parameters so that R-L = 21 is ignored.
B.3.3 End Control. The descriptive procedure
h end (Py-PrPp); v end (Pn PR'.Pp);
have the effect of setting the hidden variables H4 and HS5, respectively, to indicate their parameters. The parameters
PnPRPpPN PR Pp’ are names of procedures (ordinally dummy statements if hend and vend are not
specified) which are activated in case of normal line alignment, R-overflow, P-overflow, normal page alignment,
R’-overflow, and P’-overflow, respectively.
76
B.3.3 The descriptive procedure call
TABULATION (n)
has the effect of setting the hidden variable H7 (Section B.3.5) to indicate the parameter n. Here n is
the width of the tabulation field, measured in the number of characters on the external device (Section B.5.1,
Process C). If tabulation is not called then H7 = 1.
B.3.4 End of Data. The descriptive procedure call
no data (L)
has the effect of setting the hidden variable H6 to indicate the parameter L. Here L is a label. End of data as defined
here has meaning only on input, and it does not refer to any specific hardware features; it occurs when data is requested
for input but no more data remains on the corresponding input medium. At this point, a transfer to statement labeled
L will occur. If the procedure no data is not used, transfer will occur to a “label” which has effectively been in-
serted just before the final end in the ALGOL program, thus terminating the program. (In this case the implementor may
elect to provide an appropriate error comment.)
B.3.4 End of Data
End of data is defined as the occurrence of an end-of-file condition on the input device.
If the procedure NO DATA was not called, transfer occurs to the label established for the channel by
the EOF procedure (Section 3.3). If the EOF procedure was not called, or if the established label is
no longer accessible, the object program terminates abnormally with the message UNCHECKED EOF.
B.3.5 Examples. A layout procedure might look as follows:
procedure LAYOUT; begin format (*/);
if B then begin format 1(‘XB’,Y + 10); no data (L32) end;
‘h lim (if B then 1 else 10,30) end;
Note that layout procedures never have formal parameters; this procedure, for example, refers to three global quantities,
B, Y and L32. Suppose Y has the value 3; then this layout accomplishes the following:
Hidden
Variable Procedure if B = true if B = false
H1 format ‘138° P
H2 h Jim (1,30) (10,30)
H3 v lim (1,00) (1,00)
H4 h end (. (,.)
H5 v end (,.) (,.)
H6 no data L32 end program
НТ “tabulation 1 1
77
As a more useful example, we can take the procedure LAYOUT of Section B.1 and rewrite it so that the horizontal
margins (11,110) are used on the page, except that if P-overflow or R-overflow occurs we wish to use the margins
(16,105) for overflow lines.
procedure LAYOUT; begin
format 1 (+, (X(BB-ZZZZ.DD) ,//) п);
h lim (11,110); h end (K,L,L) end;
procedure K; h lim (11,110);
procedure L; h lim (16,105);
This causes the limits (16,105) to be set whenever overflow occurs, and the’/” in the format will reinstate the original
margins when it causes procedure K to be called. (If the programmer wishes a more elaborate treatment of the overfiow
case, depending on the value of P, he may do this using the procedures of Section B.6).
B.4 List Procedures
B.4.1 General characteristics. The concept of a list procedure is quite important to the input-output conventions de-
scribed in this report, and it may also prove useful in other applications of ALGOL. It represents a specialized application
of the standard features of ALGOL which permit a procedure identifier, L, to be given as an actual parameter of a pro-
cedure, and which permit procedures to be declared within procedures. The purpose of a list procedure is to describe a
sequence of items which is to be transmitted for input or output. A procedure is written in which the name of each
item V is written as the argument of a procedure, say ITEM, thus: ITEM(V). When the list procedure is called by an
input-output system procedure, another procedure (such as the internal system procedure out item) will be “sub-
stituted” for ITEM, V will be called by name, and the value of V will be transmitted for input or output. The standard
sequencing of ALGOL statements in the body of the list procedure determines the sequence of items in the list.
A simple form of list procedure might be written as follows:
procedure LIST (ITEM);
begin ITEM(A); ITEM(B); ITEM(C) end
which says that the values of A, B, and C are to be transmitted.
A more typical list procedure might be:
procedure PAIRS (ELT);
for i : = 1 step 1 until n do begin ELT(A[i]);
ELT(B[i] ) end
This procedure says that the values of the list of items A[1],B[1], A{2], B[2] ,..., A[n], B[n] are to be transmitted,
in that order. Note that if n<O no items are transmitted at all.
The parameter of the “item” procedure (i.e., the parameter of ITEM or ELT in the above examples) is called by narne.
It may be an arithmetic expression, a Boolean expression, or a string, in accordance with the format which will be
associated with the item. Any of the ordinary features of ALGOL may be used in a list procedure, so there is great
flexibility.
78
Unlike layout procedures which simply run through their statements and set up hidden variables H1 through H6, a list
procedure is executed step by step with the input or output procedure, with control transferring back and forth. This
is accomplished by special system procedures such as in item and out item which are “interlaced” with the
list procedure, as described in Sections B.4.2 and B.5. The list procedure is called with in item (or out item) as
actual parameter, and whenever this procedure is called within the list procedure, the actual input or output is taking
place. Through the interlacing, special format control, including the important device-independent overflow procedures
can take place during the transmission process. Note that a list procedure may change the hidden variables by calling a
descriptive procedure; this can be a valuable characteristic, e.g. when changing the format, based on the value of the
first item which is input.
,
B.4.2 Other applications. List procedures can actually be used in many ways in ALGOL besides their use with input or
output routines; they are useful for manipulating linear lists of items of a quite general nature. To illustrate this fact,
and to point out how the interlacing of control between list and driver procedures can be accomplished, here is an ex-
ample of a procedure which calculates the sum of all of the elements in a list (assuming all elements are of integer or
real type):
procedure ADD(Y ,Z); begin
procedure A(X): Z : = Z + X:
Z : = 0; Y(A) end
The call ADD(PAIRS,SUM) will set the value of SUM to be the sum of all of the items in the list PAIRS defined in Sec-
tion B.4.1. The reader should study this example carefully to grasp the essential significance of list procedures. It is a
simple and instructive exercise to write a procedure which sets all elements of a list to zero.
B.5 Input and Output Calls
Here procedures are described which cause the actual transmission of input or output to take place.
To give a more complete range of input-outputprocedures, the following calls have been added:
IN CHARACTER IN REAL IN ARRAY
OUT CHARACTER OUT REAL OUT ARRAY
Character Transmission
The procedures IN CHARACTER and OUT CHARACTER provide the means of communicating between
input-output devices and the variables of the program in the terms of basic characters.
IN CHARACTER (channel, string, destination)
OUT CHARACTER (channel, string, source)
IN CHARACTER examines the next basic character on the channel; if its value corresponds to the
external BCD value 00g, the integer variable destination is set to -1. If not, the character is compared
for equality with the characters that comprise the string. If a match is found at the Jth charecter,
destination is set to value J; if no match is found, destination is set to 0.
OUT CHARACTER examines the value of source. If it is negative, the character which corresponds to
external BCD 00, is output. If the value is in the range of 1 to J, where J is the length of the string,
the corresponding character of the string is output; otherwise an object program error results.
79
In both IN CHARACTER and OUT CHARACTER embedded string quotes ‘ and ’ are each counted as
three characters, as in the procedure CHLENGTH (Section 3.2.1).
B.5.2 Transmission of Type real
Transmission of information of type real between variables of the program and an external device may
be accomplished by the procedure calls
IN REAL (channel, destination)
OUT REAL (channel, source)
where channel and source are arithmetic expressions and destination is a variable of type real.
The two procedures IN REAL and OUT REAL form a pair. The procedure IN REAL will assign the next
value appearing on the input device to the real type variable given as the second parameter. - Similarly,
procedure OUT REAL will transfer the value of the second actual parameter to the output device.
A value which has been transferred by the call OUT REAL is represented in such a way that the same
value, in the sense of numerical analysis (Section 3.3.6), may be transferred back to a variable by means
of procedure IN REAL,
The procedures IN REAL and OUT REAL handle numbers in standard format.
B.5.3 Transmission of Arrays
Arrays may be transferred between input-output devices by means of the procedure calls
IN ARRAY (channel, destination)
OUT ARRAY (channel, source)
‘where channel must be an arithmetic expression and destination and source are arrays of type real.
Procedures IN ARRAY and OUT ARRAY also form a pair; they transfer the ordered set of numbers
which form the value of the array, given as the second parameter. The array bounds are defined by
the corresponding array declaration rather than by additional parameters (the mechanism for doing
this is already available in ALGOL-60 for the value call of arrays).
The order in which the elements of the array are transferred corresponds to the lexicographic order of
the values of the subscripts as follows:
alkı,ko,... ‚km ] precedes
alj1,j2.... im) provided
k;=ji 1=1,2,...,P-1)
and ky <p (1=p =m)
80
It should be recognized that the possibly multidimensional structure of the array is not reflected in the
‘corresponding numbers on the external device where they appear only as a linear sequence as defined
above.
The representation of the numbers on the external device conforms to the same rules as given for IN
REAL and OUT REAL; in fact it is possible to input numbers by IN REAL which before have been output
by OUT ARRAY,
B.5.1 Output
An output process is initiated by the call:
out list (unit, LAYOUT. LIST)
Here unit is an integer parameter called by value, which is the number of an output device (cf. Section B.1.1). The param-
eter LAYOUT is the name of a layout procedure (Section B.3), and LIST is the name of a list procedure (Section B.4).
There is also another class of procedures, named output n, forn=0,1,2, ..., which is used for output as follows:
output n (unit, format string,eq,e>, ..., en)
B.5.1 Output
The single procedure with call:
OUTPUT (channel, format string, €1,€9;...,€p)
replaces the n+l procedures defined with call:
OUTPUT n (channel, format string, €1,9,...,ep)
п = 0, ©
The number of e; variables included in the call to OUTPUT defines to which of the n+1 procedures
(defined in the proposal) it is equivalent. For example:
OUTPUT (channel, format string, eq)
is equivalent to
OUTPUT 1 (channel, format string, eq)
defined in the proposal.
A call to OUTPUT may include 0-61 variables.
Each of these latter procedures can be defined in terms of out list as follows:
procedure output n(unit, format string, e4,09, . . . en);
begin procedure A; format (format string);
81
procedure B(P); begin Pleq); Ple); ...; Plen) end;
out list (unit, A,B) end
We will therefore assume in the following rules that out list has been called.
Let the variables p and p' indicate the current position in the output for the unit under consideration, i.e., lines 1,2, ...
p' of the current page have been completed, as well as character positions 1,2, ...,p of the current line (i.e., of line
p'+1). At the beginning of the program, p = p' = 0. The symbols P and P' denote the line size and page size (see Sec-
tion B.2). Output takes place according to the following algorithm:
Y
Step 1. The hidden variables are set to standard values:
H1 is set to the “standard” format“? ,
H2 is set so that L= 1,R =oo.
H3 is set so that L' = 1,R'=o0,
H4 is set so that Py, Pg, Pp are all effectively equal to the DUMMY procedure defined as follows:
“procedure DUMMY ;;"".
HS is set so that Py, Pr’, Pp are all effectively equal to DUMMY.
H6 is set to terminate the program in case the data ends (this has meaning only on input).
Step 2. The layout procedure is called; this may change some of the variables H1, H2, H3, H4, H5, H6.
Step 3. The next format item of the format string is examined. (Note. After the format string is exhausted, “standard”
format, Section A.5, is used from then on until the end of the procedure. In particular, if the format string is *?, standard
format is used throughout.) Now if the next format item is a title format, i.e., requires no data item, we proceed directly
to step 4. Otherwise, the list procedure is activated; this is done the first time by calling the list procedure, using as actual
parameter a procedure named out item this is done on all subsequent times by merely returning from the proce-
dure out item ‚which will cause the list procedure to be continued from the latest: out item call. (Note: The
identifier out item has scope local to out list ‚so a programmer may not call this procedure directly). After
the list procedure has been activated in this way, it will either terminate or will call the procedure out item. In the
former case, the output process is completed; in the latter case, continue at step 4.
Step 4. Take the next item from the format string. (Notes. If the list procedure was called in step 3, it may have called
the descriptive procedure format |, thereby changing from the format which was examined during step 3. In such a
case, the new format is used here. But at this point the format item is effectively removed from the format string and
copied elsewhere so that the format string itself, possibly changed by further calls of. format , will not be interrogated
until the next occurrence of step 3. If the list procedure has substituted a title format for a nontitle format, the “item”
it specifies will not be output, since a title format consists entirely of insertions and alignment marks.)
Set “toggle” to false. (This is used to control the breaking of entries between lines.) The alignment marks, if any, at the
left of the format item, now cause process A (below) to be executed for each ‘’/"’, and process B for each “1”. If the
format item consists entirely of alignment marks, then go immediately to step 3. Otherwise the size of the format (i.e.
the number of characters specified in the output medium) is determined. Let this size be denoted by S. Continue
with step 5. -
Step 5. Execute process C, to ensure proper page alignment.
82
Step 6. Line alignment: If p < L—1, effectively insert blank spaces so that p = L — 1. Now if toggle = true, go to step 9;
otherwise, test for line overflow as follows: If p + S > R, perform process D, then call PR and go to step 8; otherwise, if
р + $ > P, perform process D, call Pp. and go to step 8.
Step 7. Evaluate the next output item and output it according to the rules given in Section A: in the case of a title format
this is simply a transmission of the insertions without the evaluation of an output item. The pointer p is set to p + S. Any
alignment marks at the right of the format item now cause activation of process A for each "/” and of process B for each
1", Return to step 3.
r
Step 8. Set toggle to true. Prepare a formatted output item as in step 7, but do not record it on the output medium yet
(this is done in step 9). Go to step 5. (It is necessary to re-examine page and line alignment, which may have been altered
by the overflow procedure; hence we go to step 5 rather than proceeding immediately to step 9.)
Step 9. Transfer as many characters of the current output item as possible into positions p + 1, . . . , without exceeding
position P or R. Adjust p appropriately. If the output of this item is still unfinished, execute process D again, call PR
(if R <P) or Pp (if P <R), and return to step 5. The entire item will eventually be output, and then we process align-
ment characters as in step 7, finally returning to step 3.
Process A. (*/” operation) Check page alignment with process C, then execute process D and call procedure PN-
Process B. (“1" operation) If p > 0, execute process A. Then execute process E and call procedure Py’.
Process C. (Page alignment)
If o' <L' — 1 and p > 0: execute process D, call procedure PN, and repeat process C.
Fo <L' — 1 and p = 0: execute process D until p' =L' — 1.
If o' + 1> R’: execute process E, call procedure PR', and repeat process C.
If p° + 17 P': execute process E, call procedure Pp-, and repeat process C.
Process D. Skip the output medium to the next line, set p = 0, and set p' =p' +1.
Process E. Skip the output medium to the next page, and set p' = 0.
Steps 1-9 and Process A-E have been implemented as follows:
Step 1. (Initialization)
The hidden variables are set to standard values:
H1 is set to the standard format °°.
H2 is set so that L = 1, R = =,
H3 is set so that L’ = 1, В’ = œ,
H4 is set so that Py, Pr, Pp are all effectively equal to the DUMMY procedure defined as follows:
"procedure DUMMY;;".
H5 is set so that Py, Pr’, Pp’ are all effectively equal to DUMMY.
H7 is set so that TAB = 1.
83
Step 2. (Layout)
The layout procedure is called; this may change some of the variables H1,H2,H3,H4,H5,H". Set T to
false. (T is a Boolean variable used to control the sequencing of data with respect to title formats;
T = true means a value has been transmitted to the procedure which has not yet been output.)
Step 3. (Communication with list procedure)
The next format item of the format string is examined. (Note. After the format string is exhausted,
standard format, Section A.5, is used until the end of the procedure. In particular, if the format string
is *”, standard format is used throughout.) If the next format item is a title format (requires no data
item), proceed directly to step 4. If T = true proceed to step 4. Otherwise, the list procedure is
activated: this is initiated by calling the list procedure, using a procedure named OUT ITEM as the
actual parameter. Each subsequent return from the procedure OUT ITEM will cause the list procedure
to be continued from the latest OUT ITEM call. Since the scope of the identifier OUT ITEM is local to
OUT LIST, this procedure cannot be called directly.
After the list procedure has been activated it will either terminate or call the procedure QUT ITEM.
If it terminates the output process is completed. If the procedure OUT ITEM is called, T is set to
true [and any assignments to hidden variables that may have been made by calls on list procedures will
cause adjustment to the variables H1,H2,H3,H4,H5,H7, which are local to OUT ITEM, the procedure will
then continue at step 4.
Step 4. (Alignment marks)
If the next format item includes alignment marks at its left, process A (a subroutine below) is executed
for each /, process B for each | and process C for each J. |
Step 5. (Get within margins)
Process G is executed to ensure proper page and line alignment.
Step 6. (Formatting the output)
The next item is taken from the format string.
In unusual cases, the list procedure or an overflow procedure may have called the descriptive procedure
format, thereby changing the format string. If so, the new format string is examined from the beginning;
and it is conceivable that the format items examined in steps 3, 4, 6 might be three different formats.
At this point, the current format item is effectively removed from the format string and copied elsewhere;
so that the format string itself, possibly changed by further calls of format, will not be interrogated until
the next occurrence of step 3.
Alignment marks at the left of the format item are ignored. If the format item is not composed only of
alignment marks and insertions, the value of T is examined. If T = false, action is undefined (a nontitle
format has been substituted for a title format in an overflow procedure, and this is not allowed). Other-
wise, the output item is evaluated and T is set to false. The rules of format are applied and the char-
acters XqXo...Xg, Which represent the formatted output on the external device, are determined.
84
Step 7. (Check for overflow)
If p + s=<R and p +s =P, where s is the size of the item as determined in step 6, the item will fit on
this line, so step 9 is executed.
Step 8. (Processing of overflow)
Process H (p + s) is performed. Then if p + s =R and p + s =P, step 9 is executed; otherwise K is set
to min (R, P) - р. x,X9.. .x, is output, p is set = min (R, P), and xyXg...Xg_ | tO X41} X49... Xg. 8 is
decreased by k and step 8 repeated.
Step 9. (Finish the item)
X1X9 ...X, is output, and p increased by s. Any alignment marks at the right of the format item now
cause activation of process A for each /, process B for each |, and process C for each J. Return to
step 3.
Process A (/ operation)
Page alignment is checked with process F, and process D is executed. Procedure Py; is called.
Process B (1 operation)
If p>0, process A is executed. Process E is then executed and procedure Py called.
Process C (J operation)
Page and line alignment are checked with process G. Then K is set = ((р -1, + 1) + ТАВ +1) х ТАВ +1. -1
(the next tab setting for p), where TAB is the tab spacing for this channel. If k=min (R, P), process
Hk) is performed; otherwise blanks are inserted until p =k.
Process D (New line)
The output device is skipped to the next line, p is set to 0, and p’ is set to p' +1.
Process E (New page)
The output device is skipped to the next page, and p is set to 0. Skipping the output device to a new page
involves setting character 1 of the next line to a print control character. On a normal line, character 1
is set to a value which results in single spacing. This character does not appear if the external device
is a printer; on any other device, it is the first character on the external device. When paging is
specified, character 1 is not available for use, regardless of the external device. To overcome the loss
of this character position, the procedure H LIM (Section B.3.2) increases the values of the L and R
parameters by 1.
If no paging is specified, the user may reference character 1; H LIM does not adjust the L and R param-
eter values. However, if the external device is a printer, character 1 of each record is interpreted by
the driver to control page ejection and to control random page and line skipping. The user should set
this character to avoid loss of a significant character.
85
Process F (Page alignment)
If p* +1 < L‘ process D is executed until p’ = L' -1, If p’ + 1 > R’: process E is executed, Pr: is called,
and process F is repeated. If p’ + 1 > P’: process E is executed, Pp/|is called, and process F repeated.
This process must terminate because 1<L' <R' and 1<L'<P'. (fa value 1' > P is chosen, L' is set
equal to 1.)
Process G (Page and line alignment)
Process F is executed. Then, if p + 1<L: blank spaces are output until p + 1 = L. If p+1>R or
p+ 1>P: process H (p + 1) is performed. This process must terminate because 1=L=R and 1=L =P,
If a value of L > P is chosen, L is set equal to 1.
Process H(k) (Line overflow)
Process D is performed. If k > R, PR is called; otherwise Pp is called. Then process G is performed
to ensure page and line alignment. Note: upon return from any of the overflow procedures, any assign-
ments to hidden variables made by calls on descriptive procedures will cause adjustment to the corre-
sponding variables H1,H2,H3,H4,H5,H7 local to OUT ITEM.
B.5.2 Input
The input process is initiated by the call:
in list (Unit LAYOUT,LIST)
The parameters have the same significance as they did in the case of output, except that unit is in this case the number
of an input device. There is a class of procedures input n which stand for a call with a particularly simple type of
layout and list, just as discussed in Section B.5.1 for the case of output. In the case of input, the parameters of the “item”
procedure within the list must be variables.
B.5.2 Input
The single procedure with call:
INPUT (channel, format string, eq, ©9, - - . En)
replaces the n+1 procedures defined in the proposal with call:
INPUT n (channel, format string, €1,€9,...€,)
п = 0, ©
The number of ej variables included in the call to INPUT defines to which of the n+1 procedures (defined
in the report) it is equivalent. For example:
INPUT (channel, format string, eq, eg, 3)
is equivalent to
INPUT 3 (channel, format string, €], €9, eg)
defined in the proposal.
A call to INPUT may include 0-61 variables.
86
The various steps which take place during the execution of “in list are very much the same as those in the case of
out list, with obvious changes. Instead of transferring characters of title format, the characters are ignored on input.
If the data is improper, some standard error procedure is used. (cf. Section A.1.3.8).
The only significant change occurs in the case of standard input format, in which the number S of the above algorithm
cannot be determined in step 4. The tests p + S>R and p + S>P now become a test on whether positionsp +1,0+2,...,
min (R,P) have any numbers in them or not. If so, the first number, up to its delimiter, is used: the R and P positions
serve as delimiters here. If not, however, overflow occurs, and subsequent lines are searched until a number is found
(possibly causing additional overflows). The right boundary min (R,P) will not count as a delimiter in the case of overflow.
This rule has been made so that the process of input is dual to that of output: an input item is not split across more than
one line unless it has overflowed twice. Notice that the programmer has the ability to determine the presence or absence
of data on a card when using standard format, because of the way overflow is defined. The following program, for example,
will count the number n of data items on a single input card and will read them into A{1] ,A [2] ,...,Aln]. (Assume
unit 5 is a card reader.)
procedure LAY; h end (EXIT EXIT,EXIT);
procedure LIST(ITEM); ITEM(A[n + 1] );
procedure EXIT; go to L2;
n:=0;L1: in list(S, LAY,LIST); n : = n + 1; go to L1;
L2:; comment mission accomplished;
Steps 1-9 and A - E of input have been implemented as follows:
Step 1. (Initialization)
The hidden variables are set to standard values:
H1 is set to the standard format ‘ °.
H2 is set so that L = 1, R =,
H3 is set so that L’ = 1, R° = œ,
H4 is set so that Py, Py, Ppare all effectively equal to the DUMMY procedure defined as follows:
"procedure DUMMY;;",
Н5 15 set so that Pyy, Pps Pp’ are all effectively equal to DUMMY.
H6 is set to terminate the program in case the data ends.
H7 is set so that TAB = 1,
Step 2. (Layout)
The layout procedure is called; this may change some of the variables H1,H2,H3 ,H4,H5,H6,H7. Set T to
false. T is a Boolean variable used to control the sequencing of data with respect to title formats;
T=t true means a value has been requested of the procedure which has not yet been input,
87
Step 3. (Communication with list procedure)
The next format item of the format string is examined. (After the format string is exhausted, standard
format is used until the end of the procedure. In particular, if the format string is *”, standard format
is used throughout.) If the next format item is a title format, (requires no data item)' step 4 is executed
directly. If T = true step 4 is executed. Otherwise, the list procedure is activated; this is initiated by
calling the list procedure, using a procedure named IN ITEM as the actual parameter. Each subsequent
return from the procedure IN ITEM, will cause the list procedure to be continued from the latest IN
ITEM call. Since the scope of the identifier IN ITEM is local to IN LIST, this procedure cannot be called
directly. After the list procedure has been activated, it will either terminate or it will call the proced -
ure IN ITEM. In the former case, the input process is completed; in the latter case, T is set to true
and any assignments to hidden variables resulting from the list procedure will cause adjustments to
the variables H1, H2, НЗ, H4, H5, H6, H7 (which are local to IN ITEM) and will then continue at step 4.
Step 4. (Alignment marks)
If the next format item includes alignment marks at its left, process A is executed (a subroutine below)
for each / , process B for each f , and process C for each J.
Step 5. (Get within margins)
Process G is executed to ensure proper page and line alignment.
Step 6. (Formatting for input)
The next item is taken from the format string. In unusual cases, the list procedure or an overflow pro-
cedure may have called the descriptive procedure format, thereby changing the format string. In such
cases, the new format string is examined from the beginning; it is conceivable that the format items |
examined in steps 3, 4, 6 might be three different formats. At this point, the current format item is
effectively removed from the format string and copied elsewhere; so that the format string itself, pos-
sibly changed by further calls of format, will not be interrogated until the next occurrence of step 3.
Alignment marks at the left of the format item are ignored. If the format item is not composed only of
alignment marks and insertions, the value of T is examined. If T = false, undefined action takes place
(a nontitle format has been substituted for a title format in an overflow ow procedure, and this is not
allowed). Otherwise, T is set to false.
Step 7. (Check for overflow)
If the present item uses N format, the character positions p +1, p + 2,...are examined until either a
delimited number has been found, (in which case p is advanced to the position following the number, and
step 9 is executed) or position min (R, P) has been reached with no sign, digit, decimal point, or 10
encountered. In this case, step 8 is executed with p = min (R,P). If N format is not used, step 8 is
executed if p + s > min (R, P), or step 9 if p + s < min (R, P).
Step 8. (Processing of overflow)
Process H (p +s) is performed and the following procedure:
N format: Characters are input until a number followed by a delimiter is found and step 9 is executed;
or if position min (R, P) is reached, a partial number may have been examined. Step 8 is repeated until
a number followed by a delimiter has been input.
88
Other: If p+s <R and p +s =P, step 9 is executed; otherwise input k = min (R, P) -p characters, set
p = min (R, P) decrease s by k, and repeat this step.
Step 9. (Finish the item)
If any format other than N is being used, s characters are input. The value of the item that was input
here is determined (steps 7 and 8 in the case of N format) using the rules of format. This value is
assigned to the actual parameter of IN ITEM unless a title format was specified. p is increased by s.
Any alignment marks at the right of the format item now cause activation of process A for each /,
process B for each |, and process C for each J. Return to step 3.
Process A ( / operation)
Page alignment is checked with process F, process D is executed and procedure Py called.
Process B ( | operation)
If p=0, process A is executed. Then process E is executed and procedure Ps called.
Process C. (J operation)
Page and line alignment are checked with process G. Then letk = ((p-L+1) + TAB+1)x TAB+L -1
(the next tab setting for p), where TAB is the tab spacing for this channel. If k =min (В, P), process
H(k) is performéd; otherwise character positions are skipped until p =k.
Process D, (New line)
The input medium is skipped to the next line, p is set to 0, and p’is set to p’ + 1.
Process E. (New page)
The input medium is skipped to the next page, and p’is set to 0. Skipping the input device to a new page
involves the assumption that the next line on the input device begins the new page (control character in
position 1 which is not accessible by the program) as specified in the corresponding process of output.
Process TF. (Page alignment)
Н р’ + 1<L' process D is executed until p’=L’ - 1. If p’+ 1>R’: process E is executed, Pp called, and
process C repeated, If p+ 1>P: process E is executed, P p called, and process C repeated. This
process must terminate because 1 =L'=R’ and 1=<L'=P, (If a value of L’ >P is chosen, L’ is set equal
to 1.)
Process G. (Page and line alignment)
Process F is executed. Then, if p+1<L: character positions are skipped until p+1=L. If p+1>R or
p+1>P: process H (p+1) is performed. This process must terminate because 1=<=L<R and 1=L =P,
If a value of L>P ischosen, Lis set equal to 1.
Process H(k) (Line overflow)
89
Process D is performed. If k>R, Pp is called; otherwise Pp is called, Then process G is performed
to ensure page and line alignment, NOTE: Upon return from any of the overflow procedures, any
assignments to hidden variables that have been made by calls on descriptive procedures, will cause
adjustments to the corresponding variables, H1, H2, H3, H4, H5, H6, H7 local to IN ITEM.
B.5.3 Skipping
Two procedures are available which achieve an effect similar to that of the “tab” key on a typewriter:
h skip (position, OVERFLOW)
v skip (position, OVERFLOW)
where position is an integer variable called by value, and OVERFLOW is the name of a procedure. These procedures are
defined only if they are called within a list procedure duringan inlist or outlist operation. For h skip,
if p< position, set p = position; but if p = position, call the procedure OVERFLOW. For v skip, an analogous proce-
dure is carried out: if p' <position, effectively execute process A of Section B.5.1 (position -- p') times; but if p’ > position,
call the procedure OVERFLOW.
B.5.3 Skipping
The procedures H SKIP and V SKIP have been replaced by the procedure TABULATION, described in
Section B.3.3.
B.5.4 Intermediate data storage
The procedure call
put (n, LIST)
where n is an integer parameter called by value and LIST is the name of a list procedure (Section B.4), takes the value
specified by the list procedure and stores them, together with the identification number n. Anything previously stored
with the same identification number is lost. The variables entering into the list do not lose their values
The procedure call
get (n, LIST)
where n is an integer parameter called by value and LIST is the name of a list procedure, is used to retrieve the set of
values which has previously been put away with identification number n. The items in LIST must be variables. The
stored values are retrieved in the same order as they were placed, and they must be compatible with the type of the ele-
ments specified by LIST; transfer functions may be invoked to convert from real to integer type or vice versa. If fewer
items are in LIST than are associated with n, only the first are retrieved; if LIST contains more items, the situation is
undefined. The values associated with n in the external storage are not changed by get.
B.5.4 Intermediate Data Storage
The procedures GET and PUT are not implemented; they have been replaced by GET ARRAY and PUT
ARRAY, although these are in no way analogous. The calls are:
GET ARRAY (channel,destination)
PUT ARRAY (channel,source)
90
Destination and source are the names of arrays. These procedures can be used only on channels de-
fined with the character A on the channel card (Chapter 7).
GET ARRAY reads one record of the same length as destination directly from the channel into destina -
tion. The record is not stored first in a format area, and no regard is made for maximum record size
or paging. The record should contain the array arranged by rows (as defined in Transmission of Array).
PUT ARRAY writes one record, equal in length to source, directly from source to the channel. The
record is not stored first in a format area and no regard is made for maximum record size or paging.
The record reflects exactly how the array is stored in memory, by rows.
B.6 Control Procedures
The procedure calls
out control (unit, x1,x2,x3,x4)
in control (unit, x1,x2,x3,x4) |
may be used by the programmer to determine the values of normaily “hidden” system parameters, in order to have finer
control over input and output. Here unit is the number of an output or input device, and x1,x2 X3,x4 are variables. The
action of these procedures is to set x1,x2,x3,x4 equal to the current values of p,P, p',P” » respectively, corresponding to
the device specified. |
B.6 Control Procedure
In the input-output system as described up to this point, the physical limits characteristic of the various
devices (P,P’), the number of spaces (k) which serves as a number delimiter in standard format, and the
current value of the character pointers (p, p’), are effectively system parameters which are not directly
accessible to the programmer, These quantities are accessible to, and in many cases modified by, the
several input and output procedures.
To obtain finer control over the input-output processes, the programmer can gain access to these
quantities through the procedure call
SYSPARAM (channel,function,quantity)
Channel is an arithmetic expression called by value specifying the input-output device concerned.
Function is an arithmetic expression called by value specifying the particular quantity to be accessed,
and specifying whether that quantity is to be interrogated or changed.
Quantity is an integer variable called by name which will either represent the new value or be assigned
the present value of the quantity dependent on function.
The following list defines the standard set of quantities accessible through SYSPARAM and the corre-
sponding value of function,
91
For the external device associated with channel:
If function = 1, quantity : = p;
If function = 2, р: = quantity
If function = 3, quantity : = p’;
If function = 4, p’ : = quantity?
If function = 5, quantity : = P;
If function = 6, P : = quantitytt
If function = 7, quantity : = P’;
If function = 8, P’ : = quantitytt
If function = 9, quantity : =k;
If function = 10, k : = quantity
p and p’ are the character and line pointers
P and P’ are the physical limits of the device
k is the number of blanks delimiting a standard number format
B.7 Other Procedures
Other procedures which apply to specific input or output devices may be defined at installations, (tape skip and
rewind for controlling magnetic tape, etc.). An installation may also define further descriptive procedures (thus
introducing further hidden variables); for example, a procedure might be added to name a label to go to in case of an
input error. Procedures for obtaining the current values of hidden variables might also be incorporated.
B.7 Other Procedures
The following additional procedures have been implemented. They are described fully in 3.3 and 3.4.
{Since p and p' represent the actual (physical) positions on the external device, function = 2 or 4 will
generally cause some action to take place for that device. When setting p if quantity > p, insert
blanks until p = quantity. If quantity <p perform a line advance operation, set p = 0 and insert blanks
until p = quantity. When setting p' if quantity >p’ perform line advance operations until p' = quantity.
If quantity <p’ skip to next page, set p’ = 0, and perform line advance operations until p’ = quantity.
ttThese operations change the physical limits for the input-output device where this is possible (e.g.,
block length on magnetic tape). When these limits cannot be changed for the input-output device these
functions are equivalent to a dummy statement.
92
CHLENGTH
STRING ELEMENT
MANINT (Label)
ARTHOFLW (label)
Control Procedures ( PARITY (channel, label)
EOF (channel, label)
\ BAD DATA (channel, label)
/ SKIPF (channel)
SKIPB (channel)
ENDFILE (channel)
REWIND (channel)
UNLOAD (channel)
\ BACKSPACE (channel)
IOLTH (channel)
MODE (channel, type)
CONNECT (channel, array, label)
Ty
Hardware Function Procedures 4
DUMP (identifying integer)
C. An Example
A simple example follows, which is to print the first 20 lines of Pascal's triangle in triangular form:
These first 20 lines involve numbers which are at most five digits in magnitude. The output is to begin a new page, and it
is to be double-spaced and preceded by the title “PASCALS TRIANGLE". We assume that unit number 3 is a line printer.
Two solutions of the problem are given, each of which uses slightly different portions of the input-output conventions.
begin integer N, K, printer;
integer array A{0:19];
procedure AK (ITEM); ITEM (A[K]):
procedure TRIANGLE; begin format (‘62’); h lim (58 - 3 X N, 63 + 3 X N)
end;
93
printer :=3;
output O (printer, ‘* PASCALSUTRIANGLE*//):
for N :=0 step 1 until 19 do
begin A[N] :=1;
for K :=N — 1 step —1 until 1 do A[K] := А[К - 1] + A[K];
for K :=0 step 1 until N do out list (printer, TRIANGLE,AK) ;
output O (printer, ‘//”) end end
begin integer N,K, printer:
integer array A[0:19];
procedure LINES;format 2 (*XB,X(62Z),//,57-3XN,N+1) ;
procedure LIST(Q); for K :=0 step 1 until N do Q(A[K]);
printer := 3;
output 1 (printer, ‘120S//’,'PASCALSL TRIANGLE’);
for N :=0 step 1 until 19 do
begin À [N] : = 1;
for K :=N - 1 step —1 until 1 do A[K] : = A[K - 1] + A[K]:
out list (printer, LINES,LIST) end end
D. Machine-dependent Portions
Since input-output processes must be machine-dependent to a certain extent, the portions of this proposal which are
machine-dependent are summarized here.
1.
2.
94
The values of P and P' for the input and output devices.
The treatment of |,L, and R (unformatted) format.
The number of characters in standard output format.
The internal representation of alpha format.
The number of spaces, K, which will serve to delimit standard input format values.
REFERENCES
Naur, P.(Ed.) Revised report on the algorithmic language ALGOL-60 Comm. ACM 6 (1963), 1-17.
Extended ALGOL reference manual for the Burroughs B-5000. No. 5000-2102, Burroughs Corp., Detroit, 1963.
SHARE ALGOL-60 translator manual. No. 1426,1577 SHARE Distr. Agency. Oak Ridge ALGOL compiler for the Con-
trol Data 1604 computer. Oak Ridge Nat. Lab., Oak Ridge, Tenn.
Duncan, F. G. Input and output for ALGOL-60 on KDF 9. Comp. J. 5 (1963), 341-344.
Hoare, C. A. R. The Elliott ALGOL input/output system. Comp. J. 5 (1963), 345-348.
McCracken, D. D. Guide to ALGOL programming. Wiley, New York, 1962. AED compiler. Electronic Systems lab.,
MIT, Cambridge, Mass.
Ingerman, P. Z. A syntax-oriented compiler, etc. U of Penn., Moore School of Elect. Engineering, Philadelphia, Pa. 1963.
Ingerman, P. Z., and Merner, J. N. Revised revised ALGOL-60 report. Unpublished.
Perlis, A. J. A format language. Comm. ACM 7 (1964), 89-97.
Baumann, R. ALGOL -Manual der ALCOR-Gruppe. Elektron, Rechen. H. 5/6 (1961), H.2 (1962).
95
3.2 ADDITIONAL INPUT-OUTPUT PROCEDURES
An additional set of primitive procedures exists without declaration, as follows:
CHLENGTH (string)
STRING ELEMENT (51,1, 52, Хх)
3.2.1 CHLENGTH
CHLENGTH is an integer procedure with a string as a parameter. The value of CHLENGTH (string)
is equal to the number of characters of the open string enclosed between the outermost string quotes.
It is introduced to make it possible to calculate the length of a given (actual or formal) string. Each
embedded string quote counts as three characters, because the 48-character representation of the
ALGOL symbol * is '(' and * is ')' (see Table 1, Chapter 4).
3.2.2 STRING ELEMENT
The procedure STRING ELEMENT is introduced to enable the scanning or interpretation of a given
string (actual or formal) in a machine independent manner. It assigns to the integer variable x an
integer corresponding to the ith character of the string sl as encoded by the string s2.
Effectively an OUT CHARACTER (Section B. 5) process is performed on the string sl according to
the integer variable i. An IN CHARACTER process is then performed with the resultant character
on the string s2, producing an integer value to be stored in the integer variable x.
3.3 CONTROL PROCEDURES
Each one of these procedures establishes a label to which control
transfers in the event of a manual interrupt, arithmetic error
(overflow, underflow or division fault), irrecoverable parity error,
TMANINT (label) end-of-file condition, or mismatch of input data and the corresponding
ARTHOFLW (label) format. Each procedure can be called as many times as necessary
to modify the label in the course of a program. PARITY, EOF, and
PARITY (channel,label) BAD DATA must be called once for each channel for which a label is
EOF (channel,label) to be established. If a procedure has not been called; or if the label
is no longer accessible when the corresponding condition occurs, the
BAD DATA (channel,label) \ object program terminates abnormally with an error message.
If IN LIST is in operation, a label may be established by the NO
DATA procedure (Section B. 3.4) instead of by the EOF procedure.
During the execution of the IN LIST procedure, any label establishecl
by NO DATA procedure takes precedence over an EOF label.
TA MANINT label can be established for lower 3000 MASTER, upper 3000, and 6000, but control
cannot be forced to go to the label by any external means.
96
3.4 HARDWARE FUNCTION PROCEDURES
A channel is input if last used for a read operation, output if last used for a write operation, and
closed if not previously referenced or if referenced by a closing procedure such as ENDFILE.
If any of the following procedures are called for an external device which cannot perform the opera-
tion, the procedure is treated as a dummy procedure; and at the completion of the procedure, the
channel is considered to be closed.
SKIPF (channel)
This procedure spaces the external device forward past one end-of-file mark. Itis treated as a
dummy procedure on an output channel. If the channel is associated with a mass-storage device,
the procedure is treated as a dummy procedure.
SKIPB (channel)
This procedure spaces the external device backwards past one end-of-file mark. On an output
channel before the spacing occurs, any information in the format area is written out and an end-
of-file mark is written and backspaced over. If the channel is associated with a mass-storage
device, the procedure is treated as a dummy procedure.
ENDFILE (channel)
This procedure writes an end-of-file mark on the external device. It is treated as a dummy proce-
dure on an input channel. Before the end-of-file mark is written, any information in the format
area is written out.
REWIND (channel)
This procedure rewinds the external device to load point. On output before rewind occurs, any
information in the format area is written out; and an end-of-file mark is written and backspaced
over.
UNLOAD (channel)
This procedure unloads the external device. On output before unloading occurs, any information in
the format area is written out; and an end-of-file mark is written and backspaced over.
BACKSPACE (channel)
This procedure backspaces past one line on a non-A type channel and one operating system logical
record on an A type channel. On output before the backspace occurs, any information in the format
. area is written out; and an end-of-file mark is written and backspaced over.
97
3.5 MISCELLANEOUS PROCEDURES
IOLTH (channel)
This procedure can be used only on non-formatted channels (those used for GET ARRAY and PUT
ARRAY). It yields the number of array elements in the last read or write operation on the external
device (the number in the last GET ARRAY or PUT ARRAY operation).
MODE (channel, type).
This procedure sets density or parity for the subsequent reading or writing of the external device.
Density and parity are initialized on a channel card and depend on the value of TYPE, as follows:
0 No density or parity selection required
1 Do not change density, set parity to odd (binary)
Do not change density, set parity to even (BCD)
No .density selection required, do not change parity
Set density to low (200 bpi), do not change parity
Set density to medium (556 bpi), do not change parity
Sa E WwW N
Set density to high (800 bpi), do not change parity.
T CONNECT (channel, array, label)
This procedure is used to connect the array ARRAY to the channel specified by CHANNEL, so that
the array may be used as the formatting area of the channel (Chapter 7). If, for any reason, the
connection cannot be made (e. g. , the array size is too small to encompass the desired formatting
area) an exit to the label LABEL is taken.
Upon exiting the block in which the array ARRAY is declared, the channel CHANNEL is returned to
its closed state. On output, any information in the formatting area is written out and an end-of-file
mark is written and backspaced over.
DUMP (identifying integer)
This procedure may be used to obtain output of the local (and formal) variables in the currently
active block (procedure body). The format is that of the object-time abnormal termination dump
(Chapter 12). The dump is entitled:
THIS IS DUMP NUMBER <identifying integer> AT LINE <line number>
Identifying integer is an integer type variable, and the number is modulo 8192. 'The line number is
the source line number from which DUMP was called.
T CONNECT is a dummy procedure for lower 3000.
98
3.6 INPUT-OUTPUT ERRORS
At object-time, two types of errors not directly concerned with programming are detected: illegal
input-output operation requests and invalid transmission of data (Chapter 8).
3.6.1 ILLEGAL INPUT-OUTPUT OPERATIONS
The object program terminates abnormally with a diagnostic if:
An input (output) operation is requested on a channel associated with a device which cannot
read (write), or on a device which is prevented by the operating system from reading (writing).
If the last operation on the channel was neither an input (output) nor a closing operation (such as
REWIND for input).
3.6.2 TRANSMISSION ERRORS
Transmission errors are first treated by standard recovery procedures. If an error persists, it is
irrecoverable.
On an irrecoverable parity error, control transfers to the label established for the channel by the
PARITY procedure. If the PARITY procedure was not called or if the established label is no longer
accessible, the object program terminates abnormally with the diagnostic UNCHECKED PARITY.
3.7 END-OF-FILE
When an end-of-file is encountered on an external input device, control transfers to the label
established for the channel by the NO DATA procedure (within IN LIST only) or the EOF procedure.
If neither procedure has been called and if a label established by either is no longer accessible, the
object program terminates abnormally with the message UNCHECKED EOF. During execution of
the IN LIST procedure, any label established by NO DATA takes precedence over a label established
by EOF.
3.8 END-OF-TAPE
If an end-of-tape is detected during writing, the standard system end of tape procedure is executed.
99
INPUT TO COMPILATION 4
Input to the compiler may be an ALGOL source program or an ALGOL source procedure. More
than one source program or source procedure may be compiled with a single call of the compiler.
In the following definitions, the symbol eop indicates a card which contains only the characters
'EHOP', in columns 10-14.
-
4.1 SOURCE PROGRAM DEFINITION
The following definition for an ALGOL source program is based on the definition of an ALGOL
program (Section 4.1.1, Chapter 2).
Syntax
<pre> :: = <empty> < any sequence of symbols except
begin, code or procedure>
<post> :: = <empty> | <any sequence of symbols except eop>
< source program> :: = <pre> <program> <post> eop
Semantics
À source program must contain declarations for all variables referenced in it. It must contain
declarations for all procedures (except standard) it calls, including procedures that are compiled
separately from the main program as an ALGOL source procedure (Section 5.4.6, Chapter 2).
Compilation of an ALGOL source program (generation of object code) starts with the first ALGOL
symbol 'BEGIN' in the source deck and terminates with the end symbol which causes the number
of begin and end symbols to be equal, or the eop card, whichever occurs first. If the eop card
occurs first, however, a diagnostic is issued.
Any information in the source deck prior to the first begin or between the final end and the eop is
treated as a commentary, printed as part of the source listing and included in the line count.
A program name is generated from the characters in columns 1-7 in 6000 (and 1-8 in 3000): of the
first source deck card, provided the character in column 1 is alphabetic. This name is terminated
with the seventh (eighth) character or by the first non-alphanumeric character encountered. If the
character in column 1 is not alphabetic, the name generated is XXA LGOL (XXXALGOL). The
generated name is assigned to the subprogram output from the source program (Chapter 5) and is
printed on the page headings of the source listing.
100
4.2 SOURCE PROCEDURE DEFINITION
The following definition of an ALGOL source procedure is based on the definition of a procedure
declaration in the ALGOL-60 Revised Report (Section 5.4.1).
Syntax
<pre> ::= <empty> | < any sequence of symbols except
begin, code or procedure>
<mid> :: = <empty> | <any sequence of symbols except procedure>
<post> ::= <empty> | <any sequence of symbols except eop>
<d> :: = <digit>
<code number> ::= <d> | <d><d> | <d> <d> <d> | <d><d><d><d> |
<d><d><d><d><d>
<code head> :: = <pre> code <code number>; <mid>
<code tail> :: = еор | ; <post> eop
< source procedure> :: = <code head>
< procedure declaration >
< code tail >
Semantics
À source procedure must contain declarations for all variables referenced in it. It must contain
declarations for all procedures (except standard) it calls, including procedures which are compiled
separately as ALGOL source procedures (Section 5.4.6, Chapter 2).
À source procedure may employ the same language features as a procedure declared in a source
program, except it may not be formally recursive. That is, the procedure identifier may not oceur
within the body of the procedure other than in a left part in an assignment statement (Section 5. 4. 3,
Chapter 2).
Compilation of an ALGOL source procedure is initiated by the ALGOL symbol code ("CODE"). This
symbol must be followed immediately by a number in the range 0-99999, and then by a semi-colon
(.»). The same code number is included in the body of the declaration for this procedure in the
source program or source procedure referencing it (Section 5.4.6, Chapter 2).
Compilation of an ALGOL source procedure starts with the symbol procedure ("PROCEDURE") which
may be preceded by one of the type declarators real ("REAL"), integer ("INTEGER"), or Boolean
(BOOLEAN).
101
If the procedure symbol is encountered before the code symbol, compilation of the procedure starts
normally, but an error message is issued, and the code number 00000 is supplied.
Compilation of an ALGOL source procedure ends at the normal end of the procedure declaration.
If the body of the procedure is a single statement, the end is at the semi-colon (.,) terminating that
statement. If the body is a compound statement or block, the end is at the semi-colon following the
balance of begin and end symbols.
The semi-colon in both cases may be replaced by the eop card. If the eop card occurs before the
single statement is complete or before begin and end symbols balance, a diagnostic is issued.
Information in the source deck prior to the code symbol, between the code number and the procedure
symbol, and between the end of the procedure and the eop card is treated as commentary. Commen-
taries are printed as part of the source listing and included in the line count.
The name generated for the procedure is always CPxxxxx (CDPxxxxx) where xxxxx is the code
number. If five digits are not specified, the number is zero-filled on the left. For example, 20
becomes 00020. Any error in the specification of the code number results in 00000. The generated
name is assigned to the subprogram output from the source procedure and is also printed on the page
headings of the source listing. |
4.3 SOURCE INPUT RESTRICTIONS
A single source program or single source procedure, or any combination of these, may be compiled
with one call of the compiler. Whether the resulting output constitutes an acceptable object program
for execution depends on the mode (segmented or non-segmented) of the output, and any special binary
subprogram input (Chapter 5).
The object program resulting from the compilation of a single source program in either mode, with
no special binary subprogram input, is always executable, provided there are no compilation errors.
Source input for compilation must be in the form of cards or card images, described here only as
cards.
Various operating system control cards are required to request an ALGOL compilation. Included
in these is the ALGOL control card (Chapter 6).
4.4 LANGUAGE CONVENTIONS
The input cards contain the character representations for the ALGOL symbols shown in Table 1
For example, to include the ALGOL symbol begin, the user punches the characters 'BEGIN'.
102
A blank character has no effect on the compilation process, except in strings (Chapter 2). Blanks
may be freely used elsewhere to facilitate reading. For example, MEAN UPPER BOUND, MEAN
UPPERBOUND, and MEANUPPERBOUND are treated as being identical (the same name). Similarly,
blanks may be included in the character representation of the ALGOL symbols. The ALGOL symbol
real may be punched as 'REA L' instead of the normal 'REAL'.
4.5 CARD CONVENTIONS
Only columns 1-72 of each card are interpreted by the compiler. No syntactic meaning is attached
to these boundaries; any language structure may appear across the boundaries of two or more cards.
At compile-time, each card is counted and assigned a line count (beginning at 0) for reference by
error messages. This line count is included in all source language listings as are columns 73-80
of each card.
4.6 SOURCE DECK
A source deck consists of the cards which constitute one ALGOL source program or one ALGOL
source procedure. The last card in a source deck must contain only the characters 'EOP' (eop)
in columns 10-14.
The source decks to be compiled are stacked consecutively, following the operating system control
cards. The stack may contain any number of source programs or source procedures in any order
within the restrictions described above. 'The 'EOP' card of the last source deck must be followed by
a card containing only FINIS in columns 10-14. In 6000 ALGOL only, the source stack appears as
one logical record on the input file. The ALGOL compiler may be called for two purposes in which
no compilation of a source stack occurs:
Preparation of a segmented object program exclusively from relocatable binary subprogram
input (G option)
Execution of a segmented object program which already exists from a previous compilation
(R option only)
In these two cases, the source input stack and the FINIS card must be absent.
103
104
PROGRAM SOURCE DECK
terminal commentary’
//END'
/
[ 'BEGIN' source code
initial commentary!
program namef
T Optional
PROCEDURE SOURCE DECK
'code' nnnnn. , followed by
'real' 'procedure' or
'integer' 'procedure' or
( "EOP!
Zz
Zz
A
L£
Éd |
8 terminal commentary?
/ 'END' |
|
1
]
( source code
/
L
/ E.
initial commentary?
|
'procedure'
T Optional
105
Table 1. Character Representation of ALGOL Symbols
ALGOL 48-Character ALGOL 48-Character
Symbol Representation Symbol Representation
A-Z A-Z true "TRUE"
a-z ~ false 'FALSE'
0-9 0-9 go to 'GO TO'
+ + if "IF!
- - then "THEN"
X * else 'ELSE'
/ / for "FOR
tt 'POWER' do 'DO'
+ / or 'DIV' step 'STEP'
> 'GREATER' until "UNTIL
> "NOT LESS while 'WHILE'
= = or "EQUAL" comment "COMMENT!
# "NOT EQUAL’ begin "BEGIN"
< "NOT GREATER' end 'END'
< 'LESS' own 'OWN'
A 'AND' Boolean -"BOOLEAN'
у 'OR' integer 'INTEGER'
= 'EQUIV real 'REAL'
= "NOT" array 'ARRAY'
2 "TMPL' switch 'SWITCH'
. . procedure "PROCEDURE!"
, , string 'ST RING"
: .. label "LABEL!
; > value "VALUE"
10 ! code TT 'CODE'
Ld UU eop tt 'EOP'
( (
= .=Or ..=
) )
[ (/
] /)
6 '"(
9 ')'
+ In a format string, t is represented by an asterisk.
+7 Not defined in the ALGOL-60 Revised Report; code is defined in Section 5.4.1, Chapter 2;
eop in Chapter +4.
106
OUTPUTS FROM COMPILATION 5
5.1 BINARY OUTPUT
The binary output (machine code) generated from one ALGOL compilation (one library call of the
ALGOL compiler) may be requested in non-segmented or segmented form by a control card option.
The maximum size of the binary output generated from a single source program or source procedure
deck is 131,072 words in the 6000 series (or 32,768 in the 3000).
The non-segmented mode generates an object program which can be loaded for execution by the system
loader. This mode may be requested also when the output is to be used as supplemental input to a
subsequent ALGOL compilation which calls for segmented output.
When the object program and its data requirement will not fit as a whole into available memory,
the segmented mode should be requested. The object program is divided into 512-word segments
to be loaded by a special loader routine contained in the run-time supervisory subprogram ALGS.
5.1.1 NON-SEGMENTED OUTPUT
For each source program or source procedure deck in the source input stack (Chapter 4), the com-
piler generates a standard operating system binary relocatable subprogram. These subprograms
are written out on the load-and-go and/or the punch unit in accordance with operating system
specifications.
After compilation, the load-and-go file also contains any subprograms written on it in the same job
prior to the compilation. These subprograms may be written in any way —- by an assembly, copy,
or another ALGOL compilation.
An object program to be loaded for execution must contain only one subprogram generated from a
source program, but it may contain the subprograms for any number of separately compiled source
procedures. Any attempt to load an object program which is not legal in this sense may result in a
system loader error or unpredictable execution.
Since the output from compilation need not be executed (for example, may be used only as supple-
mentary input to another compilation), there are no compiler restrictions on the number and order
of source program and source procedure decks in a source input stack (Chapter 4).
Each subprogram output by the compiler is a multiple of 512 words long and is assigned the name
generated when the source deck is read.
107
Each subprogram contains an external name for any standard library subprograms or separately
compiled source procedures called in that subprogram, and also the external name ALGORUN for
6000 and ALGOLRUN for 3000 (the library subprogram which contains all of the global routines
controlling object program execution).
Thus, a legal object program causes the loading of the object program itself, the standard library
subprograms and separately compiled source procedures called, and the controlling program
ALGORUN, (or ALGOLRUN,.
5.1.2 SEGMENTED OUTPUT
For an ALGOL compilation requesting segmented output, the compiler generates a segment file
which contains the binary form of the object code in 512-word segments. The segmented form of
the object code can be the subprograms (multiples of 512-words) of the non-segmented form, divided
into individual 512-word segments. The segment file contains the subprograms for:
1. Each source program deck in the source stack
2. Each source procedure in the source stack
In addition, if supplementary user binary subprogram input is specified on the control card (U option)
the file contains:
3. Each of the user's subprograms
Also incorporated in the segment file are:
4. The subprograms for each of the standard library procedures called from the subprograms
inl, 2, 3or4
GI
All remaining subprograms for each separately compiled source procedure called from the
subprograms in 1, 2, 3 or 4 which are not yet incorporated
In the mode which calls for compilation from user binary subprograms (G option), the segment file
does not contain the subprograms created from steps 1 and 2, since the source stack is empty.
A segment file must contain only one subprogram generated from a source program and may contain
the subprograms for not more than 50 separately compiled source procedures.
A segment file may contain no more than 511 segments (261,632 words).
Since a segment file can be used only for execution under compiler control, the compiler diagnoses
any infringement of these rules.
108
Loading and execution of an object program on a segment file is controlled by the ALG5 routine, the
last pass of the compiler. Thus, a segment file can be executed immediately in the same compilation
process in which it was created. Execution occurs after all source decks in the stack have been
compiled and their outputs incorporated into the segment file.
A segment file may also be saved for later execution in a completely separate process. (In this
case, ALGs5 is called immediately, and the preceding passes of the compiler are omitted.)
ALG5 contains the global routines which control object program execution plus the segment loading
routine. The segment loading routine keeps a record of each segment currently in memory. If a
segment is required for execution and it is already in memory, control passes to it immediately.
If not, the routine loads it from the segment file. Segments loaded are retained until available
memory is full and further space is required for another segment or for the object-time stack of
variables.
Segments are freely relocatable so that they may be overlaid when memory space is required. If
needed again, a segment is read back into memory (though not necessarily into the same locations
as previously occupied).
Object program execution requires space for at least two segments, otherwise execution cannot begin
or continue normally.
In lower 3000 and 6000 only, conversion of the object code from relocatable binary format (non-
segmented) to segments on the segment file involves partial or total relocation of instructions
before recording them on the file. This relocation takes into account the memory situation at
compile-time.
5.2 ASSEMBLY-LANGUAGE OBJECT CODE
The compiler generates the object code directly into binary form, with no intermediate assembly
language form. If an assembly language form of the object code is requested, the compiler encodes
the binary form into COMPASSŸ format which may be listed or punched. The listing has the same
format as a COMPASS listing, with each COMPASS instruction appearing on one line. The punch
form results in a legal COMPASS assembly deck, with one COMPASS instruction punched in the
proper positions in one card.
T 6000 COMPASS Reference Manual Pub. No. 60190900
3600 COMPASS Reference Manual Pub. No. 60052500
3000L Compatible COMPASS Reference Manual Pub. No. 60174000
109
5.3 SOURCE LISTING
The user may request a printed listing of any source program or source procedure compiled. Each
line in the listing corresponds to one card in the source deck (one line on the ALGOL coding sheet).
The lines appear in the same order as the cards in the source deck. Each line contains an exact
image of the corresponding card, right shifted for readability.
Each source card in a deck is assigned a line number by the compiler, beginning at 0. Every tenth
line of the listing contains the line number assigned to the corresponding card.
Diagnostics generated during compilation are printed following the source listing. Each consists
of a summary of the error condition and the approximate source line number on which the error was
detected.
Diagnostics are printed even if the source listing is suppressed. Chapter 8 contains a complete
description of system diagnostics.
110
ALGOL CONTROL CARD 6
6.1 6000 ALGOL
The ALGOL compiler is called from the library by a standard operating system library card — the
ALGOL control card.
The name ALGOL in columns 1-5 is followed by a parameter list which specifies input-output options.
The parameter list is enclosed in parentheses or preceded by a comma and terminated by a period.
If no parameters are specified, ALGOL must be followed by a period. The card columns following
the right parenthesis or the period may be used for comments; they are ignored by ALGOL. The
parameters are separated by commas and may appear in any order. Blank columns used for reada-
bility are ignored. All parameters must be fully contained on one card. The general formats of
the card are:
ALGOL (e, » Co Carr)
ALGOL, ©. › C9: Ca: Ce » C
6.1.1 INPUT-OUTPUT OPTIONS
Each c; has the form c or c=fn where c is any sequence of 1-7 characters beginning with one of the
parameter letters defined below. For example, L and LIST are equally acceptable for the list
parameter. If =fn is not specified, the standard file name associated with each parameter is used;
otherwise the file name fn is used.
Except for the I parameter, the absence of any parameter suppresses the corresponding option.
If I is omitted, source input is on the standard input device.
Specification of certain parameters precludes specification of others; conflicting file names are
illegal. Illegal, meaningless, or contradictory combinations of parameters and/or file names are
diagnosed by the compiler, which makes a legal selection, outputs the following diagnostic to the
dayfile, and continues compilation normally:
ALGOL CON-CARD ERROR
v, W, X, y, z DELETED
111
Acceptable parameter letters are defined below.
I Source input (same as absence of I unless =fn is included). Standard file name is INPUT.
L List source input; if suppressed, only diagnostics are printed. Standard file name is OUTPUT.
X Object program in standard relocatable binary (non-segmented) load-and-go form. Standard
file name is LGO.
P Object program in standard relocatable binary (non-segmented) punched form. Standard file
name is PUNCHB.
S Object program in segmented form. Suppresses any X option but not P option form of the
object program. Standard file name is SEGMENT. This file must be a disk file.
R Execute the object program in segmented form. If the S option is included also, the segmented
program compiled is executed. If the S option is not included, the segmented program is
assumed to exist already, and all options (I, U, G in particular) are suppressed. The source
stack must be completely empty. Standard file name is SEGMENT. This file must be a disk file.
U User subprogram input supplementary to I. May be included only when the S option is included.
Standard file name is LGO.
G User subprogram input exclusively. May be included only when the $ option is included.
Suppresses any explicit or implicit I option. The source stack must be empty. Standard file
name is LGO. Only one of the options U and G may be included.
A List the assembly language encoded form of the object code in standard assembly language
listing format. Standard file name is OUTPUT.
B Punch the assembly language encoded form of the object code in standard assembly language
card format. Standard file name is PUNCH.
N Suppress array bounds checking in the object program (Section 3.1.4.2, Chapter 2). No file
name required.
Some typical control cards are listed below.
ALGOL, L,5,R. Compile source input, list, prepare and execute a segmented object program.
ALGOL, L, X. Compile source input, list, prepare object program in relocatable binary
load-and-go form.
ALGOL. Compile source input, list diagnostics only. No other output.
ALGOL, G,5,R. Prepare segmented object program from user relocatable binary sub-
programs only, and execute.
Three files are used internally by the compiler, INTERM1, INTERM2, and LIBRARY; these names
should not be used for other options.
112
6.2 3000 ALGOL Excluding MASTER
The first column of the card contains a 7,9 punch, the name ALGOL appears in columns 2-6. Parameters which specify
options may appear in any order. They are separated from each other by commas; blank columns used for readability
are ignored. All parameters must be fully contained on one card. The general format of the card is:
JALGOL, C1, C7, CH... CH
6.2.1 INPUT-OUTPUT OPTIONS
Each of the c; has the form c or c=n, where c is any sequence of characters beginning with one of the acceptable param-
eter letters defined below. For example, L and LIST are equally acceptable for the list parameter. n is a logical unit num-
ber or file ordinal. If =n is not specified, the standard unit or file associated with each parameter is used; otherwise the
unit or file n is used.
Except for the I parameter, the absence of any parameter suppresses the corresponding option. The absence of I indicates
that the source input is on the standard input device.
The specification of certain parameters precludes the specification of others, conflicting file names are illegal. Any illegal,
meaningless, or contradictory combinations of parameters and/or unit numbers are diagnosed by the compiler, which
makes a legal selection, outputs the following diagnostic to the standard output device, and continues compilation normally:
ERROR IN CONTROL CARD OPTION x IS DELETED.
Acceptable parameter letters are defined below :
! Source input (same as the absence of I unless the =n option is included). Standard unit is 60.
L List the source input. Diagnostics are printed even if source listing is suppressed. Standard unit is 61.
X Object Program in standard relocatable binary (non-segmented) load-and-go form. Standard unit is 69 for upper
3000 and 56 for lower 3000.
P Object Program in standard relocatable binary (non-segmented) punched form. Standard unit is 62.
S Object Program in segmented form. Suppresses any X option but not P option form of the object program. Standard
unit is 27 for upper 3000 and 55 for lower 3000.
R Execute the object program in segmented form. If the S option is also included, the segmented program compiled is
executed. If the S option is not included, the segmented program is assumed to exist already, and all options (I, U,
G in particular) are suppressed. The source stack must be completely empty. Standard unit is 27 for upper 3000 and
55 for lower 3000.
U User subprogram input supplementary to I. May only be included when the S option is included. Standard unit is 69
for upper 3000 and 60 for lower 3000. (The U option is not included under lower 3000 SCOPE.)
G User subprogram input exclusively. May be included only when the S option is included. Suppresses any explicit or
implicit I option. The source stack must be completely empty. Standard unit is 69 for upper 3000 and 56 for lower
3000. (MSOS is 60.)
A List the assembly language encoded form of the object code in standard assembly language listing format. Standard
unit is 61.
113
B Punch the assembly language encoded form of the object code in standard assembly language card format. Standard
unit is 62.
N Suppress array bounds checking in the object program (Section 3.1.4.2, Chapter 2). No logical unit required.
Some typical control cards are listed below:
JALGOL,LS.R Compile source input, list, prepare and execute a segmented object program.
SAL GOL,L,X Compile source input, list, prepare object program in relocatable binary load-and-go form.
AL GOL Compile source input, list diagnostics only. No other output.
JALGOL,G.S.R Prepare segmented object program from user relocatable binary subprograms only, and
execute.
6.3 Lower 3000 MASTER
The first four columns of the card contain the characters ALG. Fach parameter specifies an option. Parameters may be
in any order on the card and are separated from each other by commas. The general format of the card is:
SALG, ©], Co, С 3, a Ch
6.5.1 INPUT-OUTPUT OPTIONS
Each c; has the form c or c=n, where c is any sequence of characters beginning with one of the acceptable parameter
letters defined below. For example, L and LIST are equally acceptable for the list parameter. n is the data set identifier
(dsi) of the file to be used for the option. If =n is not specified, the option uses a standard file.
Except for the I parameter, the absence of any parameter suppresses the corresponding option. Any illegal, contradictory,
or meaningless combination of parameters is diagnosed by the compiler, which makes a legal selection from the set specified
and continues compilation after issuing the diagnostic:
ERROR IN CONTROL-CARD, OPTION xx IS DELETED.
Acceptable parameter letters are defined below:
I Specifies the dsi for source input (standard dsi is INP). Block size is 1280 characters.
A Specifies the dsi for the assembly language listing of the object program (standard dsi is OUT). Block size is
1280 characters.
L Specifies the dsi for the source language listing (standard dsi is OUT). Block size is 1280 characters.
X Specifies the dsi for load-and-go output (standard ая в LGO.LGO is a system scratch file). Block size is
1280 characters.
P Specifies the dsi for punchable binary output (standard dsi is PUN). Block size is 1280 characters.
114
с
N
Specifies the dsi for segment file output (standard dsi is SEGF. SEGF is assigned as a system scratch file). The block
size must be 2224 characters.
Specifies the dsi for binary input for preparation of a segment file. May only be used in conjunction with the S-option
(standard dsi is INP). Block size is 1280 characters.
Specifies the dsi for binary subprogram input supplementary to I or G for preparation of a segment file. May only be
used in conjunction with the S-option (standard dsi is INP). Block size is 1280 characters.
Specifies the dsi for segment file input for segmented execution (standard dsi is SEGF). Block size is 2224 characters.
Specifies the dsi for punchable Hollerith output of object program (standard dsi is PUN). Block size is 1280
characters.
Do not generate array bounds checking code in the object program. ( =n never appears for this parameter).
Some typical control cards are listed below:
SALG,L,S=dsi 1,R=dsi 1 Compile source input, list, prepare and execute a segmented object program.
SALG,L,X Compile source input, list, prepare object program in relocatable binary load-and-go form.
ЗАГС Compile source input, list diagnostics only. No other output.
SALG(G,R=dsi 1, S=dsi 1) Prepare segmented object program from user relocatable binary subprograms only, and
execute.
115
6000 Typical Control Card — 6000 series
(D OO AC)
Ooo —
data
“ CHANNEL, END
/ CHANNEL, 120=FILE |
7
8
9
I
File name is assigned to
0 Е
Г source deck || ALGOL channel 120
/ 7
8
9
/ ALGOL(L, $, В)
1 / REQUEST FILE. |
/ MLB, 17,200, 30000.
COMPILE PROGRAM TO SEGMENTED FILE; EXECUTE
116
TYPICAL CONTROL CARD — 3000 SERIES (EXCLUDING MASTER)
LL
£
LL
data
a CHANNEL, END
( CHANNEL, 120=LU52 Logical unit 52
7 -x-——is assigned to
RUN, 5 ALGOL channel 120.
7
y LOAD, 56
/ EQUIP, 52=MT
7
7 1
a
source deck
/ ALGOL, L, X |
(JOB, 10019, MLB, 10
LOAD-AND-GO FILE
117
TYPICAL CONTROL CARD — LOWER 3000 MASTER
77
88
$*DEF(R,...) |
$*DEF(C,...) |
и
A
L
( data cards
7 CHANNEL, END
+
L
L
A
“ channel cards
( FINIS
' EOP’ | H
VA 4 |
7 N
program source deck |
/ $ALG(L, S=dsi 1, R=dsi 1) |
/3*DEF(O,...) |
- /$*DEF (A,...) |
/$SCHED,... |
/ $JOB,...
PROGRAM COMPILATION AND EXECUTION IN SEGMENTED MODE
118
CHANNEL CARDS 7
All input-output statements (Chapter 3) specify a channel on which the operation is to be performed
and each channel is referenced by an identification number called a channel number (Section B. 1.1).
Each channel is associated with a set of characteristics, some of which are defined on channel cards.
Channel cards appear as the first or only cards of the object-time data on the standard input device;
they are interpreted by the controlling routine before the object program is entered. The three
types are: channel define, channel equate, and channel end; all must contain the characters
CHANNEL, in columns 1-8.
The relationship between the structure of a file created by the input-output statements of a program
and its physical representation as a SCOPE, MASTER or MSOS {ile is defined by the channel card.
The restrictions imposed by the operating system must be considered in creating a channel card.
7.1 CHANNEL DEFINE CARD
This card describes the characteristics to be associated with one channel number.
CHANNEL, cn=device, Pr, PPs, Kb, Rt, M, A, Dd, B
The eight characters CHANNEL, appear in columns 1-8 followed by a list of parameters.
Each parameter describes a different characteristic. Parameters are separated by commas, and
blanks may appear anywhere. The last parameter has no delimiter, but the information for one
channel must be contained on a single card. Only the cn=device parameter is required; the others
are optional and may be specified in any order.
cn channel number, unsigned integer, maximum 14 decimal digits.
device specifies the device appropriate for the operating system:
LUxx indicates SCOPE logical unit xx to be referenced whenever this number
is used in an I/O call for 3000 SCOPE.
DSIxxx xxx is data set identifier for MASTER.
file name SCOPE file for 6000. File name will be referenced by 1/0.
LUxx and DSIxxx are legal file names for 6000.
119
Pr r indicates maximum line width (r = 24 characters); when omitted, P136 is assumed. If
the Rt parameter has the form RnP (see below), r may be increased if necessary, from its
specified value, to an exact multiple of 10 characters (whole machine words), for 6000
ALGOL, 8 characters for 3000 upper ALGOL and 4 characters for 3000 lower ALGOL.
PPs s indicates maximum page (s lines) length. If PPO is specified or if the parameter is
omitted, no paging operations are performed. If the user defines page width or page
length beyond the capabilities of the corresponding external device, data may be lost.
Kb b determines the number of consecutive blanks that serves as a delimiter for a number read
or written in standard format. Omission of this parameter is equivalent to K2. The
number specified must be in the range 1 = K = R.
TRE Defines the way in which information is recorded on the external device: in this definition
t can take two forms, nP and ¢. n and c are unsigned integers. The value r used in the
following paragraph is the maximum line width specified by the Pr parameter described
above. If the R parameter is omitted, RIP is assumed.
RnP Physical records consist of n lines. Each line is r characters in length as defined
in Pr.
Re Physical records consist of as many lines as can be wholly contained in ¢ characters;
c is increased, if necessary, from its specified value to an exact multiple of 10
characters (whole machine words) for 6000 ALGOL, 8 characters for 3000 upper
ALGOL and 4 characters for 3000 lower ALGOL. In each line trailing blanks are
removed; each line ends with a record mark.
R If t is omitted, recording characteristics are the same as for Rec form, except that
the logical record length (c) has no upper bound. The end of a logical record may be
defined by returning the channel to its closed state (e.g., hardware function). In this
case, on input, the end of the logical record is treated as an end of file. R standing
alone applies to 6000 ALGOL only.
TM Indicates input-output transmission overlap (buffering). If M is included, the formatting
area size (which is a function of the R parameter) is modified to allow effective overlap
of the input-output transmission and the formatting processes.
A Channel is constructed without a formatting area, regardless of the inclusion of other
parameters. Such a channel is usable only with the procedures GET ARRAY and PUT ARRAY.
An A-type channel may be changed at object-time with the procedure CONNECT to allow it
to be used with other input-output procedures.
TM and R are not implemented in 3000 lower ALGOL. The corresponding default values of M and R
are assumed.
120
D Meaningful only for magnetic tape. D2 sets the density to 200 bpi, D5 to 556 bpi, D8 to
800 bpi, and when DO is used or the parameter is omitted, density is dependent on operator
or installation control.
B Indicates reading or writing in binary (odd) parity; absence of this parameter sets BCD
(even) parity.
7.2 CHANNEL EQUATE CARD
Channel equate cards permit the user to reference the same channel with more than one channel
number:
CHANNEL, cn, = cn,
cn, and cn, are unsigned integers with a maximum of 14 decimal digits each. Either cn,, or a
number to which cn, is linked by other channel equate cards, must appear on a channel define card
elsewhere (though not necesarily earlier) in the set of channel cards. The channel defined on that
card can be referenced by the number en, as well as cny. Any number of channel numbers may be
equated in this way with the same channel.
7.3 CHANNEL END CARD
The last card of every set of channel cards must be in the format:
CHANNEL, END
This card indicates the end of channel information and must be included even when the deck contains
no other channel cards.
7.4 DUPLICATION OF CHANNEL NUMBERS
Although a channel may be associated with more than one channel number, a channel number must
refer to only one channel. Therefore, the same channel number may not appear in more than one
channel define card in a set. Similarly, a channel number which appears on a channel define card
may not be included on the left-hand side of a channel equate card, since this is equivalent to
associating that number with more than one channel.
121
7.5 DUPLICATION OF FILE NAMES
The following rule applies to both user-defined channels and those automatically supplied by ALGOL.
A file name may appear on any number of channel define cards; although the channels remain
independent of each other, all input-output operations specifying any of the different channel
numbers refer to the same file.
The same logical unit number may appear on any number of channel define cards; although the
channels remain independent of each other, all input-output operations specifying any of the
different channel numbers refer to the same logical unit.
7.6 STANDARD ALGOL CHANNEL CARDS
Two channel cards with standard channel numbers and characteristics are automatically supplied by
the ALGOL system for the operating system standard input and output devices as follows:
[CHANNEL 60 = INPUT, P80,R
6000
CHANNEL, 61 = OUTPUT, P136, PP60,R
Unner 3000 CHANNEL, 60 = LU60, P80, M
pper CHANNEL, 61 = LU61, P136, PP60, M
Lower 3000
CHANNEL, 61 = LU61, P136, PP60
CHANNEL, 60 = DSIINP, P80
CHANNEL, 61 = DSIOUT, P136, PP60
| {ar 60 = LU60, P80
MASTER only {
The two standard files may be referenced by the channel numbers 60 and 61 and do not require
channel cards; however, these two cards are printed as part of the channel card listing as if they
were specified by the user.
122
7.7 TYPICAL CHANNEL CARDS
Some typical channel cards are:
6000
CHANNEL, 35 = NUCLEAR, P120
CHANNEL, 47 = UNCLEAR, P400
CHANNEL, 29 = 35
3000
CHANNEL, 35 = LU26, P120
CHANNEL, 42 = LU58, P400
CHANNEL, 29 = 35
123
ALGOL DIAGNOSTICS 8
Three types of diagnostics are associated with the ALGOL compiler system: compiler diagnostics,
compile-time and object-time I/O diagnostics, and object-time diagnostics.
8.1 COMPILER DIAGNOSTICS
Every error detected during compilation causes a diagnostic to be printed following the source
listing. If the source listing is suppressed, the diagnostics are output to the standard output device.
Each card of the source deck is assigned a line count, which is printed as part of the source listing,
and each compiler diagnostic includes the line count of the source card in error and a brief summary
of the error condition.
Compiler diagnostics are either alarms or messages; alarms cause the suppression of object code
generation but messages do not.
8.1.1 COMPILER MESSAGES
The following compiler messages do not necessarily indicate the presence of an error in the source
text; they provide information which may be useful in detecting errors which do not show up as
language infringements:
DELIMITER IN COMMENT
FLOATED INTEGER - 3000 only
LONG IDENTIFIER
NON-FORMAT STRING
PROGRAM BEGINS
PROGRAM ENDS
SOURCE DECK ENDS
PROGRAM BEGINS, PROGRAM ENDS and SOURCE DECK ENDS are output with every compilation
regardiess of errors.
If the line count on the PROGRAM BEGINS message is not 0, the programmer should make certain
that the beginning of the program has not been treated as commentary because of a missing or mis-
spelled delimiter (suchas begin). Similarly, if the line counts on the PROGRAM ENDS and SOURCE
DECK ENDS message differ, the end of the program may have been treated as terminal commentary.
124
8.1.2 COMPILER ALARMS
A compiler alarm indicates a serious error in the source text and causes the suppression of object
code generation regardless of user request, although normal compilation and error checking continue
to the end of the source text. Some errors, however, cause the output of a secondary alarm STOP
COMPILATION; this terminates compilation and some errors previously detected may be lost.
In the following compiler diagnostics, a note in the Comment Column indicates any diagnostic
which does not apply to all systems:
Compiler Diagnostics
ARITHMETIC OVERFLOW
ARRAY BOUND TYPE
ARRAY BOUND - LOCAL
ARRAY OR SWITCH CALL
ARRAY SIZE - NEG OR ZERO
ARRAY, SWITCH, PROCEDURE
BCT CARD
BYPASS OVERFLOW
CALL PARAMETER
CALL PARAMETER COUNT
CHARACTER
Comment
Evaluation of expression (involving constants) results Does not
in arithmetic overflow. In 6000 the condition is apply to
detected only if the result is subsequently used. 3000LT
Array bound expression is not arithmetic.
Variable specified for array bound is declared
at same level as array.
Identifier used as an array or switch has not been
so declared.
Computed array size is negative or zero. Does not
apply to
3000L
Too many subscripts or switch elements or
formal or actual parameters.
Error in BCT card on U-option file, G-option MASTER
file, or library. only
Capacity of compiler to handle forward references
has been exceeded.
Undeclared or untyped parameter in a procedure
call.
Procedure is called with the wrong number of
parameters.
Illegal character in source text.
Ÿ 3000L = lower 3000 3000U = upper 3000
125
Compiler Diagnostics
G
CHECK SUM je
| - UNIT
LIB
CHECK SUM
'CODE' INTEGER
"COMMENT!
COMMON NAME
COMMON PRESETTING
COMMON TABLE LENGTH
COMMON TEXT
G
COM-PART ju
| - UNIT
LIB
COMPOUND DELIMITER
DATA NAME/LENGTH
DATA PART
DECLARATION CAPACITY
DECLARATION CODE O-FLOW
DELIMITER
DELIMITER IN COMMENT
(MESSAGE)
126
Checksum error in binary program or specified unit.
Checksum error in a binary program on load-and-go
tape.
Literal following code is not an integer.
Comment in an illegal position in source text.
First two characters of second COMMON not OW
(for own variables).
Attempt to preset COMMON outside of defined length.
Length of Program Identification Table not 2 or 3.
Attempt to preset a common area not mentioned
in Program Identification Table.
Unacceptable BCT card.
Hardware representation of an ALGOL symbol is
incorrect (e.g., 'BIGIN').
First COMMON name not DATA or its length not
1 50, 0"
A DATA address in a binary program on the
U-option file, G-option file, or library is not
in the range of STANLIST.
Too many variables declared in a block structure.
Capacity of compiler to store labels procedures,
etc. for declaration code is exceeded.
Incorrect delimiter for the particular context
appears in source text.
Statement may have been bypassed because of a
missing delimiter (such as ; following an end).
Comments
3000U
only
3000L
only
6000
only
3000 U
only
6000
only
3000L
MASTER
and MSOS
Compiler Diagnostics
DELIMITER MISSING
DOUBLE DECLARATION
DOUBLE SPECIFICATION
DOUBLE DEFINED
'ELSE' COUNT OVERFLOW
"END'S MISSING
'EOP' GEN. BY (PAR ERR)
(BIN CARD)
(EOF CARD)
EXTERNAL REFERENCE
ADDRESS
EXTERNAL REFERENCE
RELOCATION
EXTERNAL STACK OVERFLOW
G
EXT-CARD E
I UNIT
LIB
FILL ADDRESS
FILL RELOCATION
FINIS GEN. BY {Tan ne
EOR CARD
Delimiter expected at this point in source text
not found.
Identifier declared more than once in same
block heading.
Formal parameter specified more than once in
same procedure heading.
Two or more separately-compiled procedures
with the same name found during preparation of
segment file.
Capacity of the compiler to handle nested if
statements has been exceeded.
More begin than end symbols when 'EOP!
encountered.
'EOP' (end of source deck) forced at this point
by parity error, binary card, or EOF card.
Address of external reference outside of current
segment.
External references may occur only from
program part.
More than 50 separately-compiled procedures
found during preparation of segment file.
External cards not in sequence in binary program
on specified unit.
Address of common reference outside of current
segment.
Attempt to make common reference from negative
program relocatable part or from common not
mentioned in Program Identification Table.
FINIS (end of source stack) forced at this point by
parity error or EOR card in source input.
Comments
Does not
apply to
3000L
Does not
apply to
6000
3000L
only
6000
only
30000
only
6000
only
127
Compiler Diagnostics
| PAR. ERR
FINIS GEN. BY E CARD |
EOF CARD
'FOR' CONTROL VARIABLE
FLOATED INTEGER (MESSAGE)
FLOAT-FIX OVERF LOW
FORMAL MISSING
IDC CARD
G
IDC CARD tu {- UNIT
LIB
IDENTIFIER OVERFLOW
'IF' CLAUSE TYPE
'IF!' EXPRESSION TYPE
G
ILL. camo] U {- UNIT
LIB
G
ILL-RELC U
\ - UNIT
LIB
128
Comments
FINIS (end of source stack) forced at this point 3000U
by parity error, binary card or EOF card in only
source input.
Control variable of for statement must be simple
or subscripted arithmetic.
Integer contains more than 14 digits.
Does not
Conversion from floating-point to fixed-point apply to
, 6000
exceeds 48 bits.
Value or specification appears for an identifier
not in formal list.
Error in IDC card in binary program on load-and- 3000L
go tape: cither COMMON is not 0 or DATA is not only
192(300) ,
Error in IDC card in binary program on specified 30000
unit. Either the relocation byte length is illegal only
or the program name is more than 8 characters
long.
No room in available memory to store complete
list of identifiers (symbol table overflow).
Expression following an if symbol must be Boolean.
Expressions following symbols then and else in
if statement must be same type.
Binary card with an inadmissable word count on
load-and-go tape.
3000U
only
Incorrect relocation in binary program on
specified unit.
Compiler Diagnostics
INADMISSABLE CARD
INADMISSABLE RELOCATION
INCOMPLETE ENTRY TABLE
INCOMPLETE LINK TABLE
INCOMPLETE REPLICATION
TABLE
INCOMPLETE TRANSFER
TABLE
INSTRUCTION OVERLAP
INSTRUCTION UNDER-COUNT
LABEL
LOAD ADDRESS
LOCAL VARIABLE OVERFLOW
LONG IDENTIFIER (MESSAGE)
MACHINE ERROR
MISSING DECLARATION
Binary card with an inadmissable word count
on load-and-go tape.
Incorrect relocation in binary program on
load-and-go tape.
Incorrect Entry Point Table.
Incorrect Linkage Table
Incorrect Replication Table.
Incorrect Transfer Table.
Compiler error. Internal numbering of in-
structions generated during pass three does
not agree with pass four. This error may
also occur when the amount of code generated
by a simple arithmetic or Boolean expression
exceeds the capacity of the compiler.
Compiler estimate of program size incorrect.
Identifier used as label not so declared.
Load address in text table out of range.
Too many local variables defined in same block.
Identifier exceeds 256 characters.
Machine or compiler malfunction.
Undeclared identifier.
~~"
Comments
3000L
only
6000
only
3000L
only
6000
only
3000L
only
129
Compiler Diagnostics
MISSING PROGRAM
MORE THAN ONE PROGRAM
NEW SEGMENT WITHIN TEXT
TABLE
NO 'CODE' INTEGER
NO MAIN PROGRAM
NON-FORMAT STRING
(MESSAGE)
NUMBER SIZE
NUMBER SYNTAX
OPERAND
OPERAND MISSING
OPERAND OVERFLOW
OPERATOR OVERF LOW
'"OWN' BOUNDS
PARAMETER COMMENT
PROCEDURE IDENTIFIER
PROGRAM BEGINS (MESSAGE)
130
Comments
Program appears to be missing because of
absence or misspelling of a delimiter which Does not
begins compilation (e. g., begin). apply to
3000L
More than one main program found during
preparation of segment file.
Text table overlaps two segments. 6000
only
Integer missing after code.
Only code procedures found during segmentation. 6000
only
String cannot be used as a format string.
Number exceeds the floating-point capacity
of machine.
Number incorrectly punctuated.
Incorrect operand in source text for particular
context.
Operand expected at this point in source text not
found.
Capacity of compiler to handle operands within
the same statement exceeded.
Capacity of compiler to handle nested operators Does not
exceeded. apply to
6000
Bounds in an own array must be constants.
Parameter comment replacing comma in
procedure declaration or call incorrectly formed.
Identifier in procedure call is not declared as
a procedure.
Line at which program compilation begins (appears
with every compilation).
Compiler Diagnostics
PROGRAM ENDS (MESSAGE)
REDECLARATION CAPACITY
REFERENCE OUTSIDE SEGMENT
REPLICATION ADDRESS
REPLICATION RELOCATION
SECOND DECLARATION
SEQUENCE
G
SEQUENCE | О
- UNIT
LIB
SIMPLE 'FOR' ELEMENT
SOURCE DECK ENDS (MESSAGE)
SPECIFICATION MISSING
STANDARD FUNCTION PARAM
'STEP' ELEMENT TYPE
STOP COMPILATION
STRING
Comments
Line at which program compilation ends
(appears with every compilation).
Capacity of compiler to handle similarly-
spelled identifiers in nested block structure
exceeded.
Invalid addressing found during segmentation.
6000
only
Attempt to perform replication outside current
segment.
Replication may occur only within program part.
Line on which second element of DOUBLE
DECLARATION is made.
Does not
apply to
30000
Binary cards on load-and-go tape out of
sequence.
30000
only
Cards in binary program on specified unit out
of sequence.
Simple for element is not arithmetic.
Line at which "EOP" is found or forced (appears
with every compilation).
Specification missing for identifier included as
a formal.
Parameter in call to standard procedure of
incorrect type.
Third expression in a step element must be
arithmetic.
Line at which compilation stops; error messages
for other lines may be lost. Appears in con-
junction with OPERAND OVERFLOW, etc.
3000L
only
Too many characters in a string.
131
Compiler Diagnostics
STRING LENGTH
STRING CHARACTER
STRING TERMINATION
STRUCTURE CAPACITY
SUBPROGRAM MISCOUNT
SUBPROGRAM SIZE
SUBSCRIPT COUNT
SUBSCRIPT TYPE
'SWITCH' PARAMETER
SYSTEM ERROR
TERMINATION
TOO MANY 'BEGINS'
TOO MANY BLOCK LEVELS
TOO MANY IDENTIFIERS
TOO MANY WORKING LOCS
132
Too many characters in string, or 'EOP'
encountered before end of string.
Illegal character in a string (external BCD 12 а)
'"EOP' encountered before end of string.
Compiler capacity to handle nested structure,
such as parenthetical statements, exceeded.
Incorrect number of subprograms on load-and-go
or library tape.
Size of current subprogram exceeds 128K words.
(32K - 3000)
Array or switch called with incorrect number
of subscripts.
All subscript expressions must be arithmetic.
All elements in a switch list must be labels
or designational expressions.
Compiler or machine malfunction.
Language construction in source text terminates
illegally.
A block structure contains blocks nested to more
than 32 levels.
A block structure contains block nested to more
than 32 levels.
Too many differently spelled identifiers in the
program.
Too many working locations in excess of declared
variables required to perform operations specified
in this block.
Comments
Does not
apply to
30001,
6000
only
30001,
only
Does not
apply to
3000L
3000L
only
Does not
apply to
3000L
Compiler Diagnostics
TYPE
UNDEFINED
UNDEFINED IDENTIFIER
UNDEFINED Lib-name
CDPXxxxx
VALUE SPECIFICATION
'WHILE' ELEMENT TYPE
XNL CARD
In a general expression, element types must be
consistent.
No external name found during preparation of
segment file.
Second or subsequent use of an undefined or
doubly-defined identifier.
Name on external card (library name or the name
of a separately-compiled procedure) not found on
G, U, or library unit during preparation of a
segment file
Value applied to formal parameter whose
specification does not permit a value (e.g. label).
Elements in a while statement must be
arithmetic and Boolean.
Error in XNL card in binary program on
load-and-go tape.
8.2 COMPILE-TIME AND OBJECT-TIME 1/0 DIAGNOSTICS
8.2.1 6000
Comments
6000
only
3000U
only
3000L
only
System diagnostics concerning input-output usage at compile-time and object-time appear in
DA YFILE:
ALGOL-I/O-ERROR yyy ON FILE file-name
yyy values:
P Attempt to close OUTPUT, PUNCH
3
or PUNCHB files
object-time only
P Attempt to close INPUT file
4
133
In general, the following values of yyy result from system error, improper use of I/0 system
in a handwritten procedure, or wrong segment file:
YYY
FC1 Illegal function code to 1/0 )
FC2 Error on call for open formatted
FC3 Error on call for close formatted
compile-time or
object-time
FC4 Error on call for read or write
formatted
FC5 Error on call for function
non-formatted
FC6 Error on call for read or write
non-formatted
/
SG1 Error in the segment file
SG2 Library routine missing from segment S object-time only
file
INT Error in compiler inter-pass 1/0 compile-time only
8.2.2 UPPER 3000
System diagnostics concerning input-output usage at compile-time and object-time appear on the standard output device:
134
ALGOL I/O ERROR, PARITY ON LU xx
Indicates an irrecoverable parity error on | compile-time
scratch or library tapes. only
ALGOL 1/0 ERROR, TROUBLE ON LU xx
compile-time
or
object-time
Appears when the SCOPE status reply
indicates abnormal termination of an
input-output operation.
ALGOL 1/0 ERROR, PASS OUT OF ORDER ON LIB
xxxx READ INSTEAD OF ALGx
Indicates an error in organization of | compile-time
compiler on the SCOPE library. only
ALGOL 1/0 ERROR, SEGMENT TAPE CONTROL
object-time
only
Indicates an error in the segment tape
(an incorrect or bad tape or the system
itself could possibly be in error).
8.2.3 LOWER 3000 MASTER
System diagnostics concerning input-output usage at compile-time and object-time appear on the standard output device:
ALGOL-I/O ERROR yyyyyyyy ON xxxx
Indicates an irrecoverable error on dsi xxxx. The type of error is indicated by yyyyyyyy as follows.
yyyyyyyvy
SEGCOUNT Requested more than 63 segments or exceeded scratch segment count on SCHED card.
BLKSIZE Word count too large to fit block area on a PACK request.
SEGMENT A new segment could not be mounted on a file.
EOF End-of-file condition.
PARITY Parity error.
IRRECOV Irrecoverable hardware error.
EOD End of device encountered.
DSIUNDEF File not open for specified asi.
DSIILLEG Data set identifier is illegal.
SYSERR Xxx A system error occurred. xx is the error code returned by OCAREM, MIOCS, or
the blocker/deblocker.
135
8.2.4 LOWER 3000
System diagnostics concerning input-output usage at compile-time and object-time appear on rhe standard output unit:
ALGOL-I/O ERROR yy on LU xx
An irrecoverable error occurred during compilation or execution.
Compilation or execution terminates and control returns to the
SCOPE monitor. The type of error is indicated by yy as follows:
yy
PA Irrecoverable parity error |
BC Inadmissable binary card or relocation error
CS Check sum error 4 compile-time only
LD Lost data
ET EOT J
dd MSIO reject code compile or object-time
SG System malfunction concerning segment tape
control
Pl Attempt to use segment tape
P2 Attempt to use library tape (63)
P ary ap L object-time only
P3 Attempt to write on logical unit other than
61 or 62
P4 Attempt to read logical unit other than 60
PS Attempt to read past EOF on 60.
=
Besides the above fatal cases, some hardware conditions may require operator action before normal compilation or exe-
cution can continue. The following messages occur on CTO unit:
RE-LOA D LUN xx - PRESS GO WHEN READY
xx indicates device:
The card hopper is empty but not all cards to complete an ALGOL compilation have been read. Refill hopper. Press
GO to continue.
136
The card punch has failed to feed, or a card has been mispunched. When corrected, press GO to continue.
The end of tape has been encountered on an output tape; the tape has been backspaced, two end-of-file marks written
on it, and unloaded. Mount a new tape on the designated unit. Press GO to continue.
Re-load printer with paper. Press GO to continue compilation.
8.3 OBJECT-TIME DIAGNOSTICS
Upon normal exit from an object program, the contents of all non-empty format areas are output.
The following message printed on the standard output device indicates a successful execution:
END OF ALGOL RUN
Upon abnormal termination, a diagnostic is printed on the standard output device to indicate the
nature of the error, and the contents of all non-empty format areas are output. Information which
traces the execution path through the currently active block structure is then printed on the standard
output device as follows:
THIS ERROR OCCURRED AFTER LINE xxxx
IN THE BLOCK ENTERED AT LINE xxxx
(global stack information)
(local stack information)
THIS BLOCK WAS CALLED FROM LINE xxxx
IN THE BLOCK ENTERED AT LINE xxxx
(local stack information)
THIS BLOCK WAS CALLED FROM LINE xxxx
Stack information for each block is printed following the corresponding BLOCK ENTERED line.
137
Object-Time Diagnostics
ALLOC. LIMIT OUTPUT
ALPHA FORMAT ERROR
ARITHMETIC OVERFLOW
ARRAY BOUNDS ERROR
ARRAY DECLARE ERROR
ARRAY DIMENSION ERROR
BOOLEAN INPUT ERROR
CHANNE L XXXXXXXXXXXXXX
CHN XXXXXXXXXXXXXX
CHANNEL CARD SYNTAX
CIRCULAR
PARITY
EOF
DISPLAY EXCEEDED
138
End of allocated file occurred on output.
Output value is too large.
Evaluation of an expression results in arithmetic
overflow (e.g., division by zero) for which no
provision has been made with ARTHOF LW
procedure.
Computed element address in an array is not
within total array boundaries.
Computed array size is negative or zero.
Number of dimensions in actual parameter array
in procedure call differs from number in formal
parameter array.
In Boolean formats F or P, input character is
not F or T, or 0 or 1 respectively.
Defines channel on which preceding error occurred.
Defines channel on which preceding error occurred.
Either syntax of channel card is wrong or define
and equate cards result in a circular definition
of a channel; or an irrecoverable parity error
or EOF card occurred during reading of channel
cards. The incorrect card is output before the
program terminates.
Block structure is nested to more than 32 levels;
this error can occur only because of calls to
separately compiled procedures.
Comment
3000L
MASTER
only
Does not
apply to
3000L
Does not
apply to
3000L
3000L
only
6000
only
Object-Time Diagnostics
END OF DEVICE
END OF ALLOC AREA
EOF STANDARD INP
EXPONENTIAL ERROR
FLOAT TO FIX ERROR
FORMAT ITEM ERROR
FORMAT MISMATCH
FORMAT REPLICATOR
FORMAT STRING ERROR
GET/PUT ARRAY ERROR
H/V LIM ERROR
ILLEGAL CHANNEL CARD
ILLEGAL IN-OUT
ILLEGAL MODE CALL
ILLEGAL STRING INPUT
Comment
End of device was encountered. | 3000L
End of allocated area was encountered. MASTER
only
An EOF card appears out of place on the 3000L
standard input device. MSOS only
Argument of EXP procedure is too large.
Result of converting a normal floating-point Does not
number to fixed-point form exceeds 48 bits. apply to
6000
More characters in expanded format item than
permitted in INPUT, OUTPUT, IN LIST and
OUT LIST.
Syntactically correct format string appears to be
incorrect (probably machine or system mal-
function).
Replicator in call to FORMAT procedure not
in proper range.
Incorrect format string.
GET ARRAY and PUT ARRAY may not be used
on channel for which formatting and format area
have been specified.
H LIM and V LIM arguments L, R and L', R'
out of range.
Syntax of channel card is incorrect; incorrect Does not
card is printed before program terminates. apply to
6000
Illegal operation requested for equipment selected.
T parameter in call to MODE procedure not in
proper range.
Attempt to read into a string parameter during a
call of INPUT or IN LIST.
139
Object-Time Diagnostics
1/0 CHANNEL ERROR
IRRECOVERABLE ERROR
LAYOUT CALL ERROR
LOGARITHM ERROR
LOST DATA
MANUAL INTERRUPT
MSIO-FILE LIMITS
MSIO-WRITE ON READ
MSIO-ILLEG ORDINAL
NON-FORMAT INPUT ERROR
NUMBER SYNTAX ERROR
NUMERIC INPUT ERROR
OUT CHARACTER ERROR
PARAMETER COUNT ERROR
PARAMETER KIND ERROR
140
Normal input-output procedures, except GET
ARRAY and PUT ARRAY, cannot be performed
on non-formatted channels.
An irrecoverable hardware malfunction occurred
on an 1/O device.
Procedures established by H END and V END
and label set by NODATA are not accessible
after return from the layout procedure called by
IN LIST or OUT LIST.
Argument to LN procedure may not be negative
or zero.
Information lost during transmission because of
hardware malfunction.
Manual interrupt occurred for which no provision
was made with the MANINT procedure.
1/0 request attempted beyond file limits.
Write requested on a read-only file.
Illegal file ordinal.
In non-formats, I, R, L, or M, input field
contains non-octal characters.
Number input in standard format does not
conform to proper syntax.
Data input under format control does not conform
to numeric input format.
Parameter OUT CHARACTER call is not in
proper range.
Number of actual parameters in procedure call
incorrect.
Kind of actual parameter in procedure call does
not correspond to kind of associated formal
parameter.
Comment
3000L
MASTER
only
3000L
only
3000L
only
3000L
MSOS
only
Does not
apply to
J000L
Object-Time Diagnostics
PARAMETER TYPE ERROR
S-UNIT ILL. ON CHANCARD
SIN - COS ERROR
SQUARE ROOT ERROR
STACK OVERFLOW
STANDARD OUTPUT ERROR
STRING ELEMENT ERROR
SWITCH BOUNDS ERROR
SYSPARAM-CHANNEL
SYSPARAM - WRONG F
SYSPARAM - WRONG Q
SYSTEM ERROR
TABULATION ERROR
TRUB TO MOUNT SEGMT
UNASSIGNED CHANNEL
UNCHECKED EOF
UNCHECKED PARITY
Comment
Types of actual and formal parameters in
procedure call do not correspond.
Unit defined on channel card is same as unit 30000
containing segment file. only
Argument to SIN or COS procedure is too large.
Argument to the SQRT procedure may not be
negative.
Data requirements of program exceed available
memory.
Standard output can be used only for numeric
and string formats.
Rules of STRING ELEMENT violated.
Value of switch designator out of range.
SYSPARAM procedure can be called only for
formatted channels.
SYSPARAM called with incorrect F parameter.
SYSPARAM called with incorrect Q parameter.
A system error occurred in handling input/output. 3000L
MASTER
only
Argument of TABULATION not in proper range.
A new file segment could not be mounted. 3000L
MASTER
only
No channel defined for channel number used in
program.
End-of-file mark detected, but no provision made
with EOF procedure.
No PARITY procedure for parity error detected.
141
UNDEFINED DSI A file is not opened for the specified dsi.
UNDEFINED FOR LABEL Attempt to jump into middle of for statement.
UNTRANSLATED IN ERR In untranslated formats, I, R, L, and M; input 3000L
field contains non-octal characters. only
142
COMPILER DESCRIPTION 9
The compiler consists of the subprograms ALGOL, ALGO, ALG1, ALG2, ALG3, ALG4, and ALG5.
Only ALG1 through ALG4 take part in the actual translation of a source text into object code.
ALGOL controls the compilation process, ALGO handles the control card, and ALG5 controls seg-
mented object program execution.
ALGl, ALGZ2, ALG3 and ALG4, each perform a separate function in the translation process as
described below.
9.1 INFORMATION FLOW
The output from each pass of the compiler is in the form of bytes representing an internal form of
the source text. The output stream of bytes from one pass serves as the input stream to the next
pass.
The bytes generated by each pass are first stored in available memory. If the entire stream fits
there, it is retained for processing by the next pass. Otherwise, it is written out as a scratch file
which is read back in by the next pass and the output from that pass is written onto a second scratch
file.
Each pass processes the stream of bytes in a direction opposite to the one in which they were
generated by the previous pass: ALGI and ALG3 process the bytes in the source text order; ALG2
and À LG4 process them in the reverse order.
9.2 LANGUAGE TRANSLATION
Each pass uses one or more internal pre-set tables; the value of each byte input to a pass is an index
into a table in that pass. The table entry thus referenced either yields an output byte value for the
next pass or it directs control to an action which will generate an output byte value. One or more
input byte values may generate one or more output byte values.
9.3 LANGUAGE ANALYSIS
The syntactic analysis in ALGI uses a state/delimiter method. The delimiter is the current input
byte which represents an element in the language. The state is the current syntactic situation, as
established by previous delimiters; each delimiter causes a change in state.
143
A pre-set table in ALG1 contains the syntactic rules of the ALGOL language. This table is refer-
enced by the two dimensions state and delimiter. Each entry in the table, referenced in this
manner, indicates whether or not the current delimiter is legal in the current state, the new state
to be established, and any further actions required.
Similar table actions are performed in other passes to check different aspects of a program for
legality.
9.4 IDENTIFIER (SYMBOL) TABLE
The identifier table is established by ALG1 as it reads the source text. The table contains only one
version of each distinct identifier regardless of the number of times that identifier occurs in the
source.
Each identifier in the table is linked to the next identifier with the same classification. The classi-
fication of an identifier is derived from the hash-total of the characters comprising the identifier.
Whenever the identifier table is searched, only those identifiers on the classification chain corre-
sponding to the one being considered are examined.
Each distinct identifier is associated with an integer from 513 to 4095 assigned sequentially as
distinct identifiers are encountered. The integer values are output as the byte values for the
identifier for processing by subsequent passes. The identifier table is not used after the first pass
of compilation.
9.5 COMPILER SUBPROGRAM DESCRIPTIONS
ALGOL
The ALGOL subprogram is the internal controller of the compiler. It is loaded from the library by
the operating system loader as a result of a standard operating system control card call specifying
the name ALGOL. Its main function is to load and pass control to each pass of the compiler as
required. At the end of each pass, control is returned to ALGOL for loading the next pass. At the
end of compilation, ALGOL returns control to the operating system. ALGOL resides in memory
throughout the compilation process. |
ALGO
ALGO processes the control card parameters delivered to the compiler by the operating system.
It checks specified options for legality and sets the appropriate information for these options for
later use.
144
ALGI1
A LG1 reads the source code and translates it into an internal form of the ALGOL-60 reference
language. It performs all syntax analysis on the source program, generates the output stream of
intermediate information for processing by ALG2, and prints the source text in parallel with the
processing.
ALG1 consists of various control routines plus the three routines TASK1, TASK2, and TASK3 which
perform the principal functions. TASK3 is immediately called on entry to ALG1; TASK3 references
TASK2 to perform subsidiary functions; TASK2 itself calls TASKI1 for functions subsidiary to it.
TASK1 analyzes and checks the hardware representation of the source text, and converts it to the
internal form of ALGOL symbols. All comment structures are removed.
TASKI1 also assembles strings and transmits these and any diagnostic alarm indications directly
to the output stream for later processing by ALG2. TASK1 is called by TASK2 whenever the latter
requires another ALGOL symbol.
TASK2 processes the intermediate bytes from TASKI. If assembles identifiers into a table, and for
each distinct identifier, it outputs a unique integer value byte to TASKS. TASK2 also assembles
numeric constants and outputs a byte for each to TASK3. It transfers information concerning each
constant and any alarm indications directly to the output stream. TASK2 is called by TASK3 when
the latter requires the intermediate byte describing the next source text element.
TASK3, using the bytes furnished by TASK2, examines the entire program for syntactic correctness.
It also rearranges the procedure headings for more convenient processing in later passes and
further classifies certain delimiters, such as the comma and semi-colon, into more exact contextual
meanings. The results of this processing are transferred to the output stream for processing by
ALG2.
If an error is found in a structure, TASK3 suppresses the remainder of the structure up to the
terminating delimiter (such as ; , end,then, else, etc.) replacing it with the special byte which
indicates trouble and bytes indicating the nature of the error. (ALG2 processes this information
in reverse order; it encounters the trouble byte and then removes that part of the structure which
was already in the output stream before TASK3 detected the error.)
ALG2
ALG?2 performs two principal tasks:
It detects each declaration or declaration-like entity, and develops a systematic representation
for them. This representation is output for processing by ALG3 directly behind the begin
of the appropriate block.
It totally removes from the output stream statements marked by the trouble byte. In
general, this ensures syntactic correctness of the remaining code.
145
ALG2 processes the input stream of bytes in the reverse of the source text order (opposite
direction to ALGI1 output). ALG2 consists of various control routines plus the routine TASK4
which performs the two principal functions.
À LG3
A LG3 performs the following major functions:
Generates relative addresses of all variables in the stack.
Checks kinds and types to ensure consistency between the declaration of a given variable
and its use in the statements and expressions of the program.
Generates machine code in a macro-like format which is convenient for À LG4 to use in the
final generation of program addresses.
ALG3 processes the input stream of bytes in the source text order (opposite order to ALG2 output).
ALG3 consists of various control routines plus the three routines TASK5, TASK6, and TASK7 which
perform the principal functions.
TASK5 processes the declarations of a block; it sets up a declaration table which contains descriptions
of all currently accessible variables. Each description includes the kind, type, block level, and
block relative address of the associated variable. This table is referenced by TASK6.
TASK6 checks the types and kinds of all variables for consistency between declaration and use in
the program; and it sets up the reverse Polish notation of the source text, calling upon TASKT
for each element of this Polish string. An error-free program is assumed in TASK6 (as far as
delimiter structure is concerned), this situation having been achieved by TASKs3 and TASK4.
TASK6 contains three sections: it handles operands as they are encountered from the input; it
handles incoming operators and stacks them if necessary; and it handles the priority processing of
stacked operators.
TASK7 is called by TASK6 for each element of a Polish string. Each operand element is stacked by
TASK7 until it encounters an operator element. At this time, it generates the object code (in
macro-like format) for the operator and the corresponding stacked operands.
After each call to TASK7 (for either an operand or operator), control returns to TASK6 for the
next element in the Polish string.
ALG4
ALG4 generates all output from the compiler. The major outputs are: assembly form of object
program (options A and B), relocatable binary form of object program (options X and P), and
segmented form of object program (option 5).
ALG4 processes the input stream of bytes in the reverse of the source text order (opposite direction
to ALG3 output).
146
A LG4 consists of various control routines plus the three routines TASKS, TASK9, and TASK10
which perform the principal functions. TASKS handles the input bytes from ALG3; TASK9 handles
binary relocatable input, and TASK10 generates all of the compiler outputs (except for the source:
listing) from information furnished by TASKS and TASKS.
TASKS generates units of 512 machine instructions and constants from the macro-like bytes output
by ALG3. TASKS scans backwards through the translated program, generating code from the last
end to the first begin, filling in final program point addresses.
TASKS builds up each unit in a 512-word area, stacking instructions from the end with higher
address towards the end with lower address, and stacking constants from the other end. When
the two meet, TASKS calls TASK10 to output the unit.
TASK9 converts subprograms from a relocatable binary form into units of 512 words as described
for TASKS. Like TASKS, it calls TASK10 for every such unit prepared.
TASK10 is called by both TASKS and TASK9 when either has a complete unit of 512 instructions and
constants to output. The three main sections of TASK10 handle assembly language output (A and
B options), relocatable binary output (X and P options), and segmented output (S option). Depending
on the outputs requested, any or all of these sections are executed for any one unit.
9.6 OVERALL COMPILER FLOW
Not all of the passes ALGI1 through ALGS are loaded and executed for every compilation requested.
The selection of passes is based on the compilation and object-code output options specified on the
control card (Chapter 6). Each pass sets information indicating the next pass to be loaded.
The following diagram illustrates the overall flow of the compiler passes based on the control card
options specified.
147
OVERALL FLOW DIAGRAM OF ALGOL COMPILER
end process : =
false
Entry from — _
. multiple : =
Operating
true
System ——
ALGO |
RA 18? G? - next :=1
no
yes {ves
next :=4
_ multiple
next 175 : = false
pe \
| ALGOL
\ Exit to
end yes ,
rocess ={ operating
Р y system
| no
Load and
call
ALG (next)
АСТ ALG2 / ALG3 SN ALG4 ALG5
next :=2 next :=3 next :=4 next :=1 end ga
| ess := true
| |
по /
FINIS y À multiple ?
yes no
multiple в
: = false
yes |
end proc-
next :=5 : = true
| |
148
OBJECT PROGRAM 10
10.1 RUN-TIME SUPERVISORY PROGRAM
A run-time supervisory program, called ALGORUN for 6000 and ALGOLRUN for 3000 for non-
segmented execution and ALGS5 for segmented execution, controls object program execution in
either segmented or non-segmented form. The supervisory program consists of controlling routines
which handle the dynamic stack of variables and the segment structure. ALG5 and ALGORUN
(or ALGOLRUN). are functionally identical except that ALG5 additionally contains the segment
loading and controlling routine.
All calls to the separate global routines are generated within the object program as machine jumps
to different positions in a data vector. Each position of the data vector contains the address of one
particular routine at execution time. The contents of the data vector are defined by the supervisory
program.
10.2 OBJECT-CODE STRUCTURE
Regardless of the final form of the output requested, the object code is generated in segments of 512
machine words. Each segment consists of instructions and any constants referenced by these in-
structions. The object code is generated backward (from the last to the first begin).
Within each segment, the constants are stacked above the instructions and are given lower addresses
than the instructions. The instructions are sequenced so that execution within each segment proceeds
normally from low address to high. The last instruction in each segment is a system jump to the
first instruction of the next logical segment (the one physically preceding). The program is entered
at the last segment generated (the logical beginning of the program).
10.3 OBJECT-CODE GENERATION
The object code is generated first in an internal representation of the final code in segments of 512
words as described above. The non-segmented output is obtained directly from this representation;
the segments collectively form one standard operating system relocatable binary subprogram. The
segmented output is obtained by modifying the address fields of instructions so that each segment is
individually relocatable; each modified segment is output separately to the segment file. (A binary
subprogram which already physically exists is incorporated into a segment file by first converting it
to the internal representation.) It, therefore, follows that the two forms of the object code are
structurally identical.
149
10.4 LIBRARY SUBPROGRAMS
The library subprograms obey the same structural rules as a binary subprogram generated by the
compiler. Each subprogram consists of one or more segments, and each contains one or more of
the standard procedures. The standard procedures are organized logically, so that functionally
similar procedures (such as SIN and COS, and IN REAL and IN ARRAY) are contained in the same
subprogram.
10.5 ADDRESS-FIELD CONVENTIONS
Three basic types of references can be made in an object program: a reference to the stack, and a
reference from one instruction to a point in the same segment, or to a point in a different segment.
Correspondingly, three types of address fields are generated. In addition, except for stack refer-
ences, the forms of the address fields are different in the non-segmented and segmented output,
though at execution time (after loading), they are essentially the same.
Reference to the Stack
Every variable in the stack is referenced relative to a stack reference address (Chapter 11), which
is the beginning address of the stack area reserved for the block in which the variable is declared.
Such references are therefore generated as the relative number (position) of the variable in its
block plus an index register which contains the appropriate stack reference address.
Reference to the Same Segment
Such a reference can be either a reference to a constant in the segment or a compiler-generated
jump to a point in the same segment (such as a bypass in an if statement).
In the non-segmented form, the address field is a normal subprogram address, relative to the
beginning of the whole subprogram. In the binary form, this field is flagged to indicate that it
requires positive program relocation by the system loader, which results in the desired absolute
address.
In the segmented form, the address field is changed to the relative position of the desired location
within the segment itself (000YYY). This field is flagged in the segment file to indicate that it
requires segment relocation when the segment is loaded, which results in the desired absolute
address.
Program jumps (as opposed to compiler-generated jumps), such as those generated from go to
statements, are generated in the form of a reference to a different segment even if the destination
address is in the same segment.
150
Reference to a Different Segment
Such a reference can result only from a transfer of control requirement (which may necessitate a
jump out of the segment). Because of this, all such transfers are performed through the run-time
supervisory subprogram, in both the segmented and non-segmented forms.
This transfer of control is generated as a call to one of the routines in the supervisory subprogram,
with the destination address as a parameter to call.
In the non-segmented form, the address field is the complement of the normal subprogram address
in relation to the beginning of the whole subprogram. In the binary form, this field is flagged to
indicate that it requires negative program relocation by the system loader, which results in the
complement of the desired absolute address.
In the segmented form, the address field is changed to MMMYYY where MMM is the segment number
of the referenced segment on the segment file. This is interpreted by the controlling routine as
relative location 000YYY within the segment MMM (which is loaded if not already available).
A reference from the program to a library or separately compiled procedure has exactly the same
form as a reference to a different segment, except for the form of the destination address in the
actual program. This always has the form 000YYY where YYY is a constant which is used as a
relative address into a table which contains the addresses of all such procedures.
151
OBJECT-TIME STACK 11
11.1 STACK STRUCTURE
According to the rules of the ALGOL language, a variable is active (available for reference) in any
block to which it is local or global. A variable is local to the block in which it is declared and global
to the sub-blocks within the block in which it is declared.
Depending on the block structure and the variables declared at each level, not all variables are active
at the same time. The object programs produced by ALGOL overlay variables which are not simulta-
neously active. The overlay process is described below.
During execution of an object program, all variables are contained in a variable-length memory stack
consisting of 60-bit (48-bit) entries, one or more pertaining to each active variable. Since the stack
includes only active entries, the size fluctuates.
The compiler assigns to each variable an address relative to the stack reference for the block in which
that variable is declared in the reverse order of their declarations. The stack reference for each block
is the position in the stack where the entries for that block are assigned at object-time. It is derived
as follows:
When a new block is entered which is nested in the last block entered, the stack reference for the new
block is assigned to the first available (inactive) position in the stack. Certain preliminary information,
including the stack reference of the next outermost block, is set into the stack, beginning at this
reference point.
The compiler assigns a block level number to each block in the program, and the object program main-
tains 32 display entries each of which contains the stack reference for blocks at the corresponding level.
The display entry corresponding to the new block is set to contain the new stack reference. Since there
are 32 display entries, a program may contain a block structure in which blocks are nested up to a depth
of 32 levels.
When a block is exited, the space in the stack occupied by its local variables is released as the variables
become inactive. The display entry corresponding to the block being exited necessarily contains the
stack reference for this block (the point up to which the stack can be released).
A go to reference from one block in a nest to an outer one results in an exit from that block and from
all of the blocks up to but not including the referenced block. Thus, the effect is to change the environ-
ment of the active variables to be only those local or global to the referenced block.
When a procedure call is made, the current environment (or record of it) is preserved, since a return
must be made to it at the completion of this call. The environment in which the procedure is declared
is established, and the procedure entered. This results in a change of the display, but no stack is
released. The procedure is executed with the corresponding variables available to it, and the original
environment is re-established.
152
Consider the following program outline:
begin
procedure R
begin
begin
R
5
A end end
— begin — na
begin
P x R
A
— end
begin
Y goto L
end end
L:
begin
B
end
end
Block P is the program itself; blocks A and B and procedure R are at the same level within P; block S
is contained in procedure R; blocks X and Y are at the same level within block A. Block X contains a
call to procedure R; block Y contains a jump to label L within the outermost block (the program itself).
The changes in the stack and display entries can be visualized as follows:
153
Stack Contents at Different Stages during Program Execution
q Wo
yrxe
1O1V
a 9
Axjuo
TOIFV
д ‘полу
утхе
лоу
A 91
aus
191
Xx UIOLJ
31x
хе1у\у
y Vox]
3х
лезуу
g UIOJJ
ухе
хезуу
S 0}
AIjuo
101
Yu 01
Axque
JUV
X 0}
Axyuos
T917V
у 93
AUS
19017
Я ©}
AUS
1013Y
Stack
Reference
154
Address
a and b
x and y
ol
Display Entry Values at the Same Stages!
Display
Ent
— — ый
—— — —
Чана — аннннио tt
31
32
not used
fempty
Following the call to procedure R, the information for blocks A and X remains in the stack; however it
is not accessible, since the corresponding display entries are overwritten (and re-established when R
is exited). The information for block P also remains in the stack; but this is accessible, since its
display entry is not changed. This exactly follows the rules described in the ALGOL-60 Revised Report
concerning the accessibility of variables during and after return from a procedure call.
11.1.1 OWN VARIABLES
All own variables are assigned entries in the stack prior to the entries assigned to the outermost block
of the program. Thus, own variables are treated as global in definition (local to the whole program),
though they are only local in scope to the block in which they are declared, just like other variables.
For an own array, the stack entries for each element in the array appear prior to the entries for the
outermost block; the other entries for the array appear in the normal position in the declaration block.
11.1.2 STACK LISTING
The object program controlling system includes a routine which produces the active contents of the stack
in a meaningful format upon abnormal object program termination. This structured dump may also be
called by the procedure DUMP. Own variables do not appear in such a dump.
11.2 STACK ENTRIES
11.2.1 VALUE OF VARIABLES
Simple local variables and simple formal parameters called by value are represented in the stack as
follows:
Real
60-bit ¢8-bit) entry in standard floating-point form (Section 5.1.3, Chapter 2).
Integer
60-bit (48-bit) entry in standard floating-point (fixed-point, vight-justified integer) form
(Section 5.1.3, Chapter 2).
Boolean
6000: 60-bit entry in which bits 58-0 are always set to 0. Bit 59 is set to 1 for true and 0
for false.
Upper 3000: 48-bit entry in which bits 47-0 are always set to 0. Bit 0 is set to 1 for true and 0 for false.
Lower 3000: A 48-bit entry in which bits 47-25 are always set to 0. Bit 24 is set to 1 for true and 0 for false.
155
11.2.2 DESCRIPTION OF VARIABLES
All descriptions of variables in the stack have the following general form:
6000
XXXX XXXXXX XXXX XXXXXX
( х = 0: > <i>, <>. <>, <b>, - address 1 <s>, <o> y address 2
| x =1: > <i>, <>, «>, <>.
х = 0 Transformation required
x=1 No transformation required
Depending on the value of x, the remaining 11 bits of the upper 12 are either their true values or their
one's complement values, as shown above.
t is the type of the variable
Type Possible Use
No type
Integer.
formal and local
Real
Integer -real
Integer -real-integer
formal only
t
0
1
| 2
3 Boolean
4
5
6 Real -integer-real
7
Real -integer
в is the sign of address 1, wherever applicable
3000
XX XXXXXX | XX XXXXXX
j ddr
<*>. <>. address 1 <i>, <k> 5 address 2
156
indicates whether or not a transformation must be applied in the case of a formal arithmetic variable, and
can take the following values:
x Transformation
0 None
1 Fix
2 Float
3 Fix-then-float
Possible Use
formal and local
formal only
is the type of the variable
a
Type
No type
Boolean
Real
Integer
SS MM NN VW N Ss DS
Integer-real
Real-integer
Real-integer-real
Possible Use
formal and local
formal only
is used by the system in conjunction with k as described later
is the kind of variable
6000 3000
Kind Possible Use
K K
00 02 Switch
01 03 String
02 04 Label of designational expression
formal and local
03 05 No-type procedure
04 06 Typed procedure
05 07 Array
06 10 Constant
07 11 Expression
formal only
10 12 Simple variable
11 13 Subscripted variable
157
The interpretation of address 1 and address 2 depends on the kind (k) of the description as explained
below.
A stack entry representing an arithmetic value may have a structure which makes it appear to be a
description.
11.3 DETAILS OF DESCRIPTIONS
The following detailed explanations of the descriptions are ordered according to the kind, k. Return
information for a procedure call does not have a kind; it is described first.
11.3.1 TERMINOLOGY
All references to the stack in the object program are relative to the beginning of the stack area for a
particular block. When a block is entered at execution time, the base address of the corresponding
stack area is assigned. This absolute base address is the stack reference, RRRRRR of the block,
The term segment location, SSSSSS, means an address pointing to a position in the object program. In
non-segmented execution, it is the 18-bit complement of an absolute address. In segmented execution,
it is interpreted as a 9-bit segment number followed by a 9-bit segment relative address.
The term stack address, AAAAAA, means an absolute address pointing to a particular stack entry.
Detailed explanations of the descriptions are given for 6000 ALGOL on pages 158 to 162 followed by
3000 on pages 162 to 166.
11.3.2 DESCRIPTIONS FOR 6000
XXXX KXXXXX XXXX XXXXXX
Return
Information Number of formals | SSSSSS | <s> 1 <Appetite> RRRRRR
s - sign of SSSSSS
Appetite = No. of formals + No. of constants + 1.
SSSSSS Segment location of next sequential instruction
following the procedure call.
RRRRRR Stack reference of the block in which the
procedure call is made.
XXXX XXXXXX XXXX XXXXXXK
00 Switch
5777 | AAAAAA 0000 NNNNNN
AAAAAA Stack address of the description of the first
element of the switch list.
NNNNNN Number of elements in the switch list.
158
In a switch declaration, this description is immediately preceded in the stack by the descriptions of the
labels or designational expressions (sce kind 02, below) which constitute the switch list, as follows:
аааааа,
01 String
02 Label
< Designational expression of the no switch element> 60
< Designational expression of the (a-1) switch element>
<Designational expression of the lst switch element>60
<B5777 aaaaaa 0000 1>60
XXXX XX XXXX XXXX XXXXXX
5767 | SSSSSS | 4000 | <c>1 <0>1 <X>g<N>10
¢ Format string flag
с = 1 string has been analyzed and can be used
as a format string.
©
q
0 string must be analyzed to see if it can be
used as a format string.
X X replicator count in the string.
N Number of characters in string.
The string itself is stored in-line in the object program.
SSSSSS Segment location of the first word address of the string.
XXXX XXXXXX XXXX XXXXXXx
9757 | SSSSSS | 4000 | RRRRRR
SSSSSS Segment location of the point in the object program
corresponding to the label.
RRRRRR Stack reference of the block containing the label.
For each for statement, the compiler generates an artificial label with the same description as a
normal label. This label is used to return from the end of the for statement to the control at the
beginning. Whenever the for statement is not in execution, the segment location, SSSSSS, of this label
is set to point to a special system entry segment location 000011, in order to detect abnormal use of the
statement. In addition, bit 59 of the description is preset to 1 before entry to each step-until element,
and set to 0 after this element has been entered.
159
02 Designational
Expression
03 No-type
Procedure
04 Typed
Procedure
05 Array
KXXX XEXXXKXX XXXX XXXXXXx
5757 | SSSSSS | 4000 | RRRRRR
SSSSSS Segment location of the code which evaluates the
expression and jumps to the resulting address.
RRRRRR Stack reference of the block containing this code.
XXXX XXXKXKXK XXXX XXXXXX
7747 | SSSSSS | 4000 | RRRRRR
SSSSSS Segment location of the procedure.
RRRRRR Stack reference of the block containing the procedure.
KXXX XXXXXXx XXXX XXXXXX
004t
{oot SSSSSS | 4000 | RRRRRR
SSSSSS Segment location of the procedure.
RRRRRR Stack reference of the block containing the procedure.
XXXX XXXXXX XXXX KXKXXX
{2 AAAAAA | 0000 | DDDDDD
AAAAAA Base address of the array elements in the stack.
DDDDDD Base address of the dope vector in the stack. The
dope vector is used to calculate the addresses of the
array elements (see below).
The elements of an array are assigned above the last working location of the particular block.
own arrays are handled in the same way, except that their elements are assigned among the own
variables.
The elements of an array called by value are copied (and transformed, if necessary) to a position above
the working locations of the block of the procedure,
160
In an array declaration, the dope vector of the corresponding bound -pair list precedes the descriptions
for all array identifiers of an array segment.
The dope vector for the array declaration
array A [£, : U1, 49: U9,... In: Unl is:
< Cn > 60
< Ch-1“Cn>60
<Со * Са* ass sen e eue * Ch-1*Cp,>60
< Length of array > 60
DDDDDD < Lower bound effect > 60
< п = No. of dimensions > 60
where Ci = Ui - La +1
Length of array = C, *C5"Cg..... *C
Lower bound effect = (((.. (81 * Cog + 49) * Cg + £3)*...)* Cy + An
The address of any element is referenced by the base address of the array plus
(((.. (11 * C9 + 19)* Ca +i3)*....) Ch +in - lower bound effect.
For example, the description of the declaration
array A, B [1:3,2:5] is:
< 4> 60
< 12> 60
dddddd < 6> 60
< 2> 60
<5725 bbbbbb 0000 dddddd> 60
<5725 aaaaaa 0000 dddddd> 60
XXXX | XXXXXX | XXXX XXXXXX
Com | 42008) | 00000 | 0000 | AAAAAA
AAAAAA Address of the constant in the stack.
161
07 Expression
10 Simple
Variable
11 Subscripted
Variable
XXXX XXXXXX | XXXX XXXXXX
007t
{ot SSSSSS | 4000 | RRRRRR
SSSSSS
expression.
RRRRRR
XXXX | XXXXXX | XXXX XXXXXX
210t
ed 000000 | 0000 | AAAAAA
AAAAAA
XXXX | XXXXXX | XXXX XXXXXX
011t
1 6 ed SSSSSS | 4000 | RRRRRR
SSSSSS
of the subscript variable,
Address of the simple variable in the stack.
Segment location of the code which evaluates the
Stack reference of the block containing this code.
Segment location of the code to evaluate the address
RRRRRR Stack reference of the block containing this code.
11.3.3 DESCRIPTIONS FOR 3000
Return
Information
02 Switch
162
XX
XXXXXXx
XX
XXXXXX
Number of formals
RRRRRR
Number of constants
+1
SSSSSS
SSSSSS
procedure call.
Segment location of next sequential instruction following the
RRRRRR Stack reference of the block in which the procedure call is made.
XX
XXXXXX
XX XXXXXX
00
NNNNNN
02 | 6AAAAA
6AAAAA Stack address of the description of the first element of the switch
list. (The 6 provides an index register number for indirect addressing.)
NNNNNN Number of elements in the switch list.
In a switch declaration, this description is immediately preceded in the stack by the descriptions of the labels or designa-
tions expressions (see kind 04, below) which constitute the switch list, as follows:
< Designational expression of the n' h switch element > 48
< Designational expression of the (n—1)* A switch element > 48
aaaaa < Designational expression of the 1st switch element > 48
< 00 n 02 baaaaa > 48
03 String XX XXXXXX XX XXXXXX
<X> <N> <e>. <03> SSSSSS
12 12 | % 175
c Format string flag
c = 1 string has been analysed and can be used as a format string.
с = 0 string must be analysed to see if it can be used as a format string.
XX replicator count in the string.
N Number of characters in string.
The string itself is stored in-line in the object program.
SSSSSS Segment location of the first word address of the string.
04 Label XX хххххх XX | хххххх
00 | RRRRRR | 04 | SSSSSS
SS Segment location of the point in the object program corresponding
to the label.
RRRRRR Stack reference of the block containing the label.
For each for statement, the compiler generates an artificial label with the same description as a normal label. This label
is used to return from the end of the Jor statement to the control at the beginning. Whenever the Jor statement is not in
execution, the segment location, SSSSSS, of this label is set to point to a special system entry segment location 000011,
in order to detect abnormal use of statement. In addition, bit 47 of the description is preset to 1 before entry to each
step-until element, and set to 0 after this element has been entered.
163
04 Designational
Expression
05 No-type
Procedure
06 Typed
Procedure
07 Array
XX XXXXKX XX | XXXXXX
00 | RRRRRR | 04 | SSSSSS
555555
RRRRRR Stack reference of the block containing this code.
Segment location of the code which evaluates the expression and jumps
to the resulting address
XX XXKXXX XX | XXXXXX
00 | RRRRRR | 45 | SSSSSS
555555 Segment location of the procedure.
RRRRRR Stack reference of the block containing the procedure.
XX XXX KKK XX | XXXXXX
<x>, <t> 3 RRRRRR | 46 | SSSSSS
e)
SSSSSS Segment location of the procedure.
RRRRRR Stack reference of the block containing the procedure.
хх XXXXXX XX XXXXXX
<x> 3 <t> 3 AAAAAA | 07 | 6DDDDD
AAAAAA Base address of the array elements in the stack.
6DDDDD Base address of the dope vector in the stack. The dope vector is
used to calculate the addresses of the array elements (see below).
The 6 provides an index register number for indirect addressing.
The elements of an array are assigned above the last working location of the particular block, but do not appear in the
dump.
own arrays are handled in the same way, except that their elements are assigned among the own variables.
The elements of an array called by value are copied (and transformed, if necessary) to a position above the working
locations of the block of the procedure. |
164
In an array declaration, the dope vector of the corresponding bound-pair list precedes the descriptions for all array iden-
tifiers of an array segment.
The dope vector for the array declaration
array A 1%] : uz, Ro up, ... Q
Upper 3000
< C, >48
< C,_] > 48
< С» > 48
<n = No. of dims.>24 < Length of array > 24
DDDDD < Lower bound effect > 48
where Ci =U; —; +1
Length of array =C¡ * C9* C3..... *C,
n° u,/ is:
Lower 3000
<C, > 24 <Not used > 24
< С, >24 <Not used > 24
<CH > 24 <Not used > 24
< Length of array > 24 <Not used > 24
< Lower bound effect >24 <n = No. of dims. > 24
Lower bound effect =(((. (2; * Co+Q9)*C3+23)*...)*C +2,
The address of any element is referenced by the base address of the array plus
((..(i7 *Co9+iy)*Cz+i3)*....)*C ti, — lower bound effect.
For example, the description of the declaration
array A, B [1 : 3,2: 5] is:
Upper 3000
< 4 >48
< 2> 24< 12> 24
ddddd < 6 > 48
<<x>3 <t>3 bbbbbb 07 6ddddd > 45
<<x>3 <t>3 aaaaaa 07 óddddd > 48
Lower 3000
< 4 > 24 < Not used > 24
< 12 > 24 < Not used > 24
<6 >24 < 2 > 24
165
10 Constant
11 Expression
12 Simple
Variable
13 Subscripted
Variable
166
AX
XXXXXX
KXXXXXXK
o <t> 3
AAAAAA
10
000000
AAAAAA Address of the constant in the stack
XX XXXXXX XX | XXXXXX
<>. <>. RRRRRR | 51 | SSSSSS
SSSSSS
RRRRRR Stack reference of the block containing this code.
Segment location of the code which evaluates the expression.
XX XXXXXX XX | хххххх
>, <b>, AAAAAA | 12 | 000000
AAAAAA Address of the simple variable in the stack.
XX XXXXXX XX | XXXXXX
<>. <t> 3 RRRRRR | 53 | SSSSSS
SSSSSS
RRRRRR Stack reference of the block containing this code.
Segment location of the code to evaluate the address of the
subscript variable.
OBJECT-TIME ABNORMAL TERMINATION DUMP 12
Upon abnormal termination of an object program, a diagnostic is printed on the standard output
device to indicate the nature of the error. The contents of all non-empty output format areas are
output on their respective files. If a non-empty format ares is associated with standard output, its
contents appear on that file preceding the object-time diagnostic. This information is followed by
a structured dump.
12.1 STRUCTURED DUMP
The structured dump traces the execution path through the block structure currently active when the
error occurs. The information relevant to the ALGOL program at the time the error occurred
(values, descriptions, and/or locations of variables) is selected from core storage for printing in
this dump. The dump has the following format:
THIS ERROR OCCURRED AFTER LINE xxxx
IN THE BLOCK ENTERED AT LINE xxxx
(global information)
(environmental information)
THIS BLOCK WAS CALLED FROM LINE xxxx
IN THE BLOCK ENTERED AT LINE xxxx
(environmental information)
THIS BLOCK WAS CALLED FROM LINE xxxx
IN THE BLOCK ENTERED AT LINE xxxx
(environmental information)
sa a B82 + = 8 + 0
LINE xxxx refers to the number assigned to each source image line during compilation and printed
with the source program listing. If the block entered is a standard procedure, the word STAN
appears instead of the line number.
12.2 GLOBAL AND ENVIRONMENTAL INFORMATION
6000
Each line of global and environmental information consists of an 18-bit address ficld printed as 6
octal digits, and a 60-bit information ficld, representing the contents of one stack entry, printed as
20 octal digits in fields of 4, 6, 4, and 6, as follows:
167
Address Field Information Field
XXXXXX XXXX XXXXXX XXXX XXXXXX
3000
Each line of global and environmental information consists of a 15-bit address field printed as 5 octal digits, and a
48-bit information field, representing the contents of one stack entry, printed as 16 octal digits in fields of 2, 6, 2,
and 6, as follows:
Address Field Information Field
KXXXX XX XXXXXX XX XXXXXX
12.2.1 GLOBAL INFORMATION
The global information applies to the running program as a whole, without regard to the currently
active block structure. It has the following format:
THE GLOBAL VARIABLES ARE...
UA, VALUE
Uv information field
LASTUSED
UA, UV, and LASTUSED are the names of variables internal to the ALGOL system.
UA contains the address of the last accessed formal parameter, the address of the value of a typed
procedure, or the address of the last referenced array element. The address field gives the contents
of UA. The information field gives the contents of the location referenced by this address.
UV is used only to contain either the value of the last accessed formal parameter if this does not
appear in the stack (such as, a formal expression) or the value of a typed procedure. (Whenever
UV is in use, UA contains the address of UV). The address field gives the address of UV. The
information field gives its contents.
LASTUSED contains the address of the top stack element. The address field gives the address of the
top stack element. The information field gives the contents of the location referenced by this address.
168
12.2.2 ENVIRONMENTAL INFORMATION
Environmental information consists of descriptions or values of formal and/or local variables be-
longing to the appropriate block level. Formal variables appear only if the particular block is a
procedure. Simple local variables and simple formal parameters called by value are represented
by their values; all other variables are represented by a description. The format of these values
and descriptions are given on pages 155 to 166.
FORMAL VARIAB LES
Formal variables are dumped in the following structure:
1st line Return information
2nd line 1st formal parameter
3rd line 2nd formal parameter
last formal parameter
1st constant used as actual parameter
2nd constant used as actual parameter
* db #9 +# +»
LOCAL VARIABLES
In addition to every declared variable, one stack entry exists for cach artificial label generated
for a for statement and one for each designational expression of a switch list; moreover, each
bound-pair list, in an array declaration containing n bound pairs, generates n+2 (n+l ) stack
entries. All these entries appear in the stack in reverse order from their appearance in the
source program and they are dumped in this form. Any additional stack entries following the first
declared (last printed) variables represent intermediate working locations generated by the compiler.
169
THE ALGOL 48-CHARACTER SET
Character Card Punch Character Card Punch
A 12-1 Y 0-8
B 12-2 Z 0-9
C 12-3 0 0
D 12-4 1 1
E 12-5 2 2
F 12-6 3 3
G 12-7 4 4
H 12-8 5 o
I 12-9 6 6
J 11-1 7 7
K 11-2 8 8
L 11-3 9 9
M 11-4 + 12
N 11-5 - 11
O 11-6 * 11-4-8
P 11-7 / 0-1
Q 11-8 = 3-8
R 11-9 ( 0-4-8
S 0-2 ) 12-4-8
T 0-3 . 12-3-8
U 0-4 , 0-3-8
у 0-5 | ! 4-8
W 0-6 $ 11-3-8
X 0-7 Ш LT
T blank column
170
SAMPLE PROGRAM B
The following program is in the exact form that is punched into the cards that comprise the source
deck (the hardware language).
2-DIMENSIONAL ARRAY.
THIS PROGRAM DECLARES A SERIES OF ARRAYS OF EVER-INCREAS ING
DIMENSION, THE ARRAY IS THEN FILLED WITH COMPUTED VALUES, ONE
OF WHICH IS ALTERED. THE ALTERED VALUE IS THEN SEARCHED FOR
AND PRINTED,
THE PROGRAM HALTS WHEN THE DECLARED ARRAY SIZE EXCEEDS THE
AVAILABLE MEMORY. WHEN THIS OCCURS, THE PROGRAM EXITS WITH
THE MESSAGE STACK OVERFLOW ON THE STANDARD
OUTPUT UNIT.
'BEGIN' 'INTEGER' I.,
I..=10.,
L..L..=I+1,,
OUTPUT(61, '('/,3D')',I).,
'"BEGIN' 'ARRAY' A(/-3*L..—-I,I..2*1/)., 'INTEGER' P,Q.,
'"FOR' P,.=-3%I 'STEP' 1 'UNTIL' .1 'DO'
'FOR' Q..=I 'STEP' 1 'UNTIL' 2*I 'DO'
A(/P,Q/)..=-P+100%*Q. ,
A(/-2%1,T+2/). .=A(/-2%1 ,1+2/)+10000. ,
'FOR' P,.=-3*I 'STEP' 1 'UNTIL' -I 'DO'
'"FOR' Q..=1 'STEP' 1 'UNTIL' 241 "DO"
'IF' A(/P,Q/) 'NOT EQUAL' 100*Q-P 'THEN'
'BEGIN' OUTPUT(61,'('/,5D')',A(/P,Q/)) 'END'.,
"GOTO" L
'END'
'END'.,
'EoP'
171
COMPARISON: ALGOL 3000L/3000U/6000
(SUBJECT TO CHANGE)
172
Internal Representations
Features 3000L 3000U 6000
© | own variables in
5 separately compiled NO YES
5 procedures
[|
size or variables 48 bits 60 bits
real 48-bit normal 60-bit normal
variable floating point floating point
integer 5 48-bit 60-bit normal
variable fixed point floating point
Boolean Only upper 24 bits All 48 bits Only high-order bit
variable significant: significant: significant:
true : : = non-zero true : : = non-zero true : : = non-zero
false : : = zero false : : = zero false : : = zero
Integer numbers,
> 14 signif. digits
Treated as type real,
FLOATED INTEGER message
Treated as type
integer, no message
real - integer
conversion
Round, change from float to fix, possible
FLOAT-FIX OVERTLOW diagnostic
Round only. No
other change
integer - real
conversion
Change from fix to float, possible loss
of low-order significance”
No change; already
in desired form
Compile-time
arithmetic
NO
Yes, between constants in expressions,
possible ARITIIMETIC OVERTLOW diag.
Evaluating array
element address
Fixed point 24-bit
arithmetic
Fixed point 48-bit
arithmetic
I'loating point 60-bit
arithmetic
Form of string
chars. in obj. code
Internal BCD
Display Code
General
Core space needed
by compiler
6000 24-hit words
8000 48-bit words
10,000 60-bit words
Compiler estimates
size of object-
program и
Yes, INSTRUCTION
UNDER COUNT diag-
nostic issued if
incorrect
NO
Operating System /Hardware
Compile-time 1-0
device definition
According to the corresponding operating system
A
Object-time I-O
device definition
on ALGOL channel
LUxx, where-xx is a SCOPE logical unit
number or DSIXxx, where xxx is a data
set identifier for MASTER
SCOPE file name
(Note: LUxx is a
legal file name)
Relocatable binary
output format
According to the corresponding operating system
Segmented binary
output format
Segment file containing 512-word segments, the recording
characteristics varying across the series
ALGOL control
card
According to the corresponding operating system
CHARACTER REPRESENTATION OF ALGOL SYMBOLS
Table 1. Character Representation of ALGOL Symbols
ALGOL 48-Character ALGOL 48-Character
Symbol Representation Symbol Representation
A-Z A-Z true 'TRUE'
a-z ~ false "FALSE"
0-9 0-9 go to 'GO TO!
+ + if "IF!
- — then "THEN"
X * else "ELSE!
/ / for "TOR"
bo "POWER! do "DO"
+ / or 'DIV' step 'STEP'
> 'GREATER' until 'UNTIL'
> 'NOT LESS' while 'WITLE'
= = or 'EQUAL' comment "COMMENT"
# 'NOT EQUAL" begin 'BEGIN'
< 'NOT GREATER' end 'END'
< 'LESS' own 'OWN'
A 'AND' Boolean "BOOLEAN
У 'OR' integer "INTEGER!
= 'EQUIV' real 'REAL'
T1 ' МОТ" array "ARRAY!
> 'IMPL' switch 'SWITCH'
procedure "PROCEDURE!
, , string "ST RING"
: label 'LABEL'
; . value 'VALUE'
10 ' code 1+ 'CODE'
LJ || еор TT "EOP!
( (
= ,=or..=
) )
(/ '
/)
С" Га) он! у
{ In a format string, + is represented by an asterisk.
t+ Not defined in the ALGOL-60 Revised Report; code is defined in Section 5.4.1, Chapter 2;
eop in Chapter 4.
173
INDEX
Abnormal Termination 167
Actual-Formal Correspondence 40
Address Fields 150
ALGOL-60 Revised Report 8
Input-Output 58
ALGORUN, ALGOLRUN 108, 149
ALGOL, ALG1 5, 144
ALG2 6, 145
ALG3, ALG4 6, 146
ALG5 6, 109, 149
Alignment Marks 67
Alpha Format 66
Arithmetic Expressions 23
Operators 25
Precedence of Operators 27
Type 26
Transformation of Type 34
Array Bounds Check 21
Array Declaration 44, 45, 161
ARTHOFLW 96
Assembly Language Object Code 109
Assignment Statements 33
Type 34
BACKSPACE 97
BAD DATA 96
Basic Concepts 14
Binary Output 107
Blanks 15, 70, 103
Block 31
Level Number 152
Structure 152
Body Replacement 40
Boolean 28
Expressions 28, 29
Format 67
Variables 42, 43
Bound Pair List 45
Card Conventions 103
Channels 72, 73
Channel 119
Cards, Standard 122
Cards, Typical 123
Define Card 119
End Card 121
Equate Card 121
Number 119
Number, Duplication of 121
Character 65 |
Set 170
Transmission 79
Character Representation of ALGOL Symbols 106
CHLENGTH 96
Code 41
Procedure Body 49, 51
Comma Suppression 61, 62
Comparison Table 3000/6000 172
COMPASS 109
Compiler
Description 143
Diagnostics 124
Outputs 5.
Overall Flow Diagram 148
Package 5
Subprograms 143
Compound Statements 31
Conditional Statement 35
CONNECT 98
Contents of ALGOL-60 Revised Report 9
Control Card 111
6000 111
3000 1183
3000 MASTER 114
Parameter Letters 112
Typical 6000 112, 116
Typical 3000 114, 117
Typical 3000 MASTER 115, 118
Index-1
Control, Horizontal and Vertical 73
Controlled Variable 39
Data Set Identifier 119
Data Storage, Intermediate 90
Decimal Points 62
Deck Structure 104
Declarations 41
Delimiters 15
Designational Expressions 30
Diagnostics 133
Compile-Time and Object-Time I/O
6000 133
30000 134
3000L 136
3000 MASTER 135
Object-Time 137
Digits 14
Display Entry 152
Dummy Statement 35
DUMP 98
Dump 167
Object-Time Abnormal 167
Structured 167
ENDFILE 97
End of Data 77
End-of-File 99
End-of-Tape 99
ENTIER 23
Environmental Information 167
EOF 96
Error 124
Arithmetic 25
Detection 5
Diagnostics 124
Input-Output 99
Exponent Part 63
Expressions 19
Arithmetic 23
Designational 30
Index-2
File Names 122
FORMAT 75
Formats
Alpha 66
Codes 69
Number 59
Standard 69
String 64, 65, 68
For 37
Statements 37
List 38
Function Designators 21, 48
Functions 22
GET ARRAY 90
Global Information 167
Go To Statements 34
Hardware
Function Procedures 97
Language 7, 12
H END, V END 75
H LIM, V LIM 75
Hidden Variables 77
Horizontal Control 73
Identifiers 16
Identifier Table 144
IN ARRAY 80
IN CHARACTER 79
IN CONTROL 91
IN LIST 71
Index of Definitions of Concepts
and Syntatic Units 55
Information Flow 143
Input-Output 58
ACM Proposal 59
Calls 79
Error Condition 68
Example 93
Number Formats 59
Procedures 70
Processes 86
IN REAL 80
Insertions 61
Integer 18
Labels 831
Numbers 18, 27
Variables 42, 43
INTERM1, INTERM2 112
IOLTH 98
Labels 31
Language 143
Analysis 143
Conventions I/O 102
Translation 143
Layout Procedures 75
Letters 14
LIBRARY 112
Library Subprograms 150
Line Width 120
List Procedures 78, 79
Logical Values 15
Machine Configuration 6
Machine -Dependent I/O Processes 94
MANINT 96
MASTER 119
Memory 6
Usage 4
Metalinguistic Connectives 18
Variables 18
MODE 98
MSOS 119
Name Replacement 40
NO DATA 75
Nonformat 66
Non-Segmented Output 107, 149
Numbers 16
Format 17, 59, 63
Internal Representation 17
Types 18
Object-Code 149
Object Program Execution 5
Object Program Stack 152
Operators 25
Precedence Arithmetic 27
Precedence Boolean 29
Operating Systems 6
OUT ARRAY 80
OUT CHARACTER 79
OUT CONTROL 91
OUT LIST 71
OUTPUT 81
OUT REAL 80
Output 58
Calls 79
Processes 81
Procedures 70
Overlay Process 152
Own 41
Arrays 45
Variables 41, 44, 155
Page Length 120
Parameter Delimiters 41
PARITY 96
Procedures 39
Control 91, 96
Declaration 46
Hardware Function 93, 97
Input-Output 70, 75, 96
Separately Compiled 49
Standard 23
Statement 39
Procedure Statement Restrictions 40, 41
Program Sample 171
Publication Language 7, 12
PUT ARRAY 90
Quantities 19
Real 18
Numbers 18, 27
Transmission of Type 80
Variables 27, 42, 43
Index-3
Reference Language 7, 11
Replicators 61
REWIND 97
Run-Time Supervisory Program 149
Sample Layout 3
SCOPE 119
Scopes, Influence of 46
Segment 150, 151
File 108
Location 158
Segmented Output 107, 108, 149
Sign Suppression 61, 62
SKIPF, SKIPB 97
Skipping 90
Source
Deck 103
Input 4
Input Restrictions 102
Listing 110
Procedure 101
Program 100
Specifications 48
Stack 152
Address 158
Entries 155
Reference 150, 158
Structure 152
Standard 22
Format 69, 70
Functions 22
Statements 31, 32
Assignment 33, 34
Conditional 35, 36
Dummy 35
For 37
Go To 34, 35, 39
Procedure 39
Step-Until 38
String 18, 19
Formats 61, 64, 65
STRING ELEMENT 96
Subprograms 5, 6, 107, 108
Subscript 20, 21
Bounds 45
Expression 30
Index-4
Switch Declarations 45
Designator 46
List 46, 159, 169
Symbols 173
Syntax 13
SYSPARAM 91
TABULATION 75
Title Format 67
Transfer Functions 23
Transmission 80
Errors 99
Of Arrays 80
Of Type real 80
Truncation 62
Type
Conversion 18
Declaration 42
Types 19
UA, UV, LASTUSED 168
Unit Numbers 72
UNLOAD 97
Values 19
Value Assignment 40
Variables 20, 152
Formal 156, 169
Global 152, 168
Local 152, 156, 169
Metalinguistic 13
Own 41, 44, 155
Representation in Stack 155
Subscripted 45
Vertical Control 73
While 38
Zero Suppression 61, 62
CONTROL DATA
COMMENT AND EVALUATION SHEET
ALGOL Generic Reference Manual
3000/6000
Pub. No. 60214900 December, 1967
THIS FORM 1S NOT INTENDED TO BE USED AS AN ORDER BLANK. YOUR EVALUATION
OF THIS MANUAL WILL BE WELCOMED BY CONTROL DATA CORPORATION. ANY
ERRORS, SUGGESTED ADDITIONS OR DELETIONS, OR GENERAL COMMENTS MAY
BE MADE BELOW. PLEASE INCLUDE PAGE NUMBER REFERENCE.
NO POSTAGE STAMP NECESSARY IF MAILED IN U. S. A,
FOLD ON DOTTED LINES AND STAPLE
STAPLE
STAPLE
STAPLE
FIRST CLASS
PERMIT NO, 824%
MINNEAPOLIS, MINN,
BUSINESS REPLY MAIL
NO POSTAGE STAMP NECESSARY IF MAILED IN U,S,A.,
POSTAGE WILL BE PAID BY
CONTROL DATA CORPORATION
Documentation Department
3145 PORTER DRIVE
PALO ALTO, CALIFORNIA 94304
E
Es
SD
E
|
|
|
E
|
TR
оО
E
FOLD
STAPLE
CONTROL DATA
ESE
CORPORATE HEADQUARTERS, 8100 34th AVE. SO., MINNEAPOLIS, MINN, 55440
SALES OFFICES AND SERVICE CENTERS IN MAJOR CITIES THROUGHOUT THE WORLD
Pub. No. 60214900 Litho in U.S.A.
">