Contact us Heritage collections Image license terms
HOME ACL Associates Technology Literature Applications Society Software revisited
Further reading □ OverviewAssessingSystem OverviewPreprocessor DialectsExecution SpeedsAlgol Paper No 11Man or Boy?Algol LibraryAlgol Bulletin 1
ACD C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACLApplicationsAlgol :: Algol System
ACLApplicationsAlgol :: Algol System
ACL ACD C&A INF CCD CISD Archives
Further reading

Overview
Assessing
System Overview
Preprocessor Dialects
Execution Speeds
Algol Paper No 11
Man or Boy?
Algol Library
Algol Bulletin 1

The Listing, Editing and Library Facilities of the Atlas Algol Compiler

F R A Hopgood and A G Bell

August 1966

1. INTRODUCTION

This paper describes the Listing, Library and Editing facilities recently added to the Atlas Algol Compiler via the Processor written at the Atlas Laboratory. It is hoped that these facilities will soon be available at London and Manchester. Knowledge of the previous Atlas Algol Paper is assumed.

2. LISTING

The listing facilities provided serve three main purposes:

  1. To define the unique layout of the program required for line editing.
  2. To provide a tool for cleaning up the layout of existing programs.
  3. To convert programs from one external form to another.

The editing facilities provided with the compiler correct particular lines of the Algol program. The original line layout of the program submitted could be the definition of lines for editing purposes or alternatively a unique layout dependent on inserting newlines on the occurrence of particular Algol symbols. The second alternative was chosen partly because of the rather poor layout of most Algol programs (especially during the debugging stage) and also no layout information needs to be stored with library items.

The LINEPRINTER listing provided by the extended form of the Processor Command is intended primarily to define this unique layout (A formal definition of the options available with the extended form of the Processor Command is defined in Appendix 1). However indenting is provided to produce a readable printout with matching begin's and end's aligned.

The simplest form of the Processor Command is:

INPUT <INPUT TYPE> WITH <PERM TYPE> I/O PROCEDURES. 
LIST ON LINEPRINTER;

This would produce a complete listing of the program as it is being compiled on output stream 0. Before each line is output the line number and the appearance of begin causes an indenting of two extra spaces to occur before all following lines until the matching end is encountered. Because of the limited character set of the lineprinter it has been necessary to change the printed form of some of the Algol symbols (see Appendix 3 for complete definition of output characters). These could in some cases have been formed by overprinting but this would reduce the speed of the lineprinter by a factor of 2.

For programs on ICT 7-hole tape, <INPUT TYPE> = ICT 7-HOLE TAPE will cause the original output routine of the compiler to be used in reading the program. This is more efficient than the processor but less flexible (comparison of times is given in Appendix 2). In particular the facilities described in this paper are part of the processor and can only be accessed via the processor. To translate ICT 7-hole tape programs via the processor requires <INPUT TYPE> = INTERNAL ICT. Therefore to list an ICT 7-hole tape program would require the command:

INPUT INTERNAL ICT WITH ICT I/O PROCEDURES. 
LIST ON LINEPRINTER;

If the listing is required on a separate output stream then the Processor Command can be extended to:

LIST ON LINEPRINTER STREAM 1; 

if the listing is required on output stream 1.

To control the amount of print out produced it is possible to modify the command by for example:

LIST ON LINEPRINTER LINES 10 TO 500;
 or  
LIST ON LINEPRINTER STREAM 1 EVERY 4TH LINE;

The other two forms of output available, ICT 7-HOLE TAPE and ELLIOTT CARDS are provided for program clean up and conversion from one dialect to another. Punching equipment is available at the Laboratory for modifying programs punched on ICT 7-hole tape or cards so these listings provide a means of converting programs to a form where they can be altered away from the machine.

The ICT 7-hole tape produced should, without alteration, be re-accepted by the Compiler. The layout of the program is similar to the Lineprinter layout. Runout is provided at regular intervals so that positions on the tape can be easily found for correction purposes. The runout positions coincide with the positions on the Lineprinter listing where extra newlines have been inserted.

