The purpose of this part of the manual is to give details of the facilities available at ACL for users of ALGOL (ALGOL stands for ALGOL 60). A specification of the ALGOL dialect available on the 1906A is given in M.2. However, a complete description of the ALGOL language is not given. A basic knowledge of ALGOL is assumed. Although primarily designed for the ALGOL user, this part is also relevant to users of the GROATS system (Part V).
The ALGOL compiler in use at ACL is XALH. This is the ICL compiler designed to run on paged 1900 computers under the control of GEORGE 4. By default, this compiler generates programs that run in 22-bit address mode and extended branch mode (22AM,EBM) and are sparse. It will, if requested, produce programs in COMPACT mode (15AK,DBM). Unlike the FORTRAN compilers, integer variables are always one 24-bit word in length. Consequently, if a mixed FORTRAN/ALGOL program is being produced, the FORTRAN segments should be compiled in COMPRESS INTEGER AND LOGICAL mode.
In general, a 1900 ALGOL program has the structure:
program description begin ........... end;
The program starts with a number of program description statements before the initial begin of the program proper. These are described in M.6. Default program descriptions can be provided so that, for simple programs, the user need not supply one.
ALGOL programs are normally compiled by the TASK system (Part B). A simple ALGOL program stored without a program description in the file FRED could be compiled and run by:
TASK ALGOL, *CR FRED
There are two special TASK parameters peculiar to ALGOL. The first one allows the user to input programs written in a dialect using the full 128-character ASCII set rather than the standard 1900 64-character set (E.4.1). In this case, the filename is preceded by /FULLMODE/ in the TASK parameter (M.3.2.2). The second one enables the user to access the postmortem dump facility (M.7.3).
For further information, the user is referred to:
(1) ICL Manual 'ALGOL : Language1 (TP No 3340). A Student Edition of this manual is available.
(2) ICL Manual 'ALGOL : GEORGE 3 and 4 Compilers' (TP No 4302).
(3) ICL Manual 'ALGOL : Compiler Library Procedures' (TP No 4228).
In the following sections, details are given of a number of library procedures. These may all be used in a program without declaration despite indications to the contrary contained in reference (3) above.
The ALGOL compiler in use at ACL provides an almost complete implementation of ALGOL 60, as defined in Revised Report on the algorithmic language ALGOL 60. The 1900 ALGOL dialect provides all the facilities specified in the ALGOL 60 Revised Report, with the following qualifications:
Some examples for (8) are given in reference (2) of M.1.5 (Part 4, pages 5-6.2).
ALGOL programs may be input to the compiler from a GRAPHIC mode file (this corresponds to card reader input, or a file input from a MOP terminal), or from a NORMAL or ALLCHARS file, which corresponds to paper tape input (E.4.1).
For GRAPHIC mode files, the 1900 character set contains only upper case letters. For ALGOL, however, these letters are used to represent the lower case letters, so that the standard function identifiers such as sin and cos (which are in lower case) may be used. Basic symbols such as if and then cannot be represented in bold face or be underlined, so these words are distinguished by enclosing them in apostrophes. For example, begin is typed or punched as 'BEGIN' and Boolean as 'BOOLEAN'. Spaces and ends of lines (ends of cards) may appear anywhere, even between the apostrophes.
Some of the other basic symbols have no equivalent characters in the 1900 character set, so other characters or groups of characters have been chosen to represent them. Examples are ¬ which is represented by 'NOT' and the space symbol which is represented by % or '-'. A full list of these representations is given in the table below.
If ALGSOURCE is a file containing this form of ALGOL source, then it may be compiled by the TASK call:
TASK ALGOL, *CR ALGSOURCE,...
The compiler will accept input from NORMAL or ALLCHAR files in one of the following two modes.
In this mode, no lower case letters are used, and the ALGOL symbols are represented as for GRAPHIC files. The source may contain Horizontal Tab characters: the Tab stops are the following columns:
7, 13, 16, 36, 60, 73, 76.
If ALGOLSRCE is a file containing this form of ALGOL source, it may be compiled by the command:
TASK ALGOL, *TR ALGOLSRCE,. ....
With this mode of input, both upper and lower case letters may be used. For identifiers, upper and lower case letters are quite distinct, and, for example, alpha, Alpha and ALPHA will be regarded as different identifiers.
In this mode, the basic symbols may be punched or typed in upper or lower case letters, or may have the cases mixed. Thus begin may be typed as 'begin' or 'BEGIN' or 'begIn'. Standard function identifiers and input/output procedure identifiers must be punched in lower case letters, for example sin(x) and not Sin(x) or SIN(x). Apart from the symbols that involve letters, all other symbols have the same representation as in the normal mode. If ALGOLSRCEFM is a file containing full mode ALGOL sources, it may be compiled by the command:
TASK ALGOL, *TR/FULLMODE/ALGOLSRCEFM, ...
As indicated in M.1.4, /FULLMODE/ is required to indicate that the source is full mode, otherwise, the compiler will assume it to be normal mode.
The following table lists the hardware representation on 1900 series computers of the different ALGOL basic symbols.
| Algol Basic Symbols | 1900 Representation | |
|---|---|---|
| Cards and Paper Tape Normal Mode | Paper Tape Full Mode | |
| a | A | a |
| . | . | . |
| z | Z | z |
| A | None | A |
| . | . | . |
| Z | None | Z |
| 0 | 0 | 0 |
| . | . | . |
| 9 | 9 | 9 |
| begin | 'BEGIN' | 'begin' |
| Boolean | 'BOOLEAN' | 'Boolean' |
| . | . | . |
| while | 'WHILE' | 'while' |
| + | + | + |
| - | - | - |
| × | ** | |
| / | / | / |
| ÷ | '/' | '/' |
| ↑ | ↑ or '**' | ↑ or '**' |
| < | < or 'LT' | < or 'lt' |
| ≤ | 'LE' | 'le' |
| = | = or 'EQ' | = or 'eq' |
| ≥ | 'GE' | 'ge' |
| > | > or 'GT' | > or 'gt' |
| ≠ | # or 'NE' | # or 'ne' |
| ≡ | 'EQUIV' | /equiv' |
| ⊃ | 'IMPL' | 'impl' |
| ∨ | 'OR' | 'or' |
| ∧ | 'AND' | 'and' |
| ¬ | 'NOT' | 'not' |
| , | , | , |
| . | . | . |
| 10 | & or '10' | & or '10' |
| : | : | : |
| ; | ; | ; |
| := | := or ← | := or ← |
| Space | % or '-' | % or '-' |
| ( | ( | ( |
| ) | ) | ) |
| [ | [ or '<' | [ or '<' |
| ] | ] or '>' | ] or '>' |
| open quote ‘ | '(' | '(' |
| close quote ’ | ')' | ')' |
Letters between apostrophes in basic symbols in the right-hand columns may alternatively be upper case with no change of meaning.
Note: Under the MOP system the symbol ← which normally denotes the ALGOL basic symbol := , is used for deleting previously input characters. Therefore, the alternative assignment symbol := must be used in ALGOL programs input from a MOP console.
There is little point in attempting to print numbers to more than 11 significant digits, since the length of a floating point number does not provide sufficient accuracy. In some cases, the eleventh digit is also incorrect.
The following code contains examples of the use of the procedures write and format:
Input and/or output are performed via procedure calls that transfer data from or to the currently selected streams. At any point in a program, there will normally be one input stream available and one output stream. To use a different stream, it is necessary to change the currently selected stream by means of a procedure call. Each stream is referenced by a stream number, and is defined by means of an 'INPUT' or an 'OUTPUT' statement in the program description. This stream number is an integer in the range 0 to 4095: the numbers chosen need not be consecutive, and the same number may be used for both an input stream and an output stream.
A disc or magnetic tape cannot be used for both input and output in the same program unless the 1900 ALGOL backing store package is being used. If this package is used, then the descriptions of input/output procedures contained in this section are not applicable to that device, and no program description statement is required for the device. The ALGOL backing store package is described in Part R of this manual.
A brief description of the procedures available is given below: for further information, the user should consult reference (3) of M.1.5. The description of each procedure includes a declaration of that procedure.
Before an input/output stream is used, it must be selected by the appropriate procedure (see below). Only one input and one output stream may be selected at any time. If an input or output procedure is called before a stream has been selected, the appropriate stream 0 is assumed.
procedure select input(n); value n; integer n;
A call of this procedure selects input stream n. Subsequent calls of input procedures take information from stream n unless and until a further call of select input selects a different stream. Note that this procedure does not release the file or peripheral connected to the old stream, so that the old stream may subsequently be reselected.
procedure select output(n); value n; integer n;
A call of this procedure selects output stream n. Subsequent calls of output procedures put information to stream n unless and until a further call of select output selects a different stream. Note that this procedure does not release the file or peripheral connected to the old stream, so that the old stream may be reselected.
It is inefficient if a program has more files open than necessary. To avoid this situation, there are two procedures available to release the files or peripherals connected to an input/output stream. This is applicable when, for example, a program starts by reading all the data from an input stream, and then makes no further reference to this stream for the remainder of the program; the input file may be released when the reading of the data is complete.
In general, once the file or peripheral has been released from a specified stream, then that stream should not be used (or reselected) again in the program (however, the user may write a special macro to deal with the HALTED and/or FAILED conditions that may arise if he does wish to re-use the stream).
procedure free input;
A call of this procedure releases the file or peripheral connected to the currently selected input stream, and resets the currently selected input stream to stream 0.
procedure free output;
A call of this procedure releases the file or peripheral connected to the currently selected output stream, and resets the currently selected output stream to stream 0.
The following ALGOL statements will release the files connected to input stream 2 and output stream 1, and then selects input stream 3 and output stream 2:
select input(2); free input; select output(1); free output; select input(3); select output(2);
real procedure read;
This procedure initiates a search from the current position on the selected input stream for the next available number. The number that is read may be a signed or unsigned integer, fixed point number or floating point number. For floating point numbers, the ALGOL basic symbol 10 (which signifies that the field following is the exponent) may be represented by &, '10' or E.
The end of each number must be indicated by one of the following terminators:
double space comma semicolon newline horizontal tabulation character
Single spaces are ignored within a number. Multiple spaces, horizontal tabulation characters and newlines are ignored before the start of a number and between the 10 symbol and the exponent. Newline is the paper tape character FE2 (E.6); on cards, the end of a card corresponds to a newline.
If, during a call to this procedure, an illegal non-numeric character is encountered in the input stream, the program will halt:
HALTED :Xc
The character c is the non-numeric character.
This procedure will always give a real result, even when reading an integer. However, it is possible to assign the result to an integer variable, thus:
i := read;
If i is an integer variable, then the real result of read will be converted to integer form before assignment.
Boolean procedure read boolean;
This procedure initiates a search from the current position on the selected input stream for one of the basic symbols true or false. All intervening symbols are ignored. The logical values are recorded on the input medium as:
'TRUE' 'FALSE'
The result of the procedure is the truth value found.
procedure print (quantity,m,n); value quantity,m,n; real quantity; integer m,n;
This outputs to the currently selected output stream, the value of the parameter quantity, preceded by a sign and followed by two spaces, in a format specified by m and n; quantity may be real or integer.
The values of m and n determine the format as follows:
d&eThe mantissa d is written to n+1 significant digits such that l≤d<10 and the exponent e consists of two digits, with a negative sign or a space for + where appropriate. The number always occupies n+9 character positions in all. If m=0 and n=5, examples of typical output are:
-1.23456& 10 -3.45678&-12 -1.00000& 2Two spaces follow the exponent.
123.45 -234.50 12.34 -1.00Two spaces follow the number.
5555 1234Two spaces follow the number.
In each format, the total count of character positions includes the two spaces following the number and a sign character which is minus or a space. If m≠0 and the number has more than m digits in the integral part, further character positions will be used to accommodate the number. This may cause the following numbers to be displaced to the right when the results are printed.
The fractional part of a number is rounded, in the decimal form, to the appropriate number of decimal places. Non-significant zeros and positive signs are replaced by spaces, except that at least one digit always appears; the minus sign is output immediately preceding the first digit of a negative number.
If the value to be printed has overflowed, question marks will be printed in the positions that would have been occupied by the digits of the number.
procedure output (quantity); value quantity; real quantity;
This outputs numbers in a standard floating point format, with ten decimal places in the mantissa (this is the same as would be produced by a call of the procedure print with m=0, n=10), followed by a semicolon and a newline.
A series of calls of the procedure output will cause numbers to be listed in a column (one to a line) when printed; for this reason, this procedure is not recommended for lineprinter output streams (it is very wasteful of paper). If the number has overflowed, or is the result of an arithmetic operation with a value > 1076 (that is outside the range of standard floating point numbers) the output consists of ? characters filling every character position.
procedure write boolean (quantity); value quantity; Boolean quantity;
This outputs to the currently selected output stream the value of the Boolean expression quantity as 'TRUE' followed by two spaces, or 'FALSE' followed by one space.
integer procedure format (t); string t;
This procedure is used to define the output format for the procedure write (M.4.5). It assigns a bit pattern, corresponding to the string t, to an integer variable, and this variable is then used as an argument to the procedure write.
The string t may contain the following layout characters (each character in the string specifies a character position in the output field):
The following points should be noted:
&+nd &-nd &#nd
Some examples are given later.
procedure write (n,f,quantity); value n,f,quantity; integer n,f; real quantity;
This procedure will output the value of quantity to output stream n in a format specified by f where f is an integer variable, the value of which has been previously set up by a statement of the form:
f : = format (‘string’);
The stream n will be selected by this procedure: it is not necessary to use select output. The value quantity will be rounded to fit the specified format; if this is impossible, an alarm printing will occur, causing the value to be printed on a new line preceded by *, W or F, and with the following format:
#d.ddddddddddd&#nd;c
There is little point in attempting to print numbers to more than 11 significant digits, since the length of a floating point number does not provide sufficient accuracy. In some cases, the eleventh digit is also incorrect.
The following code contains examples of the use of the procedures write and fomat:
integer i,j; real a,b; a : = A.51; b : = 6.92; i : = format(‘ss+ndc’); j : = format(‘+d.d&-ndss‘ ) ; write(0,i,a) ; write(0,i,b); write(0,j,a); write(0,j,b);
This will produce the following output on stream 0:
+5 +7 +4.5& +6.9& 0
Note the effect of rounding the values before printing.
procedure space (n); value n; integer n;
This procedure outputs n space characters on the current line of the selected output stream.
procedure newline (n); value n; integer n;
This procedure outputs n newlines on the selected output stream. If this is a card punch or lineprinter stream, then n-1 blank lines will be inserted in the output. If a tape punch stream is selected, n newline characters (FE2) will be output (E.6).
procedure paperthrow;
This procedure causes a page-throw on the selected output stream if it is a lineprinter stream. For a tape punch stream, a form feed character (FE4) will be output while a new card will be started for a card punch stream.
procedure runout;
This procedure generates 6 inches of paper tape if a tape punch stream is selected. For a lineprinter stream, a page-throw is generated. A blank card is produced for a card punch stream.
integer procedure readch;
This function procedure returns as its value the ALGOL internal code of the next character on the selected input stream. The internal code is integer in the range 0 to 4095 and is unique for each character (M.11). If this procedure is called after 80 characters of a card have been read the ALGOL internal code for a newline character will be returned.
integer procedure nextch;
This procedure is similar to readch except that the position in the input stream is not advanced. The same character may be re-accessed by a further call of nextch or by a call of readch (the latter will advance the input stream).
integer procedure code (s); string s;
The result of this procedure is the ALGOL internal code of the string s which will normally be a one-character string. For example:
i := code (‘A’) ;
This will set i to the ALGOL internal code of the letter A. The following 2-character strings are allowed:
i := code (‘SS’); j := code (‘%’);This will set i to 21 and j to 16 (M.11).
procedure skipch;
The next character in the selected input stream is skipped. Once this has been done, there is no way of accessing the character. It is useful for skipping end-of-line characters.
procedure printch (i); value i; integer i;
The character with ALGOL internal code value i is output to the selected output stream.
procedure write text (t); string t;
The string t is output on the selected output streams. Since the compiler removes the spaces from the string when compiling the program source, it is necessary to use another character in order to have a space output at run time; this character is %. If the user wishes to output a percent character, the string SS enclosed in string quotes must be used (in the source program).
The string t can have special layout editing characters enclosed in additional string quotes. The possible layout characters are:
character meaning s space c newline p paperthrow q open string quote u close string quote
A layout editing character may be preceded by an unsigned integer n indicating the number of characters of that type. For example:
write text (‘‘3s’STRINGS%MUST%BE%ENCLOSED‘c’IN% THE%QUOTES%‘q’%AND%‘u’’);
This would produce the output:
STRINGS MUST BE ENCLOSED
IN THE QUOTES '(' AND ')'
An example involving only layout editing characters is:
write text (‘‘2c10s‘‘);
This is equivalent to:
newline(2) ;space(10);
procedure copy text (s); string s;
This procedure copies characters from the selected input stream to the selected output stream until the terminating string s is encountered. The string s itself is not copied and the characters making up s are lost.
procedure timenow; procedure datenow;
These procedures output the time and date on the selected output stream in the formats HH/MM/SS and DD/MM/YY respectively, where HH (hours), MM (mins), SS (secs) define the time and DD (day), MM (month), YY (year) define the date.
The mathematical procedures listed in the ALGOL report are all available. These are:
abs sign sqrt sin cos arctan ln exp entier
Several additional procedures are described in reference (3) of M.1.5.
This section details some procedures that are useful for users wishing to perform their own error trapping and/or error recovery action in their programs. This section is additional to the information given in M.7.
Boolean procedure overflow;
This will check the state of the overflow register, and if it is set, return the value true. If the overflow register is clear, this procedure will return the value false. The overflow register is always left clear after a call of this procedure.
The detection of overflow in this way does not halt the execution of the program. This method may be used in preference to the ALGOL overflow error checks. The ALGOL error checks, which produce execution errors numbered 62, 65 or 69 (effective at all trace levels) and 57, 58 or 59 (effective at trace level 1 and above), may be suppressed by setting system switch 9 to on (M.5.3). The following gives an example of the use of this procedure:
if overflow then goto lab3 else goto lab1;
This statement causes a jump to lab3 if overflow is set, or lab1 otherwise.
procedure pause (n); value n; integer n;
This procedure may be used to stop the execution of a program. A call of this procedure will produce the following HALTED message in the monitoring file:
HALTED: n
The integer n must be in the range 0≤ n≤ 99. Following this halt, program execution may be continued by use of the GEORGE command RESUME. In this case, at trace levels 2 and 3, a trace list will be produced if system switch 10 is on; the trace list will have the heading:
AT MONITOR POINT n
Alternatively, the execution of the program may be abandoned. If the program is re-entered at the error entry point (entry point 8, that is, word 28), the output buffers will be emptied, a trace listing (if any) will be produced, the peripherals released and the program will then halt:
HALTED: EE
The GROATS macro uses the error entry point following any program halt caused by a call of the procedure pause.
The TASK macro will neither RESUME the program, nor re-enter it at entry point 8. Users of TASK who wish to employ this procedure should therefore either exit from TASK by means of a NORUN parameter and write a special macro to run their binary programs, or use the procedure freeall (described below) to avoid losing the contents of the program output buffers.
To avoid confusion with GROATS error halts, the argument to pause should be in the range 20≤n≤99 in a GROATS program.
procedure errortrap (p); procedure p;
The procedure p has one integer argument that is called by name. A call to errortrap indicates to the ALGOL run-time trace package that the procedure p is to be entered when an ALGOL execution error occurs. The integer parameter to p will contain the error number. The procedure p may go to a non-local label and continue with the object program, having optionally executed a private error action, or it may obey the normal exit from the procedure, in which case the error number (the parameter of the procedure) may, but need not, be changed: the program will then perform an error halt with this error number. The procedure errortrap may be called any number of times to change the trap procedure. Under no circumstances should it be called in a GROATS program, since GROATS has its own error procedure.
procedure readtrap (p); procedure p;
This procedure is used to trap errors on input such as reading invalid characters when inputting numeric data. The procedure p has one integer argument called by name. A call to readtrap will cause the procedure p to be entered when an error occurs in the procedure read. On entry to p, the integer argument will be set to the ALGOL internal code from the invalid character. The procedure p may jump to a non-local label and continue with the execution of the program; in this case, the next character in the input stream will be the character after the invalid character. Alternatively, p may exit back to the procedure which found the error (read), and the integer parameter may be changed to the ALGOL internal code of a character that is to replace the invalid one. If the argument is unchanged on exit, the invalid character will be replaced by zero. If another invalid character is returned, control is passed back immediately to the trap procedure.
If the trap procedure p ultimately exits back to the procedure read, no other characters should have been read since entry to p, otherwise execution error 1 will be reported.
The procedure readtrap may be called any number of times to change the trap procedure name.
procedure freeall;
Users who trap error conditions in their programs, or who use the procedures errortrap or readtrap, may wish to close down their programs. The procedure freeall will output a trace list (if any), empty all output buffers and release all files and peripherals attached to the program's input/output streams. This procedure may be used in conjunction with the procedure pause, as the following procedure demonstrates:
procedure error(number); integer number; begin select output(0) ; paperthrow; write text (‘execerror’);space(3); print(number,3,0) ; freeall; pause(99); end;
A call to this procedure with parameter value 27 will cause a trace list to be printed (on a new page), preceded by the heading:
EXECUTION ERROR 27
The program will then halt:
HALTED: 99
The procedure freeall should under no circumstances be used in a GROATS program.
Each bit of word 30 of an ALGOL program is known as a system switch. There are 24 switches in all, and these are called switch 0, switch 1,..., switch 23. A switch is said to be on when the corresponding bit is set to 1 and off when the bit is set to zero. For example, switch 9 is on if bit 9 of word 30 is set to 1. At the start of an object program run, all switches will be off, but switch n can be set on by the GEORGE command:
ON n
Switches 1 to 8 (1 to 6 in a GROATS program) are available for the user's own purposes; switch 0 and switches 9 to 23 are reserved for the use of standard library procedures and should only be used to obtain the effects listed below.
Switches 9 to 23 are used during program testing (M.7) and have the following interpretations:
procedure on (n); value n; integer n;
procedure off (n); value n; integer n;
Boolean procedure test (n); value n; integer n;
In each case, n is an integer in the range 0≤n≤23 and specifies the switch required. The procedures on and off set the specified switch to on and off respectively. The result of the procedure test is true if the specified switch is on and false otherwise.
As mentioned in M.1.3, it is frequently necessary to precede an ALGOL program by a program description. The following is a list of the available program description statements: specifications of these statements are given later. The program description statements should be supplied in the order in which they are listed below:
(1) Preceding the Program
'LIST', 'SHORTLIST' or 'NOLIST'
'TAB'
'WARNOFF'
'SEND TO'
next five in any order
'PMD'
'DUMP ON'
'RUN'
'SEMICOMPILED'
'LIBRARY'
'PROGRAM' or 'SEGMENTS'
Input/Output stream definition statements
('INPUT', ' OUTPUT', 'CREATE', ' OMITIO')
'SPACE'
'FAULTRUN'
'CONTINUE'
In addition, a branch and/or data mode statement may appear anywhere before the CONTINUE statement.
(2) Between Segments
The following statements are all optional; between segments includes between the program description statements listed above and the first ALGOL statement of the program:
'LIST', 'SHORTLIST', 'NOLIST' 'TRACE' 'OPTIMISE' or 'OPTIMIZE'
If it is required to consolidate the program immediately after the compilation, the PROGRAM statement should be used: this has the format:
'PROGRAM' (name)
The parameter name is at least 4 and not more than 12 alphanumeric characters starting with a letter: the first four characters of name must not be SIGN. This name has no significance for programs run under GEORGE.
If automatic consolidation is not required, the SEGMENTS statement should be used instead of PROGRAM; this has the format:
'SEGMENTS' (name)
The parameter name is as for PROGRAM. The name specified has no significance except that if any of the segments compiled is a master segment (that is, it begins with begin rather than procedure or type procedure) then this master segment will be given the first four characters of 'name' as its segment name.
If neither of these two statements is present, the compiler assumes the statement:
'PROGRAM' (AXXX)
Those users wishing to compile and consolidate their programs in the same call to TASK or GROATS may normally omit the PROGRAM statement.
The compiler will produce a listing of the source program, together with any compilation error messages and some other information. There are. two levels of listing available, namely the full listing and the intermediate listing, in addition to no listing. Provided the statement 'LIST' (NONE) is not used, it is possible to change the listing level between segments: the listing level will retain its current value until altered. The default listing level is full listing.
The first line of a full listing contains the name of the compiler, and the time and date of the compilation. The source program is then printed with the layout in which it was input, except that TAB characters are expanded to the appropriate number of spaces. Lower case letters are printed as upper case, overprinted with apostrophes.
Two columns of numbers are given at the left of the listing; the right hand column gives the ALGOL statement number that is current at the beginning of the line: this is the number used in error messages. The left hand column gives the line number in the source file; these numbers may be used when editing the file with the GEORGE EDITOR (Part G), since the numbers printed are those used by the EDITOR. The following is an example of a full listing:
11/08/34 31/05/74 COMPILED BY XALH MK. 1C LINE STATEMENT 0 0 'BEGIN' 1 1 'REAL' A,B; 2 1 A := ABS(+1); B := A+SQRT(4); 3 4 PRINT(A,1,0); 4 5 SPACE(2); 5 6 PRINT(B,3,0); 6 7 NEWLINE(2); PRINT(SIN(1.0472),1,4); 7 9 NEWLINE(2); 8 10 PRINT(ENTIER(+4.8),2,4) ; 9 11 'END'; SEGMENT AXXX LENGTH 74 NO OF BUCKETS USED 7 COMPILED #AXXX EC
The first line of an intermediate listing is the same as for a full listing. The statement numbers that would be printed at the left hand side of a full listing are then printed in rows: the numbers are separated by commas. Each number refers to one line of a source program, blank lines and comments included. The following example intermediate listing is for the same program as in the example above, but the statement 'SHORTLIST' (LP) has been inserted before the initial begin:
12/43/22 31/05/74 COMPILED BY XALH MK. 1C
STATEMENT
0, 0, 1, 1, 4, 5, 6, 7, 9, 10, 11,
SEGMENT AXXX LENGTH 74
NO OF BUCKETS USED 7
COMPILED #AXXX EC
'LIST'(LP)
This statement results in a full listing being produced. This is the default listing level for the compilation.
'LIST'(LP,m)
This form of the LIST statement may be used to alter the number of lines in the listing between page throws to m. This form may only be used as an initial statement (that is, it must not be used as an intersegment statement). This feature may be of use to remote users with paper size different to that in use at ACL.
'LIST'(NONE)
This results in no listing at all being produced. If this is used, the listing level cannot be altered by means of intersegment statements. If no listing is required initially, but one will be needed for later segments, the NOLIST statement should be used.
'SHORTLIST' (LP)
This results in an intermediate listing being produced, there is a form:
'SHORTLIST' (LP,m)
This may be used only as an initial statement.
'NOLIST' (LP)
This is used if the following segment(s) are not to be listed, but a listing is required elsewhere in the compilation. As for LIST and SHORTLIST, there is a form:
'NOLIST' (LP,m)
This again may be used only as an initial statement.
The ALGOL compiler in use at ACL will, by default, produce a sparse object program that runs in 22-bit address mode and extended branch mode. It is possible to produce programs that run in other address and branch modes by the user of the COMPACT, COMPACT PROGRAM and EXTENDED statements. These have, respectively, the formats:
'COMPACT' 'COMPACT PROGRAM' 'EXTENDED'
COMPACT will result in a dense object program running in 15-bit address mode and direct branch mode.
COMPACT PROGRAM will produce a dense object program running in 22-bit address mode and direct branch mode.
EXTENDED will produce a sparse object program running in 22-bit address mode and extended branch mode. This is the default setting and, therefore it is not normally required.
No other branch and/or data mode statements are acceptable to the GEORGE 4 ALGOL compiler, even though they are acceptable to other ICL ALGOL compilers.
It is possible for the following segments to be included in an ALGOL program:
To achieve this, it is necessary to instruct the consolidator to search other disc files, in addition to the semicompiled file produced by the compiler and the ALGOL library. The LIBRARY and SEMICOMPILED statements are provided for this purpose. The formats of these statements are:
'LIBRARY' (ED, file.subfile) 'SEMICOMPILED' (ED, file.subfile)
The parameter file is the name of the disc file concerned, and the parameter subfile is the name of the subfile (in this disc file) that is to be searched. Since a SEMI or LIB parameter is required for the TASK or GROATS macro for each file mentioned in a LIBRARY or SEMICOMPILED statement, and the file specified in the SEMI parameter overrides that given in these statements, the name file may be a dummy filename. However, the subfile name is significant (unless the LINK facility is used) and must be correct. Subfiles have the following names:
The subfile name (and the preceding full stop) may be omitted, in which case the subfile name will be assumed to be SUBROUTINES.
If a disc subfile is specified in a SEMICOMPILED statement, then all the segments in the subfile will be included in the object program. If a LIBRARY statement is used, then the disc subfile will be searched selectively, and only those procedures actually referenced will be incorporated into the object program.
If for any reason it is necessary to search a library twice, then two LIBRARY statements must appear for that file, and there must also be two SEMI macro parameters for the file.
The LIBRARY and SEMICOMPILED statements must be in the same order as the corresponding SEMI macro parameters (this order is the order in which the disc subfiles will be searched).
Object program input/output is performed via procedure calls that make use of input/output streams. It is necessary, in the program description, to associate input/output channels with these streams by means of INPUT and OUTPUT statements. Each input/output channel will normally be connected to a GEORGE filestore file or to a magnetic tape or disc exofile. These channels have a type (for example, LP for lineprinter) and a unit number associated with it. This specifies the number of the channel of that type. There can only be one channel of a particular type with that unit number. If no INPUT, OUTPUT, CREATE or OMITIO statements are present, the default input/output streams available are:
'INPUT' 0,1 = TR0 'INPUT' 2 = TR1 'INPUT* 3 = CR0 'OUTPUT' 0,2 = LP0 'OUTPUT1 1 = TP0 'OUTPUT1 3 = CP0 'OUTPUT' 4 = TP1 'OUTPUT1 5 = LP1
The defaults are different for a GROATS program. Full details are given in the ACL GROATS manual.
Input streams are defined by:
'INPUT' n = XXm
The first parameter, n, is a list of one or more integers (in the range 0 to 4095) separated by commas and in ascending numerical order. These are the stream numbers to be associated with the channel. The 2-letter code XX (CR for card reader and TR for tape reader) specifies the channel type while m is the unit number for the channel. This must be an integer in the range 0 to 15. Some examples are:
'INPUT' 5,15,21 = CR0 'INPUT' 6 = TR0
Output streams are defined by:
'OUTPUT' n = XXm
The parameters are similar to those for the INPUT statement except that the possible channel types XX are LP for lineprinter, CP for card punch and TP for tape punch.
For lineprinter channels, it is possible to specify the number of lines between page throws by:
'OUTPUT' n = LPm,p
The final parameter p defines the number of lines per page. These automatic page throws can be suppressed by setting switch 23 on. This can either be done by an ALGOL library procedure ( M.5.3.3) or by a parameter in the TASK command. The default number of lines per page is 49. It is only likely that users at remote sites would want to change this standard.
Input/output is performed either to a simple file or a subfile in a file on the magnetic tape. If the file structure on the tape has not been set up, the CREATE statement is required in the program description and no input from the tape is allowed in that run. The form of the statement is:
'CREATE' n = MTm(filename)/length 'CREATE' n = MTm(filename.subname)/length
The parameters n and m are similar to the ones in the INPUT statement. The parameters filename and subname define the file and subfile names respectively. These consist of up to 12 alphanumeric, space or hyphen characters starting with a letter. The parameter length gives the maximum block size in words that is to be written to the tape. This parameter is optional in which case a block size of 128 words is assumed.
A CREATE statement will define a file whose name is filename on a pool tape which must be on-lined before program execution starts. The file will be a simple file in the first case or a composite file containing a single subfile with name subname in the second case. Further subfiles can be added using the OUTPUT statement. If a CREATE statement is used, an OUTPUT statement is not required.
Once a file structure has been set up using the CREATE statement, subsequent runs can use INPUT and OUTPUT statements to access and write information on the magnetic tape. These commands have the formats:
'INPUT' n = MTm(filename)/length 'INPUT' n = MTm(filename.subname)/length 'OUTPUT' n = MTm(filename)/length 'OUTPUT' n = MTm(filename.subname)/length
The parameters are the same as for CREATE. For OUTPUT statements, if a simple file is specified, the contents will be overwritten. For composite files, the subfile specified will be overwritten (this will overwrite the following subfiles as well). If the subfile specified does not exist, it will be created at the end of the file.
Input/output on tapes and discs is similar. Simple and composite files are used (set up initially by the CREATE statement). However, there is no OUTPUT statement for simple files. The CREATE statement is used instead. If input and output is required on a disc channel in the same run then the ALGOL backing store package must be used.
TO set up a composite file structure in a disc file (or to overwrite ai existing one), the CREATE statement is used. It is also used to output to a simple disc file. This command has the format:
'CREATE' n = EDm(filename) 'CREATE' n = EDm(filename.subname1.subname2......subnameq)/length
The parameters are similar to those defined above. The set of subfilenames defines the subfile structure to be created in the composite file. For a simple file, input/output will start in the first bucket. For a composite file, the subfiles preceding subnameq will be created as directory subfiles while subnameq is created as a data subfile. As for magnetic tapes, an OUTPUT statement is not required for a stream defined in a CREATE statement.
Disc files already having the required file structure can be reference by INPUT and OUTPUT statements. These have the formats:
'INPUT' n = EDm(filename) 'INPUT' n = EDm(filename.subname1.subname2...subnameq)/length 'OUTPUT' n = EDm(filename.subname1.subname2...subnameq)/length
For input, the subfiles preceding subnameq must be directory subfiles. If the last subfile, subnameq, is a directory subfile, all the data subfiles contained in this subfile will be read in the order in which they appear in the directory. For output, subnameq must be a data subfile and all the preceding subfiles must be directory subfiles. New subfiles are created in the file commencing with the first subfile which is found to be missing.
This statement has the format:
'OMITIO'
It prevents the compiler supplying the normal input/output facilities. Its main use is in programs which do not use the standard input/output routines. For example, it is possible to do all input/output by the ALGOL backing store package.
Input/output stream definition statements may appear in any order but each channel should be mentioned only once. For example, the following statements are not valid:
'OUTPUT' 1 = LP0 'OUTPUT' 3 = LP0
The channel LP0 is mentioned twice. However, it could be written:
'OUTPUT'1, 3 = LP0
The total stream definition statements must be less than 19 and, in some cases, the number allowed is less than this. It is usual for the first OUTPUT statement to refer to a lineprinter channel as all trace output (M.7.2) will go to this channel.
If the ALGOL source to be compiled consists of more than one segment, a CONTINUE statement must appear in the program description. The last ALGOL statement must be followed by a FINISH statement. Full details are given in M.8.1.
The formats and use of these statements is given in M.7.
'DUMP ON' (ED)
This statement is required if the object program is to be produced in a disc file rather than in core. A BIN parameter is required in the TASK call. The same effect can be obtained by using the SAVE parameter in the TASK call and removing the DUMP ON statement and BIN parameter.
This statement is not required at ACL. It is required if the program has been saved by a DUMP ON statement and it is also required to run the program. However, the TASK system will automatically load the binary program into core and run it even if the consolidation was to a disc file. A NORUN parameter is required in the TASK call if execution is not required.
This statement is used to specify the disc file to receive the semicompiled output. At ACL, this disc file is defined by a COMP parameter of the TASK call (a workfile is used by default). However, the statement can be used to suppress the semicompiled output by including:
'SEND TO' (NONE)
The parameter NOCONS must be supplied in the TASK call if this form of the SEND TO statement is used.
'FAULTRUN'
This statement allows an object program to be produced even though it may contain semantic errors (M.7.1).
In paper tape formatted source programs, the TAB character (FE1) may be used to indicate layout. The default tab settings are character positions 7, 13 and 16. Uniform tab settings which are n characters apart may be specified by:
'TAB' n
The parameter n must be in the range 1 to 63.
The ALGOL compiler issues warnings about certain constructions in the source program that may indicate an error (M.9.6). They may be suppressed by one of the statements:
'WARNOFF' ALL 'WARNOFF' n1,n2,n3,....
The first suppresses all warnings while the second suppresses only those whose numbers are specified.
By default, an ALGOL object program has a stack which is 3K words in length. It will be extended automatically during program execution if a larger stack is required. A different initial stack size may be defined by:
'SPACE' n
The parameter n defines the size of the stack in words. It is rounded up to the next multiple of 1024.
The initial compilation of a source program frequently produces compilation errors. These errors are either syntactic or semantic. Syntax errors are detected as the ALGOL statements are read and checked. An error message is output immediately following the source line in error. It has the form:
STATEMENT n SYNTAX ERROR m
The first parameter gives the line number of the statement in error while the second parameter indicates the error number. A complete list is given in M.9.1.
If no syntactic errors are found, a second phase of the compilation takes place during which semicompiled output is produced. Semantic errors are recognised at this stage. A list of these is generated at the end of the listing for the segment. There are two possible forms:
STATEMENT n ERROR NUMBER m STATEMENT n ERROR NUMBER m CONCERNING identifier
The error numbers are listed in M.9.2. No more semicompiled output is produced once a semantic error is found. The compilation is abandoned completely once 40 semantic errors are found. In certain cases, compilation errors confuse the compiler and either spurious error messages are produced or compilation is abandoned with the message:
IMPOS. HAPPENED
If this happens, the user should correct those errors that appear to be valid and recompile the program.
If no errors have been discovered in the compilation, the listing ends with:
COMPILED #name EC
If errors have been found, the EC is replaced by ZZ. In both cases, the parameter name is the one given in the PROGRAM statement.
In general, it is not possible to consolidate a program if compilation errors have been found. However, it is still possible to generate a loadable object program if only certain types of semantic error have been discovered. This will be done if the program description includes the statement:
'FAULTRUN'
In this case, semantic errors 70-191, 200-207, 218 and 221 are reported as faults rather than errors. No attempt is made to correct these errors. Consequently, the object program may run but produce incorrect results.
If the fault occurs in a declaration or specification, the identifier(s) concerned are generally left undefined, so that subsequent use will either produce a further error or cause a declaration at a higher block level to be used, leading to incorrect results.
If the fault occurs in an executable statement, then all or part of the statement will be replaced by a jump to a run-time error routine, producing execution error number 66, indicating that a semantic fault has been reached and the program cannot continue.
The use of this facility automatically invokes trace level 2 (M.7.2.4).
When a program has compiled successfully and an object program produced, it must be tested. At the end of this test run, if the program has run without execution errors, it will halt with the message:
HALTED: AH
If the program fails, it will normally halt with the message:
HALTED: EE
This error halt is caused by the detection of errors by run-time checks; the number of checks is, to a considerable extent, under user control, through the use of the TRACE program description statement. Higher trace levels cause more execution errors to be trapped, but produce larger, slower running, object programs. The higher trace levels would normally be used only during the development stage of a program.
All execution errors cause the following message to be output:
EXECUTION ERROR m
The parameter m is the error number. These numbers and their explanations are listed in M.10. At trace levels 2 and 3 (see below), a trace listing is also produced. The error message and trace listing are output on the stream defined by the first OUTPUT statement in the program description. If no output streams exist, the error message number appears in the job's monitoring file as a display (D.5.6). In these circumstances, trace levels 2 and 3 should not be used. A lineprinter output stream should be included if trace output is required.
'TRACE' n
The parameter n may be 0, 1, 2 or 3 and specifies the tracing level to be used. The default is trace level 0. The tracing level remains set at its current value until it is altered by a further TRACE statement.
This statement is used as an intersegment statement, as specified in M.6.1.
No extra code is included at this trace level, and no trace list is produced on detection of an execution error. The errors detected at this level are as follows:
Error numbers Cause 10-29 Arithmetical errors 1,30-39,70-79 Input/output errors 40-49 Magnetic tape backing store package errors 50-53 Errors peculiar to 1900 ALGOL 62,65,69 Overflow errors 66,68 FAULTRUN errors 80-99 Errors in disc input/output and backing store package routines.
At this trace level, code is incorporated to trap 6 further errors. These are:
Error numbers Cause 57,58,59 Overflow errors 60,61,67 Array subscript errors
So trace list is produced at trace level 1.
At trace level 2, all errors trapped at level 1 are detected, together with error number 63. In addition, a trace list will be produced. This lists the last 60 monitor points passed in the program execution. A monitor point is one of the following:
Each monitor point appears in the trace listing in one of the following ways:
If the same monitor point is repeated or if identical monitor points are adjacent, this is indicated by only two lines on the list. The first is the normal representation of the monitor point, and the second line is:
EXECUTED n times
The parameter n is the number of consecutive occurrences of the monitor point.
At trace level 2, a list is output automatically when the program is abandoned by the detection of an error. A trace list may also be output when the program is halted by use of the procedure pause (M.5.2) or when the procedure mplist is called (M.7.2.6).
If the program fails or halts in some obscure manner without producing a trace list, a trace list may be obtained by re-entering the program at entry point 8. Note that the GROATS macro deals with all failures other than HALTED: EE and HALTED: PM in this manner.
This tracing level provides all the facilities of trace level 2, together with the facility to dump variables at different points in the program, according to instructions supplied in trace steering requests.
This information can be obtained automatically in the case of program failure by using the post mortem dump facility described in M.7.3.
The output of trace level 3 is affected by the settings of system switches 14 and 15 (M.5.3). Further information on trace level 3 can be found in reference (2) of M.1.5 (pages 41-44).
A number of procedures which are of use in detecting and handling program errors are described in M.5.2. In addition, there are two procedures to access the trace facilities at trace levels 2 and 3 (they have no effect at trace levels 0 and 1).
procedure mpname (s); string s;
A call to this procedure has the effect of putting the first 5 characters of the string s in the trace list. If this string is unique, it will identify a point in the program.
procedure mplst (n,m); value n,m; integer n,m;
The parameter m is in the range 0 to 99 and n is 1, 2 or 3. A call to this procedure has the effect that, if system switch 10+n is on, a trace listing will be produced, headed by the line:
AT MONITOR POINT m
This is a facility whereby, when an execution error occurs, a post mortem analysis of the state of the program (including a printing of the values of the variables) is produced. This facility involves no overhead on object program run time and core usage, except that one extra library routine is included in the program to perform the post mortem analysis. This routine will not be entered in the case of a successful run.
When a program using this facility is compiled, the compilation listing will contain extra lines which number the blocks of the ALGOL program. These block numbers are referred to in the output from the post mortem analysis routine. This is shown in the example below.
This facility is in general available only if the program concerned is compiled, consolidated and run in the same call to the TASK or GROATS macro. To use the facility, a PMD macro parameter and a 'PMD' program description statement are required. The program description statement has the form:
'PMD' (EDn, filename)
The parameter filename may be any valid dummy filename (a GEORGE workfile is used by the macros). The parameter n is the number of buckets of disc file that are to be reserved for the consolidator to use to store information for the post mortem analysis routine. If n is omitted, the default value of 30 will be assumed, and this should be sufficient for most programs. However, programs using a large number of segments (and particularly mixed language programs), and all GROATS programs require a larger value of n (for GROATS, n should be about 50). If the post mortem dump facility is used and no execution error occurs, the program will halt:
HALTED: AH
No post mortem analysis will be produced. However, if an execution error does occur, the program will not perform the normal error halt:
HALTED: EE
Instead, it will halt:
HALTED: PM
The TASK and GROATS macros deal with this situation, and will resume execution of the program so that a post mortem dump is produced. At the end of the post mortem analysis, the program will delete:
DELETED: DF
If any other halts or deletes occur when using the post mortem dump facility, the user should consult the Program Advisory Office at ACL.
Users wishing to write their own macros to run programs using the post mortem facility should consult reference (2) of M.1.5.
The following example shows the listing of a program which is to use the post mortem dump analysis facility:
11/23/37 01/11/71 COMPILED BY XALH MK. 1C
LINE STATEMENT
0 0 'PMD' (ED.PND TESTFILE)
1 0 'PROGRAM' (PMTEST3)
2 0 'CONTINUE'
11/23/37 01/11/71 COMPILED BY XALH MK. 1C
LINE STATEMENT
3 0 'BEGIN* 'REAL' XO.X1; 'INTEGER' I; 'ARRAY' A[l:4];
BLOCK 1
4 3 'REAL' 'PROCEDURE' F(X); 'VALUE' X; 'REAL' X;
BLOCK 2
5 7 F:=SQRT(X)*EXP(X);
6 7 'REAL' 'PROCEDURE' SUM(L,U,I,T);
BLOCK 3
7 9 'VALUE'L.U; 'INTEGER'L,U,I; 'REAL'T; 'ALGOL1';
7 12 'FOR' I:=1 'STEP' 1 'UNTIL' 4 'DO'
9 14 'BEGIN' 'REAL' K; 'INTEGER' J;
BLOCK 4
10 15 X0:=3-I; X1:=3+I;
11 18 K:=A[1]:=SUM(X0,X1,J,F(J));
12 19 NEWLINE(l); PRINT(I,2,0); PRINT(K,0,4);
13 22 'END'
14 22 'END';
SEGMENT PMTEST3 LENGTH 188
NO OF BUCKETS USED 9
11/23/39 01/11/71 COMPILED BY XALH MK. 1C
LINE STATEMENT
15 0 'REAL' 'PROCEDURE' SUM(L,U,I,T); 'VALUE'L.U;
BLOCK 5
16 3 'INTEGER' L,U,I; 'REAL' T;
17 5 'BEGIN' 'REAL' X;
18 5 X:=0;
19 7 'FOR' I:=L 'STEP' 1 'UNTIL' 0 'DO'
20 8 X:=X+T;
21 9 SUM:=X;
22 9 'END';
SEGMENT SUM LENGTH 49
NO OF BUCKETS USED 12
11/23/40 01/11/71 COMPILED BY XALH MK. 1C
LINE STATEMENT
23 0 'FINISH'
COMPILED #PMTEST3
COMPILED BY XALH MK. EC
The program will go wrong during the fourth call of SUM at Statement 18 with J=-1. The output from the program takes the following form:
1 1.5444& 2 2 4.8902& 2 3 1.4772& 3 ERROR TYPE 11
Output from post mortem dump analysis takes the form:
01/11/71 P.M. DUMP ANALYSIS (#XAPM MK. 3A)
ERROR OCCURRED IN PROCEDURE SQRT
SQRT CALLED FROM MASTER SEGMENT, BLOCK 2 , STATEMENT 7
DUMP OF BLOCK 2 ( PROCEDURE F );
X -1.0000000& 0
F CALLED FROM SEGMENT SUM, BLOCK 5 , STATEMENT 8
IN EVALUATION OF ACTUAL PARAMETER
IN FOR STATEMENT, CONTROLLED VARIABLE I
DUMP OF BLOCK 5 ( PROCEDURE SUM ):
L -1
U 7
X 0.0000000& 0
SUM CALLED FROM MASTER SEGMENT, BLOCK 4 , STATEMENT 18
IN FOR STATEMENT
DUMP OF BLOCK 4 :
K 1.4772101& 3
J -1
DUMP OF BLOCK 1 :
X1 7.0000000& 0
X0 -1.0000000& 0
I 4
ARRAY A
1 := 1.5443517& 2 4.8901537& 2 1.4772101& 3 UNDEFINED
END OF P.M. DUMP ANALYSIS
This section lists the commonly-occurring HALTED messages that may appear in a job's monitoring file when running an ALGOL object program. These messages are all of the form:
HALTED: xx
The possible two-character strings xx are:
AH the object program has run successfully.
EE an execution error has occurred.
CR | an input/output channel has been specified as being of the type
CR | given by xx, but has no GEORGE file attached to it.
LP | This is normally caused by the absence of (or an error in)
TP | a parameter to the GROATS or TASK macro.
TR |
CP |
ST | the ALGOL stack is not large enough. The program should be
RL | recompiled with a larger stack specified in a SPACE statement.
| This could also possibly be caused by a large program trying
| to extend to a size greater than that permitted by the current
| MAXSIZE value.
QQ an attempt has been made to branch to a missing segment.
The program should be recompiled and/or reconsolidated, and rerun,
ensuring that the missing segment is included or not accessed.
Xc c is any (non-space) character. This is caused by reading the
illegal character c in the input procedure read (M.4.4).
n n is an integer in the range 0 to 99;
this is caused by a call to the procedure pause.
When using the PMD facility (M.7.3), there are two other messages:
HALTED: PM DELETED: DF
The ALGOL compiler provides some facilities for optimising object programs. These should only be used in error-free programs compiled at trace level 0. These facilities are invoked by use of the OPTIMISE program description statement which has one of the formats:
'OPTIMISE' n 'OPTIMIZE' n
The parameter n (1 or 3) specifies the optimisation level to be used (n=2 is not available with the GEORGE 4 ALGOL compiler). The OPTIMISE statement only applies to the segment immediately following it.
This has the effect of reducing the time taken for object programs to complete any step-until list element of any for statement within the segment. This is achieved by calculating each step arithmetic expression and each until arithmetic expression once only at the start of the statement. This optimisation can be used if and only if within the segment for all list elements of this type:
This has the effect of reducing the time taken to access certain types of array elements referenced within some for statements. Use of optimisation level 3 automatically invokes level 1 optimisation. The compiler performs checks to ensure that the following conditions hold:
All three of these conditions have to be satisfied for the optimisation at level 3 to be performed. Optimisation at level 3 can only be used if the following restrictions are observed:
The scalar variables (that is, not arrays) declared in the outer-most block of the master segment are located in a lower common area called ALGOL60. Access to these variables is as fast as possible throughout the program. All other variables are located on the stack, and always take longer to access (also, the access time can depend on the depth of block nesting). Thus a programmer may well be able to speed up a program by placing the declarations of the commonly accessed simple variables into the outer-most block of the master segment wherever possible (it is not possible, for example, to put the declarations of the local variables of a recursive procedure into an outer block). This facility is independent of the optimisation level in use, and applies whether or not an OPTIMISE statement appears.
There is available for use a program which reads in a program written in 1900 ALGOL (from cards or paper tape) and punches it out on cards, tidying up the program's appearance. The layout of the output obeys the following rules:
This program is written in ALGOL and is fairly slow - it requires about 12 seconds of jobtime per 1000 lines of ALGOL source. If the ALGOL program is not correct (it contains syntactic or semantic errors), the ALGOLTIDY program may fail (probably with an execution error).
The form of the macro is:
ALGOLTIDY inputpr, outputpr, EJ
The first parameter inputpr defines the source program to be tidied. This parameter has one of the following forms:
*CR *CR filename *TR *TR filename
If the form *CR or *TR is used, then the macro will assume that the input is included with the job source, otherwise the specified file will be used. The second parameter outputpr defines the tidied output. It has one of the forms:
*CP *CP filename
If the form *CP filename is used, the output will be sent to the specified file (this must either not exist or have the write trap set). If the form *CP is used, or the parameter is omitted, a workfile is used, and if the program run is successful, the source file will be overwritten with the output (the macro will set the trap to write to the file).
Instead of exiting, the third parameter, if present, causes the macro to perform the command:
ENDJOB ALLBUT,COMMANDS
The following displays may be put into the monitoring file by the macro:
ALGOLTIDY SUCCESSFUL
This indicates that the program run was successful.
SOURCE FILE OVERWRITTEN WITH OUTPUT
This indicates that the source file was overwritten as required.
ERROR IN MACRO ALGOLTIDY: ABANDONED
This indicates that the program run was unsuccessful or the macro failed.
SOURCE FILE NOT OVERWRITTEN
If the source should have been overwritten, this indicates an error in the program.
The output file is listed on the lineprinter if the program fails.
In the normal simple case, a 1900 ALGOL program consists of the following:
program description begin ....... (Algol statements including internal procedures) end;
This program consists of only one monolithic segment, which is a master segment (since it starts with begin). The user may wish to split up this segment and compile some parts separately (perhaps some segments will be held as a semicompiled library). This involves compiling a number of successive segments.
Large program segments cause the ALGOL compiler to use large amounts of core store and, in extreme cases, to fail. This can be overcome by splitting the large segment into smaller components, and compiling these as separate segments. When a program is segmented, there must be only one master segment. The other segments must all start with one of the following ALGOL statements:
procedure name (parameter list); type procedure name (parameter list);
where type is one of integer, real and Boolean. Consider the following example:
begin
integer a,b,c,d;
real e;
procedure sample(i,j,k);
value i,k;
integer i,j;real k;
begin
j:=i+k;
end;
e: = 1.5;
a:=1;
b:=2;
sample(a,c,e);
sample(b,d,e);
end;
The procedure sample may be compiled as a separate segment. To do this, it is necessary to declare the procedure in the master segment as being an algol procedure, and then put the procedure as a separate segment following the master segment. The procedure declaration required in the master segment (or, indeed, in any other procedure that is to access the procedure sample and is not nested inside a block in which sample is declared) consists of the procedure heading, containing the name, the formal parameter list and the specification part, followed by the statement:
algol;
For example:
procedure sample(i,j,k); value i,k; integer i,j; real k; algol;
The compiler will need to know that it has to compile more than one segment. This is accomplished by using the program description statement CONTINUE together with FINISH (M.6.7). The example will then become:
'CONTINUE' begin integer a,b,c,d; procedure sample(i,j,k); value i,k; integer i,j; real k; algol; e:=1.5; a: = 1; b:=2; sample(a,c,e); sample(b,d,e); end; procedure sample(i,j,k); value i,k; integer i,j; real k; begin j:=i+k; end; 'FINISH*
The CONTINUE and FINISH statements are required if and only if the compiler is to compile more than one segment in the run. If the procedure sample was compiled separately (and, for example, included in the object program by means of a SEMICOMPILED statement), there would only be one segment to compile, and the CONTINUE and FINISH statements would be unnecessary.
In the example given above, in the first version (before segmentation), the variables a,b,c and d were global to the procedure sample and were accessible from within sample. However, after segmentation, these variables are no longer global to sample and can only be accessed in this procedure if they are passed across as parameters. In general, all variables that are global in a non-segmented program are not accessible (except as procedure parameters) to the separate segments in a segmented program.
It is possible to incorporate segments written in PLASYD, FORTRAN or PLAN in an ALGOL program. The techniques required for PLASYD are described in the PLASYD Manual published by ACL. The techniques for PLAN are similar to those required for PLASYD, In all cases, the non-ALGOL segments should be compiled by the appropriate compiler and then incorporated into the object program by using SEMICOMPILED and LIBRARY statements.
As for ALGOL segments incorporated in an ALGOL program, FORTRAN segments need to be declared in all the ALGOL segments that access these FORTRAN segments. The declarations consist of the appropriate equivalent ALGOL procedure headings, each followed by the statement external. The following example gives the declaration required for a simple FORTRAN segment:
INTEGER FUNCTION IADD(I,J,K)
IADD = I+J+K
RETURN
END
integer procedure IADD(I,J,K); value I,J,K; integer I,J,K; external;
Some ALGOL parameter types have no corresponding type in FORTRAN. The correspondence for the available parameter types is as follows:
ALGOL FORTRAN real REAL integer INTEGER Boolean LOGICAL array REAL (array) integer array COMPRESS INTEGER (array) Boolean array COMPRESS LOGICAL (array) (external) procedure External
Only the parameter types shown in this table may be used in FORTRAN segments incorporated in ALGOL programs. DOUBLE PRECISION and COMPLEX types do not exist in ALGOL. Also, ALGOL procedures may not be used as parameters of a FORTRAN procedure. If a parameter is used on the left-hand side of an assignment statement in the FORTRAN segment, or is of type procedure, the parameter must be declared (in the ALGOL declaration) as being called by name. Other parameters may be called by value only.
Integer variables and elements of integer arrays in 1900 ALGOL are always stored in one 1900 word. Therefore, the FORTRAN should be compiled in COMPRESS INTEGER AND LOGICAL mode.
None of the ALGOL variables may be accessed in the FORTRAN segments via a COMMON block, except for simple variables (that is, not arrays) declared in the outer-most block of a master segment, which are stored in the lower global area ALGOL60 in the order in which they are declared. This global area may be accessed via a FORTRAN COMMON statement of the form:
COMMON/ALGOL60/.....
The FORTRAN segments must not attempt to put arrays in this global area. All other ALGOL variables may only be accessed in the FORTRAN segments as arguments to procedure calls.
When consolidating FORTRAN segments into an ALGOL program, the FORTRAN compiler library will have to be searched as well as the ALGOL library and any other libraries required by the user.
Errors in the syntax of a program are detected when the source program is being read. Semantic errors are only detected if no syntactic errors are found. Syntactic and semantic errors are described in M.7. There are also some errors associated with trace level 3 that are detected during compilation; if a trace error is detected, an error message is output on the listing device but a loadable program could still be produced, and, if there were no other errors, the listing would not end with ZZ.
This section gives the error numbers and messages associated with compilation and trace errors.
These errors cause an error message to be output either immediately after the line containing the error or after output of an intervening line. The message takes the form:
STATEMENT x SYNTAX ERROR n
This indicates that the statement on line x has error number n.
| Error number |
Reason |
|---|---|
| 301 | This number is associated with two errors: (1) An operator other than 'BEGIN', 'REAL', 'INTEGER', 'BOOLEAN' or 'PROCEDURE' has been used to start a segment. This situation often arises through an error in a program description statement.(2) At the start of a procedure segment, 'INTEGER', 'REAL', or 'BOOLEAN' is not followed by 'PROCEDURE'. |
| 302 | The statement starts with an improper symbol. |
| 303 | 'FOR' is not followed by an identifier. |
| 304 | An identifier is followed by an improper bracket. |
| 305 | A colon is not followed by an equals sign in the 'FOR' statement. |
| 306 | An improper designational expression is used where a label is expected. |
| 307 | A specificator has been used as declarator. |
| 308 | 'OWN' is followed by 'PROCEDURE' or by 'REAL', 'INTEGER' or 'BOOLEAN* followed by 'PROCEDURE'. |
| 309 | 'PROCEDURE' is not followed by an identifier. |
| 310 | A procedure declaration contains an identifier that is not followed by a left-hand parenthesis or by a semicolon. |
| 311 | A formal parameter of a procedure should be an identifier. |
| 312 | A formal parameter of a procedure is not followed by a comma or by a right-hand parenthesis. |
| 313 | The formal parameter of a procedure declaration is not followed by a semicolon. |
| 314 | The parameter delimiter of a list of formal parameters consists of a letter string and colon that is not followed by a left-hand parenthesis. |
| 315 | A specifier is not followed by an identifier. |
| 316 | The specification part of a procedure declaration is not followed by a semicolon. |
| 317 | A type declaration contains an identifier that is not followed by a comma or by a semicolon. |
| 318 | In a type declaration, a comma is not followed by an identifier. |
| 319 | 'ARRAY' is not followed by an identifier. |
| 320 | An array declaration contains an identifier that is not followed by a left-hand bracket or by a comma. |
| 321 | 'SWITCH' is not followed by an identifier. |
| 322 | A switch declaration contains an identifier that is not followed by ← or := . |
| 323 | In a switch declaration, a colon is not followed by an equals sign. |
| 324 | An expression starts with an improper operator. |
| 325 | An expression has been used in an incorrect position, for example, on the left-hand side of an assignment statement. |
| 326 | The statement contains an improper right delimiter. |
| 327 | A right-hand parenthesis is not matched by a left-hand parenthesis. |
| 328 | A right-hand bracket is not matched by a left-hand bracket. |
| 329 | An improper operator has been used. |
| 330 | An improper operator has been used. |
| 331 | An expression has been used in an incorrect position (see 325), |
| 332 | An improper operator has been used. |
| 333 | 'THEN' is not matched by 'IF'. |
| 334 | 'ELSE' is not matched by 'THEN'. |
| 335 | A 'FOR' statement is incorrect. |
| 336 | An improper operator has been used. |
| 337 | An improper operator has been used. |
| 338 | The structure of the program is incorrect. |
| 339 | In a procedure call, an actual parameter is followed by an improper separator. |
| 340 | An improper operator has been used. |
| 341 | An improper operator has been used. |
| 342 | In a program description statement, a left-hand parenthesis is not followed by an identifier. |
| 343 | In a program description statement, a right-hand parenthesis has been omitted. |
| 344 | A non-numeric channel number has been given in a program description statement. |
| 346 | In a program description statement, the number of print positions on a lineprinter has been specified as something other than a number. |
| 347 | In a SEND TO or READ FROM statement, a generation number has been specified as something other than a number. |
| 348 | In a SEND TO or READ FROM statement, a generation number is not followed by a right-hand parenthesis. |
| 349 | A parenthesis has been used in a SPACE or PRIORITY statement. |
| 350 | There is an error in a peripheral description statement. The specified peripheral is not of an acceptable type. |
| 352 | The format of a number is incorrect. |
| 354 | A left-hand parenthesis has been omitted from a program description statement. |
| 355 | A procedure call or a subscripted variable has been used as a label. |
| 356 | An expression of an incorrect type has been used as an array subscript. |
| 360 | An array declaration contains an improper statement. |
| 363 | In a SPACE, TRACE, or PRIORITY statement, the name is not followed by a number. |
| 364 | An OMIT statement has an incorrect format. |
| 365 | No subfile has been specified in this READ FROM statement. |
| 367 | The number specified in the SPACE statement is too large (>262143). |
These errors cause an error message to be output to the listing device at the end of the segment. The message takes the form:
STATEMENT x ERROR y
This indicates that the statement on line x has error number y. The error numbers marked with an asterisk (*) will have an identifier associated with the error message.
When the FAULTRUN facility is used, the following messages may be output:
STATEMENT m FAULT NUMBER n STATEMENT m FAULT NUMBER n CONCERNING identifier
The errors which may produce these messages are:
70 to 191, 200 to 207, 218 221
| Error number |
Reason |
|---|---|
| 1 | The program is too large for the compiler to cope with. This corresponds to the message HALTED LF. |
| 31 | The disc file specified in a SEND TO statement which inserts a subfile into an already existing composite structure is not composite. |
| 32 | The compiler has been unable to obtain space on the disc either to extend the work or output file or to open a scratch file for work space. The reason for this failure is given in a display message as described at the end of this appendix. |
| 33 | A SEND TO statement specifies that an existing subfile structure is to be used. The statement has been ignored and no semicompiled output will be produced. |
| 70 | An impossible type matching has been attempted in an arithmetic expression (this error is detected only for the operators +-*/). |
| * 78 | Too few parameters have been supplied to a procedure. |
| * 79 | A parameter presented to a procedure has not been specified or has been incompatibly specified (for example 'STRING* has been presented where 'REAL' has been specified). |
| 80 | An expression has brackets that are too deeply nested for the present compiler to cope with. |
| * 81 | A formal parameter of a procedure has been specified as being called by value but the parameter is of a type (for example, switch identifier) for which calling by value is meaningless. |
| * 82 | A label has been defined more than once at the same block level. |
| * 83 | An identifier that appears in a switch list has been declared as something other than a label. |
| * 84 | An identifier in an arithmetic or Boolean expression has never been declared. |
| * 85 | This parameter has not been specified. |
| * 86 | A switch identifier is not followed by a comma or by a left-hand bracket. |
| * 87 | This identifier is an undefined label. |
| * 88 | A label has been used outside a designational expression. |
| * 89 | A simple variable is followed by a left-hand bracket. |
| * 90 | A simple variable is followed by a left-hand parenthesis. |
| * 91 | A procedure identifier is not followed by a proper operator. |
| * 92 | An array identifier is not followed by a proper operator. |
| * 98 | An identifier has been declared more than once at the same block level. |
| 99 | A value specification contains something other than identifiers and commas. |
| 100 | 'IF' is not followed by a Boolean expression. |
| 101 | 'LABEL' has been used as a declarator. |
| 102 | An attempt has been made to use 'OWN' as a specifier. |
| 103 | 'OWN' is not followed by a declarator. |
| 104 | An attempt has been made to-use 'VALUE' as a declarator. |
| 105 | 'PROCEDURE' is not followed by an identifier. |
| 106 | A list of formal parameters is not followed by a semicolon. |
| 107 | 'OWN' is followed by an incorrect specifier or declarator. |
| 108 | Something other than an identifier has been used as an identifier in a type declaration. |
| 109 | An improper declarator follows a type declarator, for example, 'REAL' 'OWN'. |
| 110 | An attempt has been made to use 'STRING' as a declarator. |
| 111 | In an array declaration, an identifier is followed by an operator that is not a comma or a left-hand bracket. |
| 114 | An operator other than a comma or a semicolon has been used in a specification. |
| 116 | 'ARRAY' is not followed by an identifier. |
| *151 | The identifier indicated did not appear in the list of formal parameters in a procedure declaration but did appear in the specification part. |
| 163 | In an array declaration, either an upper or lower bound is missing. |
| *191 | An attempt has been made to assign a value to an untyped procedure identifier or to a typed procedure identifier outside the procedure body. |
| 192 | An untyped procedure has been used in an expression. |
| 199 | An attempt has been made to compile a program or data area greater than 32K words. |
| 200 | A statement of the form A<operator>B; is incorrect. A is an expression, operator is an arithmetic, Boolean or relational operator and B is an identifier or constant. |
| 201 | In an arithmetic or assignment statement, incompatible types have been matched. |
| 202 | Previous errors have caused this message to be output at a right-hand bracket. |
| 203 | A comma has been used in a switch designator. |
| 204 | An operand of the integer division operator or of a Boolean operator was not of type integer of Boolean. |
| 205 | In a conditional expression, incompatible types have been matched. |
| 206 | Something other than an identifier has been used as a label. |
| 207 | A subscripted variable has the wrong number of subscripts (for a non-parameter array). |
| 218 | A previous error has confused the compiler. This is most likely to happen when an error occurs inside a conditional statement, or within a 'FOR' statement. |
| 219 | An error occurred before a listing device was made available, |
| 220 | 'FINISH* has been read before the end of a segment. |
| 221 | A syntactic error has occurred between the end of the last source segment and 'FINISH'. |
| 222 | There are too many peripheral description lines for the compiler to handle. |
| 230 | Trace level 3 has been requested but blocks are nested to a depth greater than 64. The compilation has been abandoned. |
Consolidator generated error messages are self-explanatory. Further details are under the specification of XPCK in TP4241.
| Error number |
Reason |
|---|---|
| 401 | The format of a request is unacceptable. |
| 402 | A request is not terminated by a comma or by a semicolon. |
| 403 | More than 100 requests have been made for one segment. |
| 404 | A request has specified a block number greater than 511. |
| *ILLEGAL SYMBOL | A non-ALGOL symbol has been found between two apostrophes. Common causes of this error are the mis-spelling of a basic symbol and the omission of one of the apostrophes. |
| ILLEGAL CHARACTER | A non-ALGOL character has occurred. |
| IMPOS. HAPPENED | Some previous error has confused the compiler. |
| CHECKSUM ERROR | A checksum error has occurred in a semicompiled segment. The run should be repeated after the regeneration of the semicompiled segment. |
These messages include opening a scratch file as work space as this operation is similar to file extension.
FILE CANNOT EXTEND
When this error occurs compilation ceases and a DISPLAY message is also output. This has the following format:
DISPLAY Xn
where:
X=S indicates failure to extend the semicompiled output file
X=W indicates failure to extend the workfile
X=P indicates failure to extend the post mortem dump file
and
n=0 indicates that the system control area is full
n=1 indicates that no space is available on cartridge
n=3 indicates that insufficient core store is available for holding further file descriptions or that an attempt has been made to open more than the maximum number of files
n=5 indicates that the file was not opened for writing.
These messages indicate either the presence of a non-disastrous error or of a possible error. The format of these messages is:
WARNING NUMBER n
| Warning Number |
Reason |
|---|---|
| 1 | A reserved word has appeared between 'END' and the next semicolon, 'END' or 'ELSE'. |
| 2 | A character which is neither a letter nor a digit has appeared in the sequence field of a card. |
| 5 | A READ FROM statement has been read. The parameters have been ignored and **** has been substituted. |
| 11 | An identifier has more than 39 characters. It has been truncated. |
| 12 | An integer constant is too large to hold. It has been floated. |
| 13 | A floating point constant is too small to hold (<2-256). It has been set to zero. |
| 31 | A disc file specified in a READ FROM statement is not composite. |
| 32 | The compiler has been unable to extend the post mortem dump file. The post mortem facility has been switched off and compilation continued. |
| 34 | A SEND TO or DUMP ON statement specifies that a file is to be renamed. The request to rename has been ignored. |
| 35 | A SEND TO or DUMP ON statement has an incorrect format. The invalid part of the statement has been ignored. |
| Error number |
Type of Error |
|---|---|
| 01 | A procedure, defined as a trap procedure by readtrap, has returned control to read or readarray after it has read some data. |
| 10 | An attempt has been made to evaluate zero to a negative power. |
| 11 | sqrt has been called with a negative parameter. |
| 12 | In has been called with a negative or zero parameter. |
| 13 | A call of the exp function has caused overflow.. |
| 14 | Overflow during calculation of x↑y |
| 30 | An attempt has been made to read past the end of data (Batch Monitor only). |
| 31 | Input data exhausted (**** has been read). |
| 33 | Overflow has occurred in an input procedure that was reading numerical data. |
| 34 | No input or output channel has been selected. |
| 35 | A magnetic tape mark has been encountered. |
| 36 | An attempt has been made to read a magnetic tape block that is larger than the size specified in the peripheral description statement associated with this input channel. |
| 37 | The required subfile cannot be found on the input tape. |
| 38 | A record to be output to magnetic tape cannot be stored in a block of length specified in the peripheral description statement associated with this output channel. |
| 40 | An attempt has been made to define a ninth channel number in the magnetic tape backing store package. |
| 41 | The record specified in a read binary statement cannot be found in the file associated with the specified input channel number. |
| 42 | A procedure call of the form input (c,s) has been made, where s is a null string. As work tapes must always be available for writing, this call is not allowed. |
| 43 | A checksum failure has occurred in the data block of a record. This error will be caused by a damaged tape or by a deck failure. |
| 44 | A channel number that has not been associated with a peripheral has been used in the magnetic tape backing store package. |
| 45 | An attempt has been made to use a total of more than 16 tapes in the whole program, ie by means of both the backing store package and the input/output system. |
| 46 | An attempt has been made to call reform with equal parameters. |
| 47 | An attempt has been made to output to a file specified as an input file in the magnetic tape backing store package. |
| 48 | An attempt has been made to write past the physical end of the reel marker. |
| 49 | The procedure reset cannot recognize the data on the tape which it has been given. |
| 50 | The lower bound of an array has been declared to be larger than the upper bound. |
| 51 | A mixed language program has run out of core store. Recompile with a larger store allocation in the SPACE statement. This error occurs only in ALGOL segments incorporated into programs written in other languages. |
| 52 | A program with 'OWN' arrays has run out of space. |
| 53 | An array of more than 218 words has been declared. |
| 57 | Overflow has been detected after division. |
| 58 | Overflow has been detected after multiplication. |
| 59 | Overflow has been detected at entry to a user procedure. |
| 60 | An array subscript is too small. |
| 61 | An array subscript is too large. |
| 62 | Overflow has been detected at entry to a SRA4 library routine. |
| 63 | An actual parameter of a procedure is a constant and an attempt has been made, in the procedure body, to assign a value to this parameter. |
| 64 | No output device is available for monitoring information. |
| 65 | Overflow has been detected at the conclusion of an otherwise successful run. |
| 66 | A program with semantic faults has reached an error and cannot continue. |
| 67 | An array subscript expression is too large for the array element to be accessed correctly. |
| 68 | A program with semantic faults has terminated. |
| 69 | Overflow has been detected at entry to a parametric procedure. |
| 70 | An incorrect number of dimensions has been specified for a read array or write array procedure. |
| 71 | A column or row checksum has been misplaced in the data supplied to read array. |
| 72 | A grand checksum is not followed by £ in the data supplied to read array. |
| 73 | There is an error in a checksum in the data supplied to read array. |
| 74 | S,G or Z is not followed by a semicolon in the data supplied to read array. |
| 75 | An improper symbol has been presented to the procedure inbasic. |
| 76 | An improper symbol has been presented to the procedure outbasic |
| 77 | fullcode has been called with an impermissible string. |
| 78 | An attempt has been made to access a scratch tape that has not been reopened by restore. |
| 79 | The specified terminating string for a call of instrarr or copytext is not acceptable. |
| 80 | An element specified in a disc backing store procedure would be outside the range of the file.. |
| 81 | The integrity code check has failed. |
| 82 | The purge date of the file specified for output has not yet passed. |
| 83 | A logical bucket number is out of range. |
| 84 | The system control area is full. |
| 85 | There is no space available on a disc for the extension of a file or for a scratch file. |
| 86 | A file does not have one-block buckets. |
| 87 | An attempt has been made to write to a file opened by instore. |
| 88 | An undeclared channel number has been used in the direct access backing store package. |
| 89 | More than eight channels have been used in the direct access backing store package. |
| 90 | The parameters of an opening procedure in the direct'access backing store package are in an incorrect format. |
| 91 | The elements specified in a getpart, getparti, putpart or putparti procedure are not within the bounds or are incorrectly related. |
| 92 | A channel number defined in the direct access backing store package is not in the range 1 to 15. |
| 93 | There is insufficient space available on a disc for a scratch file or for the extension of a file. |
| 94 | A channel number has been declared twice in the direct access backing store package. |
| 95 | The specified EDS unit number is already in use. |
| 96 | With the INPUT statement, a subfile description mentioned in the statement is missing; with the OUTPUT statement, one of the following conditions has occurred: (1) no subfile mentioned in the statement (2) the file specified does not have a subfile structure (3) a subfile, other than the last subfile in the statement is not a directory subfile (4) the last subfile in the statement is not a data subfile. |
| 97 | A record of zero length has been read from a direct access file. |
| 98 | An attempt has been made to access a scratch disc file that has not been reopened by restore. |
This table lists the ALGOL internal code values of the 1900 character set. The procedures readch and code produce these values as results.
| 1900 character |
Algol Internal Code |
1900 character |
Algol Internal Code |
1900 character |
Algol Internal Code |
|---|---|---|---|---|---|
| 0 | 0 | @ | 3936 | ||
| 1 | 1 | A | 3873 | a | 3937 |
| 2 | 2 | B | 3874 | b | 3938 |
| 3 | 3 | C | 3875 | c | 3939 |
| 4 | 4 | D | 3876 | d | 3940 |
| 5 | 5 | E | 3877 | e | 3941 |
| 6 | 6 | F | 3878 | f | 3942 |
| 7 | 7 | G | 3879 | g | 3943 |
| 8 | 8 | H | 3880 | h | 3944 |
| 9 | 9 | I | 3881 | i | 3945 |
| : | 10 | J | 3882 | j | 3946 |
| ; | 11 | K | 3883 | k | 3947 |
| < | 12 | L | 3884 | l | 3948 |
| = | 13 | M | 3885 | m | 3949 |
| > | 14 | N | 3886 | n | 3950 |
| ? | 15 | O | 3887 | o | 3951 |
| Space | 16 | P | 3888 | p | 3952 |
| ! | 17 | Q | 3889 | q | 3953 |
| " | 18 | R | 3890 | r | 3954 |
| # | 19 | S | 3891 | s | 3955 |
| £ | 20 | T | 3892 | t | 3956 |
| % | 21 | U | 3893 | u | 3957 |
| & | 22 | V | 3894 | v | 3958 |
| ' | 23 | W | 3895 | w | 3959 |
| ( | 24 | X | 3896 | x | 3960 |
| ) | 25 | Y | 3897 | y | 3961 |
| * | 26 | Z | 3898 | z | 3962 |
| + | 27 | [ | 3963 | Carriage Return | 3997 |
| , | 28 | $ | 4020 | Line Feed | 3994 |
| - | 29 | ] | 4021 | End-Of-Line | 3994 |
| . | 30 | ↑ | 4022 | ||
| / | 31 | ← | 4023 |