Kalgol resurrection — towards a definitive version
Strategy
The objective always was preserve the source code of Kidsgrove Algol (Kalgol)
so that it can be browsed on-line and executed so as to compile Algol60 programs.
The Kalgol.compiler operated within a magnetic tape based filing system called POST.
The whole system ran as a series of overlays called “bricks” each of which
occupied store from word 1600 upwards.
The first 1600 words of store held a permanently resident module (KAB00) which supplied
facilities to the overlays via a subroutine call to word 70 (JSE70; in Usercode).
The API for this interface was in terms of “channels” which were I/O
streams implemented on magnetic tapes.
Although we have the (uncommented) code of the resident module, we do not have its
companion set-up module.
So the strategy can be summed up as converting the surviving listings to machine-readable source text,
and write substitutes for the missing components.
Initially this involved reverse engineering, but part way through the project, some documentation came to light
in the Science Museum.
Not only do we have to produce a substitute for part of the POST system, one of the bricks (KAB20)
is also missing.
Fortunately the documentation that came to light included a hand-written version of this brick.
This must have been an early version, and subsequent examination showed this to be the case.
In essence, David Huxtable has created brick 20 by developing the handwriting into working code.
There is hope that this can be described separately.
Initial development involved writing a new resident module in C, and accessing it via
a new OUT, viz OUT 70.
The code was integrated within DH's emulator.
This has now been superseded by
a version of this code written in KDF9 code (KAL4 not Usercode), and its
method of working is described here.
We now have a version of the Kidsgrove compiler which consists of the original bricks,
plus substitutes written in KDF9 code, so our resurrected system could actually work on
a real KDF9, or any emulator capable fo simulating the 5 magnetic tape decks that the
system uses, as did the original in its optimum form.
Usage
To run the compiler you need the Algol60 source code in a file called
test.a60 (say), such as this on-line example,
and a system tape, which you need to generate (see below).
You also need the initial KDF9 binary program
KAB00.bin,
which you then run either with:
mkchan test.a60 chan6.pt
kdf9 -d KAB00.bin chan6.pt > t.t
or
ln chan6.pt TR1
mkchan test.a60 chan6.pt
ee9 < KAB00.bin > TP0 This line needs updating to describe the current version of ee9.
The diagnostics
(which come out on the KDF9 operator's typewriter) are rather voluminous.
The Holdsworth version is packaged in
testpt.bat.
The binary program (or an error report if you are really unlucky) will emerge
on a paper image.
There is an implementation for ee9 packaged with the release.
For the kdf9.c emulator the binary program is on a file called ptp.bin.
This is converted into a binary file mt.out (say) for use with the emulator:
xbin ptp.bin mt.out
kdf9 -d mt.out str20.txt
The last parameter is the paper tape stream 20 data for the program.
Simplest set up
A kit of parts is included with the ee9 emulator release.
The following describes use with the DH emulator, and should work on any computer.
You need to download and compile the first 3 of the following programs:
- kdf9.c The KDF9 emulator
- mkchan.c creates the image of the POST input tape
- xbin.c converts the paper tape output into a binary program, or prints the failure report
- mtdiag.c gives diagnostic listing for the work tapes
- xbin2.c unpicks the results of the compilation and extracts the binary program
- htmform.c makes HTML listings of assembler output, etc
- kal3.c The modern Usercode compiler
- kal3.y The yacc input file for the above
If you do not have yacc or bison you can download
y.tab.c and
y.tab.h
Programs 4 to 8 are needed if you are wanting to run programs
too large for the KAA01 Usercode Compiler (see below).
You also need:
There is a motley collection of demonstration and test programs in test.a60.
Channels
Each of channels 0, 4, 5, 6 and 7 is implemented by a mag tape.
Channel 0 is a system tape whose creation is described below.
Its label is SYSTAPE9.
The other mag tapes are work tapes, and are used as such by the compiler.
Channels 4 and 6 are read channels, and 5 and 7 are write channels.
A command interchange allows the swap over of 4 and 5, or of 6 and 7.
The resident module (called PANACEA or KAB00 in the documentation)
is implemented in KAL4
(source code and
assembler listing).
Channels 3 and 17 are both concerned with hard copy output, and are
implemented by OUT 8 to stream 30.
Channel 2 is something of a mystery, and was probably something to do with
a paper tape reader.
It is not implemented in KAB00.k4.
Input of Algol 60 source code
In production operation the Algol 60 source code was held in a mag tape
library system called POST, which we do not have.
Brick 01 (the first pass) reads the source code from channel 6,
which must have been set up somehow by POST.
Our implementation has a new brick 81
(source code and
assembler listing).
which reads paper tape (not
via PANACEA) and writes to channel 7
This then interchanges channels 6 and 7 and does a brick change to KAB01.
In order to postpone the writing of KDF9 code to decode Algol Basic Symbols,
the paper tape read by KAB81 is an octal dump of the mag tape blocks
which is created by a C program mkchan.c,
which reads Algol source terminated by a line startng with 4 stars or the end of the file.
So test.a60 can conain lots of example programs whose order is shuffled to
bring the desired input to the front.
System tape usage
The system tape holds all the overlays (bricks) the Algol libraries, the
run-time system and a tiny mystery file (KAB97) which is essential but whose significance
is unclear.
This tape supports three of PANACEA's functions:
- Brick change
in which a new overlay is brought into memory and entered
- Find
in which a the channel 0 tape is positioned
- Read
which follows a find and is used for reading Algol library material or the Usercode run-time system
System tape creation
It is important that this tape is written using KDF9 mag tape instructions.
This is so that the system will work on any emulation of KDF9 and is
independent of the format of the files emulating magnetic tapes.
The only medium upon which we can feed information into KDF9 code is via paper tape.
The system tape SYSTAPE9 is created by a KDF9 program
mksys2.k4
which reads the octal dump of the system tape:
systape.txt.
If you are using Bill Findlay's emulator
ee9
this is all you need to do.
As well as creating the system tape, mksys2 also
labels 4 work tapes.
With a new version of ee9 this is likely to be
unnecessary, but at present limitations in the implementation
of mag tape in ee9 make this necessary.
It is wise to delete all files whose names are of the form MT*
before running mksys2
If you are using David Holdsworth's emulator
kdf9.c,
the system tape ends up in a file tape4.mt
which must then be renamed tape9.mt.
It is wise to delete all files whose names are of the form tape*.mt
before running mksys2.
The mag tape emulation in kdf9.c is very limited and
just sufficient to support PANACEA.
The octal dump of the system tape is created by a C program
mksys.c
which reads a data file
syslist.txt
listing the modules to be included on the tape.
This creates a “paper tape”
systape.txt
which is the octal dump of the channel 0 system tape.
The bricks are read directly from the .bin files created by
the Usercode compiler, or the KAL4 assembler as appropriate.
The libraries are incorporated from .pt files
which are presently handcrafted in a rather shameful way.
A0.pt is the library A0, Z9999.pt the runtime system
and ch0.pt the mystery file read by brick 01.
All necessary files for creation of the system tape can be downloaded
from the index file.
Development considerations
If developing code in kAlgol bricks it is rather tiresome to keep
generating the system tape.
There is a Windows command file
sysgen.bat
which eases (trivialises?) this task
when using the Holdsworth emulator.
There is a version which does brick change using OUT 1.
It is
KABZZ.bin.
The source text is
KABZZ.k4.
The hope is to finish with a system that will run on any emulator (or even a real machine with 5 tape decks).
The original exploration of APIs involved writing re-engineered substitutes for missing components in C,
and activating these by use of a new OUT70, so called because the PANACEA interface went via JSE70.
So we have two options for the PANACEA API, selected by whichever binary program is run at the start:
- KABDH is the our original implementation of the PANACEA API,
and uses OUT70 for all the panacea functions.
It will only work with the kdf9.c emulator with out70.c incorporated (see below).
The source text is KABDH.txt
and the assembler listing is KABDH.htm
- KAB00 is a new implementation of the PANACEA API,
and uses only KDF9 instructions.
It uses a system tape holding all the bricks the runtime system and the standard function library.
It is intended that it works with any emulator, but may not have got there yet.
This tape had to be generated before running the compiler.
The source text is KAB00.k4
and the assembler listing is KAB00.htm
- KABZZ is a slight variant of KAB00, and differs only in that
the bricks are loaded with OUT1 rather than reading the system tape.
It is intended for development of bricks without the need to create a system tape.
The source text is KABZZ.k4
Library files
The preparation of a library file (either runtime or A0, or any addition to the library repertoire)
is a somewhat messy process (documented below).
In the real system, the Usercode generated by brick 60 was then turned into binary code
by brick 84, the POST Usercode Compiler.
We do not have this, and have two variants, differing in the way that the runtime system is incorporated:
- KAB84.txt is our original implementation, and has evolved to the point
where only 9 instructions are actually obeyed.
The rest of the source text is of historic irrelevance.
After swapping channels 6 and 7, it uses OUT70 to invoke a C routine brick83()
which writes a Usercode program in the file prog.txt.
It takes a runtime system from a file runtime.txt
and incorporates it along with the generated code taken from the brick 60 output.
The source text is KAB84.txt
- KAB84.k4 is our new version which incorporates the runtime system
from the system tape, where is resides under the name of Z9999.
The output is currently on paper tape in 2 files:
ptp.txt which is in ISO-Latin-1, and
ptp.bin which is the same content in KDF9 paper tape binary code.
The source text is KAB84.k4
and the assembler listing is KAB84.htm
There are several library files on the system tape.
They are incorporated from files such as ch0.pt, A0.pt, and Z9999.pt.
The first of these was crafted by hand and it is the mystery first read from the system tape.
The others are created using mkchan with a -l switch which
adds a header,
which can can be seen in A0.pt and Z9999.pt.
The number in the header after the library name is the number of blocks in the file.
The lines are also flagged with the indication that they are from library text.
This has the effect of making the line count in any error reports corresponding with the
original Algol 60 source.
For example:
mkchan -l A0.a60 A0.pt
mkchan -l runtime2.txt Z9999.pt
KDF9 emulators
In order to run this software you need a KDF9 emulator.
There are at least 2 of them:
-
Bill Findlay's ee9 which is written Ada
and takes a very thorough approach to emulating the machine.
-
David Holdsworth's kdf9.c
which is written to run such KDF9 software as we have so far uncovered,
and omits any instructions that we have not so far encountered.
Its floating point is not completely pukka.
For running kAlgol it has had an OUT70 blister added, and there are
still elements of this blister involved, so to compile it one needs:
gcc -g -DPOST -o kdf9 kdf9.c out70.c