DOCSLIB.ORG

Fiendish Designs

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Fiendish Designs Fiendish Designs A Software Engineering Odyssey © Tim Denvir 2011 1 Preface These are notes, incomplete but extensive, for a book which I hope will give a personal view of the first forty years or so of Software Engineering. Whether the book will ever see the light of day, I am not sure. These notes have come, I realise, to be a memoir of my working life in SE. I want to capture not only the evolution of the technical discipline which is software engineering, but also the climate of social practice in the industry, which has changed hugely over time. To what extent, if at all, others will find this interesting, I have very little idea. I mention other, real people by name here and there. If anyone prefers me not to refer to them, or wishes to offer corrections on any item, they can email me (see Contact on Home Page). Introduction Everybody today encounters computers. There are computers inside petrol pumps, in cash tills, behind the dashboard instruments in modern cars, and in libraries, doctors’ surgeries and beside the dentist’s chair. A large proportion of people have personal computers in their homes and may use them at work, without having to be specialists in computing. Most people have at least some idea that computers contain software, lists of instructions which drive the computer and enable it to perform different tasks. The term “software engineering” wasn’t coined until 1968, at a NATO-funded conference, but the activity that it stands for had been carried out for at least ten years before that. To engineer something, a road, a car engine, a skyscraper or a piece of computer software is to design and build it, using the techniques and technology known at the time. I have worked in software engineering for about forty years, from 1962 to 2002. For the last 20 years of this time I specialised in formal methods of software development. My first job after graduating was with Elliott’s, a British computer manufacturer, in 1962. Elliott’s no longer exists as a separate company, but has been absorbed into the last remaining British mainframe manufacturer, ICL, through a succession of mergers and take-overs. Chapter 1 Flanges and Festivities Late in the fifties, British Thompson-Houston merged with Hollerith to become the British Tabulating Machine Company. Both these companies produced tabulators, machines that sorted punched cards and which, with a bit of persistence and patience on the part of their operators, could carry out basic statistical processes. In 1960 Powers Samas, an engineering firm, merged with them and the result was International Computers and Tabulators, ICT. I had worked as a vacation student with ICT just at that time, doing logic design and circuit board layout for a new compact military machine; if I ever knew the name of it, I have forgotten. But ICT at about that time were conscious that the word “tabulator” indicated an obsolescent technology, and so they changed their name to International Computers Limited, 2 ICL. By the time I had graduated, there were two other large British computer manufacturers, English Electric and Elliott's. Elliott Brothers had themselves recently absorbed part of NCR, National Cash Registers Ltd. There was also a smaller firm that nonetheless produced mainframe machines, Leo Computers. Leo Computers came about in a rather surprising way. A chain of cafés called Lyons’ Corner Houses were to be found all over London. They needed to coordinate their accounts and required computer power to do so efficiently. Rather than pay someone else to supply their computers, they formed their own computer manufacturing subsidiary, Leo. No “buy in” policy for them! Leo continued producing computers for some years before they were bought by English Electric, who also took over Marconi, an electronics firm who, famously, designed and manufactured radios but also much other electronic equipment, especially for the military. Marconi was one of the firms with whom I had an interview when choosing my first job after graduating. English Electric made the KDF9 computer, a rival in size and performance to the IBM 360, which dominated the market for many years. Later still, towards the end of the sixties, English Electric-Leo- Marconi, EELM, was absorbed into ICL. But back in 1962 Elliott’s produced the 803 machine and were embarking on a more powerful version of it, with the same instruction code, the Elliott 503. In the early 1960s computers were seen as large calculators: machines that could carry out complex mathematical calculations. Most, if not all, application software was about performing large calculations for some purpose. Academic courses reflected this, and were limited to post- graduate diplomas, concentrating on numerical analysis and automata theory. Several polytechnics also provided some more practical HNC courses. Most programmers working for Elliott’s were maths graduates, a few with a post-graduate diploma in computing. A minority were HNC holders. I was one of a batch of new graduates who joined the Scientific Computing Division at Elliott’s. Other graduates joined several other divisions at the same time, so there were some twenty or thirty of us, all newcomers. We rapidly got to know each other and, almost all of us being single graduates living in digs and assorted shared flats and so on, there would be a party to go to every Saturday night. All of us in the Scientific Computing Division spent a few days on a course in which we were taught to program. The language we were taught was the machine code for the Elliott 803. This machine occupied a fairly large room. The central processor was housed in several six-foot high 19 inch wide cabinets. The 803 was one of the first machines to use semiconductors, germanium transistors and diodes, for its electronics. It was consequently relatively compact. A paper tape reader and punch, and a card reader and punch were held in similar cabinets, and the operator’s console was desk-shaped, and held an on-off switch, various lamps and buttons and a “number generator”, which was a row of toggle switches on which one could set up a binary number. There were instructions in the machine for reading the setting on the number generator and for displaying patterns on the 3 lamps. One could also set up an instruction on the number generator and press a button causing the machine to obey it. This was the principal way of booting up a program, by setting up a jump to its starting address on the number generator and obeying it. A line printer could print out results of the calculations or other work that a program had performed. These printers were the first to be attached to a computer and consisted of a rotating drum and rows of hammers. Paper edged with detachable sprocket holes would be fed into the printer. The drum had lines of characters embossed on it. Each line had the same character embossed along all of its character positions. Usually, a line of characters would be printed on each rotation of the drum. The character to be printed at each character position was controlled by timing the hammer at that position to strike when the correct line of the drum was under it. These printers were large and noisy, but were the main means of printing output for most computers. Programmers could book time on the machine to run their programs, or request one of the operators to do so. I preferred to make use of the operators’ services, but most of my colleagues liked to be more hands on. I caused much amusement when I went to use the machine myself for the first time after I had been working there for nearly a year. “What, you’ve never used the machine before, Tim?” The first programming course covered the two main versions of the machine code and gave advice about how to program, using the accumulator and main storage. The machine code was numeric, having a couple of octal digits for the instruction and the rest for the address. Octal numbers were used rather than hexadecimal. The word size in the machine was 39 bits. This may seem bizarre today, when word sizes are invariably a whole number of bytes. Each instruction occupied 18 bits, so that two instructions fitted into each word. One bit remained, in between the two instructions. This was called the “B-line”. Setting the B-line caused the contents of the address in the first half to be added to the second instruction. This was useful for working with arrays and lists. The first five bits of each instruction contained the operation code and the remaining 13 bits the address. In this way the instruction code could address a store of 8192 words. The computers were supplied with a main store of either 4096 or 8192 words. The first versions of the 803 had no backing store. Any intermediate information generated by a program would be punched out onto paper tape, ready to be read in again. Later versions had backing stores consisting of magnetic film, specially manufactured by Kodak. This was 35 mm film with sprocket holes and a magnetic coating instead of a photographic one. The film was wound onto reel-to-reel decks. The simplest version of the machine code was “ absolute”; the addresses in the instructions referred to specific, absolute locations and the program would only work if it was loaded into a specific location in store. This was so primitive and restrictive that it was only used for some very basic utilities.
Load more

