Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ Overview □ 18. Getting started □ 19. SRC orders □ 20. ICL manufacturing □ 21. UNIX strategy □ 22. ACCENT UNIX □ 23. Microcode UNIX □ 24. UNIX developments □ 25. PERQ - DAP □ 26. PR □ 27. SUSSG □ 28. Competitors □ 29. Communications □ 30. Office pilots □ 31. GKS
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
⟶ ACD ⟶ Single User Systems ⟶ PERQ History ⟶ Part V
⟶ ACD ⟶ Single User Systems ⟶ PERQ History ⟶ Part V
ACL ACD C&A INF CCD CISD Archives
Further reading ⇓

□ Overview
□ 18. Getting started
□ 19. SRC orders
□ 20. ICL manufacturing
□ 21. UNIX strategy
□ 22. ACCENT UNIX
□ 23. Microcode UNIX
□ 24. UNIX developments
□ 25. PERQ - DAP
□ 26. PR
□ 27. SUSSG
□ 28. Competitors
□ 29. Communications
□ 30. Office pilots
□ 31. GKS

1982

22. ACCENT UNIX

The agreed objectives of the project were as follows:

  1. A full Version 7 UNIX implementation.
  2. 32-bit arithmetic and paged 32-bit virtual addressing with a flat address space.
  3. An implementation which would permit a natural evolution to future enhancements, such as distributed operating systems.
  4. The possibility of compiling and running programs developed under the existing POS system, where feasible.
  5. To provide interworking between programming languages at the procedure call level. This would allow mixed language programming.

To rea1ise these objectives, the SERC implementation was to use the Accent operating system kernel which provided:

  1. Inter-process communication (IPC) via messages which are passed through logical entities called ports, allocated by the kernel.
  2. Virtua1 memory management - each process had a flat 232 16-bit word address space protected from other processes. This made it impossible for processes to interfere with each other except by IPC, and made for a very secure system.
  3. Security - ports are protected kernel objects, and the kernel provides processes with a secure capability to send a message to, or receive a message from, a port. Port access rights cannot be forged or accidentally created. Consequently interaction between different processes can be delineated precisely.
  4. Process management: including process creation, destruction and UNIX fork. The kernel provides interrupt control, scheduling and some process monitoring and debugging.
  5. Device Access via IPC.
  6. Microkernel - microcode support for process queue management, low level scheduling, I/O support, interrupt handling, and virtual memory address translation and paging.

The major activities to be completed were:

  1. Compiling System: a major part of UNIX is written in C so implementation of a C compiler to the Accent Q-codes was essential. The UNIX Portable C compiler was to be modified to generate Q-codes. It is a 2-pass compiler with, in theory, the code generation occurring in the second pass. A FORTRAN compiler also exists under UNIX sharing a common back end with the C compiler. In theory, once the second pass of the C compiler is changed, the FORTRAN compiler is straightforward.

    A loading system needs to be implemented to load the compiled code from the various languages.

    The existing Three Rivers PASCAL compiler could work almost unchanged and an ISO PASCAL compiler needed to be implemented (in fact, subcontracted to UMIST).

  2. UNIX Kernel: a set of processes on top of the Accent kernel needed to be implemented to provide the facilities of the UNIX kernel. This was the major part of the design and implementation work. Most of the other work was modifying existing code.
  3. UNIX Utilities: port the complete set of UNIX utilities to the new version of UNIX. In most cases, they are written in C and, assuming no PDP11 dependence, should be a routine recompilation. Some, such as debugging aids, are machine specific and need to be redefined. Some are specific to the PDP11 and would not need to be reimplemented.

The main pieces of software developed for the implementation of the UNIX kernel were:

  1. Switchboard: a process which routed I/O requests to appropriate device drivers or the file system. It also handled pipe traffic.
  2. Registrar: this kept an active record of births and deaths of processes, and thus maintained a table of active processes and provided the process identifier (PID) for each UNIX process.
  3. File Server: based on the CMU interim file server which gave access to the POS file system.
  4. System Interface: mapped UNIX system calls on to Accent calls.
  5. Device Drivers: defined as processes which use Registrar to identify it and Switchboard to provide the appropriate routing.

In implementation terms, the major problems that arose were:

  1. UNIX is not portable: many more dependencies on the PDP11 architecture were encountered than anticipated. Earlier UNIX ports had been to similar architectures to the PDP11. This was the first to a significantly different architecture.
  2. Poor compilers: the philosophy of the 2-pass compilation with code generation in the second pass had not been strictly adhered to in either the C or FORTRAN compilers.
  3. UNIX bugs/features: UNIX, being an early operating system with incremental developments, no longer had a unified overall philosophy nor did it have the security of Accent. Consequently, much effort was spent simulating the bugs/features of UNIX.
  4. UNIX utilities: there were many undocumented PDP11 dependencies the major one being that some utilities even generated PDP11 machine code in line. Other problems arose such as the assumption in utilities that address zero contained zero, dividing by zero gives zero as a result, most significant byte of word has same address as the word, function pointers are 32-bit addresses etc.
⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site