Milestone-Proposal:The Atlas computer and the Invention of Virtual Memory: Difference between revisions

From IEEE Milestones Wiki
No edit summary
No edit summary
Line 73: Line 73:
<b><u><i>4. The Problems</i></u></b>
<b><u><i>4. The Problems</i></u></b>


Quoting from [Kilburn 1962]: “In a universal high-speed digital computer it is necessary to have a large-capacity fast-access main store. While more efficient operation of the computer can be achieved by making this store all of one type, this step is scarcely practical for the storage capacities now being considered. For example, on Atlas it is possible to address 10<sup>6<sup> words in the main store. In practice on the first installation at Manchester University a total of 10<sup>5<sup>  words are provided, but though it is just technically feasible to make this in one level it is much more economical to provide a core store (16,000 words) and drum (96,000 words) combination.”
Quoting from [Kilburn 1962]: “In a universal high-speed digital computer it is necessary to have a large-capacity fast-access main store. While more efficient operation of the computer can be achieved by making this store all of one type, this step is scarcely practical for the storage capacities now being considered. For example, on Atlas it is possible to address 10<sup>6</sup> words in the main store. In practice on the first installation at Manchester University a total of 10<sup>5</sup>  words are provided, but though it is just technically feasible to make this in one level it is much more economical to provide a core store (16,000 words) and drum (96,000 words) combination.”
In addition to this, in early computer systems peripheral transfers took place under direct program control using input/output instructions which normally required several milliseconds for their completion.  By the time the Atlas computer was developed, the disparity between processor and peripheral speeds had become so great (of the order of 10,000:1) that it was essential that peripherals be operated on a time division basis, with each peripheral interrupting the main program when it required attention.  Since the routines controlling these peripherals were required to be resident in store concurrently with the main user program, and since the system was extended to allow several user programs to co-exist in store, it was no longer feasible either to optimise programmed transfers between the core and drum stores (so as to eliminate the drum access time of 6 ms) or even to allow users to program transfers within a shared physical store when they had no knowledge of other users' requirements.  Consideration of these problems led, in 1958 [Edwards 2020], to the idea of providing users with a virtual address rather than an actual physical address and to the development of a paging system to map virtual addresses on to the real, physical storage devices.  Thus the integration of the Atlas core-drum combination into an apparently one-level store was a function of the machine itself, rather than a software facility, as it had been on earlier machines such as Mark I and Mercury.
In addition to this, in early computer systems peripheral transfers took place under direct program control using input/output instructions which normally required several milliseconds for their completion.  By the time the Atlas computer was developed, the disparity between processor and peripheral speeds had become so great (of the order of 10,000:1) that it was essential that peripherals be operated on a time division basis, with each peripheral interrupting the main program when it required attention.  Since the routines controlling these peripherals were required to be resident in store concurrently with the main user program, and since the system was extended to allow several user programs to co-exist in store, it was no longer feasible either to optimise programmed transfers between the core and drum stores (so as to eliminate the drum access time of 6 ms) or even to allow users to program transfers within a shared physical store when they had no knowledge of other users' requirements.  Consideration of these problems led, in 1958 [Edwards 2020], to the idea of providing users with a virtual address rather than an actual physical address and to the development of a paging system to map virtual addresses on to the real, physical storage devices.  Thus the integration of the Atlas core-drum combination into an apparently one-level store was a function of the machine itself, rather than a software facility, as it had been on earlier machines such as Mark I and Mercury.



Revision as of 16:22, 14 January 2021


To see comments, or add a comment to this discussion, click here.

Docket #:2020-12

This Proposal has been approved, and is now a Milestone


To the proposer’s knowledge, is this achievement subject to litigation? No

Is the achievement you are proposing more than 25 years old? Yes

Is the achievement you are proposing within IEEE’s designated fields as defined by IEEE Bylaw I-104.11, namely: Engineering, Computer Sciences and Information Technology, Physical Sciences, Biological and Medical Sciences, Mathematics, Technical Communications, Education, Management, and Law and Policy. Yes

Did the achievement provide a meaningful benefit for humanity? Yes

Was it of at least regional importance? Yes

Has an IEEE Organizational Unit agreed to pay for the milestone plaque(s)? Yes

Has an IEEE Organizational Unit agreed to arrange the dedication ceremony? Yes

Has the IEEE Section in which the milestone is located agreed to take responsibility for the plaque after it is dedicated? Yes

Has the owner of the site agreed to have it designated as an IEEE Milestone? Yes


Year or range of years in which the achievement occurred:

1957 - 1962

Title of the proposed milestone:

The Atlas Computer and the Invention of Virtual Memory 1957-1962

Plaque citation summarizing the achievement and its significance:

