Pegasus AUTOCODE(ID:2898/peg001)Autocode for the Pegasus systemAutocoder for the Ferranti Pegasus computer Hardware:
Related languages
References: in Proc. I.E.E., Vol. 103, Part B, Supplement No. 2, 1956 view details in Proc. I.E.E., Vol. 103, Part B, Supplement No. 2, 1956 view details in Proc. I.E.E., Vol. 103, Part B, Supplement No. 2, 1956 view details INTRODUCTION Experience with the Ferranti Mark I Computer at Manchester University showed that it was possible to reduce considerably the time needed to prepare certain kinds of program by using a conversion program known as the Mark I Autocode (Brooker, 1956, 1958). It was consequently decided to prepare a similar program for the Ferranti Pegasus Computer. As far as the differences between the two machines allowed, the main features of the Mark I Autocode have been retained and, while there are some omissions, a number of useful additional facilities have been provided. The scheme is particularly well suited to occasional users with relatively small scientific or technical problems to be solved and who do not wish to go to the trouble of learning the normal programming methods; often only a day or less is needed to learn the simplified technique used with the Autocode, and programs can then be easily and quickly written down. Use of the scheme entails a reduction in the effective speed of computation, but this is frequently acceptable because of the very great reduction in programming time. We give first a description of the scheme from the point of view of the user, and then describe some of the techniques used to make it realizable. Extract: A Brief Description Of The Autocode A Brief Description Of The Autocode The calculation which is to be performed must first be broken down into a sequence of simple steps, each of which is written down as an Autocode instruction (or order); the sequence of instructions forms the program of the calculation. When this program has been prepared it is then typed out, more or less as written, on a teleprinter or a keyboard perforator. This produces a length of punched paper tape, called the program tape, which can be read into the computer by the Autocode routine. At this stage the instructions making up the program are simply converted into a suitable form and stored inside the computer; they are not obeyed. At the end of the tape are some special symbols which cause the machine to start obeying the program it has just read in, i.e. to start the calculation. Extract: APPLICATIONS APPLICATIONS The Autocode is intended mainly for relatively small scientific or technical calculations, especially those in which the results are required quickly. Many of these calculations can be put on to the computer in a very short time, often a few hours only, once the problem has been precisely described. This should be contrasted with the weeks, or even months, which might be required to program the problem in the ordinary way. The fact that the running of the program may take much longer if the Autocode is used may not matter, since it is often quite brief in any event. There are some problems in which the cost of the extra machine time is saved by the reduction in programming costs; many "one-off" problems are of this kind, the program being used only once after it has been written. Even if the program is to be used several times there are advantages in having the originator prepare the program himself, which may be impracticable if he has to learn ordinary programming methods first. In this way many people throughout an organization can be using the computer directly on their own calculations, and a general computer consciousness can spread. In some Autocode programs it may be advantageous to re-write the "inner loops" in ordinary machine language, and hence to achieve nearly the same speed as if the Autocode had not been used. An important application, in business as well as technical calculations, is that in which an Autocode program is written as a preliminary to the preparation of a machine-language program. The Autocode version can be used to test proposed methods and flow-diagrams, and can very readily be changed in the light of results: it can also be used to provide a few sets of accurate results and intermediate values, which can be very useful in later testing of the machine program; it may also provide indications of how scaling should be done if the ultimate program is to work with fixed-point numbers. This application is specially useful in exploratory work where it is difficult to see what sort of processes should be used in the final program. in The Computer Journal 1(4) January 1959 view details in The Computer Journal 1(4) January 1959 view details in Goodman, Richard (ed) "Annual Review in Automatic Programming "(1) 1960 Pergamon Press, Oxford view details External link: Online copy in The Computer Journal 3(4) January 1961 view details in Goodman, Richard (ed) "Annual Review in Automatic Programming "(1) 1960 Pergamon Press, Oxford view details in Goodman, Richard (ed) "Annual Review in Automatic Programming "(1) 1960 Pergamon Press, Oxford view details in Goodman, Richard (ed) "Annual Review in Automatic Programming "(1) 1960 Pergamon Press, Oxford view details Most of the papers are written in a style and manner which seem to have become universally accepted for papers on computer programming, at least in the English-speaking world and probably in others. This style insists on a liberal dosage of impressively detailed flow charts which, considering the well-known and understandable reluctance of programmers to read their own programs much less those of others, one suspects most readers hastily skip over, willingly granting their authenticity. The flow charts are invariably accompanied by long lists of special instructions described in the private patois of the author, who seems blissfully unaware or unconcerned that his specially constructed vocabulary of acronyms may present;. rough going to the reader from the inlying provinces. Finally, the style demands long and wearisome descriptions of basic concepts (e.g., subroutine; symbolic instruction, etc.) long since familiar to the average reader, some indication of difficulties as yet to be surmounted (e.g., automatic storage allocation; easier debugging; et al). Nevertheless, the volume does give some idea of the status of automatic programming systems in Great Britain in early 1959. It also contains a concise description of the 709 SHARE operating system, and another brief account of FLOW-MATIC and MATH-MATIC. There are two interesting appendices worthy of mention. Appendix One consists of reprints of two papers by the late A. M. Turing, "On Computable Numbers with an Application to the Entscheidungsproblem", in which the "Turing machine" was conceived, and a brief corrective note on the same subject. Appendix Two contains the "Preliminary Report of ~ ACM-GAMM Committee on an International Algebraic Language", since published elsewhere. The reviewer cannot suppress the question of whether this sort of material (Appendices excepted), so soon obsolescent or obsolete and so difficult to present adequately in short papers, deserves the effort and expense required to reproduce it between the bound hard covers of a handsome book. in ACM Computing Reviews 2(03) May-June 1961 view details in The Computer Journal 4(1) April 1961 view details in The Computer Journal 4(1) April 1961 view details Ferranti computers use teleprinters which include a limited number of mathematical symbols in the character set. Hence the Pegasus Autocode comes easily to mathematicians: again one looks at the machine as a number of registers, some holding integers with exact counting and others holding floating-point numbers accurate to seven or eight significant decimal digits. This autocode can also be used on Sirius or Mercury; on Sirius, a machine code program tape may quickly be compiled for future use. Extract: Introduction Introduction Electronic computers are able to work at high speeds only because they are programmed. Analysis of a problem, or a data processing procedure, and the programming of it for a computer in machine code, is a laborious task. In the early machines, users soon appreciated the advantage of having standard programs for assembly and program development, and a library of routines for regular calculations, complex number input and output, and for tracing the course of programs during program development, particularly when unexpected results were given when the program was tried on the machine. Where jobs are to be done regularly, it is still most economical, in the long run, to program them in machine language using such library routines as may be available. But for jobs which have to be done only once, or where it is desirable to try-out part of the job first and then extend the application of the computer, simplified programming systems have been developed. By their means, the computer can be addressed in a form of English, or by direct use of mathematical symbols if these are available in the character set of the teleprinter-punch used for punching the program. These simplified programming systems to which I shall apply the term "Autocodes" (originally named by Brooker at Manchester), together with available libraries of programs, constitute a very significant extension of the machinery which is now available. Besides saving the time spent on programming, these systems reduce the clerical errors of program writing by eliminating many tedious steps and this also reduces the time taken by program development. They also make it easier for the writer (or another person) to amend the program at a later date. In the earlier systems, the simplification entailed a varying loss of operating speed, varying between two and fifteen times as long to do a job on the machine. But a half hour of computer time after a few hours' programming in autocode is a more economic proposition for a one-off job, or trial of a routine job, than several weeks on programming, followed, after several trials, by a successful five-minute run on the computer. The newer programming systems, which involve a preliminary operation to compile a machine code program, will suffer less loss of speed and will become the normal method of programming computers for calculations and dataprocessing work, where the operations are not sufficiently standard to justify the writing of specific or general programs in machine language. Extract: Work at Rothamsted Work at Rothamsted In his valedictory Presidential address to The British Computer Society in London on 26 September 1961, Dr. Frank Yates reviewed the contribution which computers have made and are making in research statistics. It is on the solution of problems involving heavy numerical computation, in pure research, and in engineering design that, in his view, computers have achieved their most striking successes: Dr. Yates went on to point out that even in fields where computational tasks had previously been performed on desk calculators, computers could introduce three new features: (a) Speed, e.g. where further progress depends on knowing results to date. (b) A more thorough job, with better editing of data and more accurate calculations. (c) Relegation of computational methodology to the machine, so that people requiring to do calculations do not have to know the detail of the calculations involved. His paper (Yates, 1962), published in the January issue of The Computer Journal, reviews experience at Rothamsted and the development there of general programs for statistical work and some autocodes at other centres. If a general purpose program is available to include a mathematical procedure or the statistical method which one needs for a piece of analysis, then more people can use the computer. 1 have prepared a schedule of some of the schemes that are now available, or may be expected to be available early in 1962. Those who have access to a computer may find this of interest to follow up whichever line of development is applicable. Extract: Applications in Metal Box Company Applications in Metal Box Company In a paper published in The Computer Journal for April 1961 (Gearing 1961) 1 referred to the use which we, in The Metal Box Company Limited, had made of Pegasus autocode. I reviewed, in some detail, two programs. One of these was an analysis of a market survey for household trays in which interviews were conducted with some 1,100 households, covering 17 general questions and 10 observations of each tray found at the house: these questionnaires were analysed and 17 tables for the internal report were printed direct from the computer output tape. The other program related to part of our work on experimental sales forecasting and is now available in the Pegasus/Sirius interchange scheme (Ferranti, 1960). Our first computer application to quality control was in 1958-59 when we undertook an analysis of variance in connection with a productive operation being camed out by a group of machines in the chain between the sheet of tinplate and the finished open top can. Three factors were involved. The autocode program for Pegasus was thought to be rather slow and a full machine code program was written by Mr. D. Bulcock and is now available in the Pegasus interchange scheme. There are other analyses of variance programs available, notably one by BISRA (Caner and Taylor, 1960) which caters for up to seven factors, but if there are more than seven levels and only three factors involved, our program permits all the levels of data to be used. Nowadays, we would not attempt to write a full machine code program unless the job was going to be frequently done and would require considerable machine time. In the group of machines which we are using, a compiler-program has become available which automatically translates the Pegasus autocode program into Sirius machine orders (Ferranti, 1959 and 1961). In 1960 we were asked to assist in the analysis of data on the variability of some raw material which had been collected from sampled consignments over two years. Several different characteristics of the material had been measured. An autocode program was wntten to analyse each characteristic separately, prmting sample means, ranges, standard dev~ations, and compiling frequency distributions of means and standard deviations. A hierarchic analysis of variance was also given at the end of each characteristic. We were asked to undertake this work on 29 March and the calculations were substantially completed on 12 Aprll. Further calculations and a correlation between two characteristics were made on 3 June and 5 October 1960. Here I would like to stress that although the program was written in autocode, which is normally advocated for one-off jobs, the program is a general one. The progress of the calculations is controlled by ten parameters and the print routine by seven more. Thus one program served for the analysis of all the different characteristics, including some that involved preliminary arithmetic on pairs of observations. The correlation program was written separately but took only two hours to write, using pairs of exlsting data tapes fed in on the two tape readers simultaneously. Extract: Scientific Autocodes Scientific Autocodes The list appended covers a wide range of programs. compilers, autocodes. Among the autocodes which can be taught in a few days and which are already fully operational are : Mercury autocode. Pegasus/Sirius autocode. Ferranti Matrix Interpretive Scheme. Deuce Alphacode. IBM Fortran. Edsac 2 Autocode. Stantec Zebra Simple Code. Elliott 803 autocode. Elliott and other systems based on ALGOL Extract: The Pegasus Autocode The Pegasus Autocode (also available for Sirius). Ferranti computers use teleprinters which include a limited number of mathematical symbols in the character set. Hence the Pegasus Autocode comes easily to mathematicians: again one looks at the machine as a number of registers, some holding integers with exact counting and others holding floating-point numbers accurate to seven or eight significant decimal digits. This autocode can also be used on Sirius or Mercury; on Sirius, a machine code program tape may quickly be compiled for future use Extract: Commercial Autocodes Commercial Autocodes Those concerned with Commercial Data Processing should have a look at: ICT Rapidwrite-Cobol. Ferranti Nebula. Cleo & Gypsy when available. These may take a couple of weeks to study, because, speaking from experience with Nebula, there are not only procedure descriptions but also file outlines and specifications of format of data and results when dealing with computers having considerable ancillary equipment. The Scientific Autocodes are usually concerned with one medium of inputloutput only, punched tape or punched-cards. Programming a data processing operation in a Commercial Autocode like Nebula becomes a full-time job; but it is easier to train staff in Nebula than a machine code and the autocode compiler will (we hope) take care of housekeeping routines when opening and closing files. We are using young men and women of O level mathematics, who have had experience of controlling our punched card routines, for this work. in The Computer Bulletin March 1962 view details An extended autocode for Pegasus W Barrett and AJ Mitchell University Electronic Computing Laboratory, Leeds, UK An account is given of a program written for a Pegasus computer which will accept instructions, written in a language based on Pegasus Autocode, but which may include general algebraic expressions. A number of other features have been included in the new program; in particular, means are provided whereby the user can readily add new functions and other facilities. External link: Online copy Abstract: An account is given of a program written for a Pegasus computer which will accept instructions, written in a language based on Pegasus Autocode, but which may include general algebraic expressions. A number of other features have been included in the new program; in particular, means are provided whereby the user can readily add new functions and other facilities. Extract: Introduction 1. Introduction At the Leeds University Computing Laboratory, which is equipped with a Ferranti Pegasus computer, the Pegasus Autocode, as described by Clarke and Felton (1959), has been found invaluable by many users having comparatively small problems to present to the computer. Used with discretion, it can reduce not only the time required to write programs, but also the total computer time needed, since development time is much reduced. Since Pegasus Autocode was written, various new features were incorporated into the University's computer, of which this program did not take full advantage. Late in I960, it was therefore decided to embark on the preparation of a new program, now known as Extended Autocode; this should accept any program written for Pegasus Autocode, but should have substantial additions, which it was hoped would still further simplify the preparation and development of users' programs. Some gain in speed of execution of programs was also sought. Although the language in which programs are presented to Extended Autocode is basically that of Pegasus Autocode, the Extended Autocode itself is an entirely new program having nothing in common with Pegasus Autocode except for some programming techniques used in evaluating certain functions. Section 2 of this paper contains a brief account of certain features of Pegasus, additional to those outlined in Clarke and Felton (1959), a knowledge of which is assumed in the following Sections. These latter contain an account of the additional facilities incorporated in Extended Autocode as they affect the user, followed by a general description of the organization of Extended Autocode, and an account of the algebraic compiling routine. Extract: The Extended Autocode language The Extended Autocode language The principal addition made to the original Pegasus Autocode language in writing Extended Autocode is that certain types of instruction may contain "general arithmetical expressions." These are merely extended expressions involving any number of variables, indices or explicit numbers, function titles, and symbols representing arithmetic operations, combined with brackets so as to be meaningful with the normal conventions; functions may have up to six arguments, and both variables and indices may appear in the same expression. Further extensions allow the use of repeated indices in suffices of variables and integers, and in specifying labels in jump instructions. Some examples of valid instructions follow: v n\ = 1 -0 + 01 X SIN (- v(n\ — 1 + w3) + v(-n2 + 4))) 0(3 + /i2) = ( v(n\ + 7) - n(/il - n2 + 7))/roi3 PRINT SQRT (v2 X (nl + 5) - vl\ 3045 ----> (nl + n1\ 2-45 X EXP vlQQ + vlQl > 0. Other extensions incorporated in Extended Autocode do not affect the structure of the language, but provide additional facilities. Firstly, indices are stored as full-length integers, whose value may range between —238 and 238 — 1, so that full-length integer arithmetic may be carried out. The possibility of indexing integers, as already explained, is of value in this connection. Secondly, a system of error printing has been introduced. If an error is detected either during input of instructions or of data, or during execution of a program, a message is printed and the computer stops. A typical message, which includes the number of the label next preceding the instruction in which the error occurs: ERROR. SQRT ARG NEG AFTER 3) will illustrate the scope of this facility; it is then possible to re-enter the program at a given labelled instruction. Thirdly, a directive DEFINE has been introduced to assist users who wish to have available new functions, additional to those appearing in the standard list. It is merely necessary (i) to head the autocode program with the word DEFINE, followed by the name of the function and other necessary information; (ii) to provide a subroutine tape, punched in ordinary machine language, of a program for the evaluation of the function. Several such sequences may head one program if desired. This directive was in fact used to add all functions and directives, except DEFINE itself. The standard list of directives and functions now greatly exceeds those available in Pegasus Autocode, there being over 80 such titles. One of these, which may be specially mentioned, is the directive SET, which enables the normal allocation of storage space for indices, variables, labels and compiled program to be changed. Extract: The organization of Extended Autocode The organization of Extended Autocode When an autocode program is presented to the computer, an input routine reads the instructions and compiles a stored program; this is subsequently interpreted by an executive routine. To this extent, Extended Autocode follows the same pattern as the original Pegasus Autocode, but there are important differences of organization, of which an account follows. (a) In Pegasus Autocode, both the input and executive routines are in the main store of the computer simultaneously, and indeed certain sections are common to both. In Extended Autocode, on the other hand, the input and executive routines are quite independent of one another; the latter is not in fact transferred from magnetic tape to the main store until input of the autocode program is complete. Although the input routine is much more extensive, the whole of the space it occupies is thus made available for other purposes during execution of a program. It is normally allocated to the storage of numbers, with the result that all indices, and the first 56 variables, are in the intermediate access * The phrase "autocode program" will be used to denote a program of instructions written in the Extended Autocode language. store, making a significant contribution to the speed of execution. (b) The dictionary is treated as a single list, in lexicographical order, of titles of all kinds, whereas, in Pegasus Autocode, the dictionary is divided into three independent sections, each corresponding to a particular mode of occurrence in the autocode program, and each in arbitrary order. The use of a single list simplifies the addition of new titles, while the adoption of lexicographical order enables the dictionary to be searched by a binary-chopping technique, which is much faster than a single-word search. (c) The form of the compiled program is entirely different from that used in Pegasus Autocode, since this latter system, in which the basic unit of storage is a block of eight words, is not sufficiently flexible for the efficient storage of groups of instructions representing general algebraic expressions, or indeed, the more general system of indices allowed in the Extended Autocode language. In Extended Autocode, the consecutive words of the compiled program are interpreted one by one by the executive routine, and are of three types: (i) a positive word, causing a transfer of information to or from the main store; (ii) a negative word, treated as a pair of machine instructions and obeyed; it may either carry out some operation required in the execution of the program, or serve as a cue to a subroutine of the executive routine; (iii) any word will be treated as a number, an operand of some operation, if immediately preceded by a special word of type (ii). This latter word may be thought of as analogous to a warning character; it is necessary since the word representing a number may take an arbitrary value. (d) When input of an autocode program is complete, Initial Orders are called in to read, from a special library on magnetic tape, known as Autolib, a basic executive routine, followed by subroutines for the evaluation of any functions which appear in the particular program. The standard Initial Orders Assembly facilities are used to reject any subroutines not required, and also to insert the necessary cues to the accepted subroutines into the compiled program. When this process is complete (i) the space reserved for labels, (ii) the compiled program, (iii) the executive routine, (iv) subroutines for evaluation of functions, together occupy one continuous zone of the main store. A consequence of this system is that the space required for any particular program is reduced to a minimum, and that additions to Autolib do not affect the storage requirements of existing Autocode programs. Further amendments can be made to one subroutine without disturbing the others; for example, additional printing styles have recently been added, which permit the replacement of "+" by "space." in The Computer Journal 6(3) October 1963 view details General Information Pegasus and Sirius are the names of computers made by Ferranti Ltd., of Manchester. Pegasus is a medium-sized, medium-speed machine with a magnetic drum store of 8192* words capacity, working in fixed-point binary arithmetic, with a word length of 39 binary digits which corresponds to 11 decimal places. Sirius is a more compact machine, working in decimal. The store is normally 4000 words but is extendable to a theoretical maximum of 10000 words, a word holding 10 decimal digits. Both machines use paper tape as their input and output media, using the code given in the Appendix. The autocodes used for the two machines are practically identical and everything in this chapter applies to both unless otherwise stated. in The Computer Journal 6(3) October 1963 view details in ACM Computing Reviews 5(02) March-April 1964 view details The preface states that "this book is intended to serve as an introduction to the programming of automatic computers." The first 24 pages present such an introduction, apparently assuming that this is the reader's first contact with a stored-program digital Computer. Part II, which makes up about 60 percent of this short volume, consists of three chapters, each of which describes a different autocode. The word "autocode" as used in England corresponds roughly to "compiler language') in the United States. The authors apparently consider an autocode to be machine-dependent, in contrast to a "universal computing language" like Algol, which is machine independent. The three autocodes discussed are for the Pegasus-Sirius, the Elliott 803, and the Ferranti Mercury. The machines themselves are not described here in any detail. They are all rather small machines, and are not of very great general interest. Unfortunately, the Same is true of their autocodes. The Mercury autocode is treated at greatest length and in greatest detail. It is an interesting system, but its interest is now mostly historical, illustrating some of the early work of Brooker and his colleagues at Manchester. Most of the material in this book will be of interest only to the devoted specialist and perhaps to the historian in the field of computer languages. A final section of the book presents a 14-page discussion of Algol. It is a good but very brief resume of the language. in ACM Computing Reviews 5(02) March-April 1964 view details Pegasus In 1953 W. S. Elliott left the Computer Division of Elliott Brothers to join Ferranti. He led a team that designed a medium-sized computer using packaged circuit techniques (the same packaged circuits originally developed under NRDC contract for the Elliott 401). In this machine, sold as Pegasus from 1956, Ferranti applied the lessons learned on the earlier Mark I and Mark I* computers to produce a more marketable and serviceable machine (Berners-Lee 1969). Through the auspices of NRDC, Ferranti secured the services of C. Strachey, who was largely responsible for the system design of Pegasus, and he deftly bridged the gap between engineer and programmer. Many novel and elegant features make the Pegasus a machine especially worthy of study (for example, see Braunholtz 1959). The prototype Pegasus was developed in premises acquired in Portland Place, London, which subsequently became the Ferranti London Computer Centre. Parallel with developing the prototype, a programming group was established in 1954 with G. E. Felton as manager. Felton reported directly to Swann, the Ferranti computer sales manager, for once again software was seen as part of the sales function. Strachey took a leading part in developing the "initial orders" for Pegasus; this input routine was very elegant and outshone any contemporary British effort. The initial orders consisted of about 1000 instructions, an unprecedentedly large input routine for its day in Britain. The input routine contained many interesting features, perhaps the most innovative of which was subroutine assembly. Incorporating subroutine assembly into the Pegasus input routine doubtless originated from Wilkes's assembly subroutines for the EDSAC (see Campbell-Kelly 1980a). The programmer could call a library subroutine simply by supplying a "tag" that gave the library number of the routine and any parameters. When the user's program was input, the initial orders scanned the library (paper) tape for the required routines, relocated and parameterized them, and made the necessary linkage. The library search was a particularly nice feature, since it saved the tedious and error-prone task of assembling the program from individual paper tapes as had to be done on other machines. A comprehensive subroutine library was developed by Felton and his team. Altogether, more than 100 subroutines were produced in the first year or so of Pegasus's operation. Ferranti produced handsomely printed and bound library specifications, which were distributed by the Pegasus Library Service. When Felton had settled in at Ferranti and the subroutine library was under way, the first major programming project he gave his attention to was a matrix interpretive scheme. This was clearly a high priority, for Pegasus was competing directly with DEUCE for the lucrative aircraft industry market; furthermore, the first order for a Pegasus had already been placed by the Hawker Aircraft Company. The matrix scheme (Hunt 1956) was in intensive use from early 1956; it had an elegant notation by Felton and a respectable performance - although it was only half as good as that of the optimum-coded DEUCE. Once the matrix scheme was under way in 1955, Felton turned his attention to an autocode for the Pegasus (Clarke and Felton 1959). He had been much impressed by Brooker's work on the Mark I Autocode at Manchester, and he designed the Pegasus Autocode along similar lines. (Incidentally, Felton was quite unaware of any contemporary American developments at this time.) The Computing Machine Laboratory staff at Manchester University consulted freely on the project and advised on overcoming the problems of the two-level store (Brooker 1977). The autocode was released in the summer of 1953 and was an immediate success both with users and in Ferranti's own computing service, where it was used for small and one-time jobs. In retrospect, Felton recaps that the most significant feature of the programming activity for the Pegasus was that they produced "...a commercial product which could be run to solve industrial problems at a large number of installations. This was a very different thing from the other, more academic exercises" Not the least part of achieving this was rigorous testing, which ensured a high degree of reliability for all the Pegasus library routines. The development of programming systems for Pegasus can be summarized as follows. Largely as a result of its experience with the Mark I and Strachey's influence, Ferranti recognized the need to supply software along with the hardware -- if only as a sales inducement. The programming department set up to produce the software was a small, intimate affair by later standards, but it was recognizably the same animal as the software-development department of any present-day computer manufacturer. Pegasus software was of outstanding quality and well suited to the user. Pegasus opened up a new era in the provision of high-quality programming systems by manufacturers of computers in Britain, and it marks the turning point from a situation of laissez-faire to one of strong involvement. This point of transition makes the Pegasus an especially appropriate machine with which to conclude this discussion of early programming systems. Extract: Conclusions Conclusions When we compare the development of programming at the three centers -- Cambridge, Manchester, and Teddington -- there are several factors to consider. First, we must consider the quality of the programming system; this is a subjective issue that ranges from the purely aesthetic to the severely practical -- for example, from the elegance of an implementation at one extreme to the speed of a matrix inversion at the other. We must also consider the failures of the three centers, especially the failure to devise a programming system that exploited the full potential of the hardware. Finally, we must consider the influence of the programming systems on other groups; this is less subjective -- it was described in the previous two sections and is summarized in Figure 2. Few could argue that Cambridge devised the best of the early programming systems. The work done by Wilkes and Wheeler stood out as a model of programming excellence. Cambridge made several outstanding contributions to early programming: the use of closed subroutines and parameters, the systematic organization of a subroutine library, interpretive routines, and the development of debugging routines. Perhaps the finest innovation was the use of a symbolic notation for programming, as opposed to the use of octal or some variant. It is difficult for us today to appreciate the originality of this concept. If Cambridge can be said to have had a failure, it was the failure to develop programming languages and autocodes during the middle and late 1950s, as reflected in the second edition of Wilkes, Wheeler, and Gill (1957), of which Hamming said in a review, It is perhaps inevitable that the second edition, though thoroughly revised, does not represent an equally great step forward, but it is actually disappointing to find that they are no longer at the forefront of theoretical coding. (Hamming 1958)] By neglecting research into programming languages, Cambridge forfeited its preeminence in the programming field. In the early 1950s, however, Cambridge was by far the most important influence on programming in Britain. This came about partly through the excellence of the programming system and partly through the efforts that Cambridge made to promote its ideas. Two machines (I`EO and TREAC) based their programming system directly on EDSAC, and five machines (Nicholas, the Elliott 401 and 402, MOSAIC, and Pegasus) were strongly influenced by it. It is also probably true that no programming group was entirely uninfluenced by the Cambridge work. Overseas, the influence of the EDSAC programming system was just as great, largely through the classic programming textbook by Wilkes, Wheeler, and Gill (1951) (see Campbell-Kelly 1980a). At Manchester the programming system devised by Turing for the Mark I makes a disappointing contrast with the elegance of the Cambridge work. From the point of view of notation, it is difficult to find a single redeeming feature. Probably the only feature of real merit was the concept of dividing a program into physical and logical pages. Echoes of this idea can be discerned in today's segmented computers. In its way, Turing's programming system did have considerable influence, for all efforts to replace it with something more suitable were curiously unsuccessful. Thus programmers for both Mark Is and all seven Mark Iota's had to struggle with Turing's clumsy teleprinter notation throughout the life of these machines. Here is perhaps one of the most valuable lessons of this study: poor design decisions taken early on are almost impossible to correct later. Thus even when people with a Cambridge background arrived at Manchester, they were unable to make a really fresh start. By producing two successive input routines that were not much better than Turing's, they managed to combine the worst of both worlds: an unsatisfactory programming system that was not even a stable one. The one real high spot of the Manchester programming activity was Brooker's Mark I Autocode. Brooker's achievement was the most important programming event of the mid-1950s in Britain. If Brooker had not devised his autocode at that time, programming in Britain might have developed very differently. The autocodes for DEUCE and Pegasus were directly inspired by Brooker's and had considerable notational similarities with it. Beyond the time scale of this paper, Brooker's Mark I Autocode and his later Mercury Autocode (1958) were a dominant influence on British programming until well into the 1960s, when languages such as ALGOL 60 and FORTRAN came onto the scene in Britain. Of the three programming systems devised at Cambridge, Manchester, and Teddington, it is probably the latter that inspires the least passion. Ii the punching of programs in pure binary was an efficient method, it was also a singularly uninspiring one. Curiously, aficionados of the Pilot ACE and the DEUCE had great enthusiasm for programming these machines, which really had more to do with the joys of optimum coding and exploiting the eccentric architecture than with any merits of the programming system. In many ways the crudity of the programming system for the Pilot ACE was understandable: the speed of events, the lack of a backing store, and so on. But perpetuating it on the DEUCE was a minor tragedy; by replicating the programming system on the 32 commercially manufactured DEUCES, literally hundreds of rank-and-file programmers were imbued in this poor style of programming. MOSAIC (Section 3.4) shows that it was entirely possible to devise a satisfactory programming system for machines of the ACE pattern; it is most unfortunate that this work was not well enough known to influence events. NPL did, however, have one notable programming-success: the GIP matrix scheme devised by Woodger and Munday. This scheme became the sole reason for the existence of many DEUCES. The reliability of the mathematical programs produced by NPL, their comprehensiveness, and their speed have become almost legendary. A history of numerical methods in Britain would no doubt reveal the true role of NPL in establishing the methods of linear algebra as an analytical tool for the engineer. In an interview, P. M. Woodward, one of the principals of the TREAC programming activity, recalled, "Our impression was that Cambridge mattered in software whereas Manchester mattered in hardware" (Woodward and Jenkins 1977). He might well have added that NPL mattered in numerical methods. Because this paper has been primarily concerned with the development of programming during the period 1945-1955, Cambridge has received pride of place as the leading innovator. Had the paper been concerned principally with hardware or numerical methods, however, the ranking of the three centers would have been different. But considered purely as innovators of programming, there can be no question that Cambridge stood well above the rest. Abstract: By 1950 there were three influential centers of programming in Britain where working computers had been constructed: Cambridge University (the EDSAC), Manchester University (the Mark I), and the National Physical Laboratory (the Pilot ACE). At each of these centers a distinctive style of programming evolved, largely independently of the others. This paper describes how the three schools of programming influenced programming for the other stored-program computers constructed in Britain up to the year 1955. These machines included several prototype and research computers, as well as five commercially manufactured machines. The paper concludes with a comparative assessment of the three schools of programming. in Annals of the History of Computing 4(2) April 1982 IEEE view details in Annals of the History of Computing 4(2) April 1982 IEEE view details |