Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ OverviewIEEE CG&ADCE 1982OR for SUS 1986SUS Assess 1986Apollo Domain
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACDSingle User SystemsPERQ PapersExternal
ACDSingle User SystemsPERQ PapersExternal
ACL ACD C&A INF CCD CISD Archives
Further reading

Overview
IEEE CG&A
DCE 1982
OR for SUS 1986
SUS Assess 1986
Apollo Domain

The PERQ Workstation and the Distributed Computing Environment

J M Loveluck

July 1982

ABSTRACT

The advent of relatively inexpensive, powerful, highly interactive single-user computer systems is likely to have a profound effect on computing methods in the next decade. The concept of Distributed Interactive Computing arises if such systems are interconnected by high-speed local and wide area networks, which may also provide access to mass storage. high-quality print and graphics output devices, and other more specialised requirements. The capabilities of the PERQ are summarised. emphasising those features which make it eminently suitable for the Distributed Interactive Computing Environment.

The Science and Engineering Research Council (SERC) has embarked upon a major new initiative to exploit this new technology, and to provide a firm software base for this type of computing environment. An outline of the SERC Common Base Policy for single-user systems is presented, and the role of the PERQ. as a component of the hardware base of this policy. is indicated. The main threads of the SERC programme of hardware and software development, within the framework of the Common Base Policy, are described, emphasising a primary objective of this work. which is the realisation of the full potential of the PERQ within the distributed computing environment.

Some possible future trends in hardware and software advances in this field are mentioned, and it is pointed out that the SERC software development programme for the PERQ permits a natural evolution to a truly distributed computing system, in which the operating system. as well as other resources, is distributed over a network.

1. Introduction.

It is almost a cliche to write of the enormous advances in computer power, coupled with increasing reliability and miniaturisation, which have taken place in the last two decades. In many respects. the PERQ workstation is a continuation of this progression, but we shall seek to demonstrate below that it also opens up the possibility of radical new departures in computing methods.

The dominant mode in which computers are used today, via a terminal connection to a remote, central. mainframe, is one which developed during the sixties, and is no longer necessarily the most appropriate to this decade. The dominance of large mainframes arose because, in the past, powerful processors were expensive, and had to be shared. With the continual decrease in cost of CPU power, it is no longer obvious that they represent the best solution for all computing needs.

ne of the strengths of centralised computing facilities is that many users can share libraries of programs and databases, as well as expensive peripheral equipment, such as high quality graphics devices.

A single-user computer in isolation cannot be expected to provide all the resources which are normally made available to users of large mainframe computers. Indeed, for many applications these facilities are not all necessary. However, if a personal workstation, such as the PERQ, is connected to a high-speed local area network (LAN), giving access to some of the more specialised requirements, then one arrives at the attractive combination of the instant availability of a single-user system, and the extensive resources of a large mainframe installation. These resources may be further enhanced by access to a wide area network (WAN).

It is this blending of powerful, highly interactive, single-user systems and high-speed networks which constitutes the Distributed Interactive Computing Environment In the following sections we shall examine the attributes of the PERQ which make it ideal for this sort of computing environment, the network connections available, and some trends in software and hardware developments which should bring significant future enhancements.

2. PERQ. ICL and the SERC Common Base Policy.

The Science and Engineering Research Council (SERC) has a long standing interest in the PERQ. The Council's Rutherford Appleton Laboratory was, in fact, the first customer in the world to place an order for a system, in June 1979, shortly after the launching of the PERQ in the USA by the Three Rivers Computer Company (3RCC). It was clear to SERC, at this time, that the appearance of computer systems such as the PERQ would excite great interest in the UK university research community. The availability of low-cost single user systems would have a significant impact on coordinated research projects, such as the Interactive Computing Facility (ICF) the Distributed Computing Systems Programme (DCS), and the Software Technology Initiative (STI). In addition, SERC was expecting to receive, through its sub-committees, numerous grant applications for single-user systems.

It was realised that there were a number of dangers inherent in this situation. In the first place, there was a risk that, by not having a suitable product available at the outset, UK industry would miss the opportunity to penetrate a potentially rich and rapidly expanding market. Secondly, it was inevitable that systems similar to the PERQ would be produced by other computer companies. It was likely that small companies would be involved, at least initially, and that they would provide minimal software support and field maintenance nationwide. As a consequence of this situation, it was envisaged that a number of different systems would be purchased by SERC and its grant-holders, and this would result in considerable duplication of effort on basic software development.