The Elliott Cards output is in the dialect defined originally in Algol Paper No. 10. Reserved words are enclosed between primes and are treated as though the prime was a case shift character. This allows the Upper Case Alphabet to be defined on cards as well as the standard Lower Case. However, it does mean that Upper Case identifiers equal to the Algol symbols will have to be changed. For example a paper tape program containing an identifier BEGIN would have this translated as the Algol symbol begin when output on cards.

The columns 73 to 80 of the card are taken as a Comment Field and if desired the cards may be serialised in Columns 77 to 80 by the directive:

LIST ON ELLIOTT CARDS. 
NUMBER CARDS;

This will cause serialisation starting at 0001 to be punched on the cards. If a listing line has to be split between two cards then both are given the same serial number. This will ensure that the line numbers given on the lineprinter listing coincide with the Card Serialisation. It may be that serialisation is required starting at some other number. In this case the command would be:

LIST ON ELLIOTT CARDS.
NUMBER CARDS WITH FIRST CARD 35;

With the short field width of 72 columns, the indenting provided can become embarrassing and in this case suppression of indenting can be invoked by the command:

LIST ON ELLIOTT CARDS STREAM 1, DO NOT INDENT. 
NUMBER CARDS;

Although the Processor Command defines the form that the output will take, the final destination is in fact controlled by the Supervisor via the Job Description. Therefore if card output is required on stream 1 then this output must be defined as cards in the Job Description. Alternatively the Job Description could direct the output to a different output device. For example

LIST ON ELLIOTT CARDS;

with output stream 0 as Lineprinter will cause the Elliott Cards listing to be produced on the lineprinter. Although in general this is less elegant than the lineprinter listing, it does have the advantage of differentiating between upper and lower case alphabetic characters.

In the above section particular facilities have been described in conjunction with the output form with which they are most likely to be used. These facilities can be used with any output form in fact. For example, indenting could be suppressed on an ICT 7-hole tape or the Lineprinter listing could be serialised down the right-hand side as well as the left (see Appendix 1 for definitions of <LINES > , <INDENT> , <STREAM> and <SERIAL > ) .

The interim facility of defining a listing by a Parameter Setting of *00000001 will still work at the moment and is now equivalent to the Command:

LIST ON LINEPRINTER;

There is no guarantee that this facility will remain for any length of time.

3. EDITING

The editing facilities depend on the unique line numbering produced by the lineprinter output listing and, once a program has been listed, all editing messages inserted at the front of the program should refer to the original listing. For example, a program may be run and a listing produced (call this listing A). Editing instructions may be added at the front of the program and a second run done. Suppose this produces a listing B of the corrected program. If now additional editing instructions are added at the front of the program these should refer to the line numbers in listing A not listing B. (See Section 5 for a more sophisticated method where the latest listing is always used).

At present it is only possible to punch editing messages in the same dialect as the program is punched and these should be inserted immediately after the Processor Command if possible. If the dialect has a title or comment before the initial begin then the editing messages should appear after the first begin. In fact editing messages can be inserted anywhere in the program before the lines that are being edited as long as the insertion of the editing messages do not alter the line-layout of the program, i.e. they should only be inserted after a complete line of Algol text (e.g. following a ; would be reasonable). However it is good practice to group editing messages at the front.

Users may think that the ability to edit only in the dialect of the program is a severe restriction. However Section 5 describes a method of defining a complete program as a Library Item and, in this case, editing may be done in any dialect. It is hoped that eventually this restriction may be relaxed and switching between dialects will be allowed. This requires parts of the Processor to be rewritten to make them re-entrant.

An editing message defined in terms of the extended Backus Normal Form described in Appendix 1 is as follows:

