Kidsgrove Algol Input/Output
The kalgol I/O system was included in the source text of programs as they were
established into the POST system.
Our rescue of the kalgol compiler is based on material from Bill Waite.
This material did not include a complete system.
Not only was one brick of the compiler missing (brick 20), but there was no run-time library.
However, we acquired a surviving listing of a program (subsequently referred to as KQX)
in which the library routines were also printed out.
Our implementation of the runtime library is drawn from this.
Some bits were still missing.
The preserved walgol system is complete, and we have been able to extract
some standard functions from that source.
The original input/output system involved components which were not in any
of the surviving material, especially tables for translation of Algol Basic Symbols.
This process focussed around a multiple entry routine P295.
Althoug we have the original of this, we do not have the routines
which it calls, and it comprises about 550 lines of Usercode, almost totally
lacking in comments.
We (primarily DH) have implemented a subset version of P295, sufficient to offer
one input stream (20), and one output stream (30).
All the documented routines are there, but some merely result in runtime error messages.
There is also one undocumented routine copied from the walgol version.
The write routine P291 contains a couple of other references to internal
properties of P295.
Although there has been no attempt to implement these, there have yet to be problems as a result.
The input of Algol Basic Symbols is sufficient for reading most data, but does not process compound symboils.
The output needed to be more complete, and outputs in lineprinter format.
All the KDF9 lineprinter characters exist in ASCII except for £ and subscript 10,
which are replaced by $ (dollar) and ~ (tilde) respectively.
The scheme of P295 is that a routine wishing to generate output must
first initialise the output (R12P295),
then (repeatedly) call a routine to output a basic symbol (R14P295).
This sequence must end with call to freeze (R16P295), which then stores away
variables to enable a further subsequent use.
As a first stab at generating output we had writetext to output a string of
Algol Basic Symbols and a very simple number output routine.
It became clear that we needed the P295 routines if we were to use the surviving output routines.
The scheme that we have now owes something to its predecessor, especially the writetext routine.
The initialise routine preserves the top of stack pointer, and then advances it by 22 words.
Subsequent calls to output a basic symbol, store these on the top of the stack.
When there is a call to freeze, this string of basic symbols is translated into
printer characters which are also stored on the stack, from where they are printed via OUT 8,
using my original writetext routine P288.
There is a further refinement in P288 to ensure that each OUT 8 transfer ends with a paper motion character.
Up to 40 words (320 6-bit characters) beyond the last carriage return or paper feed
are held in a buffer in the V-stores of P288.
When stream 30 is closed, any left over characters are printed with carriage return added.
The freeze routine ends by restoring the top-of-stack pointer.
Q-store usage in my versions of P295 is deliberately circumspect.
The JS6P295 etc (inbasicsymbol) uses only Q13 and Q15.
The JS14P295 etc (outbasicsymbol) uses Q8 and stores basic symbols on the stack.
This stack usage seems a bit problematic when using the optimiser, because it
seems that the optimiser is capable of using space beyond the top of the stack.
A pragmatic gap of 22 words has been left in the current versions.