Recommended publications
  • A Universal Modular ACTOR Formalism for Artificial
    Artificial Intelligence A Universal Modular ACTOR Formalism for Artificial Intelligence Carl Hewitt Peter Bishop Richard Steiger Abstract This paper proposes a modular ACTOR architecture and definitional method for artificial intelligence that is conceptually based on a single kind of object: actors [or, if you will, virtual processors, activation frames, or streams]. The formalism makes no presuppositions about the representation of primitive data structures and control structures. Such structures can be programmed, micro-coded, or hard wired 1n a uniform modular fashion. In fact it is impossible to determine whether a given object is "really" represented as a list, a vector, a hash table, a function, or a process. The architecture will efficiently run the coming generation of PLANNER-like artificial intelligence languages including those requiring a high degree of parallelism. The efficiency is gained without loss of programming generality because it only makes certain actors more efficient; it does not change their behavioral characteristics. The architecture is general with respect to control structure and does not have or need goto, interrupt, or semaphore primitives. The formalism achieves the goals that the disallowed constructs are intended to achieve by other more structured methods. PLANNER Progress "Programs should not only work, but they should appear to work as well." PDP-1X Dogma The PLANNER project is continuing research in natural and effective means for embedding knowledge in procedures. In the course of this work we have succeeded in unifying the formalism around one fundamental concept: the ACTOR. Intuitively, an ACTOR is an active agent which plays a role on cue according to a script" we" use the ACTOR metaphor to emphasize the inseparability of control and data flow in our model.
    [Show full text]
  • A Politico-Social History of Algolt (With a Chronology in the Form of a Log Book)
    A Politico-Social History of Algolt (With a Chronology in the Form of a Log Book) R. w. BEMER Introduction This is an admittedly fragmentary chronicle of events in the develop­ ment of the algorithmic language ALGOL. Nevertheless, it seems perti­ nent, while we await the advent of a technical and conceptual history, to outline the matrix of forces which shaped that history in a political and social sense. Perhaps the author's role is only that of recorder of visible events, rather than the complex interplay of ideas which have made ALGOL the force it is in the computational world. It is true, as Professor Ershov stated in his review of a draft of the present work, that "the reading of this history, rich in curious details, nevertheless does not enable the beginner to understand why ALGOL, with a history that would seem more disappointing than triumphant, changed the face of current programming". I can only state that the time scale and my own lesser competence do not allow the tracing of conceptual development in requisite detail. Books are sure to follow in this area, particularly one by Knuth. A further defect in the present work is the relatively lesser availability of European input to the log, although I could claim better access than many in the U.S.A. This is regrettable in view of the relatively stronger support given to ALGOL in Europe. Perhaps this calmer acceptance had the effect of reducing the number of significant entries for a log such as this. Following a brief view of the pattern of events come the entries of the chronology, or log, numbered for reference in the text.
    [Show full text]
  • Proofs for the Working Engineer
    Research Collection Doctoral Thesis Proofs for the working engineer Author(s): Mehta, Farhad Dinshaw Publication Date: 2008 Permanent Link: https://doi.org/10.3929/ethz-a-005635243 Rights / License: In Copyright - Non-Commercial Use Permitted This page was generated automatically upon download from the ETH Zurich Research Collection. For more information please consult the Terms of use. ETH Library DISS. ETH NO. 17671 Proofs for the Working Engineer A dissertation submitted to ETH ZURICH for the degree of Doctor of Sciences presented by Farhad Dinshaw Mehta Master of Science, Technische Universit¨atM¨unchen Bachelor of Technology, Indian Institute of Technology Delhi born 11.01.1980 citizen of India accepted on the recommendation of Prof. Jean-Raymond Abrial Prof. Peter M¨uller Prof. Cliff Jones 2008 Abstract Over the last couple of decades the advantages of including formal proof within the development process for computer based systems has become in- creasingly clear. This has lead to a plethora of logics and proof tools that propose to fulfill this need. Nevertheless, the inclusion of theorem proving within the development process, even in domains where clear benefits can be expected, is rather an exception than the rule. One of the main goals of the formal methods endeavour is to bring the ac- tivity of formal theorem proving closer to the engineer developing computer based systems. This thesis makes some important practical contributions towards realising this goal. It hopes to shows that proper tool support can not only ease theorem proving, but also strenghten its role as a design aid. It shows that it is feasible to integrate interactive proof within a reactive development environment for formal systems.
    [Show full text]
  • Technical Details of the Elliott 152 and 153
    Appendix 1 Technical Details of the Elliott 152 and 153 Introduction The Elliott 152 computer was part of the Admiralty’s MRS5 (medium range system 5) naval gunnery project, described in Chap. 2. The Elliott 153 computer, also known as the D/F (direction-finding) computer, was built for GCHQ and the Admiralty as described in Chap. 3. The information in this appendix is intended to supplement the overall descriptions of the machines as given in Chaps. 2 and 3. A1.1 The Elliott 152 Work on the MRS5 contract at Borehamwood began in October 1946 and was essen- tially finished in 1950. Novel target-tracking radar was at the heart of the project, the radar being synchronized to the computer’s clock. In his enthusiasm for perfecting the radar technology, John Coales seems to have spent little time on what we would now call an overall systems design. When Harry Carpenter joined the staff of the Computing Division at Borehamwood on 1 January 1949, he recalls that nobody had yet defined the way in which the control program, running on the 152 computer, would interface with guns and radar. Furthermore, nobody yet appeared to be working on the computational algorithms necessary for three-dimensional trajectory predic- tion. As for the guns that the MRS5 system was intended to control, not even the basic ballistics parameters seemed to be known with any accuracy at Borehamwood [1, 2]. A1.1.1 Communication and Data-Rate The physical separation, between radar in the Borehamwood car park and digital computer in the laboratory, necessitated an interconnecting cable of about 150 m in length.
    [Show full text]
  • Journal of Applied Logic
    JOURNAL OF APPLIED LOGIC AUTHOR INFORMATION PACK TABLE OF CONTENTS XXX . • Description p.1 • Impact Factor p.1 • Abstracting and Indexing p.1 • Editorial Board p.1 • Guide for Authors p.5 ISSN: 1570-8683 DESCRIPTION . This journal welcomes papers in the areas of logic which can be applied in other disciplines as well as application papers in those disciplines, the unifying theme being logics arising from modelling the human agent. For a list of areas covered see the Editorial Board. The editors keep close contact with the various application areas, with The International Federation of Compuational Logic and with the book series Studies in Logic and Practical Reasoning. Benefits to authors We also provide many author benefits, such as free PDFs, a liberal copyright policy, special discounts on Elsevier publications and much more. Please click here for more information on our author services. Please see our Guide for Authors for information on article submission. This journal has an Open Archive. All published items, including research articles, have unrestricted access and will remain permanently free to read and download 48 months after publication. All papers in the Archive are subject to Elsevier's user license. If you require any further information or help, please visit our Support Center IMPACT FACTOR . 2016: 0.838 © Clarivate Analytics Journal Citation Reports 2017 ABSTRACTING AND INDEXING . Zentralblatt MATH Scopus EDITORIAL BOARD . Executive Editors Dov M. Gabbay, King's College London, London, UK Sarit Kraus, Bar-llan University,
    [Show full text]
  • David Hartley a Promise of Funding Has Been Received and an Outline Plan Including Cost Estimates and Timescales Has Been Drawn Up
    Issue Number 54 Spring 2011 Computer Conservation Society Aims and objectives The Computer Conservation Society (CCS) is a co-operative venture between the British Computer Society (BCS), the Science Museum of London and the Museum of Science and Industry (MOSI) in Manchester. The CCS was constituted in September 1989 as a Specialist Group of the British Computer Society. It is thus covered by the Royal Charter and charitable status of the BCS. The aims of the CCS are: To promote the conservation of historic computers and to identify existing computers which may need to be archived in the future, To develop awareness of the importance of historic computers, To develop expertise in the conservation and restoration of historic computers, To represent the interests of Computer Conservation Society members with other bodies, To promote the study of historic computers, their use and the history of the computer industry, To publish information of relevance to these objectives for the information of Computer Conservation Society members and the wider public. Membership is open to anyone interested in computer conservation and the history of computing. The CCS is funded and supported by voluntary subscriptions from members, a grant from the BCS, fees from corporate membership, donations, and by the free use of the facilities of both museums. Some charges may be made for publications and attendance at seminars and conferences. There are a number of active Projects on specific computer restorations and early computer technologies and software.
    [Show full text]
  • Formal Methods Specification and Verification Guidebook for Software and Computer Systems
    OFFICE OF SAFETY AND MISSION ASSURANCE NASA-GB-002-95 RELEASE 1.0 FORMAL METHODS SPECIFICATION AND VERIFICATION GUIDEBOOK FOR SOFTWARE AND COMPUTER SYSTEMS VOLUME I: PLANNING AND TECHNOLOGY INSERTION JULY 1995 NATIONAL AERONAUTICS AND SPACE ADMINISTRATION WASHINGTON, DC 20546 NASA-GB-002-95 Release 1.0 FORMAL METHODS SPECIFICATION AND VERIFICATION GUIDEBOOK FOR SOFTWARE AND COMPUTER SYSTEMS VOLUME I" PLANNING AND TECHNOLOGY INSERTION FOREWORD The Formal Methods Specification and Verification Guidebook for Software and Computer Systems describes a set of techniques called Formal Methods (FM), and outlines their use in the specification and verification of computer systems and software. Development of increasingly complex systems has created a need for improved specification and verification techniques. NASA's Safety and Mission Quality Office has supported the investigation of techniques such as FM, which are now an accepted method for enhancing the quality of aerospace applications. The guidebook provides information for managers and practitioners who are interested in integrating FM into an existing systems development process. Information includes technical and administrative considerations that must be addressed when establishing the use of FM on a specific project. The guidebook is intended to aid decision makers in the successful application of FM to the development of high- quality systems at reasonable cost. This is the first volume of a planned two- volume set. The current volume focuses on administrative and planning considerations for the successful application of FM. Volume II will contain more technical information for the FM practitioner, and will be released at a later date. Major contributors to the guidebook include, from the Jet Propulsion Laboratory: Rick Covington (editor), John Kelly (task lead), and Robyn Lutz; from Johnson Space Center: David Hamilton (Loral) and Dan Bowman (Loral); from Langley Research Center: Ben DiVito (VIGYAN) and Judith Crow (SRI International); and from NASA HQ Code Q: Alice Robinson.
    [Show full text]
  • Computer Conservation Society
    Issue Number 52 Autumn 2010 Computer Conservation Society Aims and objectives The Computer Conservation Society (CCS) is a co-operative venture between the British Computer Society (BCS), the Science Museum of London and the Museum of Science and Industry (MOSI) in Manchester. The CCS was constituted in September 1989 as a Specialist Group of the British Computer Society. It is thus covered by the Royal Charter and charitable status of the BCS. The aims of the CCS are: To promote the conservation of historic computers and to identify existing computers which may need to be archived in the future, To develop awareness of the importance of historic computers, To develop expertise in the conservation and restoration of historic computers, To represent the interests of Computer Conservation Society members with other bodies, To promote the study of historic computers, their use and the history of the computer industry, To publish information of relevance to these objectives for the information of Computer Conservation Society members and the wider public. Membership is open to anyone interested in computer conservation and the history of computing. The CCS is funded and supported by voluntary subscriptions from members, a grant from the BCS, fees from corporate membership, donations, and by the free use of the facilities of both museums. Some charges may be made for publications and attendance at seminars and conferences. There are a number of active Projects on specific computer restorations and early computer technologies and software.
    [Show full text]
  • Computer Conservation Society
    Computer Conservation Society Aims and objectives The Computer Conservation Society (CCS) is a co-operative venture between the British Computer Society, the Science Museum of London and the Museum of Science and Industry in Manchester. The CCS was constituted in September 1989 as a Specialist Group of the British Computer Society (BCS). It is thus covered by the Royal Charter and charitable status of the BCS. The aims of the CCS are to Promote the conservation of historic computers and to identify existing computers which may need to be archived in the future Develop awareness of the importance of historic computers Encourage research on historic computers and their impact on society Membership is open to anyone interested in computer conservation and the history of computing. The CCS is funded and supported by voluntary subscriptions from members, a grant from the BCS, fees from corporate membership, do- nations, and by the free use of Science Museum facilities. Some charges may be made for publications and attendance at seminars and conferences. There are a number of active Working Parties on specific computer restorations and early computer technologies and software. Younger peo- ple are especially encouraged to take part in order to achieve skills transfer. Resurrection The Bulletin of the Computer Conservation Society ISSN 0958 - 7403 Number 30 Spring 2003 Contents Generous BCS Support for Bombe Rebuild Project Ernest Morris, Chairman 2 AGM 2 News Round-Up 3 Society Activity 6 CCS Collection Policy 11 DAP snippets Brian M Russell 12 CCS Web Site Information 12 British Computer Corporation | a 1956 Venture Hugh McGregor Ross 13 Edsger Dijkstra remembered Brian Shearing 22 Deciphering Ancient Floppy Discs Kevin Murrell 26 The ICL Archive Hamish Carmichael 28 Forthcoming Events 31 Generous BCS Support for Bombe Rebuild Project Ernest Morris, Chairman CCS members will be familiar with the good progress of the Bombe re- build from the regular reports in Resurrection by John Harper, the project manager.
    [Show full text]
  • The Humble Humorous Researcher: a Tribute to Michel Sintzoff
    The Humble Humorous Researcher A Tribute to Michel Sintzoff Axel van Lamsweerde 1 Many of us lost a close colleague on November 28, 2010. More than that: we lost a friend. One that we used to meet regularly, all over the world, always listening to us, making interesting comments and suggestions on our work, joking on every occasion and making us discover how much fun our business is. Rather than reviewing his work in detail, this note puts more focus on Michel’s rich personality, with the hope that it will bring back fond memories among those who were lucky enough to share some good times with him. The style is intended to be personal and informal. Michel would have hated anything different, to be sure. Born in 1938 in Brussels, Michel completed his master’s degree in Mathematics at the Université catholique de Louvain (UCL) in 1962. After two years of civil service as a maths teacher in Katanga (Congo), he entered the MBLE Research Laboratory in Brussels in 1964 (MBLE stands for “ Manufacture Belge de Lampes et matériel Electrique”). This was a branch of Philips Research Labs specifically dedicated to background research in applied mathematics and computing science. After 18 years of research in programming languages, formal semantics, program analysis and concurrency at MBLE, he joined the newly founded department of Computing Science at UCL in 1982 with new interests in diverse areas such as proof systems, control theory and dynamical systems. Michel contributed to the PhD work of dozens of people in Belgium and France, as supervisor or contributor, without ever having been interested in getting a PhD himself.
    [Show full text]
  • PDF (Dissertation.Pdf)
    Kind Theory Thesis by Joseph R. Kiniry In Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy California Institute of Technology Pasadena, California 2002 (Defended 10 May 2002) ii © 2002 Joseph R. Kiniry All Rights Reserved iii Preface This thesis describes a theory for representing, manipulating, and reasoning about structured pieces of knowledge in open collaborative systems. The theory's design is motivated by both its general model as well as its target user commu- nity. Its model is structured information, with emphasis on classification, relative structure, equivalence, and interpretation. Its user community is meant to be non-mathematicians and non-computer scientists that might use the theory via computational tool support once inte- grated with modern design and development tools. This thesis discusses a new logic called kind theory that meets these challenges. The core of the work is based in logic, type theory, and universal algebras. The theory is shown to be efficiently implementable, and several parts of a full realization have already been constructed and are reviewed. Additionally, several software engineering concepts, tools, and technologies have been con- structed that take advantage of this theoretical framework. These constructs are discussed as well, from the perspectives of general software engineering and applied formal methods. iv Acknowledgements I am grateful to my initial primary adviser, Prof. K. Mani Chandy, for bringing me to Caltech and his willingness to let me explore many unfamiliar research fields of my own choosing. I am also appreciative of my second adviser, Prof. Jason Hickey, for his support, encouragement, feedback, and patience through the later years of my work.
    [Show full text]
  • Systems Architecture of the English Electric KDF9 Computer
    Version 1, September 2009 CCS-N4X2 Systems Architecture of the English Electric KDF9 computer. This transistor-based machine was developed by an English Electric team under ACD Haley, of which the leading light was RH Allmark – (see section N4X5 for a full list of technical references). The KDF9 was remarkable because it is believed to be the first zero-address instruction format computer to have been announced (in 1960). It was first delivered at about the same time (early 1963) as the other famous zero-address computer, the Burroughs B5000 in America. A zero-address machine allows the use of Reverse Polish arithmetic; this offers certain advantages to compiler writers. It is believed that the attention of the English Electric team was first drawn to the zero-address concept through contact with George (General Order Generator), an autocode programming system written for a Deuce computer by the University of Sydney, Australia, in the latter half of the 1950s. George used Reversed Polish, and the KDF9 team was attracted to this convention for the pragmatic reason of wishing to enhance performance by minimising accesses to main store. This may be contrasted with the more theoretical line taken independently by Burroughs. To quote Bob Beard’s article in the autumn 1997 issue of Resurrection, the KDF9 had the following architectural features: Zero Address instruction format (a first?); Reverse Polish notation (for arithmetic operations); Stacks used for arithmetic operations and Flow Control (Jumps) and I/O using ferrite cores with a one microsecond cycle; Separate Arithmetic and Main Controls with instruction prefetch; Hardware Multiply and Divide occupying a complete cabinet with clock doubled; Separate I/O control; A word length of 48 bits, comprising six 8-bit 'syllables' (the precursor of the byte).
    [Show full text]