<editing message>  ::= corrections <edit line *> finish 
<edit line>        ::= <delete line> | <replace line> | <after line>
<delete line>      ::= delete <N>
<replace line>     ::= replace <N > by <Algol text>
<after line>       ::= after <N> insert <Algol text>
<Algol text>       ::= Any string of Algol symbols (including library reserved words). 
                       This may be several listing lines if required.
<N >               ::= positive integer.

The underlined words such as delete are punched in a similar form to the way begin would be punched in that dialect. Any number of <editing message> may be inserted.

The meanings of the different types of edit line is as follows:

  1. delete i: The line numbered i is deleted from the program.
  2. replace i by <Algol text>: The line numbered i is removed and replaced by the string of <Algol text>.

    In both forms if a listing is being produced on the lineprinter then the deleted line will appear on the lineprinter listing preceded by ********. This serves as a check that the correct line has been deleted. If the listing is being produced on cards or tape then the deleted line is not printed. Inserting the line here would cause the program to be unacceptable as a copy of the new revised program.

  3. after i insert <Algol text>: After the line numbered i and before i+1 is inserted the string of <Algol text>

There is no limit on the number of lines that may be corrected and there is no restriction on the order of the editing lines. In particular it is not necessary to punch the editing lines with the line numbers in order.

There is however one important restriction. Only one edit line may refer to any particular line number.

Diagnostics produced by the system are as follows:

LINE TO BE CORRECTED WAS BEFORE CORRECTION
This will occur if editing messages are inserted in the program after the line numbers to which they refer. The correction is ignored.
ERROR, CORRECTION REFERS TO SAME LINE TWICE
Two editing lines have been presented referring to the same line number. The second is ignored.

All editing messages are listed on the stream defined for the normal listing. An error will occur if no listing has been defined. If editing is being done and no listing is required then a minimal listing should be specified. For example:

LIST ON LINEPRINTER LINES 1 TO 1;

An example of the use of the editing messages is as follows:

Suppose a program has been run producing the listing:

0001 BEGIN
0002   REAL Aπ
0003   INTEGER Bπ
0004   A := Bπ
0005 END

Then inserting the editing message:

 corrections
 replace 4 by if C then A := D;
 after 2 insert Boolean C ;
 integer D; C := true;
 delete 3
 finish
         

would produce a program listed as:

0001 BEGIN
0002   REAL A π
0003   BOOLEAN C π
0004   INTEGER D π
0005   C := TRUE π
0006   IF C THEN    A  := D π
0007 END

This would be preceded by the editing messages themselves and, in fact, the two deleted lines would be output preceded by asterisks after line 5 in the new listing.

4. LIBRARY FACILITIES

Directives have been added to the system to allow users to read down segments of Algol text into a program and also to define segments of Algol text as library items. The facilities serve two main purposes. The first gives users the ability to insert Standard Library Items into their programs; the second allows the whole or part of an Algol program in partially compiled form to be stored on magnetic tape and to be used in place of the original copy of the program for subsequent runs.

Standard Library Tape

The Standard Library Tape has title ALGOLIB and, if library items are required in a program, then the tape definition

TAPE 99 ALGOLIB*INHIBIT

must be inserted in the Job Description. The INHIBIT is added to ensure that the tape is file protected against accidental writing.

The procedures available on the Standard Library Tape will be extended until a comprehensive library is available. At present the Algorithms defined in the Communications of the A.C.M. Algorithm Section have been loaded on the library tape together with a set of Atlas dependent code procedures (mainly provided by I.C.T. Limited). The I.C.T. procedures should be fully debugged. On the other hand the A.C.M. algorithms have been punched and any errors noted in Certifications inserted. Trial compilations have been done to give a syntactic check of the Algorithms but no semantic checks have been attempted. Any Certification of Algorithms used would be greatly appreciated by the Atlas Laboratory. A full definition of the I.C.T. Algorithms available will be published shortly in an Atlas Paper.

To insert for example A.C.M. Algorithm 35 into a program would require the directive:

 library ACM 35;

