Kidsgrove Algol — a full kit of parts for developers

This package is intended to allow anyone with a knowledge of programming to install all the components of the Kidsgrove Compiler and experiment at source code level. The download installs original source code. It should all work on any computer with a C compiler.

It may help to run the demo20.htm example first. This shows how the compiler is run, whereas the fullkit demo enables the compiler to be built from source text. Examples of both emulators are included in demo20, but the fullkit demo just uses kdf9.c. However the systape.txt file generated will also work in demo20 with both emulators.

No knowledge of KDF9 is required in order to do the installation, but exploration of the original source code will need some KDF9 knowledge if it is to be meaningful. The KDF9 programming Manual is available on-line, as is a summary of the order code of the machine.

Installation

Down load and unzip:
       fullkit.zip
It creates a sub-directory called kdev, in which there are all the source text files to get Kidsgrove Algol running on a personal machine. The installation has 2 steps. There are Windows .BAT files and UNIX shell scripts with names ending in .sh. These all assume that kdev is the current directory.

The first step is install0 which compiles all the C-programs using gcc. You may choose to use a different compiler.

The second step is install1. It creates the system tape by packaging up the run-time library material, and assembles all the KDF9 assembly language components. In addition to creating binary programs it also creates HTML listing files. It concludes by collecting all the components into a system tape.

cd into the kdev directory, and type install0 if running windows. On UNIX-like systems type something like bash -v install0.sh.
Installation concludes by running install1.

Compiling Algol Programs

The Kidsgrove compiler was embedded in a magnetic tape filing system called POST. We do not have this system, so there is a C program (mkchan) to create an image of a POST-format magnetic tape on simulated paper tape. To compile the program pentomino.a60, you first convert it to a POST channel 6 tape:
       mkchan pentomino.a60 chan6.pt

To compile the Algol program that you have just “POSTed”
       kdf9 -d kalstrt.bin chan6.pt

The binary program will have been written to ptp.bin, possibly preceded by some text output. You can extract the binary program to pent.bin by:
       xbin ptp.bin pent.bin

To run the program:
       kdf9 -d pent.bin pentdata.txt
It will run for a few minutes or more. The printer output is in a file called punch.txt

Note for UNIX. The current directory may not be in the path, so the above commands need to be prefixed by dot slash, e.g.:
       ./kdf9 -d pent.bin pentdata.txt

Compiler Options

The Kidsgrove Compiler has various modes of operation, depending on how much output is wanted, and the level of code optimisation. The management of this facility was a part of the POST system, which loaded a bit pattern into a global variable Z38. In the absence of the POST system, the options can be indicated by a -B switch to the kdf9 command.
POST
Option
Z38 bitswitchComment
TRACE D1 -B100no longer used by the Kidsgrove Compiler
TABLES D2 -B040print reference
ORIG-SW D3 -B020indicates use of original software for assembly (see below)
TEXT D4 -B010print the generated Usercode text
NO-OPT D5 -B004omit the optimisation process
NO-TEST D6 -B002controls run time diagnostics (see below)
NO-WARN D7 -B001Obsolete
L+G D8 -B200000Load and Go operation (see below)
The following POST options are not relevant to the Kidsgrove Compiler
KALGOL D9 -B100000Always set and never tested
WALGOL D10 -B40000never set
USERCODE D11 -B20000never set
FORTRAN D12 -B10000never set
UC/RLB D13 -B4000never set

The above table comes from this internal English Electric document. Note that the setting of D5-7, is a turn-off indicator. There is more information about the meaning of options in the end-user manuals SRLM and AUM (Service Routine Library Manual and Algol Users Manual).

ORIG-SW (D3) is documented as always being set, but we do not have the original POST Usercode Compiler (KAB84) and have made a substitute using the Paper Tape Compiler (KAA01). This substitute has size limitations, and if D3 is unset the generated Usercode is output on paper tape, from where it can be assembled with kal3.

NO-TEST (D6) inhibits the generation of code which allows optional printing of the results of every assignmant statement. This is part of the run-time diagnostic facilities, which are documented in the 5 pages at the head of the Algol Users Manual.

L+G (D8) was not available with the released system. The POST system was a filing system using magnetic tape, and contained within it compilers for the creation of object programs which were stored as files on magnetic tape, from where they could be loaded and run at a later time. However, we have had to substitute for the final assembly pass with a module that has a load-and-go facility, and it was thus easy to include this option. The presence of the L+G bit in the internal documentation indicates that it must at some stage have been part of the design.

To compile with TABLES, using the original Usercode Compiler and without OPTIMISER:
       kdf9 -d -B64 kalstrt.bin chan6.pt
The default (i.e. no -B switch) is equivalend to -B66.

Compiler Structure

There is a section describing the Structure of Kidsgrove Algol in this web page.

Although it is still possible to run the system starting with KAB00, this is now included on the system tape, and the above system uses a very small starter module to fetch KAB00 from the system tape.

Into the 21st Century

NumberR/WFunction
0RSystem components
3WLineprinter Output
5WWorktape - writing
4RWorktape - reading
6RUser’s source code
7WGenerated Usercode
17WBuffered access to channel 3
The remaining channels are not used by the compiler
and are not implemented in this system
1WPaper tape punch
2RPaper tape reader
The original KDF9 Time-Sharing system had two file management systems, POST where files were stored on magnetic tape, and the later PROMPT where files were stored on disc. The modules of the system were called “bricks” and were overlaid from magnetic tape or disc respectively. Each system contained a version of the Kidsgrove compiler. Our 21st century version has been built from bricks of the magnetic tape system (POST).

Not all of the system survived. We have written new code to fill in the gaps. This is described in the KDF9 languages page.