The response of SERC to this predicament was twofold. Firstly, it formulated a policy, the Common Base Policy, to provide a network of single User systems throughout British universities, with a common hardware and software base. Briefly, the Common Base Policy adopted by SERC consists of:

The other aspect of the SERC initiative consisted of a proposal, made to ICL, that they should seek to negotiate an agreement with Three Rivers to market and manufacture the PERQ in the UK. In August 1981 ICL formally entered into commercial cooperation with the Three Rivers Computer Company, with an agreement which gave ICL marketing rights, not just in the UK, but in a number of other countries, including the whole of Europe.

As a result of this initiative, there is now a strong collaborative partnership between 3RCC, ICL and SERC. This association has recently been extended to include Carnegie Mellon University (CMU), in Pittsburgh USA, who already had strong links with 3RCC. The latter collaboration has been a particularly fruitful one for SERC's Rutherford Appleton Laboratory (RAL); the implementation of Unix on the PERQ (see below) by RAL relies heavily on the ACCENT operating system kernel developed by CMU. The RAL experience in using this software, in an environment for which it was not designed, has been invaluable to CMU in enhancing the robustness of their product.

In concluding this survey of the background to the launching of the ICL PERQ, we note that the PERQ was not the first single user system oriented towards the distributed interactive computing environment. The Xerox PARC Alto system 1, developed at the Xerox Palo Alto Research Centre (PARC) in the mid seventies, is especially pertinent to the development of the PERQ. Indeed, Brian Rosen, who played a major role in the development of the PERQ, was previously at Xerox PARCo The single-user PARC Alto systems were linked together to provide a powerful and flexible computing environment, which marked the way forward from time-shared systems.

The Xerox PARC Alto was a research project, which was not commercially viable at the time, in large measure because it was not able to take advantage of recent technological innovations, which have significantly reduced the costs of the necessary hardware components.

3. Technological Progress in Computer Hardware.

Before examining in detail the requirements of a single user system in the Distributed Interactive Computing Environment, we mention some of the recent advances in computer hardware which have made it possible to satisfy such requirements in a system which can be marketed at an economically viable price (less than 25K pounds).

Firstly, the cost of computer memory has declined steadily for many years. Significant cost reductions have coincided with the introduction of first 16K and then 64K RAM. The introduction of 256K RAM is now anticipated, and should be accompanied by further cost reduction.

The cost of computer processors has also declined with improvements in fabrication techniques of LSI chips. The introduction of bit-sliced processors has permitted the development of fast, low cost, special purpose processors.

There have also been considerable advances in bulk storage technology in recent years. Of particular relevance to single user systems has been the introduction of Winchester discs, which provide reliable, low cost storage without special environmental conditions, a crucial factor for the single-user workstation.

A high quality display is of paramount importance in the computing environment which we have described. Bit-map displays with a resolution of 1024 by 768 (A4 size) are now available commercially at reasonable cost (around 250 pounds). A flicker-free display is obtained by using a non-interlaced refresh, and the use of fast phosphors minimises smearing of the image as the display changes.

Finally, fast communications are crucial to the distributed computing environment. Special chips are now being produced for this purpose, which should greatly reduce the cost of communications interfaces, while still permitting communication speeds in excess of 10Mbits/sec.

4. PERQ and the Distributed Interactive Computing Environment.

The type of computing environment described in section 1 realises its full potential only if the interconnected single user systems satisfy certain criteria. In examining these requirements, it should be borne in mind that a number of the services provided by central mainframe installations may be made available, in the distributed environment, by network connections. Resources which are shared by network users in this way are referred to as network 'servers', and their use is illustrated in figure 1. The actual provision for any particular system will depend on local requirements.

Figure 1: Clients and Servers on a LAN

Figure 1: Clients and Servers on a LAN
Full image ⇗
© UKRI Science and Technology Facilities Council

In this section, we outline the hardware capabilities of the PERQ workstation, emphasising their relation to the requirements for a single-user system (SUS) in the Distributed Interactive Computing Environment.