to be inserted in the program at the required place. If a listing of the program is asked for then this line will appear on the listing. If, instead of the library line above, the whole library item is required to be listed then the directive should be:

 library ACM 35/L;

This will be necessary for example if editing of the library item is required.

It is possible that the assumed library tape number of 99 may be required for some other purpose. In this case a different tape number can be defined as follows:

Suppose tape number 3 is preferred then the Job description would contain
TAPE 3 ALGOLIB*INHIBIT

and the library directive would be:

 library ACM 35/3;

(if a listing is required ACM 35/3/L or ACM 35/L/3 is allowed)

As far as the library class names are concerned there is only one alphabet and Upper and Lower Case characters can be mixed. For example library acM 35/lj is allowed.

If several library items are to be added at the same place a multiple directive could be used as follows:

 library ACM 35, ICT 27/L, ACM 12;

There is a problem with KDF9 programs where the library directive has been used to insert the standard input/output procedures. On Atlas these are precompiled and automatically inserted into the program by the Processor Command. Therefore library directive involving the items A0 to A15 in KDF9 programs will be ignored.

Private Library Tape

The facilities described above may be used to read down Algol text from private library tapes. As long as there is no difference in form from the Standard Library Tape, the directive given above can be used with a Tape other than ALGOLIB defined in the Job Description. A Library Tape has the first two blocks as a Directory defining the Class Names, Number in each Class and positions of library items on-the tape. To set up the Directory Blocks initially, a procedure (library item ICT 12 on the Standard Library Tape) set up directory is available. This procedure will set up classes on the Tape 1 defined in the Job Description. For example:

JOB
I0000 HOPGOOD SET UP DIRECTORY
COMPUTING 30 SECONDS
OUTPUT 0 LINEPRINTER 200 LINES
TAPE 1 N0009 XYZ*PERMIT
TAPE 99 ALGOLIB*PERMIT
COMPILER ALGOL
INPUT INTERNAL ICT WITH ICT I/O PROCEDURES;
 begin
 library ICT 12;
 set up directory ({ACM,50,XYZ,20,ABD,30});
 end
***Z

