Kidsgrove Algol(ID:5893/kdf001)English Electric Algol 60 developed at Kidsgrove Hardware:
Related languages
References: in [AFIPS JCC 22] Proceedings of the 1962 Fall Joint Computer Conference FJCC 1962 view details in ACM Computing Reviews 3(01) January-February 1962 view details Aims What do we want from these Automatic Programming Languages? This is a more difficult question to answer than appears on the surface as more than one participant in the recent Conference of this title made clear. Two aims are paramount: to make the writing of computer programs easier and to bring about compatibility of use between the computers themselves. Towards the close of the Proceedings one speaker ventured that we were nowhere near achieving the second nor, indeed, if COBOL were to be extended any further, to achieving the first. These aims can be amplified. Easier writing of programs implies that they will be written in less, perhaps in much less, time, that people unskilled in the use of machine language will still be able to write programs for computers after a minimum of training, that programs will be written in a language more easily read and followed, even by those completely unversed in the computer art, such as business administrators, that even the skilled in this field will be relieved of the tedium of writing involved machine language programs, time-consuming and prone to error as this process is. Compatibility of use will permit a ready exchange of programs and applications between installations and even of programmers themselves (if this is an advantage!), for the preparation of programs will tend to be more standardised as well as simplified. Ultimately, to be complete, this compatibility implies one universal language which can be implemented for all digital computers. Extract: Two English Electric Algol 60s English Electric Algol 60 English Electric set out with the aim of implementing the full ALGOL 60 report. At the Kidsgrove service bureau they expected to have a wide range of users and of problems and therefore they needed a language which could be universally understood and implemented, as well as eventual fast and efficient object programs. In fact, they have developed two compilers, one at Whetstone, a fast compiler of 3,000 instructions operating on the one-pass load-and-go principle but with no special attempt at efficiency, and the other at Kids-grove, a larger affair of some 20,000-30,000 instructions, designed to be more efficient with exceptionally good procedures but involving several machine passes. Both are expected to be ready for full use by the end of 1962. The Whetstone compiler is suitable for one-off programs but that at Kidsgrove is designed for production programs which require a greater efficiency. These two compilers have certain properties in common. They accept almost identical versions of ALGOL, and that almost the whole of ALGOL and certainly nothing but ALGOL. For both there is an available library of procedures in ALGOL, and in both one can communicate with the machine only in ALGOL. But the Kidsgrove compiler has greater facilities for checking and amending the source program, and also for the final printing out of programs. Finally, English Electric endorsed the opinion that ALGOL was not difficult to learn: their experience was that, including recursive procedures and side effects, a course would not last even the Amsterdam time of four days to an audience of experienced programmers. in The Computer Bulletin September 1962 view details in The Computer Bulletin September 1962 view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (3) 1963 Pergamon Press, Oxford view details in ACM Computing Reviews 4(01) January-February, 1963 view details This paper describes a program written almost entirely in KDF9 ALGOL that will translate a source program written in one of the currently operational conversational languages TELCOMP into an object program in ALGOL text on paper tape ready for running. This allows the preparation of fault-free programs by means of conversational mode programming which may then be run on a larger, faster machine capable of accepting ALGOL. The translator is a two pass translator. In the first pass the standard functions are rendered into their equivalent ALGOL form or, if no equivalent exists, a procedure body is output on paper tape for inclusion in the object program. The various declarations real or array required by the object program are detected in the first pass and stored in a numerical form ready for output to the object program when the first pass is complete. To avoid overfilling the core store when a long program is to be translated each line of the source program is dealt with individually and then stored on magnetic tape. Extract: Aims of the program Aims of the program The primary object of the program was to accept any source program in TELCOMP 1 or 2 without restriction. The second aim was that the resulting ALGOL object program should be as close to normal ALGOL usage as would be consistent with the primary aim. Extract: The read procedure The read procedure The TELCOMP programs are run using a TELETYPE terminal, these terminals produce non-fixed parity IS0 code 8 hole paper tape. The English Electric KDF9 ALGOL compilers do not provide facilities to read mixed parity paper tape, and consequently input procedures were written in 'USERCODE' which is a low level language for the KDF9 computer. The input TELETYPE character code is translated to the internal KDF9 ALGOL basic symbol code by a directly addressable look-up table, operating during the transfer process. The look-up table is accessed by using the arbitrary numeric value of the input characters as a modifier address acting on the base address of the look-up table. Any odd characters, line feeds, carriage returns and erases are removed. The TELETYPE 'Control S' character is used to identify the end of a TELCOMP line of program. The TELETYPE paper tape character code has variations between the directly keyed program and that * Department of Building Science, University of Liverpool dumped up the line from the computer. Both codes have been made to produce a common sequence of basic symbols. The read in process is terminated by the presence of the word 'DUMPED' after a 'Control S' character which is the standard TELCOMP program terminating instruction. Extract: Types of instruction available in TELCOMP Types of instruction available in TELCOMP Each line of a TELCOMP program has a label. This is called a step number and it can lie in the range 1 to 99.99999. This step number is followed by one instruction only. The instructions allowed are described in the TELCOMP manual (1967). Most of these instructions can be followed by a list of expressions separated by commas which are controlled by the instruction. These are explained as follows: SET SET A=B, C= 1 x SIN(TH), D=LN(l+E) These are assignment statements that when written in ALGOL 60 would appear thus: A:=B; C:=l + sin (TH); D:= In (l+E); DEMAND and READ The operation of the instructions DEMAND and READ are similar. DEMAND interrogates the user for the value of a variable, READ reads the variable off paper tape. The instruction: DEMAND A, B, C would appear in the object program as: A:=read(20); B:=read(20); C:=read(20); TYPE, PRINT, PLOT and SEND The instructions TYPE and PRINT are output instructions that have a high degree of flexibility via a FORM (or Format) statement that controls the layout of a line of information output via the TYPE or PRINT instruction. PLOT is similar although the output is in graphical form. And SEND is a tape punching instruction that can punch any binary number in the range 0-255 on paper tape. These instructions can be matched by suitable ALGOL write commands except for the SEND facility which needs special treatment. DO and TO The instructions DO and TO are jump instructions. As previously stated a TELCOMP program is divided into steps. A group of step numbers each having the same whole number part is called a PART. A DO instruction can call either a whole PART or a part of a PART or a single STEP. The TO instruction is simpler in that control is not returned to the point at which the TO instruction occurred. Thus a TO statement can have only one expression following it and it is analogous to a goto statement in ALGOL 60. DONE and STOP DONE is an instruction that deems the current part number to have been done. Control is thus returned to the point at which the last DO statement occurred. The instruction STOP stops the action of the program entirely irrespective of the nesting of DO statements that may be current. Any of these instructions can be controlled by as many FOR or IF clauses as can be placed on one line. (Except that FOR cannot modify a TO instruction.) For example, the TELCOMP instruction TYPE A[I] IF A[I]> 1 FOR 1=1 : 1: 10, 20 would appear as in KDF9 ALGOL as for I:= 1 step 1 until 10, 20 do begin if A01 [I] > 1 then begin write (device number, format statement, A01 [I]) end end in The Computer Journal 12(3) 1969 view details in The Computer Journal 14(1) 1971 view details The compilers available were for Usercode and ALGOL. Usercode is an assembly language with good mnemonics for operations, but very limited addressing techniques. For ALGOL two compatible compilers were available. The 'Whetstone' system (Randell and Russell, 1964) offers excellent diagnostic facilities; compilation is extremely fast, but the subsequent interpretation is slow. The 'Kidsgrove' system (Hawkins and Huxtable, 1963) is an optimising compiler, with long compilation times, and rather limited diagnostics, but producing a fairly efficient object code. No compiler allowed library insertion at compile time; instead each text file contained a copy of any library material, inserted when the file was created. in The Computer Journal 14(1) 1971 view details The Kidsgrove compiler for KDF9 (Hawkins and Huxtable, 1963) was produced with the aim of doing very extensive array subscript optimisation. Unfortunately this sometimes produces incorrect code, so the option to do the optimisation is rarely used. Without this optimisation, the array accessing code is very poor. Some improvements have been made by Oxford University and the author to overcome this defect, but they are not considered here. The KDF9 itself presents substantial problems to the compiler writer. The stack mechanism does not allow for automatic overflow, so the compiler must empty the stack on procedure and function calls. Environment control and array accessing are not very convenient on KDF9 because the address registers must be loaded and unloaded via the stack. Although KDF9 does execute more instructions than many machines quite a large proportion of the instructions only involve the stack and so are relatively fast. Extract: Conclusion Conclusions The main advantage of a non-conventional architecture for the compilation of ALGOL 60 appears to be the production of extremely compact object code. This is achieved with the B5500 by a very short address length within an instruction. Because of the dynamic storage allocation of ALGOL 60, access to simple variables is always by a small offset from an environmental pointer. Hence an address length within an instruction of only 9 bits is adequate. Anything in excess of 9 bits is likely to be wasted. On the other hand, several index registers or their equivalent are necessary for environment control and array accessing. Such registers must be capable of being updated rapidly for procedure entry and exit, and for access to name parameters. Access to array elements is usually via an array word which can be addressed in the same way as a simple variable. A short address length may preclude some array access optimisation, for instance if 'a' is a global array of fixed size a[200] could be accessed by a single instruction provided the address field was large enough. In fact the B5500 does not allow array accessing optimisation because the storage protection system depends upon access via the array word (descriptor). The optimisation produced by the ALCOR compilers (Grau, 1967), could be done on a machine with a short address length, but not the B5500. Array bound checking is an area where special hardware can be used to great advantage. Unfortunately the hardware on the B5500 does not deal with the general value of the lower bound, so that explicit code must be generated by the compiler to subtract the value of this lower bound if it is non-zero. Options to do bound checking on other machines tend to be very expensive in processor time. The 1108, although having no built-in hardware for array accessing, has a convenient instruction for bound checking. With this instruction, a single test can be made to see if the operand lies within the range defined by two registers. Apart from the production of compact code from ALGOL 60, it is clear that in many scientific fields non-conventional machines can have other substantial advantages. Array bound checking has already been mentioned, but other examples lie outside the scope of this paper, for instance distinction between data and program and the ability to share the available core store between processes. The majority of these advantages are in the field of operating system design, and so are not considered here. Such advantages are likely to have a substantial effect upon the performance of the compiling system itself, and the easy way in which such systems can be developed. in The Computer Journal 15(1) February 1972 view details Resources
|