SODA(ID:34/sod001)Symbolic Optimum DEUCE AssemblySymbolic Optimum DEUCE Assembly Program. Symbolic assembler for a one-level storage virtual machine for the English ELectric DEUCE. Written by Gordon Bell who later played an important role in DEC, while on a Fulbright fellowship to Australia. Hardware:
Related languages
References: This paper deals generally with translation and interpretive schemes, and specifically with a suitable translation routing for use with the DEUCE computer. The translation program is called SODA, or Symbolic Optimum Deuce Assembly Program. Two examples of SODA use are included in the appendix. External link: Online copy Extract: Introduction to the Problem Introduction to the Problem DEUCE is a two-plus-one-address computer having twelve 32-word mercury delay lines of rapid-access storage, and an 8,192-word magnetic drum backing store (see Haley, 1956). It has proved to be a powerful tool for both scientific and commercial applications, and its usefulness is greatly increased by a large library of subroutines and programs. The cost of the machine places it in the medium-scale computer class, but the speed of operation is comparable to machines in the large-scale class. Certain aspects of programming DEUCE, however, are clerical in nature, and can be somewhat tedious; such programming work might well be left to the machine itself. The object of the work leading to this paper has been the development of a programming scheme which makes the writing down of a program much simpler and more straightforward than normal DEUCE programming. This is because the SODA language is closer to that of a mathematical language, and includes strong mnemonic aids. Any sort of intermediate routine which eases the programmer's work is especially of value in an academic environment. Universities tend to have a great number of problems which necessitate the use of a computer, but do not have the necessary programming staff to write the programs. A system such as SODA enables people who are familiar with a problem, and who are not familiar with computers, to write their own programs with relatively little external assistance. The basic difficulties in preparing a program for any machine can be minimized by the use of either interpretive or translation routines. Almost all computers in use today have routines of this nature available simply for the ease, efficiency, and convenience of the user. Even though these "intermediate" routines generally require more machine time, the aid they give the programmer (particularly a novice) makes them highly desirable from an economic point of view. Extract: Interpretive and Translation Routines Interpretive and Translation Routines Any intermediate automatic coding program for a computer may be broken down into either a translation or an interpretive routine. There are routines which combine the advantages of both translation and interpretive routines to give optimum results in terms of machine efficiency and programming effort. For example, some routines, in order to minimize programming time, require that a pseudo program be run through a translator, an interpreter, and then an optimizing program (in the case of computers with only a drum or delay-line store), before giving a coded program in machine language, suitable for the actual solution of the problem. An interpretive routine is a program which, when given an order (which is called a pseudo order) in a simplified language, calls in (i.e. transfers control to) an appropriate subsequence, stored elsewhere in the machine, to carry out that step in the calculation. After completion of the subsequence, control returns to the interpretation of the next pseudo instruction. An interpretive routine most useful for the DEUCE machine is called the General Interpretive Program (GIF). GIF, designed for handling almost any matrix manipulation, also enables the programmer to operate on large blocks of data in a prescribed sequence. Another similar but less elaborate interpretive routine for the DEUCE is the Tabular Interpretive Program (TIP). Still another interpretive program is called Alphacode; this is an alpha-numeric system which transforms the computer into a three-address machine which has indexing facilities and works entirely in floating-point arithmetic. These three routines were described by Robinson (1959). When using a translation routine, the program is first written down in terms of the pseudo orders of the translator's vocabulary, which is similar to that of an interpretive routine. These pseudo orders, however, are then fed into the translator, which produces an output program in terms of standard machine orders. It is this program, in the standard computer language, which effects the problem solution. The interpretation of the pseudo orders thus occurs only once. Since interpretation usually consumes considerable machine time, a translation scheme is of most advantage with often-used programs. It is believed that SODA is the first translation scheme prepared for DEUCE. Extract: Introduction to the New Pseudo Language—SODA Introduction to the New Pseudo Language—SODA The purpose of SODA is to make the writing down of instructions for DEUCE easier. In doing this, certain physical features of DEUCE, which may make programming somewhat tedious in the DEUCE language, have to be overcome. These problems are, in general, those that face the writer of a translation routine for a computer which has a limited amount of non-random-access storage, and another larger level of backing storage. Eight of DEUCE's twelve mercury delay-lines are connected to the control unit of the machine so that only these eight can contain the program. For programs larger than 8 X 32 instructions, more program must be brought into delay lines from the magnetic drum at the proper time. The drum contains 256 32-word tracks numbered 0 to 255. SODA makes it possible for the programmer to assume that almost the entire drum is a random-access store that handles both data and program. Since either data or program is automatically brought into delay lines only when needed, this means that SODA defines a machine with only one level of storage. When programming in the DEUCE language, the programmer usually aims at coding the program within the delay lines in an optimum manner such that the next instruction word is available at the same time that the previous order is completed. Very poor coding can result in an increase in the running time of up to several times that of an optimally coded program. SODA writes orders in terms of DEUCE instructions, and optimization is automatically done in every group of delay lines of instructions. Up to 192 DEUCE instructions, optimally coded within every set of two delay lines, may be in any group, but the programmer is not faced with the size of groups, or when and where each begins, as the transfer from one group to the next is carried out automatically. All necessary subroutines are also placed in the mercury store when a new group, or block, of instructions is brought from the drum. The new information is transferred one delay line immediately following another, a process requiring at least 13 milliseconds per delay line. It is possible that a repetitive loop in the SODA program could result in the transfer of two or more blocks of DEUCE instructions to the fast store each cycle, thereby greatly reducing the efficiency of the translated program. The more experienced SODA programmer can compensate for this to a certain extent by placing what is known as a "LOOP" control card before repetitive portions of the SODA program. Associated with each SODA operation are a specified number of DEUCE instructions. The programmer can sum the numbers associated with the SODA instructions in the loop and include the sum as a parameter of the control card. If possible, the translation process will then place the loop within a single group of DEUCE instructions. Thus, in Example 1 of Appendix 2, instructions 11-14 comprise a repetitive loop which one would desire to have as fast as possible. Therefore, a "LOOP" control card might well be inserted between instructions 10 and 11. Each DEUCE instruction must include six numbers which specify various addresses and clock times of the computer. This detail, which is attributable to the logical layout of the DEUCE hardware and insures optimum coding, discourages people who do not have time to learn the process. SODA alleviates the problem by defining a more conventional computer with less hardware; the book-keeping details of programming are therefore lessened. Another factor to which a novice must become acclimatized is that the DEUCE machine operates in binary arithmetic. There are a host of subroutines available for decimal input and output, but the details of using them are a bit involved for the inexperienced user. Although SODA operates internally either in binary or standard floating-binary form, there are pseudo instructions available which permit either binary, decimal, or floating-decimal input and output. SODA is a one-plus-onc-address "machine," recognizing either numeric or mnemonic orders which bear no resemblance to the DEUCE instruction format, and whose addresses may be written with symbolic names. It is therefore the purpose of SODA to translate to DEUCE language from a language more easily understood by the occasional user who has not had previous computer experience, that is, from a simple language which is quite close to that found in writing a step-by-step word statement of a mathematical calculation. Existing DEUCE subroutines may be used with SODA by employing a "SUBROUTINE" control card. This card associates with the subroutine a mnemonic reference in standard SODA terminology. Once the control card has been supplied to the translator, this mnemonic reference can be given at any point in the SODA program, just as if it were a regular SODA instruction, whenever it is desired to employ the subroutine. Extract: The SODA Machine and the SODA Language The SODA Machine and the SODA Language The selection of a pseudo language rests on many requirements, the most important of which are the ease with which the language can be used, and the efficiency of the final machine program. Other points of consideration include the ease with which the translation program itself can be written, and the more pressing requirements of the computation laboratory sponsoring the development. The first point argues for a language close to that which the human user employs as his own language. Thus we might desire to write algebraic equations, or merely give sentence statements of what is desired. The former of these is presently receiving some attention by Dr. C. Hamblin of the Humanities Department of the University of New South Wales, Sydney, Australia. He has already written an interpretive program using such a language. A translation program for this type of language is extremely involved, and it was felt that something which would be available quickly would be more desirable. In addition, it was felt that at a university it would be advantageous to have a language which was more like that of a conventional single-address machine. Once such a language is mastered, the step towards programming any machine, including DEUCE, is a relatively minor one. The choice for a language, therefore, embodies the principles employed in programming a more conventional type computer, with the additional facility that the instruction names and the various addresses can be alphabetical in nature, thereby allowing for mnemonic aids. Indeed, SODA incorporates many of the features employed in SOAP (Symbolic Optimum Assembly Program) for the IBM 650 computer and SAP (Share Assembly Program) for the IBM 704 machine. The basic language of these same two schemes was used as a guide throughout the development. Extract: Results Results SODA has successfully translated many programs. Reports from the programmers indicate a substantial time saving over normal DEUCE programming, and they feel that this will increase as familiarity with SODA grows. The scheme still includes many programming details that would not occur in the ideal system. Most of these result from compromises due to the difficulty of eliminating them in the available time. Nevertheless, SODA users do indicate an appreciable reduction in the overall programming burden. SODA produces a less efficient program than could be written by hand, the decreased efficiency arising from two main sources. First, a DEUCE program written by SODA contains many more instructions than the equivalent hand-written program. Secondly, calculations do not occur simultaneously with the transfer of information between the drum and the mercury store. Simultaneous computation is possible in normal DEUCE programming. Both effects are a result of inability to simulate easily the subtleties inherent in human programming. Nevertheless, the authors feel that the savings in human labour will more than compensate for the slightly decreased efficiency of the final DEUCE program. in The Computer Journal 2(2) July 1959 view details in The Computer Journal 2(2) July 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. Extract: SODA AN EXISTING TRANSLATING PROGRAM The pseudo-code, Soda, associated with this program (Ref. 4) assumes a pseudo-computer in some respects like DEUCE itself. It has a 'short accumulator', a 'lower accumulator' and an 'upper accumulator', the two latter being combined in some instructions to form a 'double accumulator' (cf. Ref. 1). Arrays of data are stored on the drum, but access to them is through two 'working stores' which can usually be regarded as independent storage units of indefinite size, though for some purposes it must be recognized that each consists of only 32 positions and that data are automatically transferred to or from these positions at appropriate times. Constants are also stored on the drum, and there is similar access to them. Arithmetic and logical operations take place between a number in one of the accumulators and either a number in an array brought into one of the working stores or a constant, and the result remains in the accumulator. That is, the code is 'one-address'; each instruction consists essentially of an address, which is usually symbolic, and a function specification which includes an indication of which accumulator is to be used. Arrays of numbers and constants ran he arhitrarilv named hv the programmer provided that not more than five alpha-numeric characters are used and at least one is alphabetic. For example, arrays may be named Al, A2, and so on, or, if there is only one of them, simply ARRAY, while the constant TT may be given the obvious name PI. The address used in an instruction referring to such an array or constant, is then its name. Provision is made for referring to any element of an array by means of four index registers, any one of which can be specified in the instruction. This method is used where the same or a similar calculation is to be done with each element of the array; if, however, the elements are disconnected and are to be used individually in the computation, the programmer can name the array by a single letter and then refer to any element by this letter followed by the position of the element in the array, e.g. if the array is called A, then ^10002 would be the address of its second element. One of the index registers is also required when this sort of reference is made. Numerical addresses refer to numbers currently in the working stores or the constants buffer store, to the accumulators or to special constants. Functions are specified by groups of three letters which have a mnemonic connexion with the description of the operation, e.g. CAS represents 'Clear and ^4dd to the Short accumulator', while SBL represents 'Subtract from the Lower accumulator'. A list of the functions built into the'scheme is given in Appendix 3 to this paper. Almost any standard DEUCE subroutine can, however, be used to introduce a new function. Both fixed- and floating-point working are catered for. To enable the normal sequence to be broken, any instruction can be given a 'next instruction location' which is an arbitrary symbol of up to five alpha-numeric characters. The instruction to which the jump is made must, of course, have the same symbol as its 'location'. Normally a next instruction location refers either to an instruction further back in the program or, at the entry to a loop, for example, to the next instruction in sequence; in other cases a special forward jump indicator must be included in the instruction or the translation program will assume that an error has been made. The only other part of an instruction is the 'decrement', which is used only with the counting functions (JIX, JXH, JXE). The decrement may be symbolic, in which case its numeric value is found in the corresponding constant address, or it may be numeric, and it may be positive or negative. The function JIX causes the decrement to be subtracted from the specified index register, the result remaining there, and a jump to be made to the specified next instruction if this result is positive. With both JXH and JXE, the specified index register is compared with the decrement; in the first case, a jump is made if the number in the register is algebraicalIv greater than or equal to the value of the decrement; in the second case, a jump is made only if they are equal. Control cards, with characteristic punchings, are inserted at various places in the program to define constants, extra DEUCE subroutines, arrays, loops (optional), and the end of the program. Appendix 4 to this paper shows a Soda program for forming a vector product. A loop control card could be inserted between cards 9 and 10; its effect may be to make the resultant DEUCE program faster by causing ;i fresh block of instructions to be brought from the drum at the beginning of the loop. The translation program reads in a set of Soda code-words together with the control cards, etc., but not, of course, the data on which the calculation is to be done. It then produces a set of DEUCE instructions In] carrying out the calculation specified, as a complete DEUCE program punched out on cards and ready for use in the normal way alter adding a standard pack of subroutine cards and the data. To assist program-testing, the translation can, at the discretion of the programmer, include a 'trace' facility. If the facility is included the DEUCE program can be made to punch out, after sequences corresponding to most Soda code-words, a code-word identification number and the contents of the accumulators and index registers; it can be made simply to stop and show the identification number after each such sequence, or it can be made to run normally. A correct program should, of course, be finally translated without the trace facility to produce an efficient DEUCE program. 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: 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 Resources
|