The {} brackets were defined on tape as ( BS -

will set up a directory on N0009 XYZ so that library items ACM0 to ACM50, XYZ0 to XYZ20 and ABD0 to ABD30 can be defined on this tape. If N Class Names are defined and the length of the ith Class Name is L(i) and the number of items allowed in the ith class is M(i) then the sum of (L(i) + M(i) +2) from i=1 to N must be less than 2044.

If only a few Class Names are defined then this means that around 2000 names of library items can be defined in the directory.

Definition of Library Items

Once the Directory Blocks have been initialised by the use of set up directory, library items can be loaded onto the tape. This is done by enclosing the piece of Algol text to be defined as a library item by the two directives commence and define. The commence directive which is similar in format to the library directive defines the start of the library item and it is concluded when the directive define is reached. These directives may be inserted anywhere in a normal Algol program. Apart from defining library items as they appear, the program will be executed as though the directives did not appear. For example:

 begin
 commence XYZ9/3; 
 real a; 
 define
 a := 0; 
 end
         

would cause the library item XYZ9 on tape 3 to be defined as:

 real a;

As with the library directive if a tape number is not specified the tape number 99 is assumed. A subsequent run of the program:

 begin
 library XYZ9/3;
a := 0;
 end
         

is equivalent to the original program.

The definition of a library item may include library directives as part of the Algol text. In this case the library directives are replaced by the Algol text of the library item and this is then defined as the new library item. Using the library item XYZ9 defined above we could have for example:

 begin
 commence XYZ22/3;
 real b;
 library XYZ9/3;
 define
a := b;
 end
         

This would cause XYZ22 to be defined as:

 real b; real a; 

and not

 real b; library XYZ9/3;

The second alternative would have been more compact on the library tape but would require the library calling mechanism to be entered recursively. It is also less efficient as far as computing time is concerned.

If a listing is required the complete listing of the Algol text of the library item XYZ9 would be given even though /L did not appear in the library directive. This is to emphasise the fact that the Algol text rather than the library directive is being defined as the new library item.

One important restriction is that the definition of library items may not be nested.

Possible diagnostics are as follows:

TAPE NOT DEFINED
Usually caused by Tape not being defined in the Job Description. Can be caused by incorrectly written library or commence directives or alternatively a define being encountered without a matching commence directive before it.
LIBRARY CLASS NAME ILLEGAL
The class name given in a library or commence directive is not defined in the relevant Library Tape Directory.
LIBRARY LINE TOO LONG
The library directive is too long. This will occur when several items are being brought down with a single library directive. It can be cured by breaking the library directive into two or more directives.
LIBRARY ITEM REQUIRED NOT ON TAPE
An attempt has been made to read down a library item which has not been defined.

5. STORAGE OF COMPLETE PROGRAMS ON MAGNETIC TAPE

A complete program can be defined as a library item by punching the commence line before the initial begin of a program and define following the final end. However, if the program is already punched, this may well be inconvenient; especially if no punching equipment is available at the Laboratory for the particular dialect concerned. For this reason an option in the Processor Command <COMMENCE >(See Appendix 1) allows a complete program to be defined as a library item. It is exactly equivalent to inserting the similar commence line before the first  begin and define after the final end. For example:

INPUT KDF9 8-HOLE TAPE WITH KDF9 I/O PROCEDURES.
LIST ON LINEPRINTER.
COMPLETE PROGRAM IS DEFINED AS LIBRARY ITEM XYZ10/5;

followed by a KDF9 program would store the program as library item XYZ10 on tape 5. Subsequently the program can be run by calling the library item down from tape using either the same or a different dialect. For example a short card program could be used:

JOB I0000 HOPGOOD PROGRAM FROM TAPE
OUTPUT 0 LINEPRINTER 1000 LINES
COMPUTING 30 SECONDS
TAPE 7 N0000LIB*INHIBIT
COMPILER ALGOL
INPUT ATLAS CARDS WITH KDF9 I/O PROCEDURES.
LIST ON LINEPRINTER π
7/8 code
LIBRARY XYZ10/7 π
7/8 code

Note that a particular tape may be given different tape numbers in different runs as long as the tape number in the Job Description and in the library directive agree.

Running fully debugged programs from magnetic tape will be more efficient in that compile time will be less as the program is partially compiled when stored on tape (see Appendix 2 for comparison of times). However it would be more reasonable to fully compile the program if it was fully debugged. (See ICT1 library procedure dump program). The facility above is mainly for use in the development stage. What is required is to read the program down from magnetic tape, make corrections required, and then redefine the program as a library item on tape. The following program shows how this would be done:

The program is defined initially as a library item:

JOB
I0000 HOPGOOD DEFINE AND RUN ELLIOTT PROGRAM
OUTPUT 0 LINEPRINTER 400 LINES
OUTPUT 1 LINEPRINTER 1000 LINES
COMPUTING 30 SECONDS
TAPE 7 N0000 ELLIB*PERMIT
COMPILER ALGOL
INPUT ELLIOTT 5-HOLE TAPE WITH ELLIOTT I/O PROCEDURES.
LIST ON LINEPRINTER STREAM 1.
COMPLETE PROGRAM IS DEFINED AS LIBRARY ITEM XAF4/7;
***B

followed by an Elliot 803 program.

This defines the program on magnetic tape N0000 ELLIB as library item XAF4. The listing obtained will start as follows:

0001COMMENCE XAF1π
0002BEGIN
etc.

Let us suppose that during the execution of the program several errors, which require correcting, were discovered. For example the corrections could be made on ICT 7-HOLE TAPE:

JOB
10000 HOPGOOD READ, CORRECT AND REDEFINE PROGRAM
OUTPUT 0 LINEPRINTER 400 LINES
OUTPUT 1 LINEPRINTER 1000 LINES
COMPUTING 30 SECONDS
TAPE 5 N0000 ELLIB*PERMIT
COMPILER ALGOL
INPUT INTERNAL ICT WITH ELLIOTT I/O PROCEDURES.
LIST ON LINEPRINTER STREAM 1.
COMPLETE PROGRAM IS DEFINED AS LIBRARY ITEM XAF2/5;
 corrections
 replace  5 by
 real a;
 delete 10
 finish
 library XAF4/L/5;
***Z

This will cause the program to be read down, corrections made to the program, redefined on tape as XAF2, and then executed. The line numbers used in the editing message are the same as appear on the original listing.

In most cases it would be possible to redefine XAF4 as the new program. However this is not desirable as any failure during the compilation would probably mean that the item XAF4 would be left as a mixture of the old and new versions of the program. Also, by defining a second item, two levels of the program are always available as a safeguard against failure. If corrections are required to the XAF2 copy then the third copy could be stored either in a new position or over the old copy at XAF4.

For safety the different copies of the program could be stored on different tapes.

For large programs this should be a convenient system for development purposes. Once the program has been stored on tape there is no further need for the programmer to reinput the whole program again. Only editing messages need to be input. The final version of the program can be output using one of the listing forms available if desired.

6. DATA PROCESSING ONLY

In the examples given so far it has been assumed that, apart from manipulation of the program, compilation and execution of the program is also required. This may not be the case. The Processor can be used as a simple data processing tool independent of the compiler. For example defining library items, manipulation of library items and listing may be required without compilation. For this reason the Processor Command also allows the option of whether to compile or not. For example:

INPUT ATLAS CARDS WITH ICT I/O PROCEDURES . 
LIST ON ICT 7-HOLE TAPE STREAM 1. 
DO NOT COMPILE;

would cause the program on Atlas Cards to be transferred to tape without any compilation or execution of the program taking place.

APPENDIX 1

PROCESSOR COMMAND

The form of the processor command is defined in a notation similar to Backus Normal Form. The extensions are those used in Compiler Compiler phrases:

The Processor Command is then defined as:

INPUT TYPE <INPUT TYPE > WITH <PERM TYPE>I/0 PROCEDURES <OPTIONS*?>;

where:

<INPUT TYPE>::= ICT 7-HOLE TAPE | ELLIOTT 5-HOLE TAPE | ELLIOTT 8-HOLE TAPE | 
                   KDF9 8-HOLE TAPE | ATLAS CARDS | INTERNAL ICT | ELLIOTT CARDS |
                   ICT 8-HOLE TAPE | ICT 1900 CARDS | ICT 7-HOLE UC | 
                   ELLIOTT 4100 TAPE
<PERM TYPE>    ::= ICT | ELLIOTT | KDF9 | GRAPH
<OPTIONS>      ::= .<OPTION> 
<OPTION>       ::= <LIST> | <SERIAL> | <NO COMPILE> | <COMMENCE > 
<LIST>         ::= LIST ON <OUTPUT TYPE><STREAM?><LINES?><INDENT?>
<OUTPUT TYPE>  ::= LINEPRINTER | ELLIOTT CARDS | ICT 7-HOLE TAPE
<STREAM>       ::= STREAM <N>
<N>            ::= Any positive integer
<LINES>        ::=  LINES <N> TO <N>| EVERY <ORDER> LINE
<ORDER>        ::= <N> TH. | OTHER | THIRD
<INDENT>       ::= , DO NOT INDENT
<SERIAL>       ::= NUMBER CARDS <OFFSET?>
<OFFSET>       ::= WITH FIRST CARD <N >
<NO COMPILE>   ::= DO NOT COMPILE
<COMMENCE>     ::= COMPLETE PROGRAM IS DEFINED AS LIBRARY ITEM <LIBLET* ><N><SN?>
<SN>           ::= . <N>
<LIBLET>       ::= A | B | C | D ...| Y | Z

Typical examples of Processor Commands are:

1.  INPUT ICT 7-HOLE TAPE WITH ICT I/O PROCEDURES;

2. INPUT ELLIOTT CARDS WITH KDF9 I/O PROCEDURES.
   LIST ON LINEPRINTER STREAM 1 EVERY THIRD LINE, DO NOT INDENT,
   COMPLETE PROGRAM IS DEFINED AS LIBRARY ITEM ACM28;
  
3. INPUT INTERNAL ICT WITH KDF9 I/O PROCEDURES.
   DO NOT COMPILE.
   NUMBER CARDS WITH FIRST CARD 50.
   LIST ON ELLIOTT CARDS STREAM 3 LINES 50 TO 500;
   

APPENDIX 2

A program punched in three different dialects has been run on Atlas to give some idea of the efficiency and cost of the various options available through the processor. The program consists of about 750 lines of Algol (about 5000 Algol symbols).

Input form                       Compilation  List         Time in instruction interrupts

ICT 7-HOLE TAPE(Standard Input)     Yes        No              3135
ICT 7-HOLE TAPE(Processor)          Yes        No              3563
ELLIOTT CARDS                       Yes        No              5617
ICT 1900 8-HOLE TAPE                Yes        No              4038
ICT 7-HOLE TAPE(Processor)          Yes    Lineprinter         4055
ICT 7-HOLE TAPE(Processor)          Yes    Elliott Cards       4385
ICT 7-HOLE TAPE(Processor)          Yes    ICT 7-Hole Tape     4132
ICT 7-HOLE TAPE(Processor)          Yes        No              3619*
LIBRARY TAPE                        Yes        No              2753
LIBRARY TAPE                        Yes    Lineprinter         3253
LIBRARY TAPE                        No     Lineprinter          795

* Program also defined as library item.

The Elliott Cards listing should be increased in speed when some improvements have been added.

APPENDIX 3

LISTING FORMS OF ALGOL SYMBOLS

ALGOL SYMBOL    LINEPRINTER             ELLIOTT CARDS         ICT 7-HOLE TAPE
    A-Z              A-Z                   'A'-'Z'              A-Z
    a-z              A-Z                   A-Z                  a-z
    0-9              0-9                   0-9                  0-9
    +                +                     +                    +
    -                -                     -                    -
    ×                *                     *                    *
    /                /                     /                    /
    ÷                //                    //                   d
    ↑                **                    **                   exp
    <                <                     'LS'                 <
    =                =                     'EQ'                 =
    >                >                     'GR'                 >
    ≠                /=                    'NQ'                 ≠
    ,                ,                     ,                    ,
    .                .                     .                    .
    10               α                     a                    α
    :                :                     ..                   :
    ;                π                     π                    π
    _                _                     (space)              S BS /
    (                (                     (                    (
    )                )                     )                    )
    [                [                     (/                   [
    ]                ]                     /)                   ]
    ¬                NOT                   'NOT'                not
    ∧                AND                   'AND'                and
    ∨                OR                    'OR'                 or
    ≡                EQV                   'EQV'                
    ⊂                IMP                   'IMP'                imp
    ≤                <=                    'LQ'                 < BS _
    ≥                >=                    'GQ'                 > BS _
    '                &                     '('                  ( BS -
    '                ?                     ')'                  ) BS -
    :=               :=                    =                    :=
    begin            BEGIN                 'BEGIN'              begin
    B79=ADDRESS OF B79=ADDRESS OF        'B'79='ADDRESS OF'   B79=ADDRESS OF
         

The ICT 7-HOLE TAPE form is the same as defined in the Atlas Algol Reference Manual (CS378B) with composite characters being formed using the backspace key and overpunching. begin is punched out as b e g i n BS BS BS BS BS UL UL UL UL UL.

Untranslatable sequences are replaced by the Algol space symbol (Usually implies that tape or cards have either been mispunched or misread).

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site