Developed at this site in 1957-1962 and operational here until 1971, Atlas was the first computer to implement virtual memory and a multi-user operating system. Atlas was conceived and designed by a University of Manchester team led by Tom Kilburn and built in collaboration with Ferranti Ltd. Virtual memory was rapidly adopted worldwide because of its versatility and has become a critical feature of general purpose computers.

200-250 word abstract describing the significance of the technical achievement being proposed, the person(s) involved, historical context, humanitarian and social impact, as well as any possible controversies the advocate might need to review.


IEEE technical societies and technical councils within whose fields of interest the Milestone proposal resides.


In what IEEE section(s) does it reside?

UK & Ireland Section, Region 8

IEEE Organizational Unit(s) which have agreed to sponsor the Milestone:

IEEE Organizational Unit(s) paying for milestone plaque(s):

Unit: UK & Ireland Section
Senior Officer Name: Matthew Gream (Treasurer)

IEEE Organizational Unit(s) arranging the dedication ceremony:

Unit: UK & Ireland Section
Senior Officer Name: Rod Muttram

IEEE section(s) monitoring the plaque(s):

IEEE Section: UK & Ireland Section, Region 8
IEEE Section Chair name: Mona Ghassemian

Milestone proposer(s):

Proposer name: Professor Roderick I Muttram CEng, FREng, FIET, FIRSE, SMIEEE
Proposer email: Proposer's email masked to public

Proposer name: Roland Ibbett, FRSE, FBCS, CEng, SMIEEE
Proposer email: Proposer's email masked to public

Proposer name: Professor Simon Lavington, CEng, FIET, FBCS,
Proposer email: Proposer's email masked to public

Proposer name: Jim Miles
Proposer email: Proposer's email masked to public

Please note: your email address and contact information will be masked on the website for privacy reasons. Only IEEE History Center Staff will be able to view the email address.

Street address(es) and GPS coordinates in decimal form of the intended milestone plaque site(s):

Brunswick St, The University of Manchester, Manchester M13 9PL. GPS: 53.466050, -2.230643

Describe briefly the intended site(s) of the milestone plaque(s). The intended site(s) must have a direct connection with the achievement (e.g. where developed, invented, tested, demonstrated, installed, or operated, etc.). A museum where a device or example of the technology is displayed, or the university where the inventor studied, are not, in themselves, sufficient connection for a milestone plaque.

Please give the address(es) of the plaque site(s) (GPS coordinates if you have them). Also please give the details of the mounting, i.e. on the outside of the building, in the ground floor entrance hall, on a plinth on the grounds, etc. If visitors to the plaque site will need to go through security, or make an appointment, please give the contact information visitors will need. The Zochonis Building, University of Manchester, The site where the first Atlas was commissioned. See additional document uploaded

Are the original buildings extant?

Yes - proposed site of Plaque

Details of the plaque mounting:

The University will install the plaque on the outside of the Zochonis Building close to the main entrance on Brunswick Street in such a manner that it is easily visible. The height of the plaque will be determined in consultation with the University's Disability Advisory and Support Service.

How is the site protected/secured, and in what ways is it accessible to the public?

The public will be able to view the plaque at all hours. The University has regular security patrols in this area throughout the night.

Who is the present owner of the site(s)?

The University of Manchester

What is the historical significance of the work (its technological, scientific, or social importance)? If personal names are included in citation, include justification here. (see section 6 of Milestone Guidelines)

1. Summary

Providing computer users with large amounts of fast memory and time-sharing the computer itself between multiple tasks are perennial issues for computer designers. Fast memories are relatively small and expensive, while large memories made from cheaper technologies are relatively slow, so designers use a combination of the two and then need a system to move memory contents between them without the user or the program being aware that this is happening. The virtual memory concept introduced as part of the Atlas project at the University of Manchester in the late 1950s was designed to do just this.

“ … The virtual memory concept introduced as part of the Atlas project at the University of Manchester in the late 1950s was designed to do just this. “The Atlas project produced the patents for Virtual Memory. I would claim that Virtual Memory is the most significant computer design development in the last 50 years. Certainly it is the most widely used.”*

“The only computers today without virtual memory are a few supercomputers, embedded processors and older personal computers.” [Hennessey 2003]. Originally called 'one-level storage' [Kilburn 1962], Atlas gave each user the illusion of having a very large fast memory by automating the transfer of code and data between a small fast main core store and a large, much slower, magnetic drum store. Prior to this, on Mercury, for example, programmers spent vast amounts of time augmenting basic algorithms with 'overlay sequences' - calls on the secondary memory to transfer data blocks (often referred to as pages) into main memory. Kilburn et al believed that the one-level storage mechanism would eliminate the need for manual overlays and estimated that programmer productivity would be improved by a factor of up to 3. The system for implementing this concept involved the use of a hardware mechanism known as paging together with appropriate software in an operating system known on Atlas as the Supervisor [Kilburn 1961].

