Introduction Edinburgh University has run its computing service on essentially the same software since 1970. This has been achieved by Porting an entire Operating System twice. The three machines used as Hosts had little in common except for byte addressing and virtual address support. The User community have had an exceptionally smooth transition between incompatable hardware which arrived with very different suppliers systems. It would be nice to report that these 15 years of stabiltity in a fast changeing world was the result of immense far sightedness on the part of the team who constructed the orignal EMAS system during 1967-70. However it would also be quite incorrect to do so. This talk, like Gaul, is divided into three parts. Firstly I will describe what actually happened. Then I will describe some design feature of EMAS which led to it being transported twice and finally I will present some of the advantages and disadvantages of running on Portable software. History. British Universities are almost entirely state funded, and the British have a habit of dismissing their governments every 4 years. This is very theraputic for the general populace but not so helpful for longer term planning. To help insulate the University from their political paymasters a device the UGC was established which received a block grant from HMG and divided it between the various Universities. Some specifc research projects are independently funded. The first computers were purchased by the universities out of UGC funds just like any other piece of research equipment. However in the early 60s there was a scandal when a certain University spent a large portion of its grant on an experimental machine which never worked. The universities were not very business minded and the unnamed manufacturer could claim to have fulfilled his contract to the letter by delivering a nonworking machine. Following this debacle, the government took a much more direct interest in the purchase of computers for Universities. The civil service purchased them and organised stringent acceptance tests. The universities had a rota obtaining a new machine every 4-5 years. This arrangement lacked the isolating buffer of the UGC and was open to much more political pressure. Various UK manufacturers offered bulk supplies of new machines to Universities as a covert form of launching aid. There provedto be little correlation between successive machines and any large investment in software was at risk at the next upgrade. Preservation of software investment was always at or near the forefront of the academic mind. The ERCC was set up as part of a government investment program that followed the elections of 1964. A National Computing Centre and a number of Regional Computing Centres were to be set to stimulate interest in this strange pastime. Each RCC was to have a separate speciality and all were to be associated with Universities but aim to serve a much wider community. In fact only 3 RCC's were set up before the next change of Government. Edinburgh's speciality was to be multi-access computing and the centre started life with a curious rag-bag of machines.{slide} The first years task were a curiously accurate cameo of the problems to come. All previous computing has been done on the Manchester Atlas and there was a compiler for Atlas Autocode(The preferred Atlas language) on KDF9. There was Fortran on the IBM360. The first efforts were devoted to making IBM compatible Fortran and Atlas Autocode available on all machines To preserve as much software as possible the SIM module was invented and written. {slide overlay}. SIM was initially a very successful concept but suffered from only providing minimum facilities. No-one at Edinburgh forsaw the seductive effect of a virtual filestore and how its Siren call would lure users to write in a way that could not be transferred back to a conventional filestore. Simultaneously a joint University and Manufacturer team was assembled to write an operating system for the 4-75. Some early feedback from project MAC, Multics and TSS was available at this time. Considerable thought was put in to the likely problem areas and possible solutions {3part slide and extended discussion}. The implementation project ended in the summer of 1970 and failed to produce a viable system. The main reasons for this were outlined on the last slide. The manufacturer had no further interest in the project and the possible extension clauses were not activated. It was a very near miss; the 5 University staff worked on and in six months a service was operating. Twelve months after the failure EMAS became the main service vehicle and generally was received with acclaim. I do not intend to describe the EMAS in any detail but ask you to note the main feature as perceived by a user { Slide}. The next stage in the saga started 5 years later with the next machine to be provided for the University. We were to get a brand new machine with a brand new operating system as a result of manufacturer/government deal. We had little say in this but were promised that the new machine would provide twice the terminal support capability of the 4-75 and twice the batch load of the 370-158{slide}. Considerable energy was spent in preparing a suitble benchmark using ERTE. Particular care was taken to measure the typing speeds, variations and waits of the average terminal users as well as obtaining a representative sequence of commands. Applying this benckmark to the new machine was devastating; for a long time it could not complete a 32 terminal version of the benchmark without any simultaneous batch at all. A long period of inaction followed during which the academics speculated on the effort needed to bootstrap an operating system and of the changes required. Eventually the manufacturer agreed he was in serious default and reparations were obtained. These included a further machine and the bootstrap went ahead {slide}. This re-implementation was compilcated by the absence of any suitable equipment to interface without network. Hardware had to be designed and built before a PDP11 could be used as a network interface. A further time wasting problem were the substantial hardware upgrades that took place in the first year of the project. However the team of four people and several part time helpers made rapid progress and in 18 months there was a servicable system. Full service commenced six months later. The bootstrapped system certainly could perform {perf slide}. The user transition was very smoothe and the machine made a substantial contribution to the available computing power in Edinburgh. The most unsaitsfactory features were:- a) The amount of time users had wasted converting programs to run under VMe b) A number of packages had been purchased outright and could not be run. The latter point was tackled; a converter was written to revise the object files and parT of the VME user interface was simulated. By 1984 the ERCC was again due for a further machine and the effort of converting or attempting to convert programs to run on VME was still fresh in many peoples minds. There was considerable User pressure to avoid a major change of system; the grounds rules had changed slightly too since by chosing from a list of second hand government machines we could obtain more less what we wanted. The choice was an Amdahl that could run a close approximation of IBM Extended Architecture. It seemed likely that this architecture would survive as long as Edinburgh wished to run Emas so the "final" bootstrapped was attempted{slide}. There was a proved communication route via an AUSCOM interfaces into PDP11s and our existing network so little effort was needed in this area. The Amdahl arrived on 1st Dec 84 and the system is currently running and under test. Spooling, file transfer, Backup, Archive and Mail are present and working. Further work is needed to interface the heirarchical file structure to all commands and some compilers are not yet ready. The MVS simulator has run its first MVS package. We expect a full service from the start of the Autumn term. Preliminary indications are tha performance will be satisfactory but serious measurement has not yet started. EVOLUTION AND PHILOSOPHY OF IMP EVOLUTION The IMP language evolved from Atlas Autocode, which itself is a direct descendant of Algol 60. Although Algol 60 had only moderate success as a programming language - it was hardly used in the United States - no other language before or since has achieved more than a fraction of its influence on programming language design. Algol's principal attraction is its block and stack structure: by collecting space together on a stack and re-using it for successive procedure calls, an Algol program causes less paging than the same program written in (say) Fortran. The disadvantages of Algol are the lack of standard input/output and the difficulties that some features of the language present to the compiler writer. The tragedy of Algol was that so little was gained from the features which presented most of the problems. Almost nothing of real power was gained either from call by substitution or failure to specify formal procedures adequately, and little was gained by the enormous generality of the for statements. Yet the problems these areas posed caused all early Algol compilers to produce comparatively low quality object code. Although Algol was to be implemented on Atlas, the prime language was a new one - Atlas Autocode. This was a simplified Algol with changes to the block, loop and procedure structures to remove the worst problem areas. It aimed to deliver 90$% of the power of Algol to the programmer while only requiring 25$% as much effort from the compiler writer. Edinburgh University started its computing with a data link to the Manchester Atlas, and this happy accident began the long association between the University and the language. When Glasgow and later Edinburgh obtained KDF9 computers it was necessary to write a compiler for Atlas Autocode; this was carried out in a short time by Mr (now Professor) Harry Whitfield and his associates. This compiler was in advance of its time in that it was written entirely in Atlas Autocode and developed on Atlas. It was transferred to KDF9 by the elegant technique of self-compilation. The compiler thus produced compared exceedingly well with the manufacturer's Algol compiler, both in compilation time and in object code efficiency. This project also confirmed that Atlas Autocode was free of implementation trouble spots and very suitable for large scale system programming. PHILOSOPHY AND STYLE IMP was to be a superset of Atlas Autocode, containing additional features for system programming. It was at this point that almost all the main language changes were made and the distinctive philosophy of IMP originated. In 1966 a system programming language was perceived to require: * efficient object code. System programs are liable to be executed millions of times. Thus features that could not be implemented efficiently should be omitted. * early compiler availability. The compiler should be available as soon as the hardware, otherwise programmers would program in something else. Consequently features that would or might cause implementation trouble spots must not creep into the language. * minimum run-time support. Some system programs like supervisors and loaders have to run in an environment almost devoid of support software. The language should be free of features requiring run-time support. $C+2 (The Atlas Autocode fault statement conflicted with this aim and had to be banned from system programs, although retained in the language for user programs.) * readability. System programs have a long life and require maintenance. It is more important that the program be easy to understand than quick to write. Optional keyword omission or abbreviations should be banned. $C+2 (The language should be "verbose rather than obscure".) * access to bizarre hardware features. System programs require access to funny features - to blow the hooter or ring the gong on hardware failure, for example. However the language would not be compromised here. Instead machine coding would be allowed at any point in the program, with access to the IMP variables and arrays. Even with fifteen years of hindsight this list still seems relevant, although the need for efficient object code was more pressing then than now. The real key to the long life of IMP is the last item in the list. By allowing machine code in extremis almost no machine-dependent features were included except the underlying one of a byte address structure. Consequently IMP has been successful on a dozen or so machines, unlike the main competitors of the era (PL360, Burroughs Extended Algol). In accordance with the language philosophy, the following changes were made to Atlas Autocode to produce IMP {slide}. SYSTEM FACTOR AFFECTING PORTABILITY a) Global-Local-Director Split This must be a good idea; if IBM's VM can be successful with the partition in such a funny place then a more sensibly partitioned system must have advantage {slide}. b) VM management divorced from hardware We envisgaed that the amount of material in the VM with a virtual filestore would be large but that the working sets would be small. For this reason we devised a very compact representation of the VM. For active segments ie segments that had one or more of their pages in the working set, an expanded table format used. Users were and still are restricted to 32 active segments. There is an overhead in activating a segment and it is at this point that sharing is discovered because the segment is already active. For active segments pages can be located by direct indexing without any searching. c) A Virtual Filestore The virtual filestore was seen as a way to save effort in that the pagingmanager doubles as the record manager. Afurther attarction is that program sharing will automatically provide datasharing. Experiences of a virtual filestore has confirmed that it is one of the real advances in computing. It has great advantages for files that are browsed rather than read sequentially and for program suites that are normally only partly executed. d) Unified messages passing All central parts of the system are linked together with a message passing system operating on a handshake basis. No component can assume anything has happened until he has received a message to say that it has happened. {slide} . this must be rather inefficient particularly on machines with vectored interupts but it keeps interfaces very simple and consistent f) All procedural interfaces outside Local controller This was done for philosophic reasons. With all users and system programmers writing in high level languages any other interface seemed inappropiate BALANCE SHEET Our portable system can be moved with much less effort than is normally involved in creating a system. Indeed it seems from VME experience that the user effort in moving their programs to any manufacturers system is likely to much greater than porting the system. There are certain measurable inefficiences in our system{slide}. However had we started with the aim of peliminating these we would have ended up with a less efficient OS Portable or semi portable OSs seem a beter way forward than endlessly building the same hardware as does IBM or the 10 year upheaval as favoured by ICL. The characteristics of UNIX are more related to its origins than to its protability!.