In October 1981, when the decision was finally made to mount UNIX on the PERQ, RAL had a PDP11/70 running Version 7 of UNIX from AT&T. This was not a virtual memory version of UNIX. The other version of UNIX coming into use on VAX systems was Berkeley UNIX which, at that time, was also not a virtual memory version.
UNIX had been ported to a number of systems with similar architecture to the PDP11 and it was possible to purchase versions of UNIX from a number of organisations which were largely compatible with the AT&T version but usually had extensions and omissions. Consequently, at the time of the decision, UNIX was in a less stable state than it is today.
ICL had almost no UNIX experience and no equipment to run UNIX on. Consequently, porting UNIX would be difficult without some use of the RAL facility.
RAL had been looking at the possibility of porting UNIX to the GEC 4000 series as this was a direction of interest to GEC (later GEC settled on UNIX as its operating system for its new Series 63 range). Consequently, some of the likely problems had been noted and possible solutions partially worked out.
In order to avoid a great dependence on POS, it was hoped that an implementation of UNIX could be completed quickly. Given sufficient manpower, the view was that it could be completed by April 1982 with a release some time in the summer of 1982. ICL have quite stringent software validation tests and require documentation etc to be produced before release. Consequently, there is an inevitable delay between completion of software development and release of the product.
The major parts of any UNIX implementation are:
The amount of work in each area differs depending on the approach and the machine. Implementing the UNIX kernel requires certain support from the hardware. If it was to be built on top of another operating system kernel, there would need to be compatibility between the two. There would also need to be compatibility between fi1estore organisations.
The Compiler work is mainly replacing the PDP11 code generation by another machine's order code. The amount of work depends significantly on how close in concept the architecture of the new machine is relative to the PDP11.
The UNIX utilities porting tends to be a routine operation for many of the utilities but some are large and complex. Again, the effort required depends to some extent on the compatibility of the two machine architectures and order codes.
The main requirements of SRC were:
RAL considered a variety of options in a discussion paper dated 17 September 1981 and a further paper was discussed with ICL early in October. The situation was complicated in that Three Rivers had contracted a Toronto software house, Human Computer Resources (HCR) , to implement a version of UNIX (Xenix) for the PERQ. HCR had already done a UNIX port.
Contact was made with Ron Baecker of HCR on 11 September to understand what HCR's plans were. They had already started work and it was feasible that a joint activity might speed up UNIX being available. HCR estimated that 4 people working for 6-9 months could do the port. They currently had two people on the project and would be willing to see a collaborative product as long as it was done in Toronto and HCR had marketing rights outside the UK.
The aim of their implementation was to use the existing Q-code microcode of the PERQ as the machine's order code and effectively write the UNIX kernel using this order code and a C-compiler that generated Q-codes. The approach was to do a lot of the work on the VAX and cross-compile.
Further technical discussions showed that they planned a traditional UNIX port resulting in Version 7 UNIX being available. Programs could consist of several code segments, one stack segment and one data segment. Variables declared within a program were to be allocated space in the stack segment. By limiting the stack and data segments to 64K words, it would not be possible to run large FORTRAN programs (for example, DIMENSION A (300,300) would fail).
They would use the standard UNIX filestore which was incompatible with the existing POS filestore . Consequently, there would be a traumatic experience for a user when moving from POS to UNIX. Process swapping was to be used rather than paging. There was also a need to implement a PASCAL compiler as HCR had no plans.
This approach did not fulfill SRC's basic objectives of a 32-bit virtual memory version of UNIX. Consequently, although useful as a back-up, it was not considered as a reasonable approach to satisfy either SRC or ICL's marketing objectives.
An option similar to above was to first change the microcode so that it was more compatible with the requirements of the C language and the UNIX kernel. Effectively, a different machine order code would be defined which was sympathetic to UNIX requirements.
A real advantage of this approach was that it would lead to an efficient implementation of UNIX. The big disadvantage was that a good understanding of PERQ microcode was required and a great deal of work has to be done prior to the work outlined in Section 21.3.1.
In SRC's view, this was only worth doing if full virtual memory support was included in the microcode. ICL's systems programmers were less convinced as to the need for this.
The Accent kernel being developed at CMU had all the functionality necessary to build the UNIX kernel on top. The Accent system used the same filestore as POS. Consequently, moving between an existing POS system and an Accent-UNIX system would be simple.
The Accent-kernel provided virtual memory management, 32-bit addressing and could function as a distributed operating system across a set of connected UNIX systems. Consequently, developments past a single processor UNIX system to a fully distributed version of UNIX could be relatively easy.
The big disadvantage of this approach was that it was heavily dependent on the work at CMU. As CMU had a great deal more effort available than either ICL or RAL, this might not be a problem.
This is equivalent to HCR's approach. However, it would probably be possible to extend the Q-codes to provide 32-bit rather than l6-bit working and a virtual memory capability.
A disadvantage of this approach was that it would probably be very inefficient as the Q-codes were not the optimal order code for UNIX. In places, C instructions which would generate a single object instruction on the PDP11 would generate 5 Q-codes on the PERQ.
A technical meeting between ICL and RAL at the end of September 1981 attempted to define the various options in more detail and make estimates of the manpower required and elapsed time before a product was available. There was general agreement that the PERQ programme could not be dependent on the HCR product and that it was essential to consider the three other alternatives in more detail.
A paper was produced in early October 1981 setting out the objectives, options and timescales. The major points were:
A meeting on 19 October 1981 looked at the options in detail. There was unanimous agreement that a conventional UNIX port was not a sensible approach. It would certainly be inefficient and there were serious doubts as to whether it would be possible without significantly modifying the order code and, if that was done, the Microcode UNIX approach would be preferable.
The full pros and cons of each approach are given in the paper defined at that time.
There was a major disagreement between ICL and SRC concerning whether to go the Microcode UNIX or Accent UNIX route. An ICL objective was to implement UNIX in a way that would give maximum compatibility with other ICL UNIX Systems. ICL felt that this could best be done by the Microcode UNIX route. There was also an ICL requirement that any UNIX implementation should fit in with ICL's plans for distributed systems and networking. The Accent UNIX route forced the Accent philosophy on to ICL which was not necessarily acceptable. ICL had doubts as to the stability of the Accent kernel and the likelihood of CMU producing a well documented product. ICL believed that a Version 7 UNIX Port with no virtual memory would be an acceptable product whereas SRC believed that would not fulfill the requirements of the university research community.
On the SRC side, it was generally felt that the timescales for the Microcode UNIX route were optimistic, especially if no microcode expert was available. The Accent route guaranteed a full 32-bit virtual memory system with the possibility of picking up a great deal of software from both Three Rivers and CMU. PASCAL would be automatically available and compilers for LISP and ADA were being developed at CMU. SRC made it clear that the ICL proposal to do Microcode UNIX without ultimate virtual memory could only be a short term expedient and was not the product required.
The SRC view was that the ICL approach had an elapsed time nearer to 11 months than 6 months.
It was decided that there was sufficient uncertainty about both approaches that they should be tried in parallel initially. This provided a fallback system if one or other project got into difficulty. The viability of the Accent route was dependent on the availability of Accent. CMU were holding a full scale presentation of the current state at their Industrial Affiliates Meeting on 9 November.
It was agreed that ICL would familiarise themselves with microcoding the PERQ and getting UNIX experience, while SRC planned a UNIX implementation based on Accent. By frequent review meetings, the state of each project could be ascertained and a decision made in the future.
Rob Witty, Len Ford and Tony Williams visited CMU for the Industrial Affiliates meeting. By then, CMU had 47 PERQs and had received the first 16K writeable control store. Each Industrial Affiliate contributed $100K per annum and in return got early access to the software and knowledge in the project. CMU realised that SRC were not industrial but was still requiring some return for SRC getting access to Accent kernel at an early stage. A possible approach might be for ICL to become an industrial affiliate and SRC provide some nominal sum while CMU would get some rights to software developed on top of Accent.
The Industrial Affiliates at that time included Xerox, ARPA, DEC, Siemens, Olivetti and Three Rivers. Siemens had two people working at CMU on the project.
Len Ford stayed on at CMU after the Affiliates meeting for several weeks getting thoroughly familiar with Accent. By the time of his return in December, the state of Accent was:
The general view was that the system was sufficiently stable that an attempt to mount UNIX on Accent was a feasible approach. Len Ford had a good knowledge of Accent, the system interfaces were known and a detailed plan of implementing Accent UNIX could be produced.
A Management Meeting was held on 15 January 1982 between SERC and ICL where a number of areas were discussed including PERQ.
The most senior ICL person present was Chris French. He was the main interface to Three Rivers and held regular monthly meetings between the two companies. The aim of both companies was to keep the hardware and software supported the same. As a result, both companies were commissioning ERCC to develop a FORTRAN 77 compiler under the POS operating system which was due for release in May.
ICL were worried at the many operating system possibilities on the PERQ:
Three Rivers had already chosen Xenix as their short-term UNIX operating system and ICL management were keen to go in that direction. Both ICL and Three Rivers believed that SPICE was the long-term operating system to be used on the PERQ.
SERC expressed concern at both the short and long-term proposals. Xenix did not provide what the UK academic community required and Spice was still a research project. It was essential that an operating system appeared on the PERQ which met the requirements of the user base.
It was agreed to continue the technical work in progress while discussions with Three Rivers took place.
As 1982 started, the decision to mount UNIX on the PERQ had been agreed by Three Rivers, ICL and SERC. Three Rivers had contracted HCR to produce a version of UNIX which was unacceptable in the long-term and probably of little use in the short-term. Meanwhile, ICL management were being pressured by SERC to put a virtual memory version of UNIX on the PERQ. At the same time, ICL wanted to keep compatibility with Three Rivers if possible.
The decision made by ICL and SERC was to do two parallel implementations of UNIX on the PERQ. Despite SERC's requirements, ICL's Microcoded Version of UNIX would not have virtual memory support in its initial release. The view of ICL' s technical staff was that virtual memory support was not needed initially and it would decrease the machine's performance. SERC's version of UNIX would be based on the CMU Accent Kernel which both Three Rivers and ICL management saw as the long-term goal as a distributed operating system kernel. The major worry concerning the SERC approach was the dependency on code still being debugged and rewritten at CMU.
Although there were technical reasons for the decision to do two parallel implementations, it must also be said that there were personality problems. The SERC staff had been working on the project for a long time and knew what the community and market required. Most of the ICL staff had been drafted on to the project from a miscellaneous set of other projects. They did not have the same feel for the requirement of the user base. They did not take kindly to a set of pseudo-academics telling them how a commercial project should be run. From SERC' s point of view, it was difficult to obtain information concerning either the number of staff or their abilities that ICL were putting on to the project. ICL may well have had similar problems with SERC.