Footnote: Robin Kerr at the December 2012 Atlas 50th Anniversary Symposium, reported in [Lavington 2012]. Robin Kerr was a member of the Atlas team at Manchester from 1959 to 1964 and subsequently worked for a number of American computing corporations, including Control Data, GE’s Corporate Research Labs and Schlumberger.

2. Virtual Memory

One of the best descriptions of virtual memory is that written by Peter Denning in [Denning 1970]: “In 1961** the group at Manchester, England, published a proposal for a one-level store on the Atlas computer, a proposal that has had profound influence on computer system architecture. Their idea, known now as virtual memory, gives the programmer the illusion that he has a very large main memory at his disposal, even though the computer actually has a relatively small main memory. At the heart of their idea is the notion that "address" is a concept distinct from "physical location". It becomes the responsibility of the computer hardware and software automatically and propitiously to move information into main memory when and only when it is required for processing, and to arrange that program-generated addresses be directed to the memory locations that happen to contain the information addressed. The problem of storage allocation (for objects represented in virtual memory) thus vanishes completely from the programmer's purview and appears in that of the computer system. By basing memory use on system-observed actual use of space, rather than (poor) programmer estimates of space, virtual memory is potentially more efficient than pre-planned memory allocation, for it is a form of adaptive system.”

Footnote: Denning references the definitive one-level storage paper [Kilburn 62] but also a brief paper [Fotheringham 1961] presented at an ACM symposium in June 1961 and later reproduced in CACM. Fotheringham states that "the ideas and concepts described in this paper were conceived and developed by the University Computer Department" and also refers to [Kilburn 1962] saying that it had been submitted for publication.


3. The Atlas Project

