Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
4315310
Bayliss , ; et al.
February 9, 1982
Title
Input/output data processing system
Abstract
An input/output processor architecture for providing an interface between peripheral subsystems and a generalized data processor. The interface processor enables data to be transferred between two address spaces (the generalized data processor address space and an external processor I/O address space) by mapping a portion of the I/O address space into a portion of the GDP address space. This mapping facility provides the peripheral subsystem with a "window" into the associated GDP subsystem. It accepts addresses within a certain subrange, or subranges, and translates them into references into one or more GDP data segments. A function-request facility provides a functional capability over certain objects within the GDP address space. The two facilities provide software on an external processor with a window into the address space of the GDP that enables the software, via the function request means, to send messages to and receive messages from the GDP and to manipulate an environment provided for the external processor within its address space.
Inventors:
Bayliss; John A.
(Portland,
OR
)
, Cox; George W.
(Portland,
OR
)
, Forbes; Bert E.
(San Luis Obispo,
CA
)
, Kahn; Kevin C.
(Portland,
OR
)
Assignee:
Intel Corporation
(Santa Clara,
CA
)
Appl. No.:
079991
Filed:
September 28, 1979
Current U.S. Class:
710/3
Field of Search:
364/2MSFile,9MSFile
U.S. Patent Documents
3573852
April 1971
Watson et al.
4044334
August 1977
Bachman et al.
4060849
November 1977
Bienvenu et al.
4092715
May 1978
Scriver
4104718
August 1978
Poublan et al.
4149242
April 1979
Pirz
4149244
April 1979
Anderson et al.
Primary Examiner:
Nussbaum; Mark E.
Assistant Examiner:
Chan; Eddie P.
Attorney, Agent or Firm:
Lamb; Owen L.
Claims
What is claimed is:
1. For use in a data processing system including a main processor of a type capable of executing an operation by means of an operator specified in an instruction, said operator being one of a set of main processor operators executable on said main processor, said system having instruction objects defining an operation, and data objects, said instruction objects and data objects being stored in a memory which can be shared by a number of processors, the instruction objects and data objects accessible to said main processor existing in an address space in said memory associated with said main processor,
an interface processor which enables an external processor to interface with said memory and said main processor, said external processor being capable of referencing an I/O address space associated with said external processor, said interface processor comprising:
means for receiving addresses and commands from said external processor, one of said commands being a particular command including bits in said particular command specifying a particular operator;
recognizing means connected to said receiving means for comparing said addresses from said external processor with address registers associated with each of a number of address blocks, each of said blocks falling within a predetermined address range within the I/O address space of said external processor,
said recognizing means including means for generating match signals, one match signal for each of said address blocks,
one of said address blocks including command register means for receiving said particular command from said external processor;
means connected to said recognizing means responsive to said match signals for mapping said addresses within said address range from the I/O address space of said external processor onto the address space of said main processor;
function request means connected to said command register means,
said function request means including means for executing a set of interface processor operators comprising access environment manipulation operators and communication operators in response to said match signal from said one of said address blocks containing said command register means,
said set of interface processor operators being a subset of said main processor operators,
one of said interface processor operators being said particular operator specified in said particular command,
said function request means including means responsive to said bits in said particular command for executing said particular operator,
whereby said external processor is able to make a request for the execution of said particular operator by said interface processor by sending an address corresponding to the address block in which said command register means is contained and writing a copy of said particular command into said command register means,
said function-request means thereby being capable of being invoked by commands contained in instructions within the I/O address space of said external processor;
first interface means for connecting said mapping means and said function-request means with said memory; and,
second interface means for connecting said address and command receiving means with said external processor;
whereby said external processor is provided with a window, via said recognizing means, into the address space of said main processor,
said interface processor operators included in said function request means providing instruction set extensions to the operator set of said external processor to thereby allow a process executing on said external processor, via invoking execution of said communication operators on said function-request means, to send messages to said main processor, and to receive messages from said main processor, and via invoking execution of said access environment manipulation operators on said function-request means, to manipulate objects within said address space of said main processor.
2. The combination in accordance with claim 1 wherein,
said mapping means for mapping said addresses within said address range from the I/O address space of said external processor onto the address space of said main processor consists of N map entries capable of supporting the random mapping of N nonoverlapping address subranges from said external processor into corresponding data segments of the address space of said main processor and wherein,
said means connected to said receiving means for recognizing said addresses from said external processor includes means for recognizing that an address falls within one of said N address subranges within the I/O address space of said external processor.
3. The combination in accordance with claim 2 wherein one map entry of said N map entries and its associated external processor I/O address subrange always maps onto a current context-control segment within said address space of said main processor, whereby said external processor is able to have access to said context-control segment, thereby enabling said external processor to read current status information stored in said current context-control segment.
4. The combination in accordance with claim 3 wherein a copy of the information contained in each processor-resident map entry is represented within acid context-control segment by a data structure comprising a plurality of fields containing parameters for controlling and defining said mapped address range.
5. The combination in accordance with claim 4 wherein said data structure within said context-control segment includes a start address for specifying the starting address of the external processor address subrange mapped by said map entry and a displacement for specifying the extent of said subrange from said start address.
6. The combination in accordance with claim 3 wherein said function-request means is represented within said context-control segment by a data structure comprising a plurality of fields containing a copy of processor-resident information related to the current or most recent function requested, said information comprising function-state information, the op code of the operator requested, the operands operated upon in performing the requested function, and an area used to record the result of the requested function.
7. The combination in accordance with claim 1 wherein said access environment manipulation operators include a first map manipulation operator, the execution of which by said function-request means allows an operation on said external processor to alter the interaddress space mapping provided by one of said address subrange map entries.
8. The combination in accordance with claim 1 wherein said access environment manipulation operators include a second map manipulation operator, the execution of which by said function-request means allows an operation on said external processor to associate a given data segment with a given address subrange map entry.
9. The combination in accordance with claim 1 wherein said communication operators include a first communication operator, the execution of which allows an external processor to receive a signal after a delay of n times quanta.
10. The combination in accordance with claim 1 wherein at least one of said address blocks is dedicated to an I/O address subrange which maps, via said mapping means, onto a current context-control segment in said main processor address space, to thereby enable said external processor to have access to said context-control segment, thereby enabling said external processor to read current status information stored in said current context-control segment.
11. The combination in accordance with claim 1 wherein at least one of said address blocks has associated with it a register containing a segment descriptor which points to the base of a data segment within said main processor address space.
Description
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to data processing systems, and more particularly to an improved input/output processor for interfacing a number of peripheral subsystems employing different communication disciplines with a general-purpose data processor.
2. Description of the Prior Art
In copending patent application Ser. No. 971,661 of Stephen R. Colley et al, entitled "Data Processing System," filed Dec. 21, 1978, there is disclosed an object-oriented data processor architecture which takes full advantage of recent advances in the state-of-the-art of very large-scale, integrated circuit technology. An object-based access mechanism is employed by both the general-purpose data processors and the input/output processors within the system. An object is a representation of related information maintained in a contiguously addressed set of memory locations. Two basic types of objects are recognized and distinguished by a processor. The first basic type (a data segment) contains ordinary data such as characters, integers, reals, etc. The second basic type (an access list) contains access descriptors. Each access descriptor provides information for locating and defining the extent of access to an object associated with that access descriptor. Processors construct complex objects by combinations of objects of the basic types. Mechanisms within the processor identify the types of complex objects and control their use.
One such complex object, a context, defines an environment made up of objects accessible to a given instance of a procedural operation. Processors recognize context objects and utilize them in process execution.
Two other types of hardware-recognizable objects, buffered communication ports and dispatching ports, are defined to provide communication between processors, and the dispatching of ready-to-run processors for execution, respectively.
The generalized data processors (GDP) perform generalized computation over a wide spectrum of data types supported by this type of processor. The input/output processor (IOP) transfers data between two address spaces that it has access to and can reference. For example, transferring data from an input device which exists in the I/O address space, into a data segment which exists in the GDP address space.
An IOP uses the same descriptor controlled segment-based address development mechanism as the GDP. The I/O operations also execute in a context-based environment similar to that provided for the GDP. An IOP also uses the same interprocess communication mechanism and IOPs are selected for service via a dispatching mechanism similar to that used by GDPs.
Because an input/output processor must interface with a number of different types of peripheral subsystems in addition to interfacing with generalized data processors, and must handle asynchronous types of operations, the circuitry for such a processor is very complex. This complexity creates certain problems when implementing an input/output processor in large-scale integrated circuit technology. These limitations include limitations on the number of input/output pins which are available on integrated circuit chips and limitations as to the amount of circuitry which can be fabricated on a single chip with current technology. To overcome these limitations, it is desirable to provide an input/output interface which will allow a plurality of different types of existing microprocessors to be connected to and work with the new data processing architecture. With such an arrangement, input/output operations of the type described above can be performed by the external processor, thus reducing the complexity of the input/output processor requirements. There must be provided an interface by which an external processor can be connected to the system and address the main memory as well as function compatibly with the main system's object-oriented architecture. Such an interface must be able to recognize addresses generated by the external processor, and map these addresses onto the address space of main memory. Furthermore, such an interface must be able to allow the external processor to communicate with processes and processors of the main system. The following is a summary of some of the prior approaches to the problem of interfacing a peripheral subsystem to a data processing system.
In Moreton U.S. Pat. No. 4,035,777 a multiprocessing system is disclosed in which each functional unit produces a response signal when it detects its own address on the bus. A port unit is provided on each functional unit chip and stores each address applied to an internal bus to which it is connected. The port unit functions to apply the stored address to the main bus if no response signal is detected within a predetermined time period. Thus, the port unit does not have to be provided with any information about which addresses are on the main bus and which are on the internal bus as it assumes that all addresses which do not produce any response on the internal bus must correspond to the main bus. Thus, in this system, additional units can be added or removed without modifying the port unit.
Each of the functional units contain a plurality of blocks of storage space, and a storage allocation list which maintains a plurality of pointers identifying the blocks of storage. The list of pointers is then used to dynamically allocate storage space by inserting or removing pointers from the list.
This patent does not disclose means for mapping peripheral subsystem addresses onto the address space of main memory, nor does it provide a functional capability over system objects stored in main memory.
Hendrie et al U.S. Pat. No. 4,048,673 discloses an input/output controller (IOC) fabricated on a chip for communication between a CPU and peripheral devices. It includes a 15-bit address and block length registers for block-oriented peripheral data transfer operations. It does not disclose a structure for providing for mapping of addresses.
Bennett et al U.S. Pat. No. 4,069,510 discloses a peripheral interface adapter which is fabricated on a single chip. The patent addresses the problem of interfacing a processor to a variety of peripheral units having varying logical and electrical interfacing requirements. It uses a control register to allow restructuring of the logical functions under program control. This allows address expansion, and redefinition of peripheral interface pins. It does not, however, show the mapping peripheral of addresses into an address space in a common memory.
Davis et al U.S. Pat. No. 4,075,691 discloses a peripheral control unit which includes a small special-purpose programmable computer. A microcode enables this computer to handle the different communication disciplines corresponding to the various peripheral devices. The control unit includes a direct memory-access module (DMA) which generates the starting address in core memory and sends or receives the 16-bit data word. This patent does not disclose the concept of mapping IO addresses onto an address space in a common shared memory.
Larson Defensive Publication T940019 discloses a computer system in which a supervisory program translates input/output "virtual" addresses which are mapped into corresponding real addresses in memory. This publication does not show the concept of mapping a portion of the IO address space in a memory in order to support data transfer between two address spaces whereby data is transferred from IO devices to main memory or is transferred from main memory to IO devices.
It is therefore a primary object of the present invention to provide a new input/output Interface apparatus which is designed to efficiently utilize large-scale, integrated circuit technology.
It is a further object of this invention to provide an input/output architectural structure which supports an object-oriented data processing system architecture and enables compatibility with systems which do not employ that architecture.
It is also an object of this invention to provide a map facility for mapping an address range from the address space of an external processor into the address space of an object-oriented data processor.
It is also an object of this invention to provide apparatus whereby software running on an external processor is given a window into the address space of an object-oriented processor that enables the software, via the execution of a limited subset of main processor instructions, to send and receive messages from said main processor and to manipulate an environment provided for the external software within the main processor address space.
BRIEF SUMMARY OF THE INVENTION
Briefly, the above objects are accomplished in accordance with the invention by providing an interface processor which employs an object-based access mechanism which is compatible with an object-based generalized data processor architecture. The GDP architecture is capable of recognizing a complex object which defines an environment in an address space associated with said GDP for execution of objects accessible to a given instance of a procedural operation. The interface processor enables external processors and their associated buses to interface with said GDP by providing a mapping facility and a function-request facility. The mapping facility includes means for mapping an address range from the address space of said external processor into the address space of said GDP. The function-request facility provides a functional capability over certain objects within said GDP address space, that can be requested by software running on said external processor. Thus, software on said external processor is given a window into the address space of said GDP that enables the software, via the function-request facility, to send messages to and receive messages from the GDP, and to manipulate an environment provided for said external processor within the GDP address space.
The present invention has the advantage that from the peripheral subsystem side the interface processor reacts like a memory device, by receiving address and command signals and responding with a ready or acknowledge signal. While, from the GDP side the interface processor reacts as a processor with a limited instruction set capable of GDP address generation and capable of performing a subset of the GDP communication operators.
A further advantage is that the peripheral subsystem processor can communicate with a GDP process or be controlled by that process, by invoking previously-defined architectural mechanisms.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing and other objects, features, and advantages of the invention will be apparent from the following detailed description of a preferred embodiment of the invention, as illustrated in the accompanying drawings wherein:
FIG. 1 is a functional block diagram illustrating the invention in relation to other components of a data processing system;
FIGS. 2A and 2B, taken together, are a block diagram of system objects for supporting input/output operations;
FIG. 3 is a block diagram of a computer system of a type in which the invention may be embodied;
FIG. 4 is a more detailed block diagram of the interface processor shown in FIG. 3;
FIG. 5 is a timing diagram of a typical read cycle; and
FIG. 6 is a timing diagram of a typical write cycle.
TABLE OF CONTENTS ______________________________________ Background of the Invention Brief Summary of the Invention Brief Description of the Drawings Table of Contents Introductory Description of the Invention ______________________________________ Part I - Interface Processor Architecture 1.0 Overall System 1.1 Basic Structures and Facilities 1.2 Peripheral Subsystem Address Mapping 1.3 Compatibility Facilities 1.4 System Configuration 1.5 System Initialization 2.0 Information Structure 2.1 Memory 2.1.1 Logical Addressing 2.1.2 Physical Addressing 2.2 Operand Formats 2.3 Operand Representation 2.4 Operand Positioning 2.5 Operand Integrity 2.6 Instruction Positioning 2.7 Peripheral Interface Addressing 3.0 Input/Output Processing 3.1 Computational Data Types 3.2 Environment Manipulation 3.3 Instruction Composition 3.3.1 Types of Operands 3.3.2 Operators 3.3.3 Data Operands 3.3.4 Access Descriptor Operands 4.0 Interface Processor Object Structures 4.1 Segments 4.2 Contexts 4.2.1 Context Objects 4.2.1.1 Context Control Segments 4.2.1.1.1 Mapping Facility Area 4.2.1.1.2 Function Request Facility Area 4.2.1.1.3 Fault Information Area 4.3 Processes 4.3.1
Process Control Segments 4.3.1.1 Process Control Segments 4.3.1.2 Current Service and Buffered Ports 4.3.1.3 Fault Buffered Ports 4.3.1.4 Fault Access Descriptor 4.3.2 Buffered Communication Ports 4.4 Processors 4.4.1 Processor Objects
4.4.1.1 Processor Control Segments 4.4.1.1.1 Interprocessor Messages 4.4.1.1.2 Processor Fault Information 4.4.2 Dispatching Ports 4.4.2.1 Alarm Dispatching Ports 4.4.2.2 Fault Buffered Ports 4.4.2.3 Fault Access Descriptors 4.5 Storage Resources, Transformers, and Labels 4.6 Processor Registers 5.0 Interface Processor Facilities 5.1 Peripheral Subsystem Address Mapping Mechanisms 5.2 Compatibility Mechanisms 5.2.1 Request Protocol 5.2.2 Environment Manipulation 5.2.3
Communication 5.2.3.1 Process-to-Process Communication 5.2.3.2 Processor-to-Processor Communication 5.2.4 A Typical Transfer Cycle 5.3 Exception Handling 5.3.1 Notification 5.3.2 Fault Mechanism Data Structures 5.3.3 Context-Level Faults
5.3.3.1 Object Access Faults 5.3.3.2 Displacement Faults 5.3.3.3 Descriptor Control Faults 5.3.3.4 Interlock Failure Faults 5.3.4 Process-Level Faults 5.3.4.1 Reference Validity Faults 5.3.4.2 Context Fault Failure Faults 5.3.4.3 Segment Descriptor Allocation Faults 5.3.4.4 Nonrestartable Faults 5.3.4.4.1 Communication Instruction Faults 5.3.4.4.2 Storage Allocation Faults 5.3.5 Processor-Level Faults 5.3.5.1 Process-Level Fault Failure Faults 5.3.5.2 Faults Without A Process 5.3.6 Consistency Halts 5.4 Debugging Support 5.5 Low-Level Initialization 5.6 Initialization And Software-Controlled Reset 5.7 Alarm Handling 6.0 Interface Processor Functions 6.1 Op-Code Field 6.2 Operands Field 6.2.1 Data Operands
6.2.2 Access Descriptor Operands 6.3 Function Interpretation 6.3.1 Physical Address Generation 6.3.2 Execution 7.0 Interface Processor Operator Set 7.1 Access Environment Manipulation Operators 7.1.1 Access Descriptor Movement Operators 7.1.2
Context Manipulation Operators 7.1.3 Map Manipulation Operators 7.1.4 Type and Rights Manipulation Operators 7.1.5 Label Manipulation Operators 7.1.6 Access Path Inspection Operators 7.2 Communication Operators 7.2.1 Process Communication Operators 7.2.2 Processor Communication Operators Part II - Interface Processor (IP) and System Interconnections 8.0 Introduction 8.1 Pin Description 9.0 General Description 9.1 Address Recognition 9.2 Mapper 9.3 PRI I/O Logic 9.4 ROM 9.5 Microprocessor Execution Unit 10.0 Peripheral Subsystem Bus Operation 11.0 Summary of Interface Processor Operation ______________________________________
INTRODUCTORY DESCRIPTION OF THE INVENTION
Referring now to FIG. 1, the following introductory description broadly describes the various elements of the system in which the invention is embodied and provides an introduction to some of the terminology used throughout the following specification. A data processing system of the type in which the present invention may be embodied is more fully described in copending patent application entitled "Data Processing System," by Stephen R. Colley, et al, application Ser. No. 971,661, filed on Dec. 21, 1978. FIG. 1 illustrates the various agents in the data processing system described in the Colley et al patent application and the mechanisms that these agents utilize. FIG. 1 also illustrates how the present invention interacts with the overall system. Arrows in the figure denote the following. The agent is located at the source of the arrow and the mechanism that the agent is using is located at the destination of the arrow. Two kinds of agents are shown, processes that are in a particular state, and the processors that the processes are executed on.
The Colley et al patent application discloses a data processor architecture which provides an object-based access mechanism which is employed by processors within the system. An object is a representation of related information maintained in a contiguously addressed set of memory locations. Two basic types of objects are recognized and distinguished by a processor. The first basic type (a data segment) contains ordinary data such as characters, integers, reals, etc. The second basic type (an access list) contains access descriptors. Each access descriptor provides information for locating and defining the extent of access to an object associated with that access descriptor. Processors construct complex objects by combinations of objects of the basic types. Mechanisms within a processor identify the types of complex objects and control their use.
One such complex object, a context, defines an environment made up of objects accessible to a given instance of a procedural operation. Processors recognize context objects and utilize them in process execution.
The architecture also provides the following hardware-recognizable objects: buffered communication ports and dispatching ports.
A buffered communication port is responsive to a currently running process and provides the means for communication between processes. This is illustrated by the interprocess communication mechanism (34) shown in FIG. 1. Each buffered port includes a dual-purpose queue for queuing messages which have been sent and for queuing processes that are waiting to receive a message.
Dispatching ports and buffered ports are utilized in the dispatching of ready-to-run processes for execution by an available processor. The dispatching mechanism (36) is shown in FIG. 1. Each dispatching port includes separate queuing means for queuing processes sent from a buffered port for execution, and for queuing processors that are available to receive a process for execution thereof.
As just described, the interprocess communication mechanism (34) is utilized to bind a message to a process, and the dispatching mechanism (36) is utilized to bind the process to an available processor, for execution. The processor with the service request (a message/process pair) examines the appropriate dispatching port. If no processor is queued at that port, then the service request is queued at the port to wait for an available processor. If there had been a processor queued at the dispatching port awaiting the arrival of a service request, then the processor with such a service request can bind the service request to the waiting processor. An interprocessor communication mechanism (42) is provided so that the requesting processor is able to communicate to the waiting processor that it can begin executing the process which has been bound to it.
The interprocessor communication mechanism has several other uses as more fully described in the above-identified Colley et al patent application.
Two types of processors are described in the above-identified Colley et al patent application, generalized data processors (GDP) and IO processors (IOP). A third type of processor referred to in this specification as a peripheral subsystem processor, is the logical combination of an external processor within a peripheral subsystem and an interface processor (IP), as contemplated by the present invention. The IP enables an external processor, such as an Intel 8085, 8086, 8088, etc., to interface with the data processing system and communicate with a GDP process or be controlled by that process.
An interface processor provides two fundamental facilities, a mapping facility and a function-request facility. The address-mapping facility allows the external processor to transfer data between two address spaces (the GDP address space and the IO address space) by mapping a portion of the peripheral subsystem address space into a portion of the GDP address space. This mapping facility provides the peripheral subsystem with a "window" into the associated GDP system. The IP accepts addresses from the external processor within a certain subrange, or subranges, and translates them into references into one or more GDP data segments.
The function-request facility is provided to execute functions which enable the IP to bring an attached external processor up to the architectural level of a generalized data processor. The function-request facility executes an extended instruction set which is available to software running on the external processor to enable that software to perform certain functions which are available to other processors (GDP or IOP processors) on the system. This mechanism allows an extent of control and manipulation over objects within the GDP address space. One such function enables software on the external processor to receive messages (such as are transmitted between processes within the GDP address space) across the IO interface. Conversely, a function is provided to enable an external processor to send a message across the IO interface to a process operating within the GDP address space. A set of operators is therefore available by means of the function-request facility for use by software on the external processor. There are basically two types of operators, operators for communication, such as send message, or wait to receive message, and access-environment manipulation operators which allow the software on the external processor to manipulate the environment in terms of the access descriptors which describe that environment. This environment, 16 in FIG. 1, is provided in the GDP address space for the external processor.
There is provided for a process running on a GDP or main processor (38) a current process environment (18). The process environment includes a context object associated with the instructions being executed by the process. This context object describes an accessing environment for software which is running in the context. The same kind of environment (20), but not including unnecessary facilities, is provided for an external processor (41) interfacing with the system through an interface processor (40). Since an interface processor has no need for an operand stack, the context being used by the external processor does not include such a stack. Also, the fault-handling mechanisms employed by an IP are different than those employed by a GDP.
Interface processors have no sequential instruction stream, and therefore no intercontext or intracontext communication mechanism is provided.
Assume now that there is a process running on a GDP (38) within the system, and that the process needs a data transfer from an IO device. The following describes how a data transfer is requested, how the request is performed by software on the external processor, and how the results of that data transfer (completion code information, etc.) is transmitted back into the GDP system.
The process running on the GDP sends a message, asynchronously, to the process running on the external processor by means of the interprocess communication mechanism (34) associated with the context object stored in main memory and associated with the IO process (20). The IO process responds to the message by performing the IO data transfer. The process running on the external processor then sends a message back to the GDP process indicating that the data transfer has been completed. This operation is similar to that described for an IO processor in the above-identified Colley et al patent application. The difference is that an external processor lacks compatible instructions and interfacing to operate within the address space of the main memory. In order to accommodate the external processor, the IP has a function-request facility. The external processor sends a command via a command interface to the IP to execute a wait-to-receive-a-message operator. The external processor will then halt or go into an idle loop until that message arrives. The IP is designed so that the external processor merely treats the function-request facility as a peripheral interface when asking for the functions to be done. This is accomplished by writing a bit pattern into a command register of the IP. The external processor also sets up a status register signifying whether it wants an interrupt at the completion of the function. The software can then halt or go into a loop testing the status information. The interface processor then performs the requested function just as a peripheral would, in this example, the wait-to-receive-a-message operator. In executing the wait-to-receive-a-message operator, the IP uses the information in the command register to find the appropriate buffered communication port by means of the access information within its context object (representing the environment within the main memory available to software running on the external processor). Upon locating the communication port the IP will find a message deposited there by a process running on the GDP. The IP then places the access descriptor for the message into the context object for the IO process. The IP then signals completion by posting status or by interrupting the external processor. The external processor then responds to the interrupt, or responds upon testing status, by issuing addresses which are mapped into main memory by means of the address map in the IP. Upon having transferred all the addresses specified in the message, the software on the external processor notifies the process running on the GDP of completion by writing a bit pattern into the command register. This bit pattern requests that the information be sent back to a specified communication port through the interprocess communication mechanism (34). Thus the software on the external processor has performed two functions. First, it asked to receive a message, and second, after receiving a message, it sent a message to the communication port specified in the received message. The external processor can now return to the instruction code that request another message, i.e., the wait-for-message operator.
PART I-INTERFACE PROCESSOR (IP) ARCHITECTURE
1.0 OVERALL SYSTEM
The Interface Processor (IP) serves as a "compatibility" component to support interfacing all sorts of "alien" components and boards, henceforth called "peripheral subsystems," to Generalized Data Processor (GDP) systems.
Generalized Data Processors (GDPs), as defined in the above-identified Colley et al patent application, function within a GDP address space and can only reference objects within that space. Interface Processors (IPs), as defined herein, function at the boundary between two address spaces. The first is a GDP or main processor address space, and the second is called a peripheral subsystem or external processor address space.
Positioned as they are at the boundary between two address spaces, interface processors present two different views of themselves: one to the associated peripheral subsystem and one to the GDP system. The main purpose of interface processors is to transfer data between these two address spaces by "mapping" of a portion of the peripheral subsystem address space onto a portion of the GDP address space. A secondary purpose of interface processors is to provide a level of functional compatibility between software in the GDP system and software in the peripheral subsystem. Given these two roles to fulfill, an interface processor provides the impression to the associated peripheral subsystem of being composed of one or more memory modules and a memory-mapped peripheral interface. The view provided to the GDP system is quite different. As described in the next section, on the GDP side an interface processor looks much like any other GDP processor. When describing the interface processor in this document, each point of view is used when appropriate. For example, from the peripheral subsystem viewpoint the compatibility mechanisms are made available by a set of functions that can be requested via the peripheral interface. From the GDP point of view, each of these functions, when executed by an interface processor, is indistinguishable from the same function being performed as part of the corresponding instruction on a generalized data processor. Functions and instructions are thus synonymous when both points of view are considered.
1.1 BASIC STRUCTURES AND FACILITIES
Interface processors use the same descriptor-controlled, segment-based, address-development mechanism as used by all processors. Interface processors also provide four-component, context-based environments similar to those provided on generalized data processors. Basically the same environment manipulation facilities are available as on other processors. Interprocess communication is supported via the same message-based mechanism used by other processors. Interface processor processes are selected for service via the same dispatching mechanism used by other processors. Interprocessor communication mechanisms are similar. Storage allocation, base/system-type management and extended-type management employ the same mechanisms. Exception handling and debugging necessarily employ different mechanisms.
1.2 PERIPHERAL SUBSYSTEM ADDRESS MAPPING
For an object-oriented data processing system to directly share all or part of an address space with a peripheral subsystem would subvert the addressing-related protection mechanism of the system. Thus, to directly interface a peripheral subsystem to such a data processing system, what is needed is some way to control the reference patterns of such peripheral subsystems. Such control must at least apply to any components of a peripheral subsystem address space shared with such system.
The interface processor supports the mapping of all or part of the addresses available to a given peripheral subsystem into the system address space. This "mapping facility" provides the peripheral subsystem with a "window" into the associated system. It accepts addresses within a certain subrange or subranges and translates them into references into one or more data segments. The number of address subranges, their sizes, the variability of the location and length of these subranges, and the representation and semantics associated with the related environment within the system are described in sections 4 and 5.
1.3 COMPATIBILITY FACILITIES
Beyond simple address-mapping compatibility, an interface processor makes other compatibility facilities available to software within an associated peripheral subsystem.
Assume that some external processor (e.g., an Intel 8085, an Intel 8088, or an Intel 8086) within the peripheral subsystem provides the necessary data manipulation facilities for that subsystem. The only additional services, beyond address mapping, likely to be required by the peripheral subsystem of the object-oriented main processor system are those unique to such systems (e.g., hardware-supported interprocess communication). For example, software within a peripheral subsystem might need to inform some managing process within the associated main processor system upon completion of a data transfer. These operators are provided via the "function-request facility" of the interface processor. The level of communication supported and the request protocol employed (i.e., command level) are described in sections 4 and 5.
1.4 SYSTEM CONFIGURATION
FIG. 1 represents the system configuration in which all interface processors will find themselves used. More detailed information on possible physical system configurations can be found in Part II of this specification.
There are several advantages to the above approach. It allows any active agent in a peripheral subsystem (called "external processors") to be brought up to main processor system addressing standards for the part of their address space within the associated system. It supports the use of all past and future peripheral subsystems produced by either Intel or other manufacturers as long as they can interface to the bus protocol supported by the interface processor. It encourages buffering to support peak data rates via memory in the peripheral subsystem close to the source/destination. It supports more distributed intelligence in peripheral subsystems (i.e., ones controlled by nonobject-oriented processors). When used as purely a mapping facility, it is a completely passive agent from the point of view of the peripheral subsystem. In fact, the peripheral subsystem need not know that some of its addresses are being mapped.
As described in section 4, the problem of supporting high speed peripheral controllers is avoided by providing special support for block transfers through some of the mapped address subranges.
1.5 SYSTEM INITIALIZATION
At system initialization, the temporary segment table directory and associated data structures (described more fully in section 4.1 of the above-referenced Colley et al patent application) must be initialized prior to any processor beginning the initialization sequence. This information cannot preexist in the required locations (i.e., be encoded there in a ROM) because it is subject to later change. Thus, the required information is moved into the required locations from an image encoded in ROM or PROM elsewhere in the system. Since none of the processors in the system have yet qualified any of their address development information, the processor performing this low level initialization must work at the physical address level. This movement is performed via a designated IP.
2.0 INFORMATION STRUCTURE
The memory component of a system is made up of one main processor address space and one or more peripheral subsystem address spaces, each containing some amount of read/write and read-only memory. All main processors (of any type) in a system can access the contents of all of the main processor address space. By mapping given peripheral subsystem address subranges into data segments in the associated main processor address space, interface processors provide external processors access to parts of the associated main processor address space. This section describes how information is represented and accessed in the main processor address space.
2.1 MEMORY
The main processor address space is implemented as a two-level memory structure. Any main processor software system exists in a segmented environment in which a logical address specifies the location of an operand. The processor automatically translates this logical address into a physical address for accessing the value in physical memory.
2.1.1 Logical Addressing
A main processor address space is partitioned into many segments. A segment is a group of contiguously addressed memory bytes, where a byte contains eight binary bits of information. A segment may be of any length from 1 to 65,536 bytes.
The instructions of an operation being executed by an external processor (including those executed by the associated interface processor upon request) have access to the information contained within the segments that make up its current context. Instructions executed by an external processor may cause the generation of one or more peripheral subsystem addresses. Those peripheral subsystem addresses which are to be mapped into the main processor address space are translated into main processor logical addresses. As part of the execution of functions requested by external processor software, interface processors make reference to operands using logical addresses.
Normally, main processor logical addresses for data operands have two components: a segment selector and an operand displacement. The segment selector specifies an index to an entry in one of the current context's primary access lists. That entry indirectly specifies the memory segment that contains the operand. The operand displacement is the offset to the beginning byte of the desired operand from the base of the chosen segment. At mapping facility setup time, each mapped peripheral subsystem address subrange is directly associated with a given main processor data segment. Thus, no segment selector component is required dynamically. The dynamic displacement into the subrange is used as the operand displacement.
The maximum logical address space of a software system is limited to U.S. Pat. No. 2,097,152 segments of 65,536 bytes each for a total of 137,438,953,472 bytes.
2.1.2 Physical Addressing
Logical addresses are translated by the processor into physical addresses much as explained in section 7 of the above-identified Colley et al patent application. The only major differences are that no caching for segment tables or data segments is done. Physical addresses are transmitted to memory by a processor to select the beginning byte of a memory value to be referenced. A physical address within the main processor address space is 24 binary bits in length. This results in a physical memory size limit for the main processor address space of 16,777,216 bytes. A physical address within a peripheral subsystem address space recognizable by an interface processor is 16 binary bits in length. This results in a physical memory subrange size limit for an interface processor of 65,536 bytes.
2.2 OPERAND FORMATS
When an external processor executes instructions which generate addresses mapped by the mapping facility, it manipulates data operands found in the data segments of the current context. An individual data operand may occupy one or two bytes of memory or a byte or double byte respectively. When an interface processor executes operators, upon request from an external processor, it manipulates data and/or access descriptor operands either encoded as literals in the registers of the function-request facility or found in the segments of the current context. An individual access descriptor operand always occupies four bytes of memory or a word. All operands are referenced as described above. The displacement in such an address is the displacement in bytes from the base address of the segment to the first byte of the operand. For operands consisting of multiple bytes, the address locates the low-order byte, and the higher-order bytes are found at the next higher consecutive addresses.
2.3 OPERAND REPRESENTATION
A convention for representing data and access descriptor structures that are stored in memory is described in section 2.3 of the above-identified Colley et al patent application. This convention is used herein. The bits in a field are numbered by increasing numeric significance, with the least-significant bit shown on the right. Increasing byte addresses are shown from right to left.
2.4 OPERAND POSITIONING
The data structures discussed above may be aligned on an arbitrary byte boundary within a data segment. Note that more efficient system operation may be obtained when multibyte data structures are aligned on double-byte boundaries if the memory system is organized in units of double bytes. The access descriptor structures discussed above may be aligned only on a word boundary within an access list segment.
2.5 OPERAND INTEGRITY
The multiprocessor architecture described in the above-identified Colley et al patent application places certain requirements on the operation of the memory system to ensure the integrity of operands that can potentially be accessed simultaneously. Indivisible read-modify-write (RMW) operations to both double-byte and word operands in memory are necessary for manipulating system objects. From the time a RMW-read is processed for a location in memory, any other RMW-reads to that location must be held off by the memory system until a RMW-write to that location is received (or until a RMW timeout occurs). Also for ordinary reads and writes of double-byte or longer operands, the memory system must ensure that the entire operand has been either read or written before beginning to process another access to the same location. Otherwise, for instance, as a result of two simultaneous writes to the same location (by two processors), the set of locations used to store the operand could contain some interleaved combination of the two written values.
2.6 INSTRUCTION POSITIONING
With the interface processor, there is no concept of a sequential instruction stream. Rather, the operators provided by the interface processor, via the function request facility, can be considered as instruction set extensions to the operator set of the associated external processor. These extensions allow software executing on the external processor to manipulate the environment provided for it in the main processor address space. It is expected that the execution of operators by the interface processor will be interspersed, upon request by external processor software, with the execution of operators provided by the external processor. Interface processor operators are requested and then executed one at a time. Any time an interface processor is executing a requested operator, it will not accept further operator execution requests.
2.7 PERIPHERAL INTERFACE ADDRESSING
From the peripheral subsystem point of view, the interface processor appears to be a combination of several memory module interfaces (i.e., equal to the number of peripheral subsystem address subranges being mapped) and a memory-mapped peripheral interface. Actually, the memory modules represented by the mapped subranges are really implemented as part of the main processor address space. The peripheral interface, which is really just another mapped subrange, is represented both by information in registers in the interface processor and by a copy of that information in the main processor address space. What are logically the memory module interfaces are selected by a 16-bit physical memory addresses within given subranges of the peripheral subsystem address space. To access an individual data operand in one of those memory modules, the external processor instruction specifies an address in the subrange associated with the segment in which the data operand is really found. The displacement into that subrange is used as an operand-selecting displacement into that segment. What are logically the command, status, and data registers of the memory-mapped peripheral interface are also selected by 16-bit physical memory addresses within a given subrange of the peripheral subsystem address space. To access an individual register in the peripheral interface, the external processor instruction specifies an address in the subrange in which the peripheral interface registers are really found. The displacement into that subrange is used as a register-selecting displacement into that segment.
Three methods are available for synchronizing interface processors with their controlling external processors. When in randon (i.e., nonblock) transfer mode, each active mapping facility subrange responds to addresses within it and the associated control signals just as would a memory module of that size and characteristics (i.e., RAM/ROM/PROM, latency, etc.). That is, it uses address reception as a stimulus. When in block transfer mode, each active mapping-facility subrange can be setup to use either address reception stimulus or request/address reception stimulus. In either case, when in block transfer mode, a mapping facility transfers data in only one direction based upon an internally-generated displacement. If an internally-generated displacement is used, with block transfers the address received serves only as a stimulus and plays no part in the displacement computation. This mechanism provides for both "swept" and "source/sink" types of transfers. The view taken with the "swept" approach is that a block of data is being transferred to/from a block of memory which is swept by a sequence of addresses. The view taken with the "source/sink" approach is that a block of data is being transferred to/from a single memory location which is addressed again and again until the block of data has been transferred. Request/address synchronization is provided to allow for better peripheral subsystem bus utilization. An interface processor accomplishes this by generating a transfer request signal to indicate its desire either to have data stored into or to have data removed from a particular associated register. The external processor will respond by generating the appropriate physical memory address. The interface processor then uses that stimulus to gate the associated data on to or off of the peripheral subsystem bus.
4.0 INTERFACE PROCESSOR OBJECT STRUCTURES
All main processors (GDPs and IOPs) make extensive use of nonprimitive, hardware-recognized, data structures to represent the various system objects defined in its functional hierarchy. For convenience, efficiency, and logical consistency, the data structures for these system objects are built from data of the primitive types described in section 3 of the above-identified Colley et al application. This allows them to be created and manipulated by any generalized data processor, without circumventing the safety and protection of the access mechanisms.
The facilities that support the recognition and use of system objects also provide for the constant checking of both their type and structure prior to use. Should a deviation from either specification be detected by a processor, an exception is recognized. Such exceptions may either be events of which software must be made aware but which do not preclude continued execution of the current instruction stream or they may be events which require immediate software attention. A number of such exceptions are described in this section. A detailed description of the exception-handling mechanisms appears in section 5.
4.1 SEGMENTS
The use of the segment as the logical basis for every type of system object is fundamental as segments form the foundation for all address development and access control. Segments also serve as the building blocks for all larger and more specialized computational objects and are the basis for realizing a multilevel or virtual memory capability. Normally, a single segment is sufficient to contain the data structure defined for a system object. In those cases, however, where a system object is a composite of primitive data and other system objects, a number of segments may be used.
When referencing the main processor address space, interface processors use the same access-descriptor-controlled, segment-based, address-development mechanism used by other processors.
4.2 CONTEXTS
In the most general terms, contexts for interface processors and generalized data processors serve the same purpose. They are used to represent an access environment in which process execution can take place. On closer inspection, however, the differences are significant. For example, with interface processors there is no concept of a sequential instruction stream. Instead the only instructions executed by interface processors are functions requested, one at a time, by software executing on the associated external processor. At a mundane level, this means that interface processor contexts need not provide access to instruction segments or operand stacks. More significantly, without a sequential instruction stream there are no concepts of intracontext or intercontext control flow either. This results in the binding between interface processor processes and contexts being static.
An interface processor context is used to represent the access environment available within the main processor system to the logical process being executed on the logical processor comprised of the interface processor and the associated external processor. The operators provided by the external processor affect the contents of data segment in this environment via the address mapping facility of the interface processor. The operators provided by the interface processor affect this environment via the function-request facility of the interface processor.
4.2.1 Context Objects
Referring to FIG. 2A, each context object consists of at least six access descriptors. Moving up from the lowest position in the context object, the first descriptor is an access descriptor for the context control segment. The next is replaced when the context is actually invoked by an access descriptor for the message passed to that context, if any. The third access descriptor is an access descriptor for the context itself. The next two descriptors are the public and private access lists of the domain in which the context's operation was defined. The sixth access descriptor is replaced dynamically whenever the associated operation selects a new entry access list. The rest of the context object, above those entries defined above, is intended for use as descriptor working storage for the context. The base rights field of a context object access descriptor is interpreted in the same manner as for all objects of base-type access list. The system-rights field of a context-object access descriptor is uninterpreted.
4.2.1.1 Context Control Segments
Each context object contains an access descriptor for an associated context control segment (FIG. 2B). The intended use of this data segment is as instance specific control information, for recording a copy of the processor-resident information contained in the function request facility and the mapping facility, for recording fault information, and as randomlyaddressable scalar working storage. Note that each of the processor-resident copies of the various state fields described below (i.e., context status, map entry state, function state, and fault state) are interlocked with respect to further change once a state change occurs. Other state changes are disallowed until the given state field has been read by external processor software. This prevents loss of any status information. Future revisions of this document will provide complete descriptions of these interlocks. The copy of processor-resident information in the context-control segment is updated by the processor whenever a significant state to that information occurs (i.e., function completion or block transfer completion).
The first double byte in the context-control segment contains context status information. It specifies the state of various internal processor flags at the moment they were last changed. The organization of the context status field is shown below. ##STR1## The interpretation of the interrupt source subfield is as follows:
00--block transfer complete
01--function complete
10--fault
11--function loading override
The map entry number is simply the binary encoding of the number of the map entry which completed a transfer.
The context locks are used to give one processor or one process exclusive access to the context anytime a change is being made to the context object. When the context is locked by a processor, the second double byte contains the locking processor's identification value. When the context is locked by a process, the second double byte contains the locking process' identification value.
The base-rights field of a context-control-segment access descriptor is interpreted in the same manner as for all objects of base-type access list. The system-rights field of a context-control-segment access descriptor is uninterpreted.
4.2.1.1.1 Mapping Facility Area
The mapping facility consists of eight map entries capable of supporting the random mapping of eight nonoverlapping address subranges from the peripheral sybsystem into corresponding main processor data segments. Two of these map entries (entries 0 and 1) are capable of supporting block transfer as well as random mapping. One map entry (entry 7) and its associated peripheral subsystem address subrange always maps onto the current context-control segment. The two major purposes of this subrange are to capture references to the function-request facility and to allow external processor software to read current status information. When operands are read from this subrange, the processor-resident information is accessed. When data is written into this subrange, it is written through to the context-control segment. Data written into the part of the subrange representing the function request facility is captured when no function is in progress. During function execution, the capture of further function requests is interlocked. As stated above, the copy of processor-resident information in the context-control segment is updated by the processor whenever a significant state to that information occurs (i.e., function completion or block transfer completion).
A copy of the information contained in each processor-resident-map entry is represented within the context-control structure shown in FIG. 2B.
The entry-state field is used to describe the current state of the given map entry. It has the following organization: ##STR2##
The 1-bit map valid subfield indicates whether or not this map entry is currently in use in mapping. If the bit is zero, this map entry is not used in address inspection. If the bit is one, this map entry is used in address inspection. The processor-resident copy of this subfield is checked by the mapping facility each time a peripheral subsystem address is received for inspection. Both the map-valid and segment-valid subfields must contain ones for a peripheral subsystem address to be mapped via a map entry.
The 1-bit segment-valid subfield indicates whether or not this map entry currently has a data segment associated with it via the corresponding data segment, segment-descriptor register. A value of zero indicates that no data segment is associated. A value of one indicates that a data segment is associated. The processor-resident copy of this subfield is checked by the mapping facility each time a peripheral subsystem address is received for inspection. Both the map-valid and segment-valid subfields must contain ones for a peripheral subsystem address to be mapped via a map entry. If the segment-valid subfield contains a one and the map-valid subfield contains a zero, a mapping setup error fault occurs.
The 1-bit transfer mode subfield indicates whether this map entry is in random or block transfer mode. A value of zero indicates that this map entry is in random mode. A value of one indicates that this map entry is in block transfer mode.
The 2-bit block transfer state subfield indicates the state of the block transfer whenever a map entry is in block transfer mode. It is encoded as follows:
00--transfer in progress
01--transfer terminated upon count runout
10--transfer termination upon fault
11--transfer termination forced
The 1-bit synchronization-mode subfield indicates which synchronization stimulus is to be used during a block data transfer via this map entry. A value of zero indicates that address reception stimulus alone is to be used. This means that the associated external processor can generate a new bus access immediately upon completion of the previous one. Such action can potentially lead to locking up the peripheral subsystem bus when the addressed map entry is not ready for another access cycle. A value of one indicates that REQ/stimulus is to be used. This means that the associated external processor can only generate a new bus access upon receipt of a REQ signal from the map entry to be addressed. By not generating a new bus access until guaranteed of reasonable response time, intermediate bus accesses by other address generators in the peripheral subsystem are allowed.
The 2-bit transfer direction subfield indicates the types of read/write requests which are valid with respect to this map entry. Interpretation of the transfer direction subfield is as follows:
00--reading or writing may occur
01--only writing may occur
10--only reading may occur
11--neither reading or writing may occur
The 1-bit memory overlay subfield indicates whether or not the peripheral subsystem address subrange associated with this map entry overlays physical memory in the peripheral subsystem. If physical memory is overlaid, whenever an address is mapped via this entry a subsystem bus protocol is employed which prevents that overlaid memory from responding. A value of zero indicates that no memory is overlaid. A value of one indicates that memory is overlaid.
The 1-bit transfer complete interrupt enable subfield indicates whether or not an interrupt is to be generated upon block transfer completion by this map entry. A value of zero indicates that an interrupt is to be generated upon block transfer completion. A value of one indicates that an interrupt is not to be generated upon block transfer completion.
When the segment-valid subfield of the entry state field indicates that a data segment is associated with this map entry, the segment selector field contains the segment selector used to reference the access descriptor for the associated data segment when access to that segment was qualified.
When the transfer mode subfield of the entry state field indicates that this map entry is in block transfer mode, the processor-resident copy of the count field indicates the number of operands remaining to be transferred for transfer termination to occur normally (i.e., upon count runout). Whenever normal transfer termination occurs, both copies of the count field are zero. Whenever normal transfer termination does not occur, both copies of the count field indicate the number of remaining, but not transferred, operands.
When the transfer mode subfield of the entry state field indicates that this map entry is in block transfer mode, the processor-resident copy of the displacement field indicates the displacement into the associated data segment of the next operand to be transferred.
The start-address field is used to specify the starting address of the peripheral subsystem address subrange mapped by this map entry. Subranges are 2**n bytes in length with n being in the range zero to sixteen. A subrange of a given power of two in size (say 16 bytes) must appear on an addressing boundary of the same power of two (i.e., a 16-byte boundary). A subrange of 2**n bytes in length will thus have a starting address containing at least n trailing zeros. Start addresses are always an integer multiple of an integer power of two (i.e., m*2**n). The n is as described above. The m is any integer such that the above conditions hold and the value of the starting address is limited to the range 0 to 65,535.
The mask field contains a mask which is used to specify the size of the peripheral subsystem address subrange to be mapped by this map entry. The mask is composed of two contiguous bit-string subfields. The higher-order bit string contains all ones. The lower-order bit string contains all zeros. The mapped address subrange is 2** (number of zeros in the lower-order bit string) bytes in length beginning at the starting address.
4.2.1.1.2 Function-Request Facility Area
The function-request facility is the part of the interface processor which accepts function requests and performs the requested function. The function-request facility area of the context-control segment contains a copy of the processor-resident information related to the current or most recent function requested. As shown in FIG. 2B, the area consists of four contiguous parts. The first part is one double byte in length and contains the function state information. The second part is one double byte in length and contains the op-code of the operator requested. The third part is eight bytes in length and contains the operands operated upon in performing the requested function. The fourth part is eight bytes in length and is used to record the result of the requested function. The organization of the function state field is shown below. ##STR3##
The interpretation of the function completion state subfield is as follows:
00--function in progress
01--function completed normally
10--function completed faulted
11--reserved
The function complete interrupt enable subfield indicates whether or not an interrupt is to be generated upon function completion. A value of zero indicates than an interrupt is to be generated upon function completion. A value of one indicates that an interrupt is not to be generated upon function completion.
The function loading override interrupt enable subfield indicates whether or not an interrupt is to be generated upon function-loading override. A value of zero indicates that an interrupt is to be generated upon function-loading override. A value of one indicates that an interrupt is not to be generated upon function-loading override.
The interpretation of the function request source subfield is as follows:
00--function requested via the function-request facility
01--function requested via interprocessor communication
10--function requested via alarm
11--reserved
4.2.1.1.3 Fault Information Area
To assist in the diagnosis of a fault, fault information is recorded in the context-control segment. At the occurrence of a fault, a processor automatically places information in this area that defines the type and circumstances surrounding the fault. The appropriate fault handler may use it to undertake repairs. Only those fields needed to record data specific to the given fault are valid upon entry to the fault handler. Which fields are valid under which circumstances is discussed in section 5. Diagrammatically, the fault-information area of a context-control segment appears as shown in FIG. 2B.
The fault-state field is used to describe the current or most recent fault state. It has the following organization. ##STR4##
The fault-state flag specifies whether or not the context is in faulted state. A value of zero indicates that the context is not in faulted state. A value of one indicates that the context is in faulted state.
The fault-level subfield indicates whether the fault which has occurred is context-level, process-level, or processor-level. The fault handler requires this information in order to know where the fault information has been stored.
Whenever a fault occurs within a context, a fault interrupt can be generated causing control within the external processor to flow from the current instruction stream to an instruction stream called the fault handler. Any repair action possible may be programmed into this handler. The fault-interrupt-enable subfield indicates whether or not an interrupt is to be generated upon occurrence of a fault. A value of zero indicates that an interrupt is to be generated upon occurrence of a fault. A value of one indicates that an interrupt is not to be generated upon occurrence of a fault.
The interpretation of the fault-source subfield is as follows:
00--fault originated in ampping facility
01--fault originated in function-request facility
10 to 11--reserved
The fault code word is used to record the cause of a fault (e.g., a segment-displacement fault).
The fault-segment selector is used to record a segment selector for a segment which caused a fault. The fault displacement is used to record the displacement which caused a fault or access-descriptor segment selector which caused a fault.
4.3 PROCESSES
Logically, a process is simply an environment in which execution by a processor can occur. When the execution of a process occurs, it does so at a particular site or point within the associated environment. In a combined external-processor/interface-processor system, that point is defined, at any instant, by a specific instruction within a specific external processor instruction stream. The additional environment provided by the interface processor, extends that of the external process to be logically within a specific context, within a specific domain within the main processor address space. The execution point moves, of course, as each instruction is executed because a new instruction is automatically specified. Occasionally, as the result of instruction execution, a new instruction stream within the external processor software is specified. Unless the process should indicate its termination, the execution point continues to move in this manner forever. There is thus a close and long-term association between the environment provided by an interface processor and a particular set of external processor software. With interface processors, there are no concepts of service period or involuntary process suspension. Interface processes operate under "run-to-completion" scheduling.
4.3.1 Process Objects
Provided there is some means for recording the coordinates of any particular execution point, a processor may suspend the execution of a process whenever necessary. When the execution of a process is suspended, its context object already records most of the information needed to resume its execution. The only piece of information it does not record is the identity of the context object currently in use by the process. That information is recorded in another hardware-recognized data structure, called a process object. Since there is no concept of intercontext control flow with interface processors, this information is constant. Thus, in the event the process is suspended, no further information need be saved.
In addition to the current context object information, a process object, 140 (FIG. 2A) contains descriptors for several other objects related to a process. Generally, these objects are not accessible to the process, but are instead used by hardware and system software for process maintenance and control.
The base rights field of a process object access descriptor is interpreted in the same manner as for all objects of base-type access list. The system-rights field of a process object access descriptor is uninterpreted.
The objects referenced by a process object are functionally described in the following subsections. In those cases where the referenced object is uniquely associated with process objects (i.e., actually part of their basic structure), the structure of the object as well as its function is described.
4.3.1.1 Process-Control Segments
The process-control segment, 150 (FIG. 2A), accessible via the first entry in a process object, contains fields for recording both process state and fault information.
The first double byte in the process-control segment contains process-status information that is otherwise not found in any of the segments associated with a process. In particular, it specifies the state of certain internal processor flags at the moment execution of the process last ceased. Finally, it contains the state of the process itself, such as whether it is running or waiting for a processor. The organization of the process status field is shown below. ##STR5##
The running/waiting bit is interpreted as follows:
0--running
1--waiting
The queued/dequeued at a buffered port bit is interpreted as follows:
0--not queued at a buffered port
1--queued at a buffered port
The queued/dequeued at a dispatching port bit is interpreted as follows:
0--not queued at a dispatching port
1--queued at a dispatching port
The assigned/deassigned bit is interpreted as follows:
0--assigned to a process
1--not assigned to a process
The process locks are used to give one processor or one process exclusive access to the process anytime a change is being made to the process object. When the process is locked by a processor, the second double byte contains the locking processor's identification value. When the process is locked by a process, the second double byte contains the locking process's identification value.
Also contained in the process control segment are two identification numbers. The first of these, called the process ID may be read by a process at any time in order to establish its own identity within a module of a system's resource management software. Similarly, the principal ID may be read by a process at any time to establish the identity of the agent or agency responsible for its creation. Normally, this will be an agent authorized to share the system's resources.
When a process-level fault occurs, fault information is recorded in the process-control segment. The fault code word is used to record the cause of a fault. The director index is used to record the index into the current segment table directory of the segment table with which a fault is associated. The segment index is used to record the index into that table of the segment descriptor for the segment that caused a fault.
The base rights field of a process control segment access descriptor is interpreted in the same manner as for all objects of base-type data segment. The system-rights field of a process-control segment access descriptor is uninterpreted.
4.3.1.2 Current Service and Buffered Ports
In certain situations, it is essential for hardware to record for later use by both hardware and software, the identity of the last port used for process service. This information is found in the third entry of its process object and is updated each time an access descriptor for the process is sent to a service port. In most cases, the current service port is simply the dispatching port last used to pair the process with a processor. Occasionally, it is a buffered port for a software service process such as resource manager.
For similar reasons, the hardware also records the identity of the last buffered port used to pair the process with a message. This information is found in the fourth entry of its process object and is updated each time the process receives a message via a buffered port or an access descriptor for the process object is enqueued at a buffered port.
4.3.1.3 Fault-Buffered Ports
Whenever a process commits a fault which cannot be handled within the current context, the process is suspended, fault information is recorded in its process-control segment, and the process is sent as a message to a maintenance process for repair or destruction. The port at which such a maintenance process waits to receive broken processes is called a fault-buffered port.
4.3.1.4 Fault-Access Descriptor
Whenever a process-level, nonrestartable, communication instruction fault occurs, the access descriptor for the message which could not be delivered is recorded in the current-process object.
4.3.2 Buffered Communication Ports
Interface-processor processes communicate with other processes by sending and receiving messages, in the form of access descriptors, at system objects called buffered communication ports. These buffered ports are the same in form and function as those described in section 4.7.2 of the above-identified Colley et al patent application.
4.4 PROCESSORS
An interface processor consists of two cooperating processing elements: a mapping facility and function-request facility. The mapping facility translates peripheral subsystem addresses into main processor system addresses. The function-request facility executes the operator set described in section 7. The mapping facility and the function-request facility can run in parallel. The only area of interference is in generating references into the main processor system. In cases of such interference, the mapping facility has priority except where there is an indivisibility requirement over multiple function-Request facility references.
4.4.1 Processor Objects
As with other processors, interface processors use a hardware-recognized data structure called a processor object to contain processor specific state and access information. This object is represented by a segment of base-type access list with the organization shown in FIG. 2B, block 142.
Within interface processor objects, all the access descriptors serve the same purpose and are treated the same way as those for the corresponding entries within processor objects for other types of processors. While serving a similar purpose to processor-control segments for other processor types, interface processor-control segments, 170, differ in some respects and are described below.
The base-rights field of a processor object access descriptor is interpreted in the same manner as for all objects of base-type access list. The system-rights field of a processor object access descriptor is interpreted as follows:
00--an interprocessor message may be broadcast via the global communication segment of this processor object, or it may be sent to this processor via the processor-control segment of this processor object.
01--an interprocessor message may be broadcast via the global communication segment of this processor object.
10--an interprocessor message may be sent to this processor via the processor-control segment of this processor object.
11--no interprocessor messages may be sent to this processor object.
These two types of interprocessor communication are described in the following two subsections.
4.4.1.1 Processor Control Segments
A processor is able to receive information directed to it from other processors by inspecting, when requested, the contents of an area called the local communication area, 172, in its processor-control segment, 170 (FIG. 2B). This segment, which is unique to each processor, is accessed via the first access descriptor in its processor object. In addition to interprocessor communication, the segment is also used to record fault and diagnostic scan information.
In order to interlock the transmission of multiple, simultaneous interprocessor messages, each processor-control segment contains a set of lock bits in its first double byte. The format of this lock field is shown below. ##STR6##
The request locks and the response lock must be clear before transmission begins. At the onset of communication, one of the request locks and the response lock are set. Following the communication, the request lock is cleared, with the response lock left set until the processor carries out the functions requested by the message.
When the port is locked by a processor, the second double byte contains the locking processor's identification value. When the port is locked by a process, the second double byte contains the locking process's identification value.
The base-rights field of a processor control-segment access descriptor is interpreted in the same manner as for all segments of base-type data segment. The system-rights field of a processor-control segment access descriptor is uninterpreted.
4.4.1.1.1 Interprocessor Messages
An interprocessor message takes the form of a word-length, bit field containing a set of processor-control flags. The semantics of these control flags and the processor response under varied conditions is presented in section 5. Interprocessor messages have two components: a general component and a processor-type specific component. The general component is stored in the third double byte of the segment by the sending processor. It has the following organization. ##STR7##
The processor-type specific component is stored in the fourth double byte of the segment by the sending processor. It has the following organization ##STR8##
The processor-count and response-count fields also participate in the message interlock function. At the time a message is sent, the sending processor initializes the response count to the processor count value. When the processor completes the requested function, it decrements the response count and tests the new value for zero. If the decremented value is zero, the processor clears the response lock. Normally, the processor count value in a processor-control segment will be initialized to one.
Another double byte bit field is present in each processor-control segment. This field contains status information about the associated processor. Included in the processor status field, as shown below, are subfields describing the processor state, dispatching state, and type. ##STR9##
The processor unit number is the value loaded into the processor at initialization or reset.
The running/stopped bit is interpreted as follows:
0--running
1--stopped
The queued/dequeued at a buffered port bit is interpreted as follows:
0--not queued at a buffered port
1--queued at a buffered port
The queued/dequeued at a dispatching port bit is interpreted as follows:
0--not queued at a dispatching port
1--queued at a dispatching port
The assigned/deassigned bit is interpreted as follows:
0--assigned to a process
1--not assigned to a process.
The dispatching state subfield is interpreted as follows:
00--using normal dispatching port
01--using alarm dispatching port
10--reserved
11--fatal error.
The meaning of these states is explained in later sections of this section and in section 5.
The broadcast acceptance mode bit is interpreted as follows:
0--broadcast interprocessor messages are being accepted and acknowledged
1--broadcast interprocessor messages are not being accepted or acknowledged.
The processor-type subfield is interpreted in the following manner:
00--generalized data processor
01--interface processor
10--reserved
11--reserved.
All of the subfields in the processor status field are initialized and maintained by the processors themselves.
4.4.1.1.2 Processor Fault Information
When a processor-level fault occurs, fault information is recorded in the processor-control segment (FIG. 2B). The processor fault code word is used to record the cause of the processor-level fault. The process fault code word, the segment table directory index, and the segment table index are used to record the same information that would have been recorded in the process object when that is not possible.
The diagnostic scan area is used to record information requested via the diagnose function of interprocessor communications.
4.4.2 Dispatching Ports
Interface processors serve processes that are ready for execution by receiving them at dispatching ports in much the same manner as processes serve messages that have been sent to them at buffered communication ports. These dispatching ports are similar in form and function as those described in section 4.8.2 of the above-identified Colley et al application. The differences are all related to the fact that deadlines are not employed by interface processors. Interface processes are normally served by interface processors in a "run to completion" fashion. In many cases, only on interface process, dispatched at system initialization time, will be associated with a given interface processor. Thus, the deadline and preemption related information is not used in dispatching ports employed by interface processors.
4.4.2.1 Alarm Dispatching Ports
Upon the detection of hardwired alarm signal, a processor will suspend any process that it may currently be executing and enter the alarm dispatching state. At that point it will begin executing any process it finds queued at the alarm dispatching port specified by the port access descriptor in its processor object. Processes present at this port are intended to be of extreme priority, such as those that might run in the event of an imminent power failure.
Interprocessor messages can be used to request a processor to either enter or exit the alarm dispatching state.
4.4.2.2 Fault-Buffered Ports
Whenever a processor commits a fault which cannot be handled within the current process, the processor is stopped, fault information is recorded in its processor-control segment, and the processor is sent as a message to a maintenance process for repair or destruction. The port at which such a maintenance process waits to receive broken processors is called a fault-buffered port.
Since the processor is stopped and does not dispatch any new process, the current process entry records an access descriptor for the process being served when the fault occurred. This obviates the need for a fault process entry.
4.4.2.3 Fault-Access Descriptors
The fault-access descriptor is to record the access descriptor which would normally be recorded in the like-named entry in the process object for the process which faulted when it is impossible to record it there.
4.5 STORAGE RESOURCES, TRANSFORMERS, AND LABELS
Storage resources, transformers, and/or labels are supported by the same mechanisms and data structures as used by the same mechanisms and data structures as used by other processors.
4.6 PROCESS REGISTERS
To efficiently access the system objects previously described in this section, each processor possesses an extensive set of internal, segment-descriptor registers. These registers are used to buffer segment address and length information obtained from segment descriptors.
The first set of registers, which are referenced directly by the microcode, is shown below: ##STR10##
The second set of registers, which are referenced directly via the mapping facility based upon the current map entry to segment bindings, is shown below: ##STR11##
Since the segment-descriptor registers can only contain segment information that is identical to that found in memory, it is never necessary to save or store their contents. Furthermore, they are only reloaded when conditions demand it for proper and efficient operation. These conditions are described in the following table:
______________________________________ REGISTER LOAD TIME ______________________________________ 0 - segment table dir. initialization; reset 1 - segment table first reference to segment table 2 - processor control seg initialization; reset 3 - processor object initialization; reset 4 - process control seg. process switch 5 - process object process switch 6 - context control seg. process switch 7 - context object process switch 8 - public access list process switch 9 - private access list process switch 10 - entry access list access list entry 11 - segment work reg. - A when needed 12 - segment work reg. - B when needed 13 - segment work reg. - C when needed 14 - segment work reg. - D when needed 0 - data segment A selection of data segment 1 - data segment B selection of data segment 2 - data segment C selection of data segment 3 - data segment D selection of data segment 4 - data segment E selection of data segment 5 - data segment F selection of data segment 6 - data segment G selection of data segment 7 - data segment H selection of data segment ______________________________________
The data segment, segment-descriptor registers are loaded automatically whenever a new data segment is selected to be bound to the corresponding entry in the mapping facility. Once loaded, they are selected directly through the correspondence with that mapping facility entry.
Interface processors also possess a set of registers for maintaining the status of the currently executing process and context, as well as the status of the processor itself. ##STR12##
5.0 INTERFACE-PROCESSOR FACILITIES
Generalized Data Processors (GDP) and Input/Output Processors (IOP) provide a set of nonprimitive, object-based facilities. The interface processor not only provides those basic facilities, but also provides other facilities specific to its specialized function of supporting the interfacing of peripheral subsystem to the main processing system. Descriptions of the basic access environment manipulation and communication facilities available on interface processors can be found in section 5
of the above-identified Colley et al patent application. Discussions of exception handling, debugging, low-level initialization, system initialization and reset, and alarm handling are also found in sections at the end of that section. In this section, the only facilities described are those which are either unique to interface processors or different but logically similar to those employed by other processors. Unless otherwise specified, all those facilities described in the above-identified Colley et al patent application are available on interface processors.
5.1 PERIPHERAL SUBSYSTEM ADDRESS-MAPPING MECHANISMS
The peripheral subsystem address-mapping mechanism makes available, via given address subranges within the peripheral subsystem address space, access to data segments which reside in the main processor address space. When an address within one of these address subranges appears on the peripheral subsystem bus, the interface processor responds as would a memory device or subsystem on the same bus.
From zero to eight such subranges can be mapped at any given time. Subranges are 2**n bytes in length with n being in the range zero to sixteen. That is, subranges of sizes 16 bytes or 32 bytes are supported whereas subranges of sizes 15 bytes or 33 bytes are not supported. Note that a subrange of a given power of two in size (say 16 bytes) must appear on an addressing boundary of the same power of two (i.e., a 16-byte boundary). A subrange of 2**n bytes in length will thus have a starting address containing at least n trailing zeros.
When a peripheral subsystem address is recognized as being mapped by one of the map entries, that address contains some displacement from the starting address of the given subrange. That subrange displacement is used directly as the operand displacement into the corresponding data segment.
In many cases the subrange and the corresponding data segment will be of equal length. If the subrange is longer than the corresponding data segment, the mapping of an address into the part of the subrange for which the corresponding data segment displacement is invalid results in a displacement fault. If the subrange is shorter than the corresponding data segment, then those valid data segment displacements beyond the length of the subrange cannot be generated. This effectively leaves that part of the data segment inaccessible through the map.
In most cases, the rights required for the associated data segment by the transfer direction information in effect for a subrange will be just those base rights which are available for that segment (i.e., only read rights required with both read-and-write rights being available). The two map manipulation operators, discussed below and described in section 7, ensure that this condition holds for any active map entry and associated data segment, segment-descriptor register.
The address subranges recognized by an interface processor can vary over time and under software control. Changes to address subrange mappings will probably occur relatively infrequently. For example, such a change would probably occur at the time a peripheral subsystem is reconfigured. The ALTER MAP operator, available via the function-request mechanism, is used to change address subrange mappings.
The bindings between the address subranges and the corresponding data segments can also vary over time and also under software control. Such binding changes will probably occur more often than changes to address subrange mappings. For example, such a change could be used to select among several input/output buffers. The SELECT DATA SEGMENT operator, available via the function-request mechanism, is used to change segment to subrange bindings. Note that when the mapping information and the data segment selection information associated with a given map entry must both be changed, the mapping information must be changed first. Subsequent selection of another data segment to be associated with that map entry need not alter the mapping information.
5.2 COMPATIBILITY MECHANISMS
The interface processor provides additional operators, beyond those available on the external processor, to allow software running on that processor to deal with the part of its environment provided within the main processor system. For example, the peripheral subsystem address-mapping mechanism only provides access to objects of base-type data segment. Access to and manipulation of objects of base-type access list is supported via the additional operators provided by the interface processor. One can consider the total operator set available to software in the peripheral subsystem to be provided by two processor components: the external processor and the interface processor.
5.2.1 Request Protocol
The interface processor supports requests for the execution of these operators via its function-request facility. This function-request mechanism appears to software in the peripheral subsystem as a memory-mapped peripheral interface consisting of a set of command/data/status registers. It has three states: inactive, with a function-request being loaded, or with a function being executed. When it is inactive, external processor software, an interprocessor communication, or an alarm occurrence can change its state to "request loading initiated" by setting the appropriate bit in the function state field. While in the request loading state, an interprocessor communication or an alarm occurrence can override request loading. If a function loading override occurs and the associated interrupt is enabled, a peripheral subsystem interrupt is generated to inform the associated external processor software. The execution of a function is initiated by setting the appropriate bit in the function state field. Once the function-request facility begins the execution of a function, further function requests from any source are interlocked until that function completes and the associated completion status has been read. The function-request facility then reenters the inactive state.
For reliablity and fault-recovery purposes, the contents of these command/data/status registers are reflected in the current context-control segment, as described in section 4.
There are two types of operators available via the function-request mechanism: environment manipulation operators and communication operators.
5.2.2 Environment Manipulation
Except for the label movement and comparison operators and the object-interlocking operators, the full complement of those environment manipulation operators available on generalized data processors is made available to external processor software by an interface processor.
5.2.3 Communication
Lacking the concept of a sequential instruction stream, interface processors need not provide any support for intra-context control flow. Interface processors, therefore, have no such operators. Interface processors do, however, support process-to-process and processor-to-processor communication as described below.
5.2.3.1 Process-to-Process Communication
There are only two major differences in communication at the process level. The first is the removal of the simple unbounded WAIT TO RECEIVE operator. No facility is lost since basically the same functionality is still available in bounded form via the WAIT TO RECEIVE OR n TIME QUANTA operator. By not providing any operators with unbounded execution times, the interface processor avoids having to provide any forced function termination mechanism or suffer from its potential misuse. The second difference is the removal of the WAIT n TIME QUANTA operator and its replacement by the SIGNAL AFTER n TIME QUANTA operator. In many cases the WAIT TO RECEIVE OR n TIME QUANTA operator will be used in situations where there is a known expected delay period which must elapse before the process can profitably continue execution. For example, this will be true in cases where the next request for service is expected to come from within the main processor system. However, when the next service requirement is expected to come from within the peripheral subsystem, a programmable timer can be quite useful. Such a timer can be used to drive a status sampling peripheral program or to provide an upper bound upon response time. For example, with some very slow speed peripherals using status-driven synchronization, it is known that if the peripheral status is sampled every n milliseconds (i.e., usually something like twice the maximum potential data rate of the peripheral) no data will be lost. With such long periods of inactivity, it makes sense to issue a signal request and make the processor available for other purposes.
5.2.3.2 Processor-to-Processor Communication
The only major difference in communication at the processor level is the addition of the processor-type specific communication facility. This is an extension of the general interprocessor communication facility already specified. It supports functions specific to a processor type. The interprocessor message is extended by a double byte to be 32 bits in length. The second double byte is used for type-specific messages. General messages are used with global interprocessor communication. Combination-general and type-specific messages are used with local interprocessor communication. There are three interface control functions that can be specified in an interprocessor communication segment.
ENQUEUE
The reaction to the ENQUEUE flag by an interface processor in the dequeued state is to enqueue itself as a message at its fault-buffered port. ENQUEUE implies STOP after enqueuing is complete. For an interface processor which is not currently dequeued, no response is required. With interface processors already in the enqueued state, no response is required.
TERMINATE TRANSFER 0
The reaction to the TERMINATE TRANSFER 0 flag by a processor on which map entry 0 is in block transfer mode with a transfer in progress is to terminate that transfer, flush the internal transfer buffer (if not empty), and change the associated block transfer state to "transfer termination forced." For an interface processor with no block transfer in progress via map entry 0, no response is required.
TERMINATE TRANSFER 1
The reaction to the TERMINATE TRANSFER 1 flag by an interface processor on which map entry 1 is in block transfer mode with a transfer-in-progress is to terminate that transfer, flush the internal transfer buffer (if not empty), and change the associated block transfer state to "transfer termination forced." For an interface processor with no block transfer in progress via map entry 1, no response is required.
Note that ENTER DIAGNOSTIC STATE function requests in general messages are ignored by interface processors.
As with all requested functions performed by interface processors, upon completion of an interprocessor communication response phase, if enabled, a function complete interrupt is generated after appropriate processor-resident status information has been updated.
5.2.4 A Typical Transfer Cycle
The following simple example describes a typical transfer cycle in terms of both control flow and data flow within both the main processor system and an associated peripheral subsystem.
A typical transfer cycle begins by a process, executing on a generalized data processor, coming to the point where it needs some data transferred from an input device to main memory or from main memory to an output device. At such a point, it sends a service-request message via an agreed-upon buffered port to a process resident on the external processor that can perform the needed transfer.
In this example, let us assume that the external processor software is divided into two parts. The first part, using the compatibility mechanisms available via the function-request facility of the associated interface processor, monitors and controls that processor. The second part provides one or more peripheral drivers (each with potentially no knowledge of the presence of the associated interface processor). When a peripheral driver is not actively engaged in performing a data transfer, control within the peripheral subsystem software resides in the interface processor monitoring software. When this monitoring software decides that the peripheral subsystem needs further work to do, it attempts to receive a service-request message from software in the main processor system. It does this by requesting that the interface processor execute one of its message reception operators (i.e., CONDITIONAL RECEIVE).
The monitoring software detects the completion of the requested function either via interrupt or status driven methods. When a service-request message is received, the monitoring software must first decide which of several potential peripheral drivers should be initiated. After performing any necessary map entry setup and/or main processor environment manipulation via interface processor functions, the monitoring software transfers control to the appropriate peripheral driver and passes any required parameters.
That peripheral driver then performs the requested data transfer in accordance with the transmitted parameters. Upon completion of the transfer, the peripheral driver returns control to the monitoring software passing back the appropriate status information.
The monitoring software then formulates a return message for the requesting GDP process. Using one of the message-transmittal operators provided by the interface processor (i.e., CONDITIONAL SEND), the monitoring software sends the return message via an agreed-upon buffered port to the requesting process. Having completed one transfer cycle, the monitoring software then finds itself in the same position that it was in at the beginning of this example: attempting to receive another service-request message and enter a new cycle.
5.3 EXCEPTION HANDLING
Various conditions may arise during normal processing which require exceptional software treatment. Considered broadly, these may either be events of which software must be made aware but which do not preclude continued processing or they may be events which require immediate software attention. The former class of events are handled via the notification mechanism; the latter via one of the fault mechanisms.
The fault mechanisms can be further subdivided into three levels. When a condition arises which prohibits normal processing to continue, either a context-level, process-level, or processor-level fault occurs. The level of the fault indicates the processing object which can no longer proceed normally. A context-level fault indicates that normal processing within the current context must be suspended, but that the situation can be handled within the process. A process-level fault indicates that normal processing of the entire current process must be suspended. A processor-level fault indicates that the normal processing of processes by the processor must be stopped and a special process executed. Each class of faults is dealt with at a level appropriate to its severity. If none of these fault levels can properly deal with the problem, then the processor will perform a consistency halt.
5.3.1 Notification
A notification is treated as an implicit SEND of an access descriptor to a process-designated port. Whenever the access descriptor count associated with an object would go to zero as the result of some normal processor activity, a notification occurs. Rather than destroying the descriptor and reducing the count, it is sent to the port designated as the notification port in the process object. If this SEND cannot complete successfully, a process-level fault occurs as described below under communication instruction faults.
5.3.2 Fault Mechanism Data Structures
There are fault recording areas associated with each level at which faults may occur. For each context, the context-control segment contains an 8-byte long data area for context-level fault information. For each process, the process control segment contains an 8-byte long data area for process-level fault information. It also has a reserved access descriptor entry for recording a fault-access descriptor if necessary. For each processor, the processor-control segment contains a
12-byte-long data area for processor-level fault information. It also has two reserved access-descriptor entries.
Each of the fault information areas has a fixed format which defines fields for any information which may ever be stored by a fault at that level. Which fields actually contain valid information after a fault is defined in the discussions of the various faults.
5.3.3 Context-Level Faults
Context-level faults require interruption of normal processing within the running context. When such a fault occurs, information identifying its cause is recorded in the context-control segment and, if enabled, a fault interrupt is generated to the associated peripheral subsystem. The state of the context is also set to faulted which causes special treatment of further context-level faults (see below). As described in section 4, the fields defined in the context fault information area are:
1. the context fault code;
2. the fault-segment selector; and
3. the fault displacement.
For any context-level fault, the first of these fields is always valid.
5.3.3.1 Object-Access Faults
All uses of access descriptors to actually make use of an object require some checking of the type of the object; in addition, it may be necessary to check the rights associated with the descriptor. If these checks do not result in a decision to permit the instruction to proceed, then an object-type fault or object-rights fault is generated. The one additional valid field is:
1. the fault-segment selector.
5.3.3.2 Displacement Faults
References to a segment must be within the extent of that segment as defined by the segment length. If a reference specifies an offset greater than the length, a displacement fault occurs. Additional valid fields are:
1. the fault-segment selector; and
2. the fault displacement.
5.3.3.3 Descriptor-Control Faults
Operations upon access descriptors directly (as opposed to operations upon the objects they reference) may require the checking of the associated descriptor control flags. If this check does not result in a decision to permit the instruction to proceed, then either a descriptor control fault or an indirect descriptor control fault is generated. The one additonal valid field is:
1. the fault-segment selector.
5.3.3.4 Interlock Failure Faults
When an attempt is made to execute an operator that requires exclusive access to a system object, the process must lock the object. If this cannot be accomplished, a fault will be generated. The one additional valid field is:
1. the fault-segment selector.
5.3.4 Process-Level Faults
Process-level faults require the suspension of the concerned process and repair by a fault-handling process. When such a fault occurs, the processor is preempted from the currently running process and information about the fault is recorded in the process object fault areas. The preempted process object is sent as a message to the fault service port identified in its process object. The processor then attempts dispatching at its current dispatching port. The limited number of process-level faults which can occur are described below.
As described in section 4, the fields defined in the process fault areas are:
1. the process fault code;
2. the directory index;
3. the segment index; and
4. the fault-access descriptor.
For any process-level fault, the first of these fields is always valid.
5.3.4.1 Reference Validity Faults
When an attempt is made to reference the contents of any segment, the valid flags of its segment descriptor and of the segment descriptor for the segment table containing its segment descriptor are inspected. If the latter of these is invalid, a segment table-directory fault occurs; if the former is invalid, a segment table-fault occurs with one exception noted below. Additional valid fields are:
1. the directory index; and
2. the segment index.
5.3.4.2 Context-Fault-Failure Faults
While a context fault is being handled (i.e., the context-fault state is faulted), the occurrence of an addi