GIP(ID:12/gip001)Interpretive autocode for DEUCEfor General Interpretive Programme Robinson, English Electric, 1956. An early interpreted language for the English Electric DEUCE, with array operations and an extensive library of numerical methods. Campbell-Kelly suggests GIP "establish[ed] the methods of linear algebra as an analytical tool for the engineer" Hardware:
Structures: Related languages
References: in [EEC] DEUCE News No. 10 (1956) English Electric Company view details in [EEC] DEUCE News No. 11 December 1956 English Electric Company view details in [EEC] DEUCE News No. 11 December 1956 English Electric Company view details in The Computer Journal 1(4) January 1959 view details INTRODUCTION The object of automatic programming is, of course, to reduce the effort required to write programs, and this is achieved by using, instead of ihe computer's own code of instructions, a pseudo-cork which is u«"illy closer to the programmer's habitual way of describing the operations which he wants the computer to perform. (The word 'programmer' is used here rather in the sense of'anyone wishing to write a program', than that of 'someone specially trained to write programs'.) A program having been written in a pseudo-code, there are two ways of making it produce the desired result, viz. by interpretation or by translation (or compiling, as it is often called). In the first method, each code-word is interpreted as it is reached in the course of the calculation, and many of them will therefore be interpreted in my times. Since the interpretations occupy computer-time additional 11 11 at required for the actual computation, interpretative schemes produce |> grains which are slower than those written in the machine-code, though in some applications, e.g. in G.I.P. and T.I.P. (Ref. 1), the amount of computation specified by each code-word is usually so great that the interpretation time is negligible. Another feature of pseudo-codes which tends to produce slow programs when the interpretative method is used is that they do not fully reflect the storage-structure of the computer. It is, of course, desirable that a pseudo-code should be as free as possible from this structure, since it is alien to the conventional description of calculations, etc. On the other hand, the structure is designed mainly to achieve as high a speed of operation as possible for a given overall cost of the computer, and the neglect of it must cause a reduction in speed. To satisfy both these requirements, which are incompatible in any interpretative scheme, and to avoid the repeated interpretation of codewords, we can use the computer to translate, once for all, a program written in a pseudo-code free from computer-determined structure into a fast program of computer-instructions, taking the storage-structure fully into account. The problems which are presented in the writing of a program for making such a translation are, however, far from trivial. In many interpretative schemes, some translation is also done, i.e. the original code-words are first translated into others with properties nearer to those of the machine-code, e.g. symbolic addresses may be converted to absolute computer addresses. (We, at English Electric, usually reserve the term 'compiling' for this process, for convenience, although it is not essentially different from translation, as defined in the previous paragraph.) A 'compiler', i.e. a program for doing this preliminary work, is much easier to write than a 'translater', and may save a good deal of interpretation time. Descriptions will be given of four interpretative schemes which have been prepared for DEUCE, one of which has been referred to by Mr. Robinson (Ref. 1). in each case, some compiling is done on the code-words before they are interpreted. The pseudo-code used in the first of these schemes, called George, is unusual, being in fact an extension of a notation ('reverse Polish') suggested for mathematics (Ref. 2). The second scheme, Alphacode, was inspired by the Manchester Autocode (Ref. 3), but attempts to make every code-word a statement in plain English. The third scheme, STEVE, employs a special-purpose pseudo-code, similar in form to those used by G.I.P. and T.I.P., but intended solely for calculations on the thermo-physical properties of steam and water. The fourth scheme, Easicode, is a general-purpose scheme with a form of compiled instruction giving rapid interpretation. There follows a description of an existing translating program whose pseudo-code is known as Soda. Both this and Easicode retain some of the storage structure of DEUCE, which has in some degree facilitated their writing but which makes the writing of programs in these pseudo-codes rather more difficult than in Alphacode, for example. Finally, some of the difficulties which arise in translating from a pseudo-code which is free from computer-determined structure are discussed, together with some of the techniques which are to be used in a program for translating from Alphacode to DEUCE machine-code. in Goodman, Richard (ed) "Annual Review in Automatic Programming "(1) 1960 Pergamon Press, Oxford view details INTRODUCTION Despite the organization of vast libraries of subroutines and programs, and the facilities for testing new programs, a real need has grown up for flexible and powerful schemes, capable of being used to construct new DEUCE programs in a fraction of the normal time. During the last four years a variety of such schemes has grown up for DEUCE, and the present paper and a companion paper by Mr. S. J. M. Denison, reviews some of these, and fits them into perspective. The schemes STAC, G.I.P. (General Interpretive Program), T.I.P. (Tabular Interpretive Program), Alphacode, GEORGE, SODA, Easicode, STEVE and the Alphacode Tabulator have been produced at intervals at various DEUCE establishments, to all of which credit should be given for the introduction of new ideas and exploitation of older ones. A study of the way in which most of these schemes develop ideas in the others, and contribute new techniques in itself an interesting genealogical exercise. Extract: GIP The General Interpretive Program (G.I.P.) is so general that it can beadapted to any kind of work, but it is particularly well suited to performing parallel calculations on data in bulk. For the interpretation of one G.I.P. instruction one may then get thousands of arithmetic operations performed, and the interpretive time ceases to be of importance. It is thus particularly well suited to matrix operations, and the bulk of the functions available in the library are for linear algebra. A feature of this scheme has been the number of problems which have been presented to DEUCE through G.I.P. as linear algebra problems, though not appearing so at first sight. This is perhaps not so surprising when one considers how the orderly methods of matrix operations are so similar to the orderly methods one must use to program successfully for a computer. The Tabular Interpretive Program, as will be described later, is particularly well suited to any operation which could be performed with a desk machine and a sheet of paper ruled into rows and columns, and where one normally performs like operations on all the numbers in a column and writes the answers in a new column. It is therefore rather like G.I.P. restricted to vector operations. Alphacode caters for the extreme case where the bulk of the operations in a program are on one variable at a time, that is problems in which parallel calculations are not required on a number of variables. In this way the three schemes are mutually complementary in that they each show up to best advantage on different types of problem. Another point of interest is the unique feature of G.I.P. in that it has a variable order code in the form of a library of functions which can be used with it. In all three schemes the instruction store is quite separate from the data store, which does not, however, prohibit instruction modification. The number of instructions permissible with each of these schemes appears small at first sight, but they represent sizable programs bearing in mind that the individual orders are so comprehensive. [...] In some respects, the Tabular Interpretive Program may be regarded as a rather special case of the General Interpretive Program, which was developed at the National Physical Laboratory four years ago, and which has proved invaluable at most DEUCE installations. The form of the instruction word—a, b, c, r for T.I.P. was taken from G.I.P.. which does not, however, have a limited range of functions r. Self-contained programs (which may, incidentally, be used independent of G.I.P.) which satisfy a few simple rules are called bricks, and any brick may be used as a function for the purposes of this scheme. There are at present almost 200 bricks in the library and not more than 63 may be used in one program. The scope and flexibility of the scheme is therefore enormous, and this explains why so many DEUCE installations have used G.I.P. for more than half of their work. G.I.P. is a program pack which performs the following operations: (i) It reads itself into tracks 235 to 255 of the drum. (ii) It reads in a parameter card saying how many bricks are being used in the current program. iii) It reads in the appropriate number of bricks, storing them from track 234 (in decreasing track number order). As il reads and stores these bricks, it notes where it has stored each one, so that it can subsequently bring it into the high speed store and obey it. It also makes a note of the first instruction in the brick. (iv) The G.I.P. program is then read in. This consists of a sequence of 'a, b, c, r' codewords, where r refers to the rth brick in the sequence just read in, and a, b, and c are parameters to be provided to that brick; a, b and c are usually drum addresses, in which case they should be small enough not to interfere with the bricks which are stored at the higher numbered tracks, (v) G.I.P. then obeys the various codewords, starting with the first and taking them in turn, except for jumps and discriminations. Seventeen values of r are set aside for jump, discrimination, modification and housekeeping instructions, so that the order code is quite flexible. For such values of r, the numbers a, b and c in the corresponding codewords usually refer to codeword numbers— this also being a feature of T.I.P. Discriminations thus take the form 'jump to codeword number b if the contents of codeword a are zero, otherwise jump to codeword number c\ Such a codeword implies that one codeword (in this case, number a) is being used as a counter rather than as a codeword to be obeyed. There are a variety of discriminations provided, as well as an unconditional jump. Others among these special values of r cater for automatic instruction modification (modify a, b or c automatically after the codeword has been obeyed), and provide facilities for reading in new bricks and either writing them over bricks already in store and which are no longer needed, or obeying them directly in the high speed store. The latter facility is particularly helpful when one is embarrassed for drum storage space and there are one or more bricks which are obeyed only once in a program. These may as well be read and obeyed directly, once and for all, and so save the storage space which they would otherwise need on the drum. To use G.I.P., therefore, a programmer does not have to possess any detailed knowledge of DEUCE programming, providing he can achieve his object by using existing bricks. He decides what bricks are required for a particular job, and having made the program of codewords, the operator then provides DEUCE with G.I.P., followed by the various bricks, followed by the codewords. The programmer will have had to count up how many of the 256 tracks on the drum will be needed In G.I.P. (which accounts for 21) and all the bricks he needs for his particular operation. The remaining tracks, which are always the lowest track numbers, are available for his data, and it will be necessary to know how the various bricks being used expect to find and store their data. Since virtually all bricks are built to accept and store data in a standard manner, the programmer's problem is to apportion the data tracks correctly. There are, nevertheless, features which a DEUCE programmer may use, since any codeword, as an alternative to the standard a, b, c, r form, may be replaced by a normal DEUCE instruction. The interpretive program will detect such an instruction (by the presence of a digit normally spare), and obey it as required. For instance, when one needs to read a single number into the machine, it might be easier to use the DEUCE instruction facility rather than to call a brick to perform such a trivial operation. The program provides generous testing facilities in the way expected of a conventional machine-order code. There is the equivalent of a 'stop key' which, when on, will cause the machine to stop on every G.I.P. instruction, and display it on lights before it is obeyed. Similarly, one can force G.I.P. to stop on a specific instruction on the keys—this facility being useful when an instruction is being examined each time it is obeyed in a loop. There are also convenient facilities for making the machine accept an instruction to replace that which it is about to obey, and to restore control or take a post-mortem in the case of a brick not behaving as expected. The majority of the bricks available for use with G.I.P. are for linear algebra operations, and as a result there has arisen a widespread belief that the scheme is restricted to matrix operations. This is not so, although the scheme has been used extensively for linear algebra and, in fact, many problems which do not, at first sight, appear to be linear algebra problems, have been solved using standard matrix bricks. In the early days, the majority of problems arising came from the aircraft industry and were presented as linear algebra operations. The standard operation to calculate Au — AlzA22~lAia' given Au, A22 and A12 uses bricks to read, invert, multiply, transpose, subtract and punch out matrices, and the complete G.I.P. instructions for performing this operation are as shown on p. 113. This program will solve the problem for Azz of order less than or equal to 31 by 31 and for An less than or equal to 41 by 31. It uses 12 bricks, for the multiplication brick has three sections and counts threefold, and the inversion brick counts fivefold. The bricks used are No. of Tracks1, 2, 3 Matrix Mult 16 4, 5 Subtract 9 6 Punch Matrix 3 7 Read Matrix 3 8, 9, 10, 11, 12 5 sections to invert the matrix 18 Total: 48 tracks. The 48 tracks of bricks (and 21 tracks for G.I.P. itself) leaves 187 tracks on the drum for the data, and the selection of the a, b and c values in the above program have been chosen so as to make the best use of this available space. It will be noted that no reference is made at all to the size of the matrices. The scheme is so arranged that the dimensions of matrices are stored with the matrices themselves, and all bricks check for compatibility, in this way the programmer merely has to specity the hrst of the (consecutive) drum tracks on which the matrix is stored. A consequence of this is that if a G.I.P. program is made to cope with a given maximum size of matrices (the restriction being storage space on the drum) then the same program, without any alteration, may be used for any matrices whose size does not exceed the given maximum. In nearly all bricks the numbers are stored in block-floating form, that is with all elements to the same number of binary places, and with the largest element shifted up to fill the storage register. This method successfully combines the speed and storage economy of fixed-point working with tin-flexibility and accuracy of floating-point operation. More recently G.I.P. has been used for a wide range of other problems, not so obviously presented as linear algebra. This has been facilitated by the ease with which a G.I.P. program can be constructed, and by the fad that even if all the required bricks do not exist, most will be available, and one or two special purpose bricks can be used. For instance, much statistical work is done on DEUCE by using G.I.P.—particularly in conjunction with a few special purpose statistical bricks. The Simplex and Transportation programs also use G.I.P.—again with a few special bricks written for these purposes. Since each function being carried out under the control of G.I.P., may be a complete DEUCE program in itself, which will be obeyed at optimum speed and which may be operating on a large amount of data, the time spent in interpreting the codeword and fetching the brick may not be a significant amount. In fact, it is about half a second. G.I.P. therefore shows up to its best advantage when it is required to operate upon large quantities of data in parallel, as typified by sizeable matrix operations. It is least efficient whenever the operations are trivial or only affect a small amount of data. It is to cope adequately with calculations on small amounts of data that T.I.P. and Alphacode were developed. Particular features of standard bricks are the elaborate checks on arithmetic accuracy and the reliability of the operator or programmer. This standard of checking was set with the first batch of bricks, and has been followed by later programs. All matrices stored on the magnetic drum have the grand sum of all the elements stored with them and, whenever any bricks makes reference to the matrix, the grand sum is checked. This is important, not so much as an arithmetical check, but as a check that the programmer has not unwittingly overwritten the 'tail end' of a matrix (which will in general be stored on a series of consecutive tracks). Similarly checks on the compatibility of matrices in, for instance, addition or multiplication arc incorporated, and such checks have proved themselves very worth while—particularly in complicated operations where a programmer may mistake the dimensions of his matrices. G.I.P. is therefore an ideal scheme for all calculations needing bulk calculations in parallel on relatively large amounts of data 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 DEUCE The English Electric DEUCE grew out of an active collaboration between English Electric and NPL. The DEUCE was based closely on the Pilot ACE (Haley i956). The initial software effort for the DEUCE lay in converting the existing Pilot ACE programs developed by NPL. Most of this work was done during 1955 in a combined effort between the users of the first three DEUCES, which were installed at English Electric, NPL, and the Royal Aircraft Establishment. This conversion work was in fact coordinated by NPL; it seems that in the mid-1950s English Electric did not see the provision of programming systems as part of their brief, although they did organize the DEUCE Users Group and a library service. Several active programming groups were associated with DEUCE installations, and by 1958 three important interpretive schemes for the DEUCE had emerged: GIP, TIP, and Alphacode (Robinson 1959). These three schemes had complementary domains of application: GIP was, of course, the famous matrix interpretive scheme from NPL, TIP was used for calculations on vectors, and Alphacode was used for scalars. The GIP matrix scheme was easily the most important programming system for DEUCE. Apart from its remarkably high speed, CIP was noted for its reliability. By means of check sums and other devices, complete confidence could be had in the results in spite of the inherent unreliability of the DEUCE (which had no parity checking, for example). The TIP (Tabular Interpretive Program) scheme was in effect a variant of GIP restricted to vector operations. The system was designed by the DEUCE group at Bristol Aero Engines to simplify programming for engineers and was widely used. TIP was a rather elegant system and required no formal understanding of linear algebra. It was intended to be accessible to anyone who was familiar with a "desk machine ... and a sheet of paper ruled into rows and columns" (Robinson 1959). TIP is an interesting relic of the transition from machine language to true programming languages. The third interpretive scheme, Alphacode, was specified by S. J. M. Denison of English Electric as an automatic coding system for naive users and for one-time jobs; Alphacode was directly inspired by the Manchester Mark I Autocode (Denison 1959). The interpreter produced programs that were typically about five times slower than conventionally coded programs, actually a considerable achievement considering the high speed of DEUCE when optimally coded. In November 1957 a project for an Alphacode translator (as opposed to the existing interpreter) was begun (Duncan and Huxtable 1961). The aim was the exceedingly ambitious one of producing translated programs as good as hand-coded ones. The translator was developed by F. G. Duncan, working at first with E. N. Hawkins and later with D. R. Huxtable. The system came into use toward the end of 1959. It was one of the most impressive programming achievements of its day, both in terms of sheer size (22,000 instructions) and in the difficulty of producing code for a machine with a multilevel store. The translator in practice produced code that was about two-thirds as good as handwritten code, a truly remarkable achievement given the complexity and subtlety of programming for the DEUCE. Several other programming schemes were produced for the DEUCE by other installations in the late 1950s. These included STAC, STEVE, GEORGE, SODA, and EASICODE (Robinson 1959). AH these systems were made available through the Users Group, but they do not appear to have been used as widely as the schemes already described. The development of software for DEUCE can be summarized as follows. The existence of a large amount of high-quality software from NPL led English Electric into believing that it was unnecessary to develop further programming systems. English Electric did see the need to coordinate and distribute programs through the Users Group and to organize programming courses. English Electric's failure to make a timely provision of an autorpatic programming system for DEUCE led to a number of ad hoc developments at various DEUCE installations during the period 1957-1959, which was a wasteful duplication of effort. In underwriting the Alphacode translator, however, English Electric demonstrated that it had at last come to recognize its duty to provide programming systems for the DEUCE. In January 1960 English Electric transferred its programming staff to the Data Processing and Control Systems Division at Kidsgrove, where an automatic programming section was established under the management of F. G. Duncan (1979). At this point, machines such as the KDF 9, for which excellent software was produced, were on the horizon. Extract: Importance of GIP 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. 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 |