The compiler bricks read and write data via a memory resident module KAB00. Although we have the original KAB00, it operatied in symbiosis with KAB80, which we do not have. The sparsity of comments led to our reimplementation of KAB00. All I/O is via “channels”, which the original POST system implemented on magnetic tapes.

The original POST implementation held all of the bricks, and library material on a system tape, which was addressed as channel 0 (and occasionally channel 8). The channels were and are used as in this table: Our system tape has the same overall form as the original, but the individual file formats differ. Its contents are defined in the file syslist.txt:
KAB00.bin   memory resident code and system start up
KAB81.bin   converts PT image generated by mkchan into channel 6 format
KAB01.bin   the original first pass - brick 01
ch0.pt      KAB97 substitute -- see below
A0.pt       Algol library A0 close to the original
A6.pt       combined I/O library composed of A1, A4, A5, A15
A1.pt       I/O basic routines -- newly written
A4.pt       main input routines - original code
A5.pt       main output routines - original code
A12.pt      sundry output routines - original code
A13.pt      sundry output routines - original code
A14.pt      copytext - original code
A15.pt      writetext - newly written
A104.pt     minimal function A4 - newly written development aid
A105.pt     minimal function A6 - newly written development aid
A106.pt     minimal function A6 - newly written development aid
A114.pt     minimal function A14 - newly written development aid
KAB02.bin   orignal brick 02
KAB20.bin   reconstructed brick 20
KAB22.bin   orignal brick 22
KAB24.bin   orignal brick 24
KAB40.bin   orignal brick 40
KAB41.bin   orignal brick 41
KAB42.bin   orignal brick 42
KAB45.bin   orignal brick 45
KAB46.bin   orignal brick 46
KAB60.bin   orignal brick 60
KAB84.bin   a newly written brick which converts tge ABS Usercode into papertape characters
Z9999.pt    runtime library essentials, sort of equivalent to KAB97
KAA01.bin   original paper tape usercode compiler
EDNK4.bin   original KAL4 assembler (not used by Kidsgrove compiler)
KAB95.bin   original error routine
KABPM.bin   new debug diagnostic post mortem
KAB99.bin   original termination routine
The surviving code was not bug free, and almost certainly not the finally released version. There have been changes to attempt to rectify known deficiencies. The source text listings are linked from this web page.

The implementation of the I/O library routines are descriped here.

Inclusion of library routines

In the original POST system KAB01 did not do library inclusion. This was done when the source code was established onto MT. So in real life, the symbol library would never be encountered by KAB01. Early in our project, it was discovered that KAB01 would recognise library and set about including the file. However, it would then crash. The bug was found and corrected. Perhaps back in 1960s nobody found the bug, and used POST to insert the libraries as a solution (workaround). This is why a surviving program has given us a free listing of the libraries. However, these do not include P290 and P289, which is why we have made replacement versions of libaray A1 and A15, as described here.

The original mechanism is discribed in §4.3.3 of the original documentation:
           http://sw-pres.computerconservationsociety.org/IMG/KDF9/AUM/page04008.jpg
           http://sw-pres.computerconservationsociety.org/IMG/KDF9/AUM/page04009.jpg


In the equivalent section of PROMPT, which is in §6 of the SRLM, library inclusion is described in just the same way as for POST. Surely this would have involved clogging up the limited disc space with multiple copies of a not very small library.

Reading the user’s souce code

Brick 01 of the compiler reads the user’s souce code from a standard POST tape, which uses 32-word blocks as described in §22.1 of the SRLM:
           http://sw-pres.computerconservationsociety.org/KDF9/SRLM/

The original brick 80 read paper tape and copied to magnetic tape in this format. We do not have brick 80, and also we would wish to start from a file of ASCII (or thereabouts) characters. The program mkchan.c reads Algol Basic Symbols with a variety of stropping conventions, as discribed here. We have 2 different emulators for KDF9 with very different magnetic tape formats. So the output from mkchan.c is written as an octal dump on paper tape (conventionally called chan6.pt). This dump is already in 32-word blocks in POST format. This is read by a new brick 81 (a kind of surrogate for part of brick 80) and written to channel 7. This brick concludes by doing an “interchange” operation to swap channels 6 and 7, leaving channel 6 ready to be read by brick 01. Apart from the issue of library inclusion described above, brick 01 (KAB01) is the original code.

Processing the generated Usercode

The final brick of the compiler (KAB60) writes the generated Usercode in Algol Basic Symbols on channel 7. The format is the same 32-word block format. Despite the absence of (KAB84) from the surviving code, a listing of the paper tape Usercode compiler (KAA01) was found in the Science Museum. Also we have a newly written Usercode translator, kal3.c. The choice between these two is made via D3 of Z38, as described above.

If D3 is unset our substitute brick 84 claims a paper tape punch, and outputs the Usercode in KDF9 paper tape code, which the emulator then outputs in ISO-Latin-1.

If D3 is set our substitute brick 84 writes on the channel 7 pseudo-mag-tape and outputs the Usercode, also in KDF9 paper tape code with 32-word transfers. There has been a slight modification to KAA01 so that it can be entered with the number of the input device (normally a paper tape reader) in N1. However, paper tape read instructions are identical to those which read magnetic tape. By writing the Usercode in 32-word blocks, the data on the tape matches the 32-word reads of KAA01.

Our KAB84 starts st location 3072, and after writing the mag tape, it reads KAA01 from the system tape into its correct locatin in memory. Under normal operation KAA01 jumps to word 0 after compiling a program, ready for another. We achieve a cleaner exit by overwritng word 0 with ZERO; OUT;, so ensuring a clean end to the compilation.
To be continued