Brooker Autocode(ID:2803/bro002)Machester Mark I autocodeCode by Tony Brooker for the Machester Mark 1, with the assistance of Cicely Popplewell, after the departure of Alan Turing. Popplewell went with a Ferranti Mercury to the Instituto de Calculo in Argentina in 1963, where she may have started a loclaised version (under review) Elegant columnar format. People: Related languages
References: in British Journal of Applied Physics 6 (1955) view details in Proc IEE 103B Supplement1956 view details Let me elaborate these points with examples. UNICODE is expected to require about fifteen man-years. Most modern assembly systems must take from six to ten man-years. SCAT expects to absorb twelve people for most of a year. The initial writing of the 704 FORTRAN required about twenty-five man-years. Split among many different machines, IBM's Applied Programming Department has over a hundred and twenty programmers. Sperry Rand probably has more than this, and for utility and automatic coding systems only! Add to these the number of customer programmers also engaged in writing similar systems, and you will see that the total is overwhelming. Perhaps five to six man-years are being expended to write the Alodel 2 FORTRAN for the 704, trimming bugs and getting better documentation for incorporation into the even larger supervisory systems of various installations. If available, more could undoubtedly be expended to bring the original system up to the limit of what we can now conceive. Maintenance is a very sizable portion of the entire effort going into a system. Certainly, all of us have a few skeletons in the closet when it comes to adapting old systems to new machines. Hardly anything more than the flow charts is reusable in writing 709 FORTRAN; changes in the characteristics of instructions, and tricky coding, have done for the rest. This is true of every effort I am familiar with, not just IBM's. What am I leading up to? Simply that the day of diverse development of automatic coding systems is either out or, if not, should be. The list of systems collected here illustrates a vast amount of duplication and incomplete conception. A computer manufacturer should produce both the product and the means to use the product, but this should be done with the full co-operation of responsible users. There is a gratifying trend toward such unification in such organizations as SHARE, USE, GUIDE, DUO, etc. The PACT group was a shining example in its day. Many other coding systems, such as FLAIR, PRINT, FORTRAN, and USE, have been done as the result of partial co-operation. FORTRAN for the 705 seems to me to be an ideally balanced project, the burden being carried equally by IBM and its customers. Finally, let me make a recommendation to all computer installations. There seems to be a reasonably sharp distinction between people who program and use computers as a tool and those who are programmers and live to make things easy for the other people. If you have the latter at your installation, do not waste them on production and do not waste them on a private effort in automatic coding in a day when that type of project is so complex. Offer them in a cooperative venture with your manufacturer (they still remain your employees) and give him the benefit of the practical experience in your problems. You will get your investment back many times over in ease of programming and the guarantee that your problems have been considered. Extract: IT, FORTRANSIT, SAP, SOAP, SOHIO The IT language is also showing up in future plans for many different computers. Case Institute, having just completed an intermediate symbolic assembly to accept IT output, is starting to write an IT processor for UNIVAC. This is expected to be working by late summer of 1958. One of the original programmers at Carnegie Tech spent the last summer at Ramo-Wooldridge to write IT for the 1103A. This project is complete except for input-output and may be expected to be operational by December, 1957. IT is also being done for the IBM 705-1, 2 by Standard Oil of Ohio, with no expected completion date known yet. It is interesting to note that Sohio is also participating in the 705 FORTRAN effort and will undoubtedly serve as the basic source of FORTRAN-to- IT-to-FORTRAN translational information. A graduate student at the University of Michigan is producing SAP output for IT (rather than SOAP) so that IT will run on the 704; this, however, is only for experience; it would be much more profitable to write a pre-processor from IT to FORTRAN (the reverse of FOR TRANSIT) and utilize the power of FORTRAN for free. Extract: Brooker Autocode Many foreign developments are worthy of mention [...] R. A. Brooker has developed a fully descriptive and vertically algebraic Autocoding System for the Manchester machine. in "Proceedings of the Fourth Annual Computer Applications Symposium" , Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois 1957 view details in "Proceedings of the Fourth Annual Computer Applications Symposium" , Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois 1957 view details in The Computer Journal 1(1) 1958 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 Belzer, J. ; A. G. Holzman, A. Kent, (eds) Encyclopedia of Computer Science and Technology, Marcel Dekker, Inc., New York. 1979 view details Mark I and Atlas is evaluated. Extract: System Software System Software. In 1949 there was no Mark I system software, except for basic utilities such as input routines. Coding was normally carried out using the symbols of the 5-track teleprinter code. Once the Ferranti Mark I had been installed software development increased, with the emphasis being on embryonic high-level languages. After one earlier effort at compiler writing (1952), the Mark I Autocode [1] was available from March 1954 as an easy-to-learn scientific programming language for users having small or medium-sized problems. An additional Autocode implementation objective was to simulate a one-level store so that the user had no need to organize his own drum transfers. It was possible to simulate this one-level store on the Mark I in a reasonably balanced way because the access time for reading an operand from the drum happened to be about the same time as a floating-point addition via an interpretive library routine. When running Autocode programs 128 tracks on the drum were reserved for instructions and 128 tracks for variables. Individual "routines" were transferred to the fast CRT store as they were required. To gain access to a variable an interpretive routine in fast store first determined on which track it lay, then transferred that track or "page" to the fast store, and finally selected the particular line within the page. Since successive operands were quite often located on the same page, steps were taken to avoid unnecessary drum transfers. Arithmetic in the Autocode system was normally performed on floating-point variables v1, v2 . . . . . etc. with provision for integers n1, n2 . . . . , to be used as indices and counters. Simple conventions also existed for control transfers, intrinsic functions, input/output, and simple job control using symbols from the five-bit teleprinter code. An impression of the neatness of the system may be gained from the following Mark I Autocode sequence which prints the root mean square (rms) of the variables v1 , v2, . . . v100. (Note that the symbol * causes printing of a variable to decimal places on a new line, and F1 signifies intrinsic function 'square root'): n1 = 1 v101 = 0 2 v102 = vn1 x vn1 v101 = v101 + v102 n1 = n1 + 1 j2, 100 > n1 v101 = v101/100.0 *v101 = F1 (v101) in [ACM] CACM 21(01) (January 1978) view details All early computer users wrote their programs in machine code so programming was something of a black art. R.A. Brooker in Manchester (now Professor and pro-Vice Chancellor at Essex) devised an Autocode for the Mark-l and Mark-I*, which was a simple, easy-to-Iearn and easy-to-use high level language - not very high, to be sure, and very slow in execution, but a great improvement on machine code if you had only a fairly small program to write. We introduced this to Harwell and it caught on. When Ferranti embarked on building Mercury - based, as I said, on the next Manchester design - Brooker decided to write a new Autocode which, because of the higher basic speed and better facilities offered by Mercury, would be much more powerful and flexible and much faster. He spent a lot of time with us at Harwell discussing what should go into the new system, so that Harwell certainly had a significant influence on what he produced. The system, Mercury Autocode, proved a great success. Although simple when compared with modern high-level languages it provided an admirable range of facilities and was very easy to learn. With various enhancements it had a remarkably long life; a compiler for the final version, called CHLF because it was produced by a collaboration between CERN, Harwell, London (University) and Farnborough (RAE), was written for Atlas and was still in use in the early 1970's. in [ACM] CACM 21(01) (January 1978) view details The primitive state of the programming system did have a valuable side effect in stimulating the development of automatic coding systems. This was quite different from the situation at Cambridge where the programming system developed by Wilkes and Wheeler was so satisfactory that much of the incentive for making improvements was removed. Glennie's AUTOCODE was an outstanding innovation. Its failure to catch on had two main causes: first, it did not overcome the worst features of programming the Mark I (scaling and storage management), and second, it did not attract the support of the laboratory (perhaps a natural reticence on the part of Glennie had some part to play here). The real success story of the programming effort was Brooker's Mark I Autocode. The success of the Mark I Autocode (especially when contrasted with Glennie's) can be attributed to several factors: 1. Ease of use. Autocode was easy to learn and use; it attracted a body of new users rather than trying to win over existing programmers. 2. Fulfilled a need. Autocode offered significant facilities not otherwise readily available (floating point, one-level storage, simplified input/output). 3. Effective selling. Autocode was promoted by a series of programming courses, an exceptionally short and comprehensible manual, and a postal service for remote users. 4. Committed support. Autocode had the full support and enthusiasm of the laboratory in terms of maintenance, documentation, programming advice, and consultancy. The above would make an effective checklist today for the launch of any new software product. Brooker's Mark I Autocode was probably the most significant programming innovation of the mid-1950s in Britain; it inspired several imitations at the time when American directions were not widely reported in Britain. For example, G. E. Felton, programming manager for the successful Ferranti Pegasus, initiated the Pegasus autocode, which was released in the summer of 1958 (Felton 1978); from this grew the autocode for the Ferranti Sirius computer shortly after. Also in the late 1950s autocodes for the Elliot 802 and 803 were produced. All these systems had an extremely strong family resemblance to Brooker's progenitor. Brooker's Mark I Autocode, and his subsequent Mercury Autocode of 1958, was a dominant influence on British autocodes until well into the 1960s. It was only in the middle and late 1960s that ALGOL 60 and FORTRAN became a significant force for British computers. in Annals of the History of Computing 02(2) view details 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. 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 a central role. Extract: Transcode Transcode The Transcode system was finished by September 1954 and was the work of myself and Trixie Worsley. A total of six person-months was required. Many of the library subroutines used as part of Transcode were created by others. The distinctive difference from Speedcode was that ours was a compiler. Because our scale-of-32 computer already used letters of the alphabet, mnemonic operation codes were obvious. Since our Transcode instructions did not have to reside in memory after translation, we could be wasteful of space. We assigned four- letter words to each operation: MULT for multiplication, SUBT for subtraction, and so on. There was no need, as in Speedcode, to have two types of instructions. We made all instructions, even those requiring only one argument, the three-address type for uniformity. The notion of making our language machine independent was never considered, so we took every advantage of the nature of Ferut s hardware. Each three-address instruction was assigned four lines of memory. One for the operation and one each for the three addresses -- this made the translation much simpler. During execution five of the eight pages of the immediate-access memory were assigned to the translated program, Perm, and the floating-point instructions. Keeping the floating-point instruction memory meant that the translated program had only to transfer control to the appropriate part, after planting the arguments and a return address in fixed locations. No transfer between drum and memory was required. This left three pages for data; part of one of these pages was also used to hold the link list of subroutines. Each floating number required three lines, one for the exponent and two for the significant digits. So a page of 64 lines could hold a maximum of 21 floating numbers. These locations were given names, essentially predeclared variable names. One page, the X-page, had locations (or variables) X01, X02, up to X21. Another, the Y-page, had Y01, Y02, up to Y21. The partial page, the Z-page, had locations Z01, Z02, up to Z13. To add the number in X01 to the number in Y01 and put the result in Z01 you used the instruction ADDN X01.0 Y01.0 Z01.0 The extra position in each of the three arguments was used for indexing. The period was just for readability and was not part of the instruction. Each of the three sets of variables could act as a vector (or an array). Indexing was done by appending the number of a B- register, which held an integer, to the variable name. The address X01.3 was the one on the X-page that was designated by X01 plus the contents of B-register 3. The contents of any B-register could be set by BSET, incremented by INCB, decremented by NEGB, and stored in memory by JOTB. The contents of B-register 5 could, for example, be increased by 3 by the instruction INCB 000.5 003.0 000.0 This is an example of an instruction that did not use all of its arguments, but, as mentioned, keeping all instructions in the same form made the compilation process much simpler. Extract: Experience with Transcode Experience with Transcode Transcode was an almost instant success. It could be learned with two hours of lectures or understood from a manual prepared by the Computation Centre staff. No longer were researchers in physics, chemistry, and astronomy waiting for the services of a professional programmer. The ease of programming and debugging decreased the time between wanting a calculation done and having results from weeks to a few days. Researchers at the National Research Council of Canada and at the Defense Research Board no longer had to rely on their programmer representatives in Toronto and were mailing programs to be punched and run. Often any errors could be found for them and results returned the same day. In 1955, thanks to the kindness of CN Telecommunications, the teletypewriter lines between Saskatoon and Toronto were made available certain evenings, and Transcode programs punched by people at the University of Saskatchewan in Saskatoon were sent to Ferut. These were run, and the results punched and sent back to their originators. This was the first recorded long-distance on-line use of a computer in Canada, and it would never have worked without Transcode. Transcode was not a toy. Examples of successful research calculations were recorded in an article addressed to Canadian physicists. Worsley and I sent a copy of our article to Grace Murray Hopper, whom we knew was working in this area, and received a warm reply: "It is so encouraging to read of the experience of others who have so successfully applied the automatic coding techniques and it helps no end in presenting the ideas to others to be able to cite your experience as well as our own." Extract: Automatic coding at Manchester Automatic coding at Manchester An early attempt at automatic coding called Autocode was completed by A.E. Glennie of the Ministry of Supply, but used only by him. It did not deal with scaling or the two-level store. In 1954 R.A. Brooker introduced his system, which he reluctantly also called Mark I Autocode.6 This he published in September 1955, too late to influence Transcode. His system had predeclared floating-point variables called v1, v2, v3, .... vS000, thus eliminating all reference to the two-level store for the data. This introduced considerable inefficiency whenever a sequence of variables was used that was longer than could be kept in the electrostatic store. A form of the assignment statement was used instead of the three-address format for arithmetic instructions. For example, v12 = v12 + v13 was used instead of Transcode's ADDN Z01.0 Z02.0 Z01.0, or n2 = n2 + l instead of Transcode's INCB 000.2 001.0 000.0. The right-hand side of the "assignment" could only be a dyadic operation. There was no loop operation, all counted repetitions being programmed explicitly. Printing was of one number at a time; for example, *v12 = v12 would result in the printing of the contents of v12 (the asterisk meant to print). Reports of the success of Brooker's Autocode were similar to those of Transcode. Transcode was more sophisticated in many ways than Autocode in having counted loops, formatted printing, ability to create functions, faster compile time, and user control of data segmentation. Extract: After Transcode Ferut continued to serve the Canadian scientific community, but by 1958 the maintenance costs were seen to be larger than the rental costs of an IBM 650 -- and the Ferut service was still on again, off again. Age was taking its toll. Ferut went to the National Research Council in Ottawa (where it was used for a while), and we got the IBM 650. My interest flagged as there already existed the SOAP (Symbolic Optimal Assembly Program) system to place the one-plus-one machine- code instructions strategically around the drum. The machine was decimal and the machine (or assembly) code was not as forbidding as Ferut's had been. But the experience we had with Transcode led us to want a higher level language for writing programs. The Fortran language had been invented and was available in time for the 650. Although it took forever to compile, it did seem the way of the future and it was to survive the next generations of machines -- it was machine independent. Fortran provided, as advertised, formula translation. Arithmetic operations did not need to be dyadic only, as arithmetic expressions could be parsed and the appropriate machine code generated. At one point, just before the demise of Ferut, we had contemplated implementing such a language ourselves, where the translation would be two stage, from the algebraic language to Transcode and then, as before, to machine code. But we never did it. Convinced that higher level languages were the only way to go, we began offering four-hour courses on Fortran using color slides and audio tapes to prepare the scientific community in Toronto to use it. When we got the IBM 7094 in the early 1960s, we were ready. Transcode was for us a major step in the direction of what had become automatic programming. It was much more than an assembly language and yet, because it had a fixed format and was definitely not machine independent, it did not rate to be called a programming language. But that depends on who makes up the definition. It was an exciting time to be involved in computing. When you are a pioneer, all contributions are welcome. Extract: Translation Translation The compiler and operating system for Transcode occupied 18 tracks on the drum. After all the information was read in from the tape, all numbers and constants being converted from decimal to binary, translation began. Each Transcode instruction was replaced by a sequence of from one to 16 machine instructions. Since the translated program resident in memory could not exceed two pages at a time, segments of this length were created, each being sent in turn to the drum and having the calling in sequence for the next segment as required for execution. A list was kept of the correspondences between Transcode instruction numbers and addresses of the beginning of the corresponding machine-code sequence (both drum track and store location). This list was used whenever a control transfer instruction (TRNS) was encountered. If the transfer was a jump ahead in the program, its location was stored in a list of as yet untranslated addresses. At the end of translation, which was signaled by the Transcode instruction QUIT in the program, all the untranslated addresses were translated in a second pass. Compile time was short relative to execution time of most programs, largely because of the simplicities obtained by using knowledge of the machine hardware to advantage in creating the Transcode language. Extract: Automatic coding Automatic coding About the fall of 1953 it was decided to try to get the computer itself to help with the coding process. In the first issue of the Journal of the Association for Computing Machinery, January 1954, J.W. Backup described his success with the Speedcoding system for the IBM 701. This material had been presented at the meeting of ACM in September 1953 and so was known to us. Speedcoding made the 701 behave as a three-address, floating-point computer and was an interpretive system. Some instructions, other than the arithmetic and input-output ones, were written with one address. The system simulated the existence of three B-tubes and thus permitted indexing of an array of memory locations. It had reasonably easy input operations for data and program, with checking features. Although programs in Speedcode ran much more slowly than machine code, the reduction in programming and testing time made it an economical alternative. This report encouraged us to launch into our own Transcode project. About the fall of 1953 it was decided to try to get the computer itself to help with the coding process. In the first issue of the Journal of the Association for Computing Machinery, January 1954, J.W. Backup described his success with the Speedcoding system for the IBM 701. This material had been presented at the meeting of ACM in September 1953 and so was known to us. Speedcoding made the 701 behave as a three-address, floating-point computer and was an interpretive system. Some instructions, other than the arithmetic and input-output ones, were written with one address. The system simulated the existence of three B-tubes and thus permitted indexing of an array of memory locations. It had reasonably easy input operations for data and program, with checking features. Although programs in Speedcode ran much more slowly than machine code, the reduction in programming and testing time made it an economical alternative. This report encouraged us to launch into our own Transcode project. Extract: Beginnings of Coding on FERUT The Ferut computer was a copy of the Mark I computer at the University of Manchester. Two years after its delivery, in Toronto, systems software had been developed to vastly enlarge the community of users. To go from a few dedicated programmers patient enough to deal with the extremely difficult machine code to a situation where anyone with two hours to spare could program successfully was a major advance. This article retraces the steps in this pioneering experiment in automatic programming, in which the author played a central role. In the late spring of 1952 an electronic digital computer built by Ferranti Ltd., Manchester, England, arrived at the University of Toronto. It was a copy of the Mark I computer at the University of Manchester and the second computer ever sold. Our computer was dubbed Ferut, combining the names of the manufacturer and the new owner. It was set up in the Physics Department across the hall from an office that I, a relatively new assistant professor, shared with C.C. (Kelly) Gotlieb, who held the title of chief computer of the Computation Centre. I had been using the center's IBM punched-card equipment to carry out wave-function calculations for complex atoms, a considerable improvement over a hand-cranked Millionaire mechanical calculator that had been the best the Physics Department had when I finished my PhD in 1949. Ferut was to me a dream come true -- days of computation could be compressed into minutes. But there was a catch -- we had to get the new machine going. From a hardware point of view the maintenance engineers had their hands full with hundreds of vacuum tubes and thousands of soldered connections, a job that was to keep them busy for months. In September 1952, ACM had a meeting in Toronto, and this attracted a number of the people from the University of Manchester whose brains could be picked for details of operating systems and machine language. This job fell to me and Beatrice H. (Trixie) Worsley, since Gotlieb was taken up with responsibilities of the conference. There was no manual with the computer and none was brought from Manchester. But a user of that computer, D.G. Prinz, had prepared one and had the facts carefully memorized. We found ourselves sitting behind him as he typed, in a most systematic way, a sort of on-line version of the Prinz manual, adding comments as he went. That was the beginning of my conversion from physicist to computer scientist -- wave-function calculations had to wait while operating system programs were written -- and I was elected. I could not have done this without the encouragement of W.H. Watson, who was both head of the Physics Department and director of the Computation Centre. in Annals of the History of Computing 16(2) Summer 1994 view details in Annals of the History of Computing 16(2) Summer 1994 view details Resources
|