Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ OverviewProject □ GEC □ Overview4000 SeriesGEC 4070 Operating SystemInstallationCommunicationsGEC 4000 familyNucleusFunctional spec.Babbage assemblerInstruction set manualNucleus manual □ Prime □ OverviewThe companyPrimos Operating SystemSystemsCommunicationsSoftwarePrime and UMISTOffice AutomationThe Schools ProjectPrime 750FOREST preprocessorMETA II TWSMETA II definitionFINGS graphics systemROOTS extended FORTRANPrime User Manual
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACDICFMulti User Minis
ACDICFMulti User Minis
ACL ACD C&A INF CCD CISD Archives
Further reading

OverviewProject
GEC
Overview4000 SeriesGEC 4070 Operating SystemInstallationCommunicationsGEC 4000 familyNucleusFunctional spec.Babbage assemblerInstruction set manualNucleus manual
Prime
OverviewThe companyPrimos Operating SystemSystemsCommunicationsSoftwarePrime and UMISTOffice AutomationThe Schools ProjectPrime 750FOREST preprocessorMETA II TWSMETA II definitionFINGS graphics systemROOTS extended FORTRANPrime User Manual

Nucleus

The GEC 4000 Series was designed as a real-time system. In consequence, a great amount of effort was spent on defining the structure of the hardware to support the operating system. This hardware was called the Nucleus and provided the critical features upon which a real-time system depended.

Special hardware registers in the central processor were used by Nucleus to keep each segment of program, called a process, or data protected from corruption by errors in other parts of the system.

Communication between processes was provided by a fully asynchronous message-handling system within the Nucleus. It was responsible for responding to all interrupts, and passing messages to the appropriate process. It decided whether a higher priority process should run at that time. Thus all low level scheduling was performed by the hardware which included dumping and reloading registers in the central processor as required.

As far as, say, a GEC 4080 program was concerned, it was working in an environment consisting of 16-bit virtual addresses. However, before these addresses were transmitted to the real store, they were converted into 18-bit actual addresses by the segmentation mechanism of the Nucleus.

The primary unit of program recognised by the 4080 hardware was the process. A 4080 software system was constructed from a set of processes, the interaction between which was entirely controlled by the Nucleus. In consequence, at the programming level, all the programmer needed to consider was the internal structure of individual processes and the smaller units of program from which a process was constructed.

Each process operated within its own address space and this was made up of a set of segments. A segment was the unit of storage recognised by the protection and relocation hardware of the 4080. Segments could be up to 16 Kbytes in units of 64 bytes.

A process could have any number of segments but they had to be within the address space 0 to 64K. This range defined the virtual address space of the process and only four segments, called the current segments were active at any one time. These started at the addresses 0, 16K, 32K and 48K. Instructions were provided so that the process could select which of its segments were the four current segments at any instance in time.

Although not restricted by the hardware, the convention was to separate code and data into separate segments as follows:

Transfer of control from this segments 3 to another code segment automatically caused that segment to be selected as the new current segment 3.

⇑ 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