Atlas was the fourth computer system to be designed and built at the University of Manchester. Previous systems had led to three commercially-available production derivatives: the Ferranti Mark I, the Ferranti Mercury and the Metropolitan Vickers MV950, all of which enjoyed commercial success. The Mark I was the first commercially produced computer to be delivered anywhere in the world (in February 1951), and its prototype, the so-called 'Baby' machine was the first electronic digital computer to run a stored program (on 21st June 1948). Mercury was one of the first computers to include a floating-point hardware arithmetic unit, and the `transistor machine', produced commercially in 1956 as the MV950, was believed to be the world's first transistor computer when it became operational in November 1953. The Atlas project, led by Tom Kilburn, was another joint venture with Ferranti Ltd. The first production version of Atlas was officially inaugurated at the University in December 1962 (a detailed history of the Atlas project can be found in [Lavington 2012]). The virtual memory concept arose as the solution to a number of problems. A photo of the Manchester installation is shown in the uploaded file Media:Atlas Photo and figure 1.pdf.

4. The Problems

Quoting from [Kilburn 1962]: “In a universal high-speed digital computer it is necessary to have a large-capacity fast-access main store. While more efficient operation of the computer can be achieved by making this store all of one type, this step is scarcely practical for the storage capacities now being considered. For example, on Atlas it is possible to address 106 words in the main store. In practice on the first installation at Manchester University a total of 105 words are provided, but though it is just technically feasible to make this in one level it is much more economical to provide a core store (16,000 words) and drum (96,000 words) combination.” In addition to this, in early computer systems peripheral transfers took place under direct program control using input/output instructions which normally required several milliseconds for their completion. By the time the Atlas computer was developed, the disparity between processor and peripheral speeds had become so great (of the order of 10,000:1) that it was essential that peripherals be operated on a time division basis, with each peripheral interrupting the main program when it required attention. Since the routines controlling these peripherals were required to be resident in store concurrently with the main user program, and since the system was extended to allow several user programs to co-exist in store, it was no longer feasible either to optimise programmed transfers between the core and drum stores (so as to eliminate the drum access time of 6 ms) or even to allow users to program transfers within a shared physical store when they had no knowledge of other users' requirements. Consideration of these problems led, in 1958 [Edwards 2020], to the idea of providing users with a virtual address rather than an actual physical address and to the development of a paging system to map virtual addresses on to the real, physical storage devices. Thus the integration of the Atlas core-drum combination into an apparently one-level store was a function of the machine itself, rather than a software facility, as it had been on earlier machines such as Mark I and Mercury.

5. Virtual Memory Hardware: the Page Address Registers

The central store (core + drum) was subdivided into blocks of 512 words. The main core store was also partitioned into blocks of this size which for identification purposes were called pages. Associated with each of these core store page positions was a "page address register" (PAR) which contained the address of the block of information at present occupying that page position see figure 1 Media:Atlas Photo and figure 1.pdf. When access to any word in the central store was required, the digits of the demanded block address were compared with the contents of all the page address registers. If an equivalence (match) occurred between the required page and a page address stored in one of the associative registers, that register indicated a 1 while the others indicated a 0. The 32 outputs from the associative registers were encoded into a 5-bit binary number and concatenated with the 9 LINE digits from the required virtual address to produce the real address to be sent to the core store. If there was no equivalence, the required page was not in the core store, and the program could not continue until it was. A 'page fault' interrupt was therefore generated and the assistance of the operating system (known as the Supervisor) invoked. The Supervisor used the full page table in order to locate the required page, initiated the necessary transfer from the drum into an empty core block, and set up the corresponding Page Address Register. It also initiated the transfer of an existing page from the core back to the drum in order to create an empty core block for the next page fault.

The choice of page to transfer out of core was made by a learning program which attempted to optimise these transfers such that pages currently in use were not chosen for rejection. The operation of this program was assisted by the provision of a use digit in each page register, which was set every time the corresponding page was accessed. All 32 digits were read and reset at regular intervals (normally every 1024 instructions), and their values added to a set of running totals maintained and used by the learning program. Each of the PARs in Atlas also contained another digit, the lock-out digit, which prevented user programs from accessing a page even though it was core-resident. This served two purposes. Firstly, it prevented programs from accessing pages to which drum, magnetic tape or peripheral transfers were taking place; with the lock-out digit set, access to that page was only permitted if the address had been generated by the drum or tape systems, or as a result of a peripheral transfer. Secondly, it prevented interference between programs co-existing in the core store; whenever the Supervisor caused a change from one program to another, it protected the pages belonging to the suspended program by setting their lock-out digits. Virtual memory thus provided an elegant way to partition the multiprogrammed memory so that users could not access each other's data. (Much of this description given above of the PARs is taken from [Ibbett 1989] Section 3.2.2.) The UK National Research Development Corporation (NRDC), acting on behalf of the University, applied for and was granted a number of UK patents relating to aspects of the Atlas design, especially paging. The relevant application numbers were 976499 (filed 16/3/1960), 979632 (filed 20/4/1960) and 979633 (filed 20/4/1960). All three were also filed in the USA at about the same time and some years later a licence to use these patents was granted to IBM. In the mid 1970s ICL contested the validity of the paging patent with respect to its implementations of paging in the ICL 1906 and 2900 series, on the grounds that these were different from that described in the patent. However, the specific implementation described in the patent is just an illustrative example and the scope of the claim in the patent is not limited to this example. By 1981 the legal case had been settled in favour of NRDC/UoM, as witnessed by ICL making a payment of £80,000 in settlement and thus acknowledging that the University had indeed invented virtual memory.

6. Replacement Algorithms

The 'learning algorithm' at the heart of the Atlas learning program assumed every page was part of a loop and estimated the cycle times of each page. When a page fault occurred, it used these estimates to predict which page would not be used for the longest time into the future, and replaced that one. This was the first so-called 'replacement algorithm'. It did not work well for programs that did not have well defined loops, and spawned an extensive research program at Manchester and elsewhere to determine how to do replacement well for a wide variety of programs. A research group at IBM Yorktown, for example, did extensive experimental tests on virtual memory in the M44/44X project ([Denning 1981 cites several M44/44X papers) that provided the data needed for robust design of virtual memory. Early 'third generation OS' such as RCA Spectra 70 and Multics in the mid-1960s extended the Atlas idea to multi-access systems and uncovered various performance issues that could make virtual memory systems unstable, e.g. the problem of 'thrashing', a sudden collapse of CPU throughput caused by excessive paging as different programs stole main memory page space from each other. Denning's development of the “working set model” was particularly important in solving this problem and remains so to this day [Denning 2020].

7. Text Book Material

In [Denning 1970] Denning continued: “By the mid-1960s the ideas of virtual memory had gained widespread acceptance, and had been applied to the internal design of many large processors ...”. Material concerning Atlas had also begun to feature in major undergraduate textbooks, though [Denning 1970] remained the definitive tutorial reference for operating systems for at least a decade.

In the 1970s the classic undergraduate computer architecture text book was “Computer Structures: Readings and Examples” by C. Gordon Bell and Allen Newell. This book was revised in 1982, mainly by Dan Siewiorek, and appeared as “Computer Structures: Principles and Examples” [Siewiorek 1982]. Both versions reproduce the original one-level store paper and by way of introduction in [Siewiorek 1982] the authors wrote (pp 104-105):

“The Atlas is one of the most important machines described in this book. The prototype was originally designed and constructed at Manchester University. The Atlas 1 and Atlas 2 were produced by Ferranti [Ltd] . Atlas 1 is the most interesting; it incorporates most of the features of the Atlas prototype. … Two original features, one-level storage and extracodes, have been copied in many other machines. A one-level store is common in most new time-shared or multiprogrammed machines. …. Atlas was about the earliest computer to be designed with a software operating system and the idea of the user machine in mind.”

In 1990 a new major undergraduate text book appeared: “Computer Architecture: a Quantitative Approach” by John L. Hennessey and David A Patterson. In Section 5.18 of the third edition [Hennessey 2003], the authors wrote:

”Although the pioneers of computing knew of the need for a memory hierarchy and coined the term, the automatic management of two levels was first proposed by Kilburn et al [1962]. It was demonstrated with the Atlas computer at the University of Manchester. This computer appeared a year before the IBM 360 was announced. Although IBM planned for its introduction with the next generation (System/370), the operating system TSS wasn't up to the challenge in 1970. Virtual memory was announced for the 370 family in 1972, and it was for this computer that the term “translation lookaside buffer” was coined [Case 1978]. The only computers today without virtual memory are a few supercomputers, embedded processors and older personal computers.”

The Atlas operating system [Supervisor] also features in text books on operating systems, e.g. Section 18.3 of the 9th edition of “Operating system Concepts” by Abraham Silberschatz, Peter B. Galvin and Greg Gagne [Silberschatz 2014]: “The Atlas operating system was designed at the University of Manchester in England in the late 1950s and early 1960s. Many of its basic features that were 
novel at the time have become standard parts of modern operating systems”.

8a. Example Architecture with Virtual Memory – IBM System/370

[Case 1978] ("Architecture of the IBM System/370" ) appeared in January 1978 in a special issue of the Communications of the ACM on computer architecture. In it the authors wrote:

“The single item that most distinguishes the architecture of System/370 from its predecessor, System/360, is the availability of a dynamic-address-translation facility, which allows programming systems to efficiently implement a group of functions which are collectively known as virtual storage. This sytem (sic) incorporates paging from a backing store as introduced in Atlas [Kilburn 1962],” [and licensed from NRDC, as described above].

An earlier paper from staff at the IBM Thomas J. Watson Research Center entitled “Dynamic Storage Allocation Systems” [Randell 1968] describes the IBM System/360 Model 67. The success of Model 67 as a time-sharing system eventually led to the inclusion of virtual memory in the System/370. Appendix A1 of this paper includes the following description of Atlas:

~The Ferranti ATLAS computer [Kilburn 1962] was the first to incorporate mapping mechanisms which allowed a heterogeneous physical storage system to be accessed using a large linear address space. The physical storage consisted of 16,384 words of core storage and a 98,304 word drum, while the programmer could use a full 24-bit address representation.

This was also the first use of demand paging as a fetch strategy, storage being allocated in units of 512 words. The replacement strategy, which is used to ensure that one page frame is kept vacant, ready for the next page demand, is based on a “learning program”'. [A description of the learning program follows in the paper].

8b. Example Architecture with Virtual Memory – DEC PDP-10

Also in the January 1978 special issue on the Communications of the ACM on computer architecture was a paper entitled “The Evolution of the DECsystem 10” [Bell 1978a]. It makes several references to Atlas, e.g. “In architecture, the Manchester Atlas was exemplary … because it illustrated a number of good design principles. Atlas was multiprogrammed with a well-defined interface between user and operating systems, had a very large address space ....” and “The page table was more elaborate than that of the Atlas … whose main goal was to provide a one-level store whereby large programs could run on small physical memories.” This paper was reproduced as Chapter 21 of “Computer Engineering” by Bell, Mudge and McNamara [Bell 1978b]. The book also makes several other references to Atlas.

8c. Example Architecture with Virtual Memory – Multics

The initial ideas for the design of the MIT Multics system (Multiplexed Information and Computing Service) appeared in “Virtual Memory, Processes, and Sharing in Multics” [Daley 1968]. In the initial Summary, the authors wrote:

“The value of a computer system to its users is greatly enhanced if a user can, in a simple and general way, build his work upon procedures developed by others. The attainment of this essential generality requires that a computer system possess the features of equipment-independent addressing, an effectively infinite virtual memory, and provision for the dynamic linking of shared procedure and data objects.”

Multics was intended to serve the computing needs of a large community of users with diverse interests, operating principally from remote terminals. One of the objectives was “To give the system responsibility for managing the distribution of information among the levels of the physical storage hierarchy. The efficient multiprogramming of many computations makes this essential, but of greater importance is the fact that users are relieved of the burden of pre-planning the transfer of information between storage levels, and programs become independent of the nature of the auxiliary storage devices in the system. …. [This objective] led to the design of a computer system (the General Electric Model 645) embodying the concepts of paging [8] and segmentation on which the initial implementation of Multics will run.” (Here [8] = [Kilburn, 1962])

8d. Example Architecture with Virtual Memory – CDC Star 100 and Cyber 205

The Star-100 was CDC's first venture (in 1974) into providing hardware support for vector processing but it also included virtual memory. Only two Star-100s were delivered but the ideas and experience gained from this project were carried forward first into the Cyber 203 and later into the Cyber 205. Neil Lincoln in [Lincoln 1982] makes no specific reference to Atlas but the Cyber 205 virtual memory system he describes corresponds very closely to the Atlas system, except that there are two page sizes, as indeed there were in MU5, the successor machine to Atlas at Manchester.

“The virtual memory system provided two units of physical memory allocation (called pages). The smaller unit contains 4096 bytes [actually 512 words, like Atlas] and is called small page. The larger unit, called large page, contains 524,288 bytes. This large page was intended for major production jobs that would consume most of the machine resources.”

8e. Example Architecture with Virtual Memory – MU5 and ICL 2900 Series

At the University of Manchester, a follow-on project to Atlas was mooted in 1966 and started in earnest in 1968. The resulting computer system became known as MU5. Many publications resulted from the MU5 project, e.g. [Ibbett 1978]. In a retrospective article on MU5 in 1999 [Ibbett 1999], the author wrote:

“Many of those involved in the project were new to the business of designing a real computer, and found themselves in an environment with much inherited wisdom, especially Tom Kilburn's, from previous Manchester projects. If there was a choice over some issue, “should it be like Atlas, or should it be different?, then there would have to be a good reason to make it different. Of course, many things were different but […...] “The use of virtual addressing was another inherited characteristic (it had, after all, been invented as part of the Atlas project) though not before the virtues of real addressing (e.g. avoiding the address translation time delay and the ability to move complete logical entities such as procedures or arrays between levels in the storage hierarchy) had been re-considered.” The conclusion was that the advantages of virtual memory far exceeded any potential advantages of any other known approach.

MU5 was a major influence on the commercially successful ICL 2900 series of computers. According to John Buckle in Chapter 1 of [Buckle 1978]:

“... the single most important external influence on the 2900 architecture was almost certainly the Manchester University MU5 system. This is hardly surprising. The association between Ferranti Computers, a constituent of ICL, and Manchester University went back to Mark 1 and had progressed through Mercury and Atlas. …. Many of the fundamental approaches to storage management and process structure on 2900 are directly derived from the MU5”

What obstacles (technical, political, geographic) needed to be overcome?

In the mid 1950s there was a concern in government circles that Britain was falling behind the United States in the production of high-performance computers and that no serious effort was being made to produce at least one really fast machine. In 1956 Kilburn's team began to give this issue serious thought and in early 1957 "A decision was made within the research group led by Tom Kilburn to design and build a fast computer with a target speed of a microsecond per instruction. The project was called Muse (microsecond engine). This would be a completely parallel machine and would have to use the latest high-speed germanium junction transistors then just becoming available . To support the project, a sum of £50K was made available from the Department’s own research fund" [Lavington 2012] and [Lavington 2012 (2)]. Whilst Muse was in its early stages, Kilburn had talked to several potential users of large computers including the UK Atomic Energy Authority and some big commercial users. From the former came the design specification for an instruction speed approaching one order per microsecond, whilst from the latter came the need to attach a large number of peripherals of various types. Both classes of user needed an immediate-access storage capacity far in excess of anything then available. It became clear at the outset that special techniques would be needed if efficient use of equipment and rapid turnaround were to be achieved in a computer system consisting of many interconnected units each with widely differing speeds. This applied not only to slow and fast peripherals and backing stores but also to high-speed transistor logic circuits interfacing with medium-speed moderate-sized main stores. The special techniques that were eventually employed included what are now known as multi-programming, job scheduling, spooling, interrupts, pipelining, interleaved storage, autonomous transfer units, all of which depended upon virtual storage and paging – though none of these techniques had been invented when the project started.

It was clear to Kilburn that the Electrical Engineering Department at Manchester had nowhere near the resources to see through such a project. (It also seemed clear to some contemporary commentators that the lavish scale of Muse would be more than sufficient to satisfy the computing demands of the entire country and that the project was rather ridiculous!). Kilburn spent the next 18 months attempting to get financial support for Muse, whilst the initial design work and assessment of technology was in progress. Ferranti, which had benefitted from two earlier collaborations (Mark I and Mercury) at first felt unable to support the Muse proposal and government finance was not forthcoming. The University team therefore went ahead with a limited version of Muse using normal departmental resources and earnings from the Mark I project. However, in October 1958 (confirmed officially in January 1959) Ferranti decided to become involved in the project and in May 1959 the UK National Research Development Corporation provided £300,000 to Ferranti, repayable through a levy on eventual sales.

By the start of 1959 the computer had been re-named Atlas and was thereafter developed as a joint University/Ferranti venture under Tom Kilburn. During 1959 the hardware design of Atlas was substantially completed, plans for the compilers were in hand using the Compiler Compiler, but the magnitude of problems associated with the Supervisor (operating system) had not been fully realised. It was with the Supervisor that Ferranti, in the form of David Howarth, made a fundamental contribution to the Atlas design [Kilburn 1961]. When Atlas was officially inaugurated on 7th December 1962 it was considered to be the most powerful computer in the world, the Ferranti salesmen equating it to four IBM 7094s. Ferranti sold two other full versions of Atlas – one to a joint London University/British Petroleum consortium and the other to the UK National Institute for Research into Nuclear Science at Harwell. By the mid 1960s, when the useful time on the Manchester Atlas was shared between the Ferranti and University computing services, anything up to 1,000 programs were being run in a 20-hour 'day'. The Manchester Atlas was closed down on 30th September 1971.

What features set this work apart from similar achievements?

The problem of integrating a relatively small fast memory and a large slow memory was well known when Atlas was being designed. Indeed previous computers designed by the Manchester team, such as the Ferranti Mark I and Mercury had a small random-access primary and a larger drum secondary store but in order to take advantage of the speed of the primary store the user had to program transfers between the two. Computers at this time were single user, so the processor could do nothing useful while the transfers were taking place. Various systems were devised in software to relieve the programmer of the tedium of organising these transfers, e.g. interpretive coding on the Mark I and Mercury, but the performance loss remained.

In the Atlas virtual memory system, a combination of hardware and system software made these transfers entirely automatic and, because the system allowed multiple programs to be co-resident in the main store, allowed the processor to continue to do useful work while they took place. No other system at that time had this capability.

There is a claim that virtual memory had been invented prior to Atlas. In [Jenseen 2004] the author claims that the first documentation of virtual memory appeared in 1956 in a technical report by Fritz Rudolf Güntsch [Güntsch 1956] and subsequently in his Technical University of Berlin doctoral thesis in 1957. However, Jenseen appears not to have understood the virtual memory concept, since the computer proposed by Güntsch (but never built) had an address space of 105 which mapped exactly on to the 105 words of the drums, i.e. the addresses were real addresses and there was no form of indirect mapping, a key feature of virtual memory. What Güntsch did invent was a form of cache memory, since his high-speed memory was intended to contain a copy of some blocks of code or data taken from the drums. Indeed he wrote (as quoted in translation in [Jenseen 2004]):

“The programmer need not respect the existence of the primary memory (he need not even know that it exists), for there is only one sort of addresses by which one can program as if there were only one storage.”

This is exactly the situation in computers with cache memory, one of the earliest commercial examples of which was the IBM System/360 Model 85 [Liptay 1968]. In the Model 85 all addresses were real addresses referring to the main core store. A semiconductor cache store, invisible to the user, was used to hold those portions of the main store in use by the currently executing program. This is exactly analogous to Güntsch's system, designed as a means to improve performance, rather than to solve the problems involved in multi-programming.

Tom Kilburn received numerous awards and accolades for his pioneering work, including three from the IEEE Computer Society: the W. Wallace McDowell Award in 1971 “For his achievement in designing and building some of the first — as well as some of the most powerful — computers in the world.”, the Computer Pioneer Award in 1982 and the Eckert-Mauchly Award in 1983.

Supporting texts and citations to establish the dates, location, and importance of the achievement: Minimum of five (5), but as many as needed to support the milestone, such as patents, contemporary newspaper articles, journal articles, or chapters in scholarly books. 'Scholarly' is defined as peer-reviewed, with references, and published. You must supply the texts or excerpts themselves, not just the references. At least one of the references must be from a scholarly book or journal article. All supporting materials must be in English, or accompanied by an English translation.

[Bell 1978a] “The Evolution of the DECsystem 10”, C.G. Bell, A. Kotok, T.N. Hastings, R. Hill, Communications of the ACM, 21, January 1978, pp 44–63.Media:Bell 1978a.pdf

[Bell 1978b] “Computer Engineering”, C.G. Bell, J.C. Mudge, J.E. McNamara, Digital Equipment Corporation, 1978.

[Buckle 1978] “The ICL 2900 Series, J.K. Buckle, The Macmillan Press, London, 1978. [Case 1978] "Architecture of the IBM System/370", R.P. Case, A. Padegs, Communications of the ACM, 21, January 1978, pp 73–96. Media:Case 1978.pdf

[Daley 1968] “Virtual Memory, Processes, and Sharing in Multics”, R.C. Daley, J.B. Dennis, Communications of the ACM 11, May 1968, pp 306-312. Media:Daley 1968.pdf

[Denning 1970] "Virtual Memory", P. Denning, Computing Surveys, Vol. 2, No. 3, September 1970. Media:Denning 1970.pdf

[Denning 1981] “Performance Modeling: Experimental Computer Science at its Best”, Communications of the ACM, President's Letter, November 1981.Media:Denning 1981.pdf

[Denning 2020] P. Denning, “Working Set Analytics”, to be published in Computing Surveys.

[Edwards 2020] D.B.G. Edwards, Private communication (the exact date in 1958 was never recorded), 2020.

[Fotheringham 1961] “Dynamic storage allocation in the Atlas computer, including an automatic use of a backing store”, J. Fotheringham, Communications of the ACM, 4, October 1961, pp 435–436.Media:Fotheringham 1961.pdf

[Güntsch, 1956] “Logical Design of a Digital Computer with Multiple Asynchronous Rotating Drums and Automatic High Speed Memory Operation”, F.R. Güntsch, Internal Report, Computing Center of Technische Universität Berlin, 1956.

[Hennessey 2003], “Computer Architecture: a Quantitative Approach”, third edition, J.L. Hennessey, D.A Patterson, Morgan Kaufman, 2003.

[Ibbett 1978] “The development of the MU5 computer system”, R.N. Ibbett, P.C. Capon, Communications of the ACM. 21, January 1978, pp 13-24. Media:Ibbett 1978.pdf

[Ibbett 1989] “Architecture of High Performance Computers” Vol. 1, R.N. Ibbett, N.P. Topham, Macmillan Education Ltd., 1989.

[Ibbett 1999] “The University of Manchester MU5 Project”, R.N. Ibbett, IEEE Annals of the History of Computing, Vol 21 , No. 1 1999, pp 24-33. Media:Ibbett 1999.pdf

[Jensen 2004] “Origin of the virtual memory concept”, E. Jenseen, IEEE Annals of the History pf Computing, 2004, pp 71-72. Media:Jenson 2004.pdf

[Kilburn 1961] “The Atlas Supervisor” T. Kilburn, R.B. Payne, D.J. Howarth, AFIPS Proc. Eastern Joint Computer Conference, vol. 20, December 1961, pp. 279-294. Media:Kilburn 1961.pdf

[Kilburn 1962] "One-level storage system",T. Kilburn, D.B.G. Edwards, M.J. Lanigan, F.H. Sumner, IRE Trans. EC-11, April 1962, pp 223-235.Media:Kilburn 1962.pdf

[Lavington 1975] “A History of Manchester Computers”, S.H. Lavington, second edition, British Computer Society, 1998.

[Lavington 2012] “The Atlas Story”, S.H. Lavington, http://curation.cs.manchester.ac.uk/atlas/elearn.cs.man.ac.uk/_atlas/docs/The Atlas story.pdf Media:Lavington 2012.pdf

[Lavington 2012 (2)] "Timeline of the MUSE/Atlas project at Manchester University, 1955 – 1971. Media:Lavington 2012 (2).pdf

[Lincoln 1982] “Technology and Design Tradeoffs in the Creation of a Modern Supercomputer”, N.R. Lincoln, IEEE Trans Computers, Vol. C-31, No. 5, pp 349- 362, 1982. Media:Lincoln 1982.pdf

[Liptay 1968] “Structural Aspects of the System/360 Model 85 – The Cache”, J.S. Liptay, IBM Systems Journal, 7, 1968, pp15-21. Media:Liptay 1968.pdf

[Randell 1968] “ Dynamic Storage Allocation Systems“, B. Randell, C.J. Kuehner, Communications of the ACM. 11, June 1968, pp 297-36. Media:Randell 1968.pdf

[Siewiorek 1982] “Computer Structures: Principles and Examples”, D. Siewiorek, C.G. Bell, A. Newell, McGraw Hill, 1982.

[Silberschatz 2014] “Operating System Concepts”, A. Silberschatz, P.B. Galvin, G. Gagne, Wiley, Ninth edition, 2014.

Supporting materials (supported formats: GIF, JPEG, PNG, PDF, DOC): All supporting materials must be in English, or if not in English, accompanied by an English translation. You must supply the texts or excerpts themselves, not just the references. For documents that are copyright-encumbered, or which you do not have rights to post, email the documents themselves to ieee-history@ieee.org. Please see the Milestone Program Guidelines for more information.


Please email a jpeg or PDF a letter in English, or with English translation, from the site owner(s) giving permission to place IEEE milestone plaque on the property, and a letter (or forwarded email) from the appropriate Section Chair supporting the Milestone application to ieee-history@ieee.org with the subject line "Attention: Milestone Administrator." Note that there are multiple texts of the letter depending on whether an IEEE organizational unit other than the section will be paying for the plaque(s).

Please recommend reviewers by emailing their names and email addresses to ieee-history@ieee.org. Please include the docket number and brief title of your proposal in the subject line of all emails.