A general impression of the PERQ hardware is provided by the illustration in figure 2, and the different components are described in more detail below.

Figure 2: PERQ Hardware

Figure 2: PERQ Hardware
Full image ⇗
© UKRI Science and Technology Facilities Council
High Speed Processor.
The SUS should be adequate for all but the most demanding computing tasks, which may be performed by specialist network servers. The PERQ CPU executes approximately 1 million Q-codes (high-level machine codes) per second, corresponding to a processor power of two thirds of a Vax 11/780 in certain cases.
An additional aspect of the PERQ processor is that it is microprogrammed. This feature permits maximum flexibility for future developments, and for special applications, as well as yielding considerable speed increases when critical functions are microcoded. The microprogram resides in a Writable Control Store (WCS) consisting of 4K 48-bit words.
An outstanding feature of the PERQ is its special processor hardware and microcode, known as RasterOp, for performing logical operations on memory. This feature, which is described by Newman and Sprou1l2 in their pioneering work on interactive computer graphics, is especially useful for the rapid manipulation of the display image. The PERQ Pascal compiler supports a RasterOp intrinsic, which invokes the RasterOp Q-Code, and software is provided to take advantage of this facility in the display of fonts and cursors. The Raster-Op hardware performs shift, mask and merge operations on 64 bits at a time, which are pipelined into the hardware. The speed is limited by the memory cycle time of 680ns for 64 bits.
Large Physical and Virtual Memory.
The falling costs of computer memory have meant that single-user systems no longer suffer from significant restrictions on physical memory size. A growing computer user requirement is for a very large virtual address space, for example. that spanned by 32 b{t words (4 Gbytes). With the fast response of a single user system. this is often a more important requirement than a large physical memory.
The PERQ provides options of 1/2 Mbyte or 1 Mbyte physical memory, and a 32 bit paged virtual memory. A 24 Mbyte Winchester disc provides extensive local filestore. and this is backed up by a 1 Mbyte floppy disc drive.
Fast Communications.
Local network communications. via a Cambridge Ring or Ethernet network, at speeds around 10 Mbits/sec are essential to the distributed computing environment. Access to wide area networks is also important. and can be provided by a ring gateway, a dedicated hardware interface between a LAN and a WAN (see figure 1), or by direct links.
There are two possibilities for connection of the PERQ to a Cambridge Ring: a relatively inexpensive outboard hardware interface, or a more costly inboard one, which could connect directly to the PERQ I/O bus and would, therefore. be considerably faster than the outboard unit.
The PERQ provides standard RS232 serial and IEEE488 (GPIB) parallel interfaces. The latter is particularly suitable for instrument control and data acquisition in a scientific environment. In addition. it can be used for communication with a local network, via a suitable outboard interface. An inboard Ethernet interface board is also available for the PERQ.
High Quality Display.
An interactive environment presupposes high quality graphics, with a display approaching the resolution of printed material. The PERQ has an A4 size, 1024 by 768 pixel black and white raster display. with 60Hz non-interlaced refresh. The display is bit-mapped in memory. Combined with the RasterOp hardware described above. the result is a high resolution display with very fast response. Hard copy output, with a variety of qualities, should also be available, but may be delegated to network servers. However. plotters or matrix printers can be driven through the PERQ RS232 or GPIB I/O interfaces.
Efficient User Interface.
A flexible and versatile user interface is a necessity for an efficient interactive computing system. User input devices should be intimately related to the SUS and its display. The PERQ tablet, with its pointing device and buttons. provides a rich interface to the PERQ display. Hardware and software provisions permit an efficient utilisation of these tools, with dynamic, multi-window displays.
The PERQ hardware also contains the possibility of a less conventional user interface in the form of voice input and speech synthesiser.

5. SERC Common Base Policy Implementation for the PERQ.

5.1. Unix Operating System.

The current PERQ software consists of: the Perq Operating System (POS); Pascal and Fortran compilers; a screen-oriented editor; a rudimentary debugger, and miscellaneous utility programs for file manipulation, etc. Although the Perq Operating System makes very efficient use of the PERQ's unique features, and is more than adequate for many applications, it has been designed specifically for the PERQ. As a consequence, it does not have the extensive supporting software libraries of more established products.

The Unix operating system has been adopted as the SERC Common Base Policy standard because of its wide acceptance among computer users. especially in universities and research laboratories. There is an extensive set of Unix utilities for the development, maintenance and documentation of computer programs, supported by active European and International user groups. An inherent flexibility is conferred upon the Unix operating system by its modular structure: efficient tools for common tasks can be amalgamated. using the Unix Shell language, to satisfy particular requirements. Furthermore, Unix is a multiprocess operating system, whereas POS is a single process system, and in this sense does not take advantage of the full capabilities of the PERQ. In addition, POS does not lend itself naturally to a more radical version of the distributed environment than that discussed above: one in which the operating system itself is distributed over a number of processors interconnected by local and/or wide-area networks. With such a system. not only special services but also processing power is distributed around the network. While the Unix operating system itself does not have such a capability, the PERQ implementation described below permits a natural extension to such a system, while maintaining full compatibility with standard Version 7 Unix.

As part of the programme of collaboration between SERC and ICL. and in pursuance of the aims of the Common Base Policy, SERC is implementing, at its Rutherford Appleton Laboratory, an operating system for the PERQ which will have the same system call interface as that of the Western Electric Unix operating system.

The design aims of the SERC PERQ Unix are:

  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 satisfy a requirement of the SERC Common Base Policy: that all language implementations should be interworkable at the procedure call level. This requirement allows the possibility of mixed language programs, and obviates the necessity for translating sections of code from one language to another.

In order to realise these objectives. the SERC implementation makes use of an operating system kernel called ACCENT, which has been developed by CMU as part of their SPICE (Scientific Personal Integrated Computing Environment) project in interactive computing3. The ACCENT kernel provides a suitable environment for a multiple process operating system. such as Unix. The environment provided includes inter-process communication (IPC) via messages, which are passed through logical entities called ports, allocated by the ACCENT kernel. Virtual memory management is also handled by the ACCENT kernel, and each process is given an independent virtual address space. This feature makes it impossible for processes to interfere with one another, except by IPC, and makes for a very secure system. Additional protection in the ACCENT kernel obtains from the fact that 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, and this means that the areas of interaction between different processes can be delineated precisely. Process management, including process creation, destruction and Unix 'fork', are also provided. The ACCENT kernel requires a 'microkernel' of microcode support, which provides process queue management, low-level scheduling, I/O support, interrupt handling and virtual memory address translation and paging.

Building Unix on the ACCENT kernel automatically satisfied a number of the requirements outlined above. However, it did carry the disadvantage that the Unix implementation would be dependent on software which was still under development, and outside SERC control. The lack of stability of the ACCENT kernel has indeed been a major problem in the SERC PERQ Unix implementation. A further difficulty, which was not foreseen, has been that the Unix operating system itself has been found to contain bugs, which only manifest themselves when the system is ported to another machine. In fact, the Unix operating system has been found to be much less portable than is generally supposed.

A major part of the Unix operating system and utilities are written in the C programming language, so implementation of a C compiler is essential to PERQ Unix. There exists a portable 2-pass version of the C compiler4, which is supposed to separate the machine-dependent parts of the compiler into the second pass. In fact, the separation is not quite so clean, and some rewriting of the first pass was also required. The strategy adopted has been to re-write the second pass, in Pascal, to generate ACCENT Q-codes. A further advantage of this scheme is that compilers for other languages can also make use of the second pass of the C compiler, as illustrated in figure 3, and this facilitates satisfaction of the SERC mixed language requirement. The Unix 2-pass Fortran compiler5 also required significant modification to conform to the design. The Unix link editor (ld) has also been rewritten in Pascal to link output from either the POS Pascal complier or the second pass of the C and Fortran compilers.

Figure 3: Pascal, Fortran and C compilers under PERQ Unix

Figure 3: Pascal, Fortran and C compilers under PERQ Unix
Full image ⇗
© UKRI Science and Technology Facilities Council

The main constituents of the SERC Unix system, apart from the ACCENT kernel and its microkernel, are outlined below; the components are all written in Pascal, as is the ACCENT kernel. Figure 4 gives an impression of the way in which the different components are interrelated.

Figure 4: Inter-relation of Components of PERQ Unix

Figure 4: Inter-relation of Components of PERQ Unix
Full image ⇗
© UKRI Science and Technology Facilities Council
  1. Switchboard. This process performs routing of I/O requests to appropriate device drivers or the file system, and also handles pipe traffic.
  2. Registrar. Process management is performed by Registrar, which keeps a record of births and deaths of processes, and thus maintains a table of active processes. The Registrar process also provides the process identifier (PID) for each Unix process.
  3. File Server. This handles access to the filestore, and is based on a CMU product which uses the same filestore structure and format as POS. This means that the same filestore can be used for POS and Unix operating systems.
  4. System Interface The interface between the user process and the other components of the Unix system are handled by the System Interface, which maps Unix system calls onto ACCENT.
  5. Device Drivers. Any number of device drivers can be included in the Unix system, each device driver registering its presence by communicating its name and server port to the Switchboard process; subsequent requests from user processes are then passed by Switchboard to the appropriate driver. The initial version will include only a Terminal Driver, but a Screen Driver and other device drivers will eventually be added. Network communication is conveniently provided in the form of a Network Driver, which may be incorporated as a special directory in the file system, in a manner analogous to that in which I/O devices are included as special files in the Unix file system. In this way, files and devices on remote machines will appear as a transparent extension of the local file system.

5.2. Communications.

5.2.1. Cambridge Ring.

A number of different types of local area network have been proposed, among which Ethernet and Cambridge Ring LANs, illustrated in figure 5, are among the most widely used. In the Ethernet approach, a number of connected nodes can broadcast messages which include a destination address. This system uses a Contention technique, where the different nodes must 'listen' to the transmission medium (the Ether) and broadcast when the medium is quiet; sophisticated hardware is required to check for collisions of broadcast packets, and the propagation delay limits the total Ethernet size. In the Cambridge Ring LAN, nodes are connected in a closed loop, and transmission is based on a system of circulating slots. A node can load data, which includes a destination address, into an empty slot, and the data is removed by the destination station. A guaranteed transmission rate is obtained by prohibiting a node from using two successive slots.

Figure 5: Ethernet and Cambridge Ring LANs

Figure 5: Ethernet and Cambridge Ring LANs
Full image ⇗
© UKRI Science and Technology Facilities Council

The Cambridge Ring LAN has been chosen as the SERC Common Base Policy standard because of technical advantages, but also because systems were available from UK industry almost two years before an Ethernet product became available. Over 20 Cambridge Ring LANs are now installed in UK universities, and a large body of experience and software is available. In order to provide PERQ ring communications within a short time scale, the Rutherford Appleton Laboratory have developed an interface which allows the ring to be accessed via the IEEE488 bus or GPIB (General Purpose Interface Bus). The GPIB is used to control the bit pad and printer on the Perq, and the ring is simply added as another device. The interface unit is designed to match the '50-way' encoded interface. This presents the station as a number of status and data registers. The RAL interface translates this node image as a single primary GPIB address, with each register having a separate secondary address. The design has been optimised to allow bulk transfers in one direction to take place with the minimum number of GPIB cycles, so that the ring can potentially be driven at full speed.

The SERC Common Base Policy lays great emphasis on the importance of conforming to UK and International standards, where available. In the field of computer communications, International Standard Protocols are not yet defined. In order to simplify the task of defining standards, it has been found advantageous to think of communications systems in terms of a number of layers, each level making use of the services offered by lower levels, and making available services to the next higher level. The International Standards Organisation (ISO) has defined a model which divides the communications functions and services into seven levels, ranging from the details of the physical interfaces to the user application level. This model provides a structure within which protocol standards may be developed.

A full definition of ISO standard protocols for communications, conforming to the layer model already established, is not expected for a number of years. In the meantime, the Data Communications Protocols Unit has been set up by the Dol to coordinate the definition of interim UK network protocols. Until the ISO standard protocols have been defined, these protocols are expected to be extensively used, and they should also influence eventual ISO standards. The protocols defined by study groups of the Data Communications Protocol Unit have been published in a series of documents which have come to be known collectively as the 'Rainbow Books'. The 'Yellow Book' in this series contains the definition of a Transport Service (TS) Protocol. Transport Service provides processes which wish to communicate with an interface which is consistent across all underlying networks, in such a way that users are insulated from the peculiarities of particular networks and their low-level protocols. SERC intend to provide a Yellow Book Transport Service over Cambridge Rings, and this will be implemented as Transport Service Byte Stream Protocol (TSBSP). This software presents the same transport service to user programs as the wide area network X25 software which will be used by SERC, and will result in a transparent extension from local to wide area network.

The TSBSP protocol requires a basic block interface to the Cambridge Ring. Such an interface has been written, to run under POS, for the PERQ GPIB/Cambridge Ring interface. A version which will run under the PERQ SERC Unix is now being devised.

5.3. Graphics.

The combination of a high-quality display and the special RasterOp hardware of the PERQ constitute a powerful graphics capability, and it is clear that a large number of applications of the PERQ will exploit this potential.

The RasterOp intrinsic which, as mentioned above, can be called from user programs, is a powerful tool for raster graphics applications. In addition, POS provides facilities for line drawing (supported by microcode) and for the subdivision of the display into a number of different areas, or windows. The latter facility permits the display of text or graphical information in a designated window, and provision is made for the creation, deletion and modification of the size and position of these windows. Using the RasterOp procedure, it is possible to develop an enhancement which allows windows to appear to move over each other, while preserving the display beneath. An algorithm which illustrates the use of RasterOp for this purpose is presented in an Appendix. The use of windows permits the user to selectively display items from a considerable quantity of textual and graphical information, in much the same way as one would select from material laid out on an office desk.

Extending these facilities for the management of windows to a multi-process operating system, such as Unix, presents a number of problems. Clearly, it would be desirable for each Unix process to be able to create and modify one or more windows, but it may also be desirable for a number of processes to display information in the same window, in a cooperative way, to share I/O devices between windows belonging to different processes, and for 'hidden' windows to signal essential information to the user. In order to avoid conflicts between the requirements of different processes, a special 'window manager' process may be necessary to supervise the creation and movement of windows.

The graphics primitives available on the PERQ are evidently very powerful tools, but there is also a need for a graphics applications package. A basic graphics package for the PERQ is being developed by ICL. In addition, ICL and SERC are collaborating on the implementation of the Graphics Kernel System (GKS), version 70, on the PERQ. The Rutherford Appleton Laboratory is currently installing an earlier version of GKS (Version 6.2) under Unix. This will be ported to the PERQ as soon as full Unix facilities are available.

The Graphics Kernel System has very recently been adopted as an ISO Draft International Standard, with a large measure of international support. In a historical account of the development of the standard?, which contains the draft Proposal as an appendix, it is argued that the timing of developments in graphics hardware played an important role in delaying the introduction of a graphics standard, and it was not until 1974, at an IFIP WG5.2 meeting in Malmo, Sweden, that any significant steps were taken towards the definition of a standard. As a result of an initiative taken at this meeting, a workshop (Seillac I) was organised by IFIP WG5.2 at Seillac, France, in 1976, which laid the seeds for the development of the GKS standard. The use of virtual input and output devices was accepted at Seillac I, and some appropriate output primitives and input devices were defined. A major clarification was the distinction between viewing a picture, and modelling a picture out of smaller items. In addition, it was agreed that an initial goal should be to define a core graphics system for viewing aspects of a picture already constructed in world coordinates.

In 1977 an ISO working group was set up, to consider computer graphics standardisation, and the current GKS Draft Standard is the result of a series of meetings of the group in the period 1977-1982.

major objective of GKS was to allow easy portability of graphics systems between different installations. In addition, the Standard is not specific to a particular language, and it should be possible to implement it in any of the ISO standard programming languages. A central concept is that of a graphics workstation, which provides the logical interface through which the applications program controls physical devices. Different types of workstation with different capabilities, reflecting the available hardware, are recognised. The concept of virtual input and output devices has been retained in GKS, but output primitives have been refined by allowing them different attributes. GKS allows great flexibility in the choice of viewport, and this is achieved by defining three different coordinate systems (world coordinates, normalised device coordinates and device coordinates) and two distinct types of transformation. Finally, the use of device independent segment storage admits the possibility of later display on devices associated with workstations not initially activated. This provision is useful if, for example, a user wishes to obtain plotter output of a picture, parts or all of which have been previously viewed on a VDU.

6. PERQ Hardware Enhancements.

A number of hardware enhancements to the PERQ have already been made, since delivery of the first systems. These include extended memory (1/2 and 1 Mbyte systems instead of the original 1/4 Mbyte), and an Ethernet controller board. Further enhancements, which are expected in the near future, are a 16K Writable Control Store, an improved I/O board (faster and with additional facilities), and a Versatek plotter-printer interface. While the PERQ workstation represents a significant advance in the capabilities of single-user computers, further refinements will undoubtedly appear in the near future. Speculation on the desirability of various hardware enhancements to the PERQ is inevitably somewhat subjective, since each user will have his or her own particular requirements. Nevertheless, a number of possible hardware developments may be selected which would have applications in several areas.

Clearly, it is important to maintain the momentum of architectural innovation found in the PERQ. One of the major strengths of the PERQ is that it is microprogrammable, and the extension of the WCS to 16K words will allow a much richer instruction set, and opens up a wide range of potential applications. The performance of the PERQ would also be greatly enhanced by the addition of paging and floating point hardware and fast cache memory, as well as increased main memory. For many graphics applications hardware for clipping and for 3D rotations is also desirable.

The PERQ display could be enriched in a number of different ways. A colour display is an obvious attraction, but with current technology such a device would have much lower resolution than the present black and white display. A grey level display, using several bits per pixel. has the effects of a higher resolution, while maintaining a greater flexibility. For many applications, larger displays are desirable, and two possibilities are an A3 size landscape display with a resolution of 1024 x 768, and a dual A4 head display, which would maintain the present resolution of the PERQ.

The user interface of the PERQ could be greatly enriched; for example, by developing the voice I/O possibilities, and by adding further input devices, such as a mouse and a touch-pad.

Finally, the I/O connectivity of the PERQ could be ameliorated by addition of further serial ports and by the addition of a multibus parallel port interface, which is used by many devices and scientific instruments. Use of the PERQ for real-time control and data acquisition will require a significant increase in I/O rates, either by improvements to the present 280 controlled I/O, or by direct interface to the PERQ I/O bus.

7. Conclusions.

We have summarised the capabilities of the PERQ personal workstation, emphasising those aspects which make it eminently suitable for distributed interactive computing. This environment, where powerful. highly interactive single-user systems with high quality displays are interconnected by high speed networks, is expected to have a profound influence on computing methods in the next decade.

The Science and Engineering Research Council is one of the biggest users of computing resources in the UK, and has anticipated this transformation in computing methods by developing a coordinating plan, the SERC Common Base Policy, which is aimed at avoiding wasteful duplication of effort in the development of basic software for single-user systems, and providing the hardware and software technology to enable an efficient utilisation of such resources. The plan envisages that by 1983 SERC will have over 200 PERQs distributed throughout the UK at universities and SERC laboratories, and that these systems will be linked to each other, and to existing facilities, by local and wide area networks.

The SERC Common Base Policy is not intended as a fixed standard, but is expected to evolve in an orderly way, to reflect continuing technological innovation, and advances is computing methods. In particular, the groundwork has already been laid for a transition to computing systems in which the operating system, as well as computing facilities supplied by network servers, is distributed over a network. This change is expected to take place around the end of this decade.

Acknowledgements.

I am grateful to Bob Hopgood and Rob Witty for comments on earlier drafts of this paper, and for providing unpublished material on the background to SERC's involvement with the PERQ, and the formulation of the SERC Common Base Policy. Dale Sutcliffe provided helpful comments on the GKS Draft International Standard.

The SERC software development work reported in this paper is being done within the Distributed Interactive Computing Section at SERC's Rutherford Appleton Laboratory, and I should like to thank all my colleagues in this Section for useful discussions and access to unpublished documentation. Specifically, Len Ford, Liz Fielding, Janet Malone, Colin Prosser, Trudy Watson and Tony Williams have worked on Unix implementation for the PERQ, and Chris Webb has been concerned with installing GKS. I have also benefited from discussions with Keith Fermor, Bill Sharp and Chris Wadsworth, who are concerned with communications.

References.

1. Thacker, C.P., McCreight, E.M., Lampson, B.W., Sproull, R.F., and Boggs, D.R.: 'Alto: a personal computer', Computer Structures: Readings and Examples (editors D. Siewioreck, C.G. Bell and A. Newell), McGraw-Hill, 1980.

2. Newman, W.M. and Sproull, R.F.: 'Principles of interactive computer graphics', McGraw-Hill, 1973.

3. Rashid, R.F.: 'Accent: A communication oriented network operating system kernel', ACM SIGOPS, 1981,15 (5), pp.64-75.

4. Johnson, S.C.: 'A tour through the portable C compiler', Unix programmer's manual, Bell Laboratories, 1979.

5. Feldman, S.I. and Weinberger, P.J.: 'A portable Fortran 77 compiler', Unix programmer's manual, Bell Laboratories, 1979.

6. Yellow Book: 'A network independent transport service', prepared by Study Group 3 of the Post Office PSS User Forum, SG3/CP(80) 1980-2-16, 1980.

7. Hopgood, F.R.A.: 'GKS - The First Graphics Standard', Rutherford Appleton Laboratory report RL-82-007, 1982.

Appendix.

In this appendix, we present an algorithm for moving an arbitrary rectangular area, or 'window', over an arbitrary display, using the facilities available from the PERQ RasterOp procedure and its corresponding hardware. The various steps of the algorithm involve copying from the display bit-map to (another part of) itself, from the display bit-map to memory buffers and vice versa, and between two memory buffers. All of these copy operations may be performed by RasterOp procedure calls using the RRpl (RasterOp Replace) function, which replaces the destination bit-map with the source bit-map. Two buffers are used alternately to store bit-maps of the part of the display hidden by the window, and in this way the original display is restored as the window passes over. The algorithm is presented as a 'pseudo program', and the steps are illustrated in Figure 6. Figures 6a and 6b show the initialisation stages, steps 1 and 2, and Figure 6c indicates the rectangular areas which are referred to in later steps; a prime is used to indicate the destination area. Figures 6d to 6i illustrate the steps (3 to 8) required to actually move the window from one position to another, and to update the buffers appropriately. The figures show an initial movement of the window, but these steps can be repeated for further movement.

BEGIN 
Initialisation 
create buffer[1], buffer[2];
index 1:= 1; index2:=2;
(1) buffer[2] gets part of display to be concealed (6a)
(2) display bit-map gets window (6b)
(this may be copied from another part of 
 memory, or constructed directly by RasterOp) 
REPEAT 
 calculate the origins, widths and heights 
 of rectangular areas to be moved;
 (save in buffer[index 1] the parts of display 
  that are going to be covered up ) 
(3) buffer[index 1] gets area A from display bit-map (6d) 
(4) buffer[index1] gets area B from display bit-map (6e)
 (now the window is copied in the new position) 
(5) display bit-map gets window at new position (6f)
 (re-draw the bits of display which have been 
  uncovered, using the display saved ) 
(6) display bit-map gets area C from buffer[index2] (6g) 
(7) display bit-map gets area D from buffer[index2] (6h) 
  (complete the image under the window in 
   buffer[index1], by copying from buffer[index2] )
(8) buffer[index1] gets area E from buffer[index2] (6i)
 (now the role of the buffers is swapped, ready for 
  a succeeding move )
 index1:=3-index1;
  index2:=3-index2 
UNTIL finished;
END

Figure 6 shows:

Step 1. The part of the display bit-map to be covered by the window is copied into buffer[2].

Step 2. The window is copied onto the screen; the window display is shown hatched. but may have arbitrary content. The rectangular areas involved in later copy operations are shown.

Step 3. Area A is copied from the display bit-map to buffer[1].

Step 4. Area B is copied from the display bit-map to buffer[1].

Step 5. The window is copied to the new position in the display bit-map.

Step 6. Area C is copied from buffer[2] to display bit-map.

Step 7. Area D is copied from buffer[2] to display bit-map.

Step 8. Area E is copied from buffer[2] to buffer[1].

Figure 6.

Figure 6.
Full image ⇗
© UKRI Science and Technology Facilities Council

Figure 6.

Figure 6.
Full image ⇗
© UKRI Science and Technology Facilities Council

Figure 6.

Figure 6.
Full image ⇗
© UKRI Science and Technology Facilities Council
⇑ 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