Atlas 2 at Cambridge Mathematical Laboratory (And Aldermaston and CAD Centre)
Total Page：16
File Type：pdf, Size：1020Kb
Atlas 2 at Cambridge Mathematical Laboratory (And Aldermaston and CAD Centre) Barry Landy, November 2012 How it came about The Cambridge Mathematical Laboratory (“Maths Lab”) had a long history of designing its own machines. EDSAC (1949-1958) was the world’s first fully functional stored program (Von Neuman) computer on which it offered a full computing service for users (the world’s first). EDSAC 2 (1958-1965), the first micro-programmed computer, carried on the innovative tradition. However, by 1961 it was time to buy or design a new machine, but this time Maurice Wilkes didn’t want another home-made one. He had £250,000 offered by the UK government available to buy a replacement for EDSAC 2. This could have bought a KDF9 but that was only about the power of EDSAC 2. The only viable machines were an IBM 7090 or an Atlas, neither of which could be afforded. The price tag for the Atlas was £2,000,000. Peter Hall (Ferranti’s Computer Manager at the time) suggested they sell Cambridge the processing unit of Atlas at “works cost”, with Cambridge and Ferranti designing a simpler memory and peripheral arrangement, thereby providing a machine for Cambridge, and a cheaper version of Atlas for Ferranti to market. David Wheeler was design authority for the joint team, responsible for design of the memory access and peripheral coordinator and any consequential modifications to the basic hardware. The wiring diagrams were designed on EDSAC 2 by Roger Needham. While the hardware was built at West Gorton it was agreed that commissioning would happen at Cambridge and two engineers from West Gorton were seconded to Cambridge for that purpose. The Eagle pub welcomed them with open arms! The machine was officially christened Titan, in line with the Ferranti tradition of choosing names from classical mythology, but was later re-named Atlas 2 by the marketing people. In Cambridge the name Titan stuck as the prototype of Atlas 2. Hardware – what was different Atlas had a full one-level store with page address registers and a high-speed drum, and these were removed for Atlas 2. Instead user programs were located dynamically by hardware (more details later) thus saving huge hardware costs. The Atlas instruction had a 10 bit function part; if the first bit was zero the remainder defined a full set of hardware implemented instructions. If the top bit was one the remaining bits defined (up to) 512 "extracodes" which called supervisor functions (like accessing magnetic tape). On ATLAS these were implemented in fixed memory which could be modified by the operating system design team (brushes); to save cost, this was changed for TITAN so that the extracodes were implemented entirely in Main Memory. This was much slower for instruction access but considerably simpler to maintain. Simplifications were also made to the peripheral control logic. Atlas 2 was thus of a similar speed to Atlas but without the flexibility and power of the one-level store and with several other cost saving decisions, including slower main memory (the Atlas 2 design permitted 2 microsecond or 5 microsecond memory; naturally we had the slower). It was therefore much cheaper! In common with Atlas the memory consisted of words 48 bits long, which could be divided into 8 separately addressable 6 bit characters or 2 24 bit half words. TITAN initially had 32K words of store, soon increased to 64K and eventually to 128K (so 1Mb of 6 bit bytes). Hardware arrived in Cambridge in 1963; software design had already started (on paper); development could start as soon as enough of the hardware was commissioned. The memory management system comprised a single base and limit pair of registers with two other registers to lock peripheral transfers implemented as 4 registers, R1-R4. R1 specified the starting point of a program; the user address was ORed with R1 to provide the absolute hardware address being accessed. The OR feature made allocating main memory quite complicated. R2 specified the size of the program region. R4 specified the lower end and R3 the upper end of a locked region within the R1,R2 limits; the program was not allowed to access this sub region. This feature permitted IO transfers (especially intended for magnetic tape). This design of memory control allowed full user protection, so that, even though multiple programs might be active, a program could only read or write the area specified in the control registers. The major drawback was that the memory allocated to one program had to be contiguous in real memory. Software – why the Atlas Supervisor couldn’t be used It had always been Cambridge’s intention to write a multiprogramming supervisor similar to Atlas comprising a job shop system (that is, jobs input from paper tape or punched cards taken from a physical queue, with the results posted back in a similar queue) with efficient I/O buffering to maximise throughput. The Atlas supervisor, which was already being written, achieved this aim by managing and exploiting the one-level store. For Atlas 2, having no one level store, we had to design and implement a different system, although we learnt from the Manchester effort and used the same methodology in terms of Interrupt processes (IRs), Supervisor Extracode Routines (SERs) and so on. The Atlas 2 Supervisor was a joint project of Ferranti and Cambridge. In the initial design stages the software team was small, comprising David Barron and David Hartley from Cambridge and Chris Spooner and others from Ferranti (which became ICT in the course of the development). In 1963 Barry Landy joined the team, and his first task was to write a diagnostic system to be used on an IBM selectric typewriter to enable the supervisor to be debugged. (Although he had first to write a program to discover the character code!) Meanwhile David Hartley was writing the nucleus, which while based on the Atlas work, had to be different from the Atlas nucleus because of the lack of a one level store. Roger Needham joined the software team when he had finished helping David Wheeler with the hardware developments. The main external distinction between the two systems was that Atlas used a drum for page and IO buffering, and Atlas 2 did not have drums, and so was designed to make use of magnetic-tape for I/O buffering, known as the “swinging well”. This in practice never operated at Cambridge but did in the second Atlas 2 at Aldermaston (see below). While it worked at Aldermaston in their “one job at a time” mode of working I personally doubt it would have worked well for a multiprogramming system. Luckily as it happened we did not have to find out. Magnetic tape was also used for paging-in parts of the supervisor which were not permanently resident in main memory. The entire Supervisor eventually comprised some 40K words of which about 15K was permanently resident. The remainder was supervisor pages, written in blocks of 512 words, which could be transferred to a free block of memory in one IO operation. The ICT team eventually grew to 21 people, and the integration of all these pieces of software written by many hands of various standards of ability was done in Cambridge, where by 1964 a day shift for users was operating (as happened on Atlas 1) under a temporary supervisor and a temporary compiler developed by Peter Swinnerton-Dyer. As a result the testing and integration of new pieces of the Main Supervisor had to be done in the evening and night (under the control of Barry Landy). Eventually the team divided into two; the Cambridge team to finish the system as planned, and the Ferranti/ICT team to modify it to suit Aldermaston Cambridge University service – how time sharing rescued the reputation In 1965, during the Cambridge development, Wilkes discovered Time Sharing at MIT, and demonstrated it at Cambridge using a 10 character per second teleprinter (!), on a telex line across the Atlantic. He insisted (rightly) that the supervisor should be modified in mid flight to permit on-line interaction with terminals. Since we had insisted on maintaining multi processing job control we were fortunate that the basics of the operating system were already suitable (or seemed to be). However there were plainly many things lacking in the hardware. As originally planned TITAN was fine for a job queue system with no permanent storage (the way that EDSAC 2 worked). A terminal interaction system required a file store and some basic swapping. In the original system design, memory allocation to jobs (ie, selection of which jobs to run) was rudimentary. Jobs were selected from the (tape) queue based on whether they would fit into the available memory on a first come first served basis. This would not work for a multi user system and so more sophisticated control was needed. Finally there had to be some way of interfacing the terminals (10 cps teletypes) to the hardware. These problems were variously solved. A Data Products 16M word disc was acquired for the filestore in 1965 (actually as a gift from Basil de Ferranti). TITAN eventually had two such discs. Each disc had independent heads for each platter, and most importantly a fixed head region which in effect we used as a drum. The disc was also used for swapping supervisor pages and for buffering the data streams of active programs instead of using magnetic tape. David Wheeler altered the design of the memory location registers described above by adding an extra control register R5. R5 specified in the bottom 18 bits the address of a piece of store which could be 64, 512, or 4096 words long; of the top 6 bits 2 control bits were used to specify the size, and the remaining 4 bits specified that one or more of four particular pages of the region (2048 to 4096 relative) were locked for transfers.