The Micro-Architecture of a Capability-Based Computer

The Micro-Architecture of a Capability-Based Computer

The Micro-Architecture of a Capability-Based Computer D.A. Abramson* - J. Rosenberg** * Department of Computer Science, Monash University, Clayton, Victoria 3168, Australia ** Department of Computer Science, University of Newcastle, N.S.W. 2308, Australia systems into information-hiding modules. Each software ABSTRACT module, according to the information-hiding principle, This paper describes the micro-architecture of a hides major design and implementation decisions from microprogrammed workstation called MONADS-PC. The other modules, so that changes to a specific module have system has been specifically designed to support a very minimal impact on the rest of the system. This implies large uniform virtual memory, capability-based addressing that alterations to data structures, to algorithms and even and information hiding software modules with procedural to lower-level abstract or real machines can be hidden interfaces. The paper gives a brief introduction to these from the users of a module (unless these involve changes topics followed by implementation details of the system. to the module’s specification). A good way of achieving this is to insist that all inter-module interfaces are purely procedural and that the private database of a module be 1. INTRODUCTION accessible only to the procedures of that module. The MONADS project was established in 1976 at The MONADS system rigorously enforces the Monash University, with the main aim of investigating information-hiding principle by not supporting fEe- improved techniques for designing and developing large standing data-structures (including files [6]) and by for- software systems. The MONADS-PC computer system bidding the exportation of variables from modules [7]. [l] was developed during 1984 as a workstation to sup- Thus all conventional program units and files are imple- port software engineering research. The 32 bit micropro- mented as information hiding modules and all data is grammed processor provides hardware support for the accessed via a procedural interface [8]. decomposition of complex software systems into information-hiding modules [2]. In the MONADS-PC system the code and data of a module are tightly coupled. On entry to a module the The MONADS architecture is highly structured and data and code of the module become addressable, and the places significant demands on the underlying hardware in previous environment is no longer accessible. Moreover it order to achieve an efficient implementation. This paper must be impossible for the code to arbitrarily change the discusses the implications of the architecture on the micro addressing environment. Thus, the procedure CALL machine and describes some of the more novel imple- instruction must set up the appropriate addressing mentation issues in the MONADS-PC computer. A full environment for the called module and the RETURN technical description of the MONADS-PC micro machine must reinstate the former environment. Because the may be found in [3]. CALL and RJXLJRN instructions are the key to the 2. THE MONADS ARCHITECTURE MONADS protection system a hardware (and firmware) supported implementation is essential. There are three central principles in the MONADS philosophy which affect the hardware, and thus are of concern to this paper. The first of these is the support for the decomposition of programs into information hiding 2.2. Uniform Virtual Memory modules, the second is the provision of a uniform virtual Most modem computers support a virtual memory. memory, and the third is the use of capability based In a virtual memory system the addressing range avail- addressing. able to programs is larger thti the size of physical memory on the machine and program addresses are 2.1. Module Structure mapped onto physical addresses by the hardware. Sec- It has long been recognized that one of the keys to tions of code or data which are not currently in physical successful software engineering is to limit the scope of memory are held in a special area on disk. Thus the access to data [4]. Parnas 121 and others 151 have sug- apparent memory space of the machine is extended by gested that this can be achieved by decomposing software using some of the disk. 138 CH2350-7/86/0000/0138$01 .OO0 1986 IEEE In the MONADS architecture the virtual memory suite of system management instructions which manipu- structure is extended to the limit. All of the disk is con- late virtual addresses in a well controlled manner. sidered to be part of the virtual memory of the machine. Thus there is no conventional filestore and files simply 3. ADDRESSING STRUCTURE reside in the virtual memory like computational data. This In the MONADS-PC system virtual addresses are 60 approach, which was fist used on the MULTICS system bits in size. This very large virtual address space is [23] and has since been adopted on at least one commer- divided into regions called address spaces. Thus a virtual cial machine [9], has the major advantage that it avoids address consists of two parts, an address space number duplication of mechanisms, Two obvious examples of and an offset (Figure 1). Each address space contains such duplication are the dual protection mechanisms data which is related in some way (e.g. the procedures of which have to be supported (one to protect running pro- a module, segments of a file). The offset identifies a par- grams from each other and the other to guarantee privacy ticular byte within the address space. of files) and the dual synchronisation mechanisms (for Address spaces are divided into many segments. example semaphores in the computational memory and Behind the segmentation scheme is a paged virtual record locks in the filestore). In both cases the same fun- memory. However, there is no direct relationship damental problem is being solved and in both cases the between segments and pages and segments may arbi- filestore mechanism is clumsier and less efficient because trarily overlap page boundaries. The details of this of the lack of hardware support. scheme are described elsewhere [12]. Each segment is There are other areas of duplication (e.g. data described by a capability which fully defines a contiguous accessing techniques) and these are discussed in [lo]. For region of virtual memory (Figure 2). all of these reasons the MONADS architecture supports a Tbe virtual address (address space number and very large uniform virtual memory. A consequence of this offset) within the capability defines the start of the seg- is that addresses must also be quite large (large enough to ment and the limit defines the end. (Note that segments address all of the disks that may be connected to the can not span more than one address space and thus the machine). limit need only be 28 bits.) Executing programs can only access segments for which they have a capability. For 2.3. Capability-Based addressing efficiency reasons capabilities are never used directly, The idea of capability-based addressing was first rather their contents are loaded into capability registers proposed by Dennis and Van Horn [ll] and can be sum- before use. The capability registers are loaded by a spe- marised as follows. Every object in the system is given a cial instruction, load-capability-register, which takes the unique, non-forgeable name. These names are never re- contents of the capability list entry and places it in the used, even when the object has been deleted. A Capabil- named register. Thus instructions need only name a ity consists of a name and a set of access rights to the capability register in order to refer to a segment of data. object identified. Capabilities are protected and cannot Access to individual bytes requires the specification of an be modified or directly generated by programs, rather additional offset within the segment. they are created and transferred under system control. A particular object can only be accessed if a procedure has 4. INSTRUCTION SET a capability for the object and can only be addressed in MONADS-PC is 32 bit machine. It supports only accordance with the access rights contained within that three basic data types, 32 bit integers, 32 bit floating- capability. Thus a fine grain of protection and control point numbers and 8 bit characters. over access to data can be achieved. There is a single accumulator which is an implicit The MONADS architecture exploits this property of operand on most arithmetic and logical operations. The capabilities in order to implement information-hiding accumulator (A) is a 32 bit register. There is also an modules. Virtual addresses in the MONADS system are accumulator extend register (AX) which is used for dou- embedded in capabilities and thus can never be reused. ble length divide and multiply operations. There are Consequently addresses must be even larger than required three index registers (H-13) and sixteen capability regis- by a uniform virtual memory. An essential feature of ters (CO-ClS) of the format described earlier. In addition capabilities is that they cannot be forged, and thus a user there are two dedicated capability/index register combina- program must be prevented from directly constructing or tions, one for accessing the computational (push/pop) area modifying a virtual address. MONADS-PC provides a of the stack and one for fetching words of code from the Address Space Number Offset within Address Space (32 bits) (28 bits) Figure 1 Virtual Address Format 139 Pages of Virtual Memory Page boundaries - I Figure 2 - MONADS Addressing Structure instruction stream. Finally there is processor status word The Cn field determines which capabiIity register to use, (PSW) which contains condition codes indicating the and the In field determines which index register to use. result of the last instruction. The OfSset field is used for a fixed offset relative to a capability register in data mode, or the literal in 16 bit MONADS-PC has three basic addressing modes, literal mode.

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    8 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us