An architecture optimized for strategic computing was built. The architecture employs a comprehensive VLSI approach, with new hardware and a new operating system. By starting from scratch it was possible to make tradeoffs at all levels (VLSI, hardware systems, and software systems) to provide optimal solutions to meet the challenges of strategic computing. In addition to a high-performance microprocessor based on reduced-instruction-set-computer (RISC) principles, a VLSI component was built for each functional block of a computer system to construct a balanced computer architecture. Instead of implementing fault tolerance with additional hardware, the requisite fault-tolerant features were built directly into these same VLSI components.<>

The BiiN operating system executive, an extensible multiuser, multitasking, object-based operating system that provides symmetric multiprocessing, distributed computing, transaction processing, and support for real-time programs, is discussed. Key system functions are embedded in VLSI to increase performance, reliability, availability and security. The operating system extends the hardware object support by providing a persistent object store. The complex data structures programmers create to describe entities like compound documents and engineering drawings can be stored as a collection of interconnected objects. The relationship between these objects is embodied in the pointers from one object to another. The operating system can store this collection of objects, as well as the pointers between objects, in the BiiN object store. The operating system provides the requisite synchronization and data integrity primitives to allow different programs to access the same objects simultaneously.<>

article Free AccessInterprocess communication and processor dispatching on the Intel 432 Authors: George W. Cox Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, ORView Profile , William M. Corwin Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, ORView Profile , Konrad K. Lai Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, ORView Profile , Fred J. Pollack Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, ORView Profile Authors Info & Claims ACM Transactions on Computer SystemsVolume 1Issue 1Feb. 1983 pp 45–66https://doi.org/10.1145/357353.357358Published:01 February 1983Publication History 15citation847DownloadsMetricsTotal Citations15Total Downloads847Last 12 Months34Last 6 weeks3 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

In this paper, we describe how the memory management mechanisms of the Intel iAPX-432 are used to implement the visibility rules of Ada. At any point in the execution of an Ada® program on the 432, the program has a protected address space that corresponds exactly to the program's accessibility at the corresponding point in the program's source. This close match of architecture and language did not occur because the 432 was designed to execute Ada—it was not. Rather, both Ada and the 432 are the result of very similar design goals. To illustrate this point, we compare, in their support for Ada, the memory management mechanisms of the 432 to those of traditional computers. The most notable differences occur in heap-space management and multitasking. With respect to the former, we describe a degree of hardware/software cooperation that is not typical of other systems. In the latter area, we show how Ada's view of sharing is the same as the 432, but differs totally from the sharing permitted by traditional systems. A description of these differences provide some insight into the problems of implementing an Ada compiler for a traditional architecture.

This paper describes interprocess communication and process dispatching on the Intel 432. The primary assets of the facility are its generality and its usefulness in a wide range of applications. The conceptual model, supporting mechanisms, available interfaces, current implementations, and absolute and comparative performance are described. The Intel 432 is an object-based multiprocessor. There are two processor types: General Data Processors (GDPs) and Interface Processors (IPs). These processors provide several operating system functions in hardware by defining and using a number of processor-recognized objects and high-level instructions. In particular, they use several types of processor-recognized objects to provide a unified structure for both interprocess communication and process dispatching. One of the prime motivations for providing this level of hardware support is to improve efficiency of these facilities over similar facilities implemented in software. With greater efficiency, they become more practically useful [Stonebraker 81]. The unification allows these traditionally separate facilities to be described by a single conceptual model and implemented by a single set of mechanisms. The 432 model is based on using objects to play roles. The roles are those of requests and servers. In general, a request is a petition for some service and a server is an agent that performs the requested service. Various types of objects are used to represent role-players. The role played by an object may change over time. The type and state of an object determines what role it is playing at any given instant. For any particular class of request, based upon type and state, there is typically a corresponding class of expected server. The request/server model may be applied to a number of common communication situations. In the full paper, several situations are discussed: one-way requestor to server, two-way requestor to server to requestor, nondistinguished requestors, resource source selectivity, nondistinguished servers, and mutual exclusion. While the model embodies most of the essential aspects of the 432's interprocess communication and process dispatching facilities, it leaves a great many practical questions unanswered. The full paper describes our solutions to those problems which often stand between an apparently good model and a successful implementation, namely: binding, queue structure, queuing disciplines, blocking, vectoring, dispatching mixes, and hardware/software cooperation. With an understanding of the mechanisms employed, the paper then reviews the instruction interface to and potential uses of the port mechanism. This instruction interface is provided by seven instructions: SEND, RECEIVE, CONDITIONAL SEND, CONDITIONAL RECEIVE, SURROGATE SEND, SURROGATE RECEIVE, and DELAY. The implementations of the port mechanism are then discussed. The port mechanism is implemented in microcode on both the GDP and IP. Although the microarchitectures differ, in both cases the implementation requires between 600 and 800 lines of vertically encoded 16-bit microinstructions. The corresponding execution times are roughly comparable, with the IP about 20% slower even though most of its microinstructions are twice as slow. Both implementations resulted from the hand translation of the Ada-based algorithms that describe these operations. Finally, the paper characterizes the performance of the 432 port mechanisms and contrasts its performance to other implementations of similar mechanisms. Three recently implemented mechanisms were chosen: one implemented completely in software (i.e., the Exchange mechanism of RMX/86 [Intel 80]) and two implemented in a combination of hardware and software (i.e., the Star0S and Medusa mechanisms of Cm* [Jones 80]). To make the comparison as fair as possible, times for each system are normalized to account for differences in their underlying hardware. The normalization factor is called a “tick” (similar to [Lampson 80]). In the full paper, the absolute and normalized performance of these implementations is examined in six different cases: conditional send time, conditional receive time, minumum message transit time, send plus minimum dispatching latency time, non-blocking send time, and blocking receive time. These performance comparisons show a 3 to 7x normalized performance advantage over the software implemented RMX/86. They show similar normalized performance to the Cm* implementations.

iMAX is the operating system for Intel's iAPX-432 computer system. The iAPX-432 1 is an object-oriented multiprocessor architecture that supports capability-based addressing. The object filing system is that part of iMAX that implements a permanent reliable object store. In this paper we describe the key elements of the iMAX object filing system design. We first contrast the concept of an object filing system with that of a conventional file system. We then describe the iMAX design paying particular attention to five problems that other object filing designs have either solved inadequately or failed to address. Finally, we discuss an effect of object filing on the programming semantics of Ada.

The Intel iAPX 432 is an object-based microcomputer which, together with its operating system iMAX, provides a multiprocessor computer system designed around the ideas of data abstraction. iMAX is implemented in Ada and provides, through its interface and facilities, an Ada view of the 432 system. Of paramount concern in this system is the uniformity of approach among the architecture, the operating system, and the language. Some interesting aspects of both the external and internal views of iMAX are discussed to illustrate this uniform approach.

The extent to which resource allocation policies are entrusted to user-level software determines in large part the degree of flexibility present in an operating system. In Hydra the determination to separate mechanism and policy is established as a basic design principle and is implemented by the construction of a kernel composed (almost) entirely of mechanisms. This paper presents three such mechanisms (scheduling, paging, protection) and examines how external policies which manipulate them may be constructed. It is shown that the policy decisions which remain embedded in the kernel exist for the sole purpose of arbitrating conflicting requests for physical resources, and then only to the extent of guaranteeing fairness.

This paper describes the design philosophy of HYDRA—the kernel of an operating system for C.mmp, the Carnegie-Mellon Multi-Mini-Processor. This philosophy is realized through the introduction of a generalized notion of “resource,” both physical and virtual, called an “object.” Mechanisms are presented for dealing with objects, including the creation of new types, specification of new operations applicable to a given type, sharing, and protection of any reference to a given object against improper application of any of the operations defined with respect to that type of object. The mechanisms provide a coherent basis for extension of the system in two directions: the introduction of new facilities, and the creation of highly secure systems.