GB2239334A - Communication between execution environments in a data processing system employing an object-oriented memory protection mechanism - Google Patents

Communication between execution environments in a data processing system employing an object-oriented memory protection mechanism Download PDF

Info

Publication number
GB2239334A
GB2239334A GB9019821A GB9019821A GB2239334A GB 2239334 A GB2239334 A GB 2239334A GB 9019821 A GB9019821 A GB 9019821A GB 9019821 A GB9019821 A GB 9019821A GB 2239334 A GB2239334 A GB 2239334A
Authority
GB
United Kingdom
Prior art keywords
subsystem
stack
procedure
environment
call
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
GB9019821A
Other versions
GB9019821D0 (en
GB2239334B (en
Inventor
Konrad K Lai
Frederick J Pollack
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of GB9019821D0 publication Critical patent/GB9019821D0/en
Publication of GB2239334A publication Critical patent/GB2239334A/en
Application granted granted Critical
Publication of GB2239334B publication Critical patent/GB2239334B/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/468Specific access rights for resources, e.g. using capability register
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/448Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4482Procedural
    • G06F9/4484Executing subprograms

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Devices For Executing Special Programs (AREA)
  • Executing Machine-Instructions (AREA)

Abstract

An environment table object, associated with a process object, includes a control stack to save the state of a calling execution environment to be restored on a return from the called execution environment. A caller's domain object 100 includes access descriptors that reference objects which define regions 0 and 1 of the called execution environment, and a subsystem ID that points to an entry in the environment table. An entry in this table specifies the object that defines region 2 of the called execution environment, and the frame pointer of the topmost stack frame in the called environment. The caller's domain object 100 also includes a supervisor Stack Pointer that is a linear address for the supervisor stack used when invoking a supervisor call in the user mode (instead of the stack pointer in the current frame) to locate the new frame. The domain object 100 further includes Procedure Entries that specify the type and address of the called procedure. Each of the procedure entries includes a Procedure Entry Type field that indicates the type of procedure to be invoked, either a supervisor procedure or a subsystem procedure, and an offset into the called execution environment to specify the first instruction of the called procedure. <IMAGE>

Description

SYNCHRONOUS COMMUNICATION BETWEEN EXECUTION ENVIRONMENTS IN A DATA
PROCESSING SYSTEM EMPLOYING AN OBJECT-ORIENTED MEMORY PROTECTION MECHANISM
CROSS REFERENCE TO RELATED APPLICATIONS
Application SN - 455,625 -- (D-1256) f lled 22.12.1989 en- titled 0Method and Apparatus for Dis.Lbling Tag Bit Recogni tion and Allowing Privileged operations to occur in an Ob ject-oriented Memory Protection Mechanism", assigned to In tel Corporation, the assignee of the present invention.
Application SN - 455y635 _ (D-1259) filed 22.12.1989 en- titled "Type Management and Control in an Object-Oriented Memory Protection Nechaniszan, assigned to Intel Corporation, the assignee of the present invention.
Application SN - 455585 - (D-1288) filed 22.12.1989 - en titled "Object Lifetime control in an object-Oriented Memory Protection MechanismU, assigned to Intel Corporation, the assignee of the present invention.
BACKGROUND OF THE INVENTION
Field of the Invention
The invention relates to data processing systems, and more particularly to a subsytem call mechanism for use in a memory-accessing system which protects memory locations from unauthorized access.
Description of the Related Art
Modern computer systems are organized such that all informa tion within the system is represented by hardware-recognized, memory-resident information structures called ob- jects. This is known as an object-oriented computer architecture. An object is a package of data that is a representation of related information maintained in a logically-contiguous addressed set of memory locations.
is In an object-oriented programming system, each type or class of object has a set of operations that are permitted to be performed on the objects that are members of the class. This is known as an object-based access mechanism. The internal structure of objects is hidden from the programmer. The programmer can manipulate the objects only with the permitted operations. Access to an object is by means of a pointer to the object called an access descriptor. An access descriptor describes the kind of representation (rep) rights (such as read rights or write rights) which define the various kinds of access to the object that are permitted by the holder of the access descriptor for that object.
In the system described in the above-reference application SH 455,625 (D-1256) programming complexity is reduced in an object-oriented computer system by tagging words stored in memory so that the protection mechanism can distinquish between ordinary data and protected access descriptors.
This type of protection is called a capability-based protec tion mechanism as distinguised from the older state-based protection mechanism. A state-based protection mechanism relies on a supervisor program state and a user state with privileged Instructions performable only in the supervisor state. In order to provide for compatiblity with the older untagged operating system and the new tagged operating sys tem, it is desirable to be able to nap supervisor calls of an untagged operating system to a tagged operating system.
It is therefore an object of the present invention to provide a call/return mechanism that can function with both a capability-based protection mechanism and a state-based protection mechanism.
SUMMARY OF THE INVENTION
Briefly. the above objects are accomplished in accordance with the Invention by providing a first processor object and a first process object defining a first execution environiment associated with a first domain object, and a second ex- ecution environment associated with a second domain object.
A first environment table object is associated with the first process. The first environment table object includes a control stack for containing subsystem linkage informa the control stack being an array of control stack en- is tries which entries save the state of the first calling execution environment to be restored on a return from the second execution environment.
The first domain object includes a Region 0 access descrip- tor that references an object which defines region 0 of the second (target) execution environment which is the target of a subsystem call, a Region 1 AD that references the object which defines region 1 of the second (target) execution environment which is the target of a subsystem call, and a subsystem ID that points to an entry in a subsystem table in the first environment table associated within the first process object. A subsystem entry in the subsystem table specifies the object that defines region 2 of the target execution environment, the frame pointer and the stack pointer of the topmost stack frame in the target environment. A supervisor Stack Pointer is provided that is a linear address (in words) for the supervisor stack used when invoking a supervisor call in the user mode (instead of the stack pointer in the current frame) to locate the new frame.
The first domain object further includes Procedure Entries that specify the type and address of the target procedure.
Each of the procedure entries includes a Procedure Entry Type field that indicates the type of procedure to be in s voked including, but not limited to, a supervisor procedure and a subsystem procedure, and an offset into the target ex ecution environment. The offset specifies the first in struction of the target procedure.
in accordance with an aspect of the invention, the Environment Table Object contains two data structures, a subsystem table and a control stack. The subsystem table locates all the region 2 stack objects and their corresponding topmost frame and stack pointers associated with a process.
is in accordance with a further aspect of the invention, a cur rent Subsystem ID is saved in the second process object to gether with the current subsystem table offset for the cur rent subsystem entry in the subsystem table associated with the first process and the linear address of the topmost frame and stack pointer is saved in the subsystem entry upon the condition that a subsystem is exited on a call to an other subsystem.
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:
FIGURE 1 is a block diagram of processor registers and system objects in which the invention is embodied; is FIGURE 2 is a more detailed block diagram of the linear addresss space structure of the execution environment of FIGURE 1; FIGURE 3 is a more detailed block diagram of a domain object of FIGURE 1; FIGURE 4 is a more detailed block diayram of a procedure entry in the domain object of FIGURE 2; FIGURE 5 is a more detailed block diagram of the environment table object Of FIGURE 1; FIGURE 6 is a more detailed block diagram of a subsystem entry of the environment table object of FIGURE 5; FIGURE 7 is a more detailed block diagram of the control stack entry of the environment table object of FIGURE S; FIGUREs 8 and 9 comprise a flow chart of the call system in struction; FIGURE 10 flow chart of the inter-subsystem call subroutine of the call system instruction of figures 8 and 9; and FIGURE 11 flow chart of the intra-subsystem call subroutine of the call system instruction of figures 8 and 9.
Description of the Preferred Embodiment
An object-oriented architecture is a computer system organized such that all information within the system is represented by hardware-recognized, memory-resident information structures called objects. An object is a package of data that is a representation of related information maintained in a contiguously-addressed set of memory locations.
in an object-oriented programming system, each type or class of object has a set of operations that are permitted to be performed on the objects that are members of the class. This is called an object-based access mechanism. The internal structure of the object is hidden from the programmer. The programmer can manipulate the objects only with the permitted operations. Access to an object is by means of an access descriptor that is a pointer to the object. An ac- cess descriptor describes the kind of rights (such as read rights or write rights) which define the various kinds of access to the object that are permitted by the holder of the access descriptor for that object.
is When describing a process, an operator is that which indicates the action to be taken on operands. An operand is usually identified by an address part of an instruction. Every instruction specifies an operator and several references. The operator specifies to the processor what hard- ware operation is to be performed, and the references select the operands to be used or manipulated. The operator specified in an instruction is encoded in two fields, the class field and the OP-code field. The class field specifies the operator class to which the operator belongs, and the OPcode field selects the hardware operation to be performed from within that class.
Execution Environment A process sees a flat linear address space out of which it allocates data. instruction. and stack space. A call instruction creates a new stack frame (activation record) on a sequentially allocated stack. More information on the stack frames can be found in US patent 4,811.208 entitled "Stack Frame Cache on a Microprocessor Chip" of Myers. et al.
An execution environment consists of the following objects:
a linear address space, a set of global and floating-point registers, an instruction pointer, and an arithmetic control register.
The global registers are unaffected when crossing procedure boundaries. One of the registers contains the current frame pointer (FP) and the remander are general-purpose registers.
The FP contains the linear address (pointer) into the current execution environment for the current (topmost) stack frame. The global registers associated with a process are saved in the process control block when the process is not The floating-point registers associated with a process are saved in the process control block when the process is not executing.
An execution environment corresponds to a process-wide address space in other systems. The system supports multiple execution environments per process, but only one execution environment can be active at a time for each process..
The Arithmetic Controls are used to control the arithmetic and faulting properties of the numeric instructions as well as for storing the condition codes. When a process is suspended, the arithmetic controls information is saved in the process control block. When a call operation Is performed to a new frame, the return IP is saved in the stack frame in the current linear address sapce.
Instruction Pointer The Instruction Pointer (IP) is a linear address (pointer) into the current linear address space to the first byte of the current instruction.
The register model consists of the 16 global registers and 4 floating point registers that are preserved across procedure boundariesi and multiple sets of 16 local (or frame) regis- ters. The register model is described in more detail in the above- referenced patent application SN 935f193.
At any instant, an instruction can address 36 of the regisas follows.
is Register Type Register Name Global Register Floating Point Register (floating point operand) Local Register GO.. G15 FPO.. FP3 LO.. L15 Global Registers There are 16 global registers associated with a process; they are saved in the process control block when the process is not executing.
Of the 16 32-bit registers, G15 contains the current frame pointer (PP) and GO..G14 are general-purpose registers. The FP contains the linear address of the current (topmost) stack frame. Since stack frames are aligned to SALIGN16 byte boundaries (SALIGN is an value depending upon a particular implementation), the low-order N bits of FP are ignored and always interpreted to be zero (N is given by SALIGN16 = 2N). This register is initialized on calls and restored on returns.
h t A reference to a register as an operand that is bigger than 32 bits uses the registers with consecutive higher register numbers.
Floating Point Registers is There are 4 floating point registers associated with a process; they are saved in the process control block when the process is not executing.
Floating point registers are accessed only as operands of floating point instructions.
Local (or Frame) Registers Registers LO..L15, the local registers, do not denote registers of the conventional variety; they are allocated upon procedure calls and deallocated upon returns.
Multiple banks of local registers are provided, one bank per procedure activation, where the program does not have to save and restore registers explicitly.
When these registers need to be saved in memory, they are saved In the first 16 words of the stack frame of the associated procedure. They represent first 16 words of the stack frame, where register LO is mapped into linear address FP+0 to PP+3. register Li is mapped into linear address FP+41 to FP+41+3, and so on.
Since instructions must begin on word (4-byte) boundaries, the two loworder bits of IP are always 0.
-g- Arithmetic Controls The Arithmetic Controls (AC) are used to control the arithmetic and faulting properties of the numeric instructions as well as for storing the condition codes. When a process is suspended, the arithmetic controls are saved in the process control block.
Arithmetic Controls (AC) contain the following information:
condition code (bits 0-2). A set of flags set by comparison (and other) instructions and examined by conditional-branch (and other) instructions.
Arithmetic Status (bits 3-6). This field is altered as an indicator by certain floating-point instructions.
Integer Overflow Flag (bit 8). Sticky flag set whenever an integer overflow occurs and the mask Is set. The flag is never implicitly cleared.
integer Overflow Mask (bit 12). If set, an integer overflow does not generate an ARITHMETIC fault. If S is the destination size. the S leastsignificant bits of the result are stored in the destination unless otherwise noted.
No imprecise faults (bit 15). If NIF is set, faults are required to be precise. If NIF Is clear, certain faults can be imprecise.
Floating-point Overflow Flag (bit 16). Sticky flag set whenever a floating-point overflow occurs and the mask is set. The flag is never implicitly cleared.
Floating-point Underflow Flag (bit 17). Sticky flag set whenever a floating-point underflow occurs and the mask is set. The flag Is never implicitly cleared.
Floating-point Invalid-op Flag (bit 18). Sticky flag set whenever a floating-point invalid operation occurs and the mask is set. The flag is never implicitly cleared.
Floating-point Zero-divide Flag (bit 19). Sticky flag set whenever a floating-point division by zero occurs and the mask is set. The flag is never implicitly cleared.
Floating-point Inexact Flag (bit 20). Sticky flag set when ever a floating-point inexact result occurs and the mask is is set. The flag is never implicitly cleared.
Floating-point Overflow Mask (bit 24). If set, a floatingpoint overflow does not generate a REAL-ARITHMETIC fault.
Floatingpoint Underflow Mask (bit 25). If set, a floatingpoint underflow does not generate a REAL-ARITHMETIC fault.
Floating-point Invalid-op Mask (bit 26). If set, a floating point invalid operation does not generate a REAL-ARITHMETIC fault.
Floating-point Zero-divide Mask (bit 27). If set, a floating-point division by zero does not generate a REAL-ARITHMETIC fault.
j.
Floating-point Inexact Mask (bit 28). If set, a floatingpoint inexact result does not generate a REAL ARITHMETIC fault.
Floating-point Normalizing Mode (bit 29). If set, denormalized numbers in reals, long reals or extended reals are t first normalized before arithmetic is performed. If clear, denormalized numbers generate a REAL-ARITHMETIC fault.
Floating-point Rounding Control (bits 31-30). This field indicates which rounding mode is in effect for floating point computation: 00 - round to nearest (even) 01 - round down (toward negative infinity) 10 - round up (toward positive infinity) 11 - truncate (round toward zero)
Stack Frame The stack frame is a contiguous portion of current linear address space, containing data in a stack-like fashion. The stack grows from low addr esses to high addresses. There is one stack frame per activated procedure, which contains local variables, parameters, and linkage information. A call operation acquires a new stack frame; a return operation releases it. When a new frame is acquired, it is aligned on a SALIGN16 byte boundary, where SALIGN is a pre-defined value.
The page or simple object into which the first 64 bytes of a frame are mapped must he of local lifetime. The lifetime of the page or simple object is checked during a call. This restriction is necessary to ensure efficient manipulation of ADs in the local registers.
In addition to the requirement that a frame is mapped onto a local page or local simple object, the mixed bit of the page or the object descriptor is set even though no tag bit may be written to the frame. This restriction is necessary to ensure efficient manipulation of ADs in the local registers.
-12 Z The fields in the stack frame are defined as follows:
Padding Area. This area is used to align the FP to the next SALIGN16 byte boundary. The size of this area varies from 0 to SALIGN 16 - 1 bytes. When a call operation is performed, a padding area Is added to round the callerts SP to the next boundary to form the FP for this frame. If the caller's SP is already aligned. the padding area is absent.
Frame Status (L0). The frame status records the Information associated with the frame, after a call, to be used on a return from the frame. The fields of a frame status are defined as follows:
is Return Status, MR (bits 0-2). This 3-bit field records the call mechanism used in the creation of this frame and is used to select the the return mechanism to be used on return. The encodings of this field are as follows:
000 Local 001 Fault 010 supervisor, trace was disabled before call 011 supervisor, trace was enabled before call 100 Subsystem (intrasubsystem) 101 Subsystem (intersubsystem) 110 Idle interrupt ill Interrupt Prereturn Trace, P (bit 3).
on a return from a frame when the prereturn trace bit is 1,a prereturn trace event (if enabled) occurs before any actions association with the return operation is performed. This bit is initialized to zero on a call if no call-trace event occurred; otherwise it is Initialized to 1.
Previous Frame Pointer. PFP (bit 4-31). A linear address to the first byte of the previous frame. Since frames are aligned to boundaries of 16 bytes or more, only the mostsignificant 28 bits of the FP are saved.
During a call, the RRR field is initialized as follows:
000 - local call. or supervisor call from supervisor mode 001 - fault call 01T - supervisor call from user mode - intrasubsystem call 101 intersubsystem call - interrupt call from idle state ill - interrupt call from executing state T Is the value of the trace-enable flag from the process controls.
is On all returns, the PRRR bits are interpreted as follows 1XXX Generate a prereturn trace 0000 Perform a local return 0001 Perform a fault return.
001T In supervisor mode, perform a supervisor return. The T bit is assigned to the trace enable bit in the process controls, and the execution mode bit is set to user. other wise, perform a local return.
010x Perform a subsystem return.
Perform an idle interrupt return.
0111 Perform an interrupt return.
Stack Pointer. SP (L1). A linear address to the first free byte of the stack. that is, the address of the last byte in the stack plus one. SP is initialized by the call operation to point to FP plus 64.
9 Return instruction Pointer, RIP (1,2). When a call operation is performed to a new frame, the return IP is saved here.
When the process is suspended, the instruction pointer of the next instruction is stored here. It contains a 32-bit linear address to which control is returned after a return to this frame. The content of the RIP of the current frame is undefined. The implication is that a procedure call saves the IP in a register of the current frame. Since im plicit procedure calls can occur (due to faults and inter rupts). programs should not use this register for other pur poses.
-- Linear Address Space Structure is Each execution environment defines a 32-bit linear address space. The linear address space is partitioned into four re gions (regions 0-3) as shown in FIGURE 2. The first three regions of an execution environment are specific to the cur rent process (i.e., defined by the process control block).
The composition of the process specific regions can be changed by a subsystem call/return. The fourth region of an execution environment is shared by all processes (i.e., de fined by the processor control block). The system does not place any restriction on where instructions, stack frames, or data are located in the linear address space.
The physical address mapping of linear addresses from 16fe000 - 0000# to 16#efff-ffff#, or region 3 offsets from 16#20000000# to 16#2fff-ffff# are reserved by the system.
These locations inay be mapped into physical addresses inde pendent of the object addressing mechanism described in ap plication SH 455,625 (Docket D-1256) for the re gion S object.
-is- A static linear address space with transparent region bound- aries can be achieved by page table sharing if all regions are bipaged.
The ADs to the four regions are always interpreted to have read-write rep rights. It Is not possible to protect each region differently using AD rep rights. Page level protection can be used to achieve finer grain protection. Also. the implementation is not required to check the tag bits on 10 region ADs (meaning that it has the option of requiring ADs or interpreting data as region ADs).
The size of each region can be changed independently. A gap Is formed at the end of a region if the object that is used is to define a region is less than 1G bytes.
A simple object can be used to define a region if the object's size is either 512, 1K, 2K or 4K bytes. The base address of a simple region object must be aligned to physical address boundaries which are multiples of its size. When a simple object Is used to define a region, the length and the base address of the simple object are assumed to satisfy the above restrictions.
When a process is executing, all four regions must be unique (in the sense that each must have a different occurrence of a region descriptor).
If the fault handler for virtual-memory faults is not a sub- system fault handler, the following occur. For any process in the executing, ready, or blocked state, the descriptors of its regions must be marked as valid (i.e., the V flags inust be set).
Instruction Protection For the processor to execute instructions, read rights are needed for locations which contain the instructions.
instruction Caching The system allows read-only caching.of any bytes In the instruction stream in a non-transparent fashion. Instruction caching is independent of the cacheable bit in the page where instructions are located. Self-modified programs are not supported by the system in a transparent fashion.
Local Procedure Mechanism is A procedure begins at any arbitrary word address in a linear address space. Procedure calls and return use a stack in the linear address space, as shown In FIGURE 1.
Two parameter passing mechanisms are possible:
Global Registers. Parameters are copied to the global regis ters by the caller and copied out (if necessary) of the global registers by the callee after the call. Return or re sult parameters are copied to the global registers by the callee and copied out of the global registers by the caller after a return. This is optimized for procedures with a small number of parameters.
Argument List. An argument pointer to an argument list on the stack is used. This is designed as an escape mechanism when there are more parameters than can be passed using global registers.
The global register approach is always faster than the argument pointer approach. Hence. the argument pointer approach should only be used as an escape mechanism, and not the only mechanism.
1 When a procedure never invokes another procedure, it can avoid copying its parameters from the global registers to the stack frame.
Instructions Local Call CALL CALL-EXTENDED is CALL and CALL EXTENDED invoke the procedure at the address specified. CALL specifies the procedure as IP plus a 24-bit signed displacement. CALL - EXTENDED specifies the procedure using a general memory effective address.
A new stack frame is allocated during the call operation and the control flow Is transferred to the specified procedure.
Return Instruction return The RETURN instruction transfers control back to the calling prodedure and releases the called procedurefs stack frame. Instruction execution is continued at the instruction pointed to by the return instruction pointer (RIP) in the calling procedurefs frame.
-is- Miscellaneous Instructions MODIFY-AC FLUSH-LOCAL REGISTERS CONVERT-ADDRESS MODIFY-AC is used to read or modify he current arithmetic controls. FLUSH- LOCAL-REGISTERS writes all local register sets except for the current one into their associated frames in memory. Because the region ADs are not directly accessi ble, the CONVERT - ADDRESS instruction can be used to convert a linear address into a virtual address.
The invention may be embodied in a microprocessor such as that described in patent application sN 455,625 (D-1256). The microprocessor is logically subdivided into five major units: the Instruction Fetch Unit, the Instruction Decoder and Microinstruction Sequencer, the Translation Lookaside Buffer, the Local Bus Sequencer, and the Integer Execution Unit and Floating Point Unit.
Inter-Environment Transfer Refer to FIGURE 1. Inter-environment call/returns provide synchronous communication between execution environments. in addition to a two-state protection mechanism (user state and supervisor state), the system also supports an object oriented, subsystem based protection mechanism.
in accordance with the present invention, procedure invocation across environment boundaries Is provided in order for a process to gain access to those data structures and procedures that are otherwise private to an environment. A do- main object is used to represent the Opublic" interface of an environment. A domain object is also used as the inter- face to both a domain-based and a supervisor call mechanism. A domain object includes a procedure table which contains the addresses and types (subsystem or supervisor) of all public procedures.
The term "subsystem transfer" (call/return) is used to describe the subsystem protection mechanism. The term "supervisor transfer" is used to describe the supervisor protection mechanism.
Execution Modes The two modes of execution can occur. User mode and Supervi---sor mode, so that conventional operating systems can be emu- is lated. The system does not define the notion of privileged instructions. All instructions can be executed in either User mode or Supervisor mode. A program gains privilege by nature of its access rights and the node it is executing in. Access rights are referred to as representation rights (rep rights), such as read only, read/write or no access. The page rep rights in the current linear address space are interpreted differently depending on the execution node. Storage used by the operating system generally has page rep rights which do not allow user access, but may be read-only or read/write in the Supervisor mode. in systems where tagging is disabled (As described in the above referenced
application SN 4559625 (D-1256), the tag bit is not available to distinguish between data and point- ers to data called access descriptors (ADs). Since all operands have tag bits of zero, any attempt to execute instructions or operand specifiers which require an AD will fault In User mode. in the supervisor mode, the fault is disabled and the data is treated as an AD. Supervisor mode allows the execution of instructions which use ADs as operands (e.g. the SEND instruction requires an AD to a port object).
In systems where tagging is enabled, the only difference between the user and supervisor modes is the page rep rights Interpretation. The automatic interpretation of data as ADs in supervisor mode in not supported. instructions which require ADs can be executed if the specIfied operand is an AD.
In an untagged system. the call_system instruction is the only way to change the execution mode to supervisor without causing a fault. The system domain contains a set of entry procedures for the operating system.
is Supervisor Procedure Mechanism The supervisor procedure call is similar to a local call. When a supervisor procedure is specified in the procedure table in a domain object, the domain object specifies the new supervisor stack pointer. if the process is in user mode, the supervisor stack pointer is used as the new frame pointer. If the process is already in supervisor mode. the stack pointer in the current frame is aligned to the next 64-byte boundary to form the new frame pointer. This allows calling supervisor procedures from a supervisor procedure. The supervisor stack is required to be frozen. This Is an intra-execution environment transfer with the exception that the execution mode (and trace enable) of the process can be changed as part of the call.
The return status field is used to signal a supervisor return on a return from the frame. A supervisor return is performed only if the process is in supervisor mode at the beginning of the instruction. otherwise, a local return is performed. This prevents the modification of the trace con- trol and the selection of either fault or interrupt return by a procedure in user mode.
The supervisor procedure mechanism is for use with a simple untagged operating system, an operating system that requires only two stacks (user stack and supervisor stack) sharing the same linear address space and two protection levels.
Subsystem Based Protection Refer to FIGURE 1 which illustrates a system transfer mechanism. The execution environments use a domain-based protection mechanism. The target execution environment of a subsystem call is defined by the contents of a domain object is (100). The procedure table (102) in a domain object is independent of that in another domain for the same execution environment; thus selected procedures in the domain can be collected together in any order using another domain object. This feature will also support procedure variables.
Public information or objects associated with an environment may be accessible to programs that are executing in other environments. These objects are accessible via a domain object, which is used to limit accessibility (by other execu- tion environments) to only the public procedures, public constants and public variables of a package.
Private information or objects associated with an environment are not directly accessible via a domain object from other execution environments. objects and data not accessible via the domain object are said to he private to the domain. As part of a subsystem call operation. objects that define the execution environment are made accessible inside the execution environment.
The rep rights of the AD (101) referencing a domain object are set.to read-only to allow access to public read-only information, indirect access to the object that contains the public variables of the domain, and pointers to the public procedures. Except for the domain object type manager. a domain object AD (101) is not given write rights. if it were otherwise, protection could be bypassed by modifying a domain object. The read-only public information can be duplicated in the domain object to avoid the extra level of indirection if it is located in a separate object. The alterable public variables are located in a separate object to which both the domain and the target execution environment (104) have an AD with read-write rights.
is Target Execution Environment A domain object (100) is used to specify the target environment (104) of a subsystem call. A subsystem transfer may change one or more of the objects that define the current execution environment. With appropriate placement in three regions (data object, Instruction Object and Stack Object) of static data, stack frames, and ihstructions, a subsystem transfer does not need to change all three regions at the same time. This information is located in the three regions as follows:
Data Object. Region 0 (110) is used for static data and private variables. A subsystem call/return changes at least region 0.
Instruction Object. Region 1 (112) is used for instructions. This allows sharing the instruction part of a domain by copying a single AD without having to use page table sharing. This region may remain unchanged during a subsys- tem call/return if the execution environments are in the same compilation unit.
4 Stack Object. Region 2 (114) is used for stack frames. This region is process specific and sharing among processes is not possible. This region may remain unchanged during a subsystem call/return if the execution environments are in the same protected subsystem.
If the fault handler for virtual-memory faults is specified in the fault table as a subsystem, the object table entries (OTEs) for the regions of this subsystem must be marked as valid. Failing to do so will lead to a system error or to an incorrect frame or stack pointer when the fault handler in invoked.
Subsystem ID and Subsystem Table A domain (100) does not directly specify the region 2 AD of the target environment (104), but indirectly with a subsystem ID (106). The subsystem table (108) locates all the re- gion 2 stack objects and their corresponding topmost frame and stack pointers associated with a process. There is a one-to-one correspondence between a subsystem ID and a region 2 AD within a process. A subsystem ID can be mapped to different region 2 ADs each associated with a different process. The subsystem ID is used to select a subsystem entry (107) in the subsystem table (108) in the environment table object (FIGURE 5) associated with the current process. A subsystem entry (FIGURE 6), in turn, specifies the region 2 AD (109) and the topmost stack frame in the region.
The word that contains a subsystem ID can be either an AD or data. If ADs are used to represent subsystem IDs, the object index field of the AD provides a system wide and unique ID for the subsystem. Otherwise, software to assigns unique
IDe to each subsystem within a single process. The subsys- k tem ID together with the subsystem table serves the following functions:
Stack object sharing among domains. Domains in the same protected subsystem use the same subsystem ID to allow stack object sharing.
Reentrancy of a stack object. When a subsystem is exited on a call to another subsystem, the linear address of the top- most frame is saved in the subsystem entry. This allows a call from subsystem A to subsystem B which in turn calls subsystem A without returning from subsystem B first.
Trusted subsystems. A zero subsystem ID indicates the cur- ls rent stack object is used for region 2. This allows two mutually suspicious subsystems to share the same trusted 11brary module (e.g., a run-time library).
Guarantee stack resource. Since the stack resource associ- ated with a subsystem need not be shared with other subsystems, it is possible under some situations for software to guarantee that stack resource exhaustion never occurs. This allows certain faults be handled synchronously.
Domain object sharing among processes. The subsystem ID also allows the same domain to be used by different processes, but the same domain is mapped to different region 2 ADs using different process specific stacks.
Control Stack The subsystem call/return mechanism maintains a control stack (in the environment table object associated with a process) for the subsystem linkage information. A control stack is an array of control stack entries which saves the state of the execution environment to be restored on a return.
Extended Subsystem Environment When the subsystem model is used, the execution environment is extended to include the following:
Environment Table Object. This includes both the subsytem table and the control stack.
Current Subsystem ID. The process is associated with a sub system ID which is saved in the process object together with information like current subsystem table offset for is the current subsystem entry.
When the subsystem model is not used, the fields in the extended environment are not used and need not be present.
Interrupt/Idle Environment When when the process is in the interrupted state, or when the processor Is in idle state, an interrupt environment table object is used in subsystem calls. The interrupt en vironment table contains an extra system defined entry for the default interrupt subsystem ID.
Domain objects Refer to FIGURE 3 which illustrates a domain object. A do main object has an architecture-defined system type. The type rights in a domain object AD are uninterpreted. The fields of a domain object are defined as follows:
Region 0 AD (bytes 0-3). This AD references the object which defines region 0 of the target execution environment for a subsystem call. If the tag bit is zero, raise a CONSTRAINT.INVALID- AD fault.
Region 1 AD (bytes 4-7). This AD references the object which defines region 1 of the target execution environment for a subsystem call. if the tag bit is zero. raise a CONSTRAINT.INVALID-AD fault.
Subsystem ID (bytes 8-11). This mixed value is the subsys- tem ID used to select an entry in the subsystem table in the environment table associated within the process object. A subsystem entry in the subsystem table specifies the object that defines region 2 of the target execution environment -- and the frame pointer of the topmost stack frame in the enis vironment. If this field is a data word of zero, the current region 2 is used and the current frame is the topmost stack frame. Bits 6-31 of the subsystem ID is used to generate a hash value into the subsystem table.
Trace Control, T (byte 12, bit 0). This bit specifies the trace enable bit of the process after a subsystem or supervisor call via this object. This bit can be used to disable or enable tracing inside a the new execution environment. This bit is ignored when calling a supervisor procedure in supervisor mode. This bit has the same encoding as that in the process controls.
Supervisor Stack Pointer.(bytes 12-15, bits 2-31). This is a linear address (in words) for the supervisor stack. This field is used when invoking a supervisor call In the user mode (instead of the stack pointer in the current frame) to locate the new frame.
The process only distinguishes between a user stack (in user mode) and a supervisor stack (in supervisor mode). If the supervisor stack pointers in different domains contain dif- k ferent values, all the stacks must be big enough to handle all supervisor procedures' needs. Hence, the supervisor stack pointers used by a process should be the same. Since the fault table is associated with a processor. all the pro s cesses sharing the same processor need to have a supervisor stack as specified by the supervisor fault handling proce dures. Hence, the supervisor stack pointer should be a sys tem wide constant.
Procedure Entries (from byte 48 to the end of the object). A procedure entry, shown in FIGURE 4, specifies the type and address of the target procedure. The fields of a procedure entry are defined as follows:
is Procedure Entry Type (bits 0-1). This field indicates the type of procedure to be invoked. The encodings of this field are as follow:
00 - local procedure 01 - Implementation Specific 10 - supervisor procedure 11 - subsystem procedure offset (bits 2-31). This 30-bit field is a word offset into the target execution environment to the first instruction of the target procedure.
Environment Table Object The environment table object, shown in FIGURE 1. contains two data structures: a subsystem table (111) and a control stack (113). This object contains information necessary for all subsystem transfer within a single process; thus there is a one-to-one correspondence between a process object and an environment table object.
z k j is This shown in more detail in FIGURE 5. The environment table object does not have a defined system type. The fields of an environment table object are defined as follows:
Subsystem Table. This area is described in the following section. The first entry is used to store the current control stack pointer, control stack limit, and subsystem table size.
Control Stack. This area is described in the following section.
-- Subsystem Table During a subsystem call, a domain object directly specifies only two out of the three objects that define the new execution environment. The domain object contains a subsystem ID (106) which indirectly specifies the third object (114) of the new execution environment. A subsystem table is a data structure within an environment table object which provides the mapping of a subsystem ID (106) to a region 2 AD (109) of the new environment. Region 2 is used for stack frame allocation on call/returns; thus this object cannot be shared among different processes.
The first entry of the subsystem table of FIGURE 5 Is a dummy entry with the following defined fields:
Current Control Stack Pointer, CCSP (bytes 0-3, bits 4-31). This is an quad-word index for this object to the next available Control Stack Entry (CSE). This field is incremented on a subsystem call and decremented on a subsystem return.
0 Control Stack Limit, CSL (bytes 4-7, bits 4-31). This is an quad-word index for this object to the first CSE reserved for the control stack overflow fault handler (ie. not for regular uses). As shown in FIGURE 11, When CCSP = WL after the completion of a subsystem call, a CONTROL STACK. OVERFLOW fault is generated.
Subsystem Table Size (bytes 12-15, bits 4-29). This field contains the size (in units of subsystem entries) minus one of the subsystem table. This size of a subsystem table must be a power of 2; thus this field contains a bit mask of ones in the least significant bits. otherwise, the behavior is unpredictable.
is Subsystem ID to Subsystem Entry Mapping As shown in FIGURE 9, subsystem ID selects the corresponding subsystem entry in the subsystem table as follows:
If the specified subsystem ID is zero or equal to the current subsystem ID, the current subsystem ID is used. Otherwise, search the subsystem table as specified below.
Bits 6-31 of the specified subsystem ID is logically-ANDed with the subsystem table size to form the Initial subsystem entry index.
Repeat the following: (1) If the subsystem ID in the selected subsystem entry is zero. a OPERATION.SUBSYSTEM-NOT-FOUND fault may be raised.
(2) If the subsystem ID in the selected subsystem entry matches (comparemixed) that of the specified subsystem ID, exit from the search.
11,.
(3) Select the previous subsystem entry, i.e. search backward. Entry 0 wraps around to the last entry pointed to by the system table size.
(4) If this is the initial subsystem entry and the process is not in interrupted state, raise a OPERATION.SUBSYSTEM NOT-FOUND fault. If the process is in interrupted state. the current subsystem is used.
Subsystem Entry The structure of a subsystem entry is shown in FIGURE 6. The fields of a subsystem entry are defined as follows:
Topmost Frame Pointer (bytes 0-3, bits 6-31). This field contains the frame pointer of the topmost stack frame. During a subsystem call into this environment, this field is used as the previous frame.pointer in the new frame. During a subsystem call from this environment, the current frame pointer is saved here. During a subsystem return to this environment, this is used as the target frame pointer. During a subsystem return from this environment, the previous frame pointer W the current frame is saved here.
Topmost Stack Pointer (bytes 4-7). This field contains the stack pointer in the topmost stack frame. During a subsystem call into this environment, this field is used to compute the frame pointer of the new frame. During a subsystem call from this environment, the current stack pointer is saved here. During an inter-subsystem return from this environment, the current frame pointer (ie. the rounded-stack pointer in the previous frame) is saved here. During other inter-subsystem return from this environment, the current frame pointer minus 64 (i.e. the rounded stack pointer in the previous frame) is saved here. During an return to this environment, this field is ignored.
A 1 11) Subsystem ID (bytes 8-11). This ID (105) identifies the subsystem the target execution environment is associated with. This ID is used as the key for matching the subsystem ID (106) to the region 2 object (114); thus it is unique within the subsystem table. A subsystem ID value of zero indicates this subsystem entry is unallocated. Subsystem table entry 0, with a subsystem ID of all ones, is used for storing control stack information.
Event-Fault Disable (byte 8, bit 2). When this subsystem is entered, this flag defines the current value of the eventfault disable bit. If the event-fault disable bit is set, no event.notice fault will be signalled. If the event-fault disable bit is clear, an event.notice fault is raised if the event-fault request flags are set. on an inter-subsystem call/return which changes the event-fault flag to 0, a pending eventfault request be raised after the call/return.
Region 2 AD (bytes 12-15). This AD (109) references the object which defines the region 2 of the target execution environment partially specified by this entry. This AD must contain read/write rights. a protection.ad-rep_rights faults may be raised otherwise.
Control Stack The organization of the control stack (113) Is shown in FIG URE 5. A control stack entry (FIGURE 7) is pushed on the control stack on a subsystem call, and popped off the.con trol stack on a subsystem return. The control stack is de limited on the low end by a reserved control stack entry.
The control stack in delimited on the high end by the con trol stack limit plus a few reserved entries (for the con trol stack overflow fault.handler). The number of entries a to be reserved for stack overflow fault handler is software defined.
When the corresponding process is being executed, parts or all of the control stack are held Internally in the processor (i.e., the memory image may not be accurate, and reading/writing the memory image does not necessarily have any effect on the control stack). The load - control stack pointer instruction can be used to flush and invalidate any cached information.
Control Stack Entry -- The format of a control stack entry is shown in FIGURE 6.
is The fields of a control stack entry are defined as follows:
Return Region 0 AD (bytes 0-3). This AD references the object which defines the region 0 of the calling execution environment of the corresponding subsystem call. on a subsystem return, region 0 is restored to this object. This AD must contain read/write rights, a protection. adrep_rights fault may be raised otherwise.
Return Region 1 AD (bytes 4-7). This AD references the ob- ject which defines the region 1 of the calling execution environment of the corresponding subsystem call. On a subsystem return, region 1 is restored to this object. This AD must contain read/write rights, a protection. ad-rep_rights fault may be raised otherwise.
Trace Control, T (byte 8, bit 0). This bit contains the trace enable bit in the process controls during the corresponding normal subsystem calls. During a subsystem return, the trace control is restored to this bit.
a Return Mode, HMM (byte 8, bits 1-3). This 3-bit field in- dicates the type of entries. This field is encoded as follows: 000 - Normal 001 Normal 010 - reserved 011 - reserved 100 - Fault 101 - Fault
110 - reserved ill - reserved intra-subsystem. inter-subsystem (CONTROL STACK.UNDERFLOW fault) (CONTROL STACK.UNDERFLOW fault) intra-subsystem inter-subsystem (CONTROL STACK. UNDERFLOW fault) (CONTROL STACK.UNDERFLOW fault) Return Subsystem Entry Offset (bytes 8-11, bits 4-31). This field contains the entry index into the subsystem table (in is the environment table) for the subsystem entry that defines the region 2 of the calling execution environment.
When a subsystem table is expanded and rehashed, the subsystem entry offset changes and needs to be updated.
Calleefs Domain AD (bytes 12-15). This AD (120) references the domain object used in this subsystem call. This is initialized during a call, but it is not used on a return.
Inter-Domain CALL/RETURN CALL DOMAIN Instruction The CALL DOMAIN instruction invokes the procedure specified by the procedure number in the specified domain object. and changes the execution environment as specified by the domain object. The specified domain AD must have read rights. The procedure number is used as a word index into the procedure table in the specified domain object for a procedure entry.
t 9 \ i CALL-SYSTEM Instruction The CALL SYSTEM instruction calls a procedure in the system domain. The system domain is a domain referenced by the processor control block. It is necessary to allow supervisor calls in an untagged system. in a tagged systemt the system domain is used to inap, supervisor calls of an untagged operating system to a tagged operating system.
FIGUREs 8 through 11 are a flow chart the CALL-SYSTEM instruction. FIGURE 10 details the inter-subsystem call subroutine of the call system instruction and FIGURE 11 details the intrasubsystem call subroutine of the call system instruction.
RETURN instruction The particular return action is determined by the return status field in the previous frame field of the current frame. This allows procedures to be invoked from both inside or outside of their associated domains, even though different actions are taken.
LOAD-CONTROL-STACK-POINTER Instruction The LOAD-CONTROL STACK-POINTER returns the current control stack pointer of the process.
While the invention has been particularly shown and de- scribed with reference to preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and detail may be made therein without departing from the scope of the invention.

Claims (6)

1. A data processing system for allowing commu- nication between a current (calling) execution environment and a target (called) execution environment, a plurality of addressable objects, including a first processor object (28) and a first process object (64) defining a first execution environment associated with a first domain object, defining a second execution environment associated with a second domain object, said objects being stored in an address space of said memory, said data processing system characterized by:
a first environment table object associated with said first process; said environment table object including a control stack is for containing subsystem linkage information, said control stack being an array of control stack entries which entries save the state of said first calling execution environment to be restored on a return from said second execution envi ronment said second domain object including a Region 0 access descriptor (AD) that references an object which defines re gion 0 of said second (target) execution environment which is the target of a subsystem call, a Region 1 AD that ref erences the object which defines region 1 of said second (target) execution environment which is the target of a sub system call, and a subsystem ID that points to an entry in a subsystem table in said environment table associated within said process object, a subsystem entry in said subsystem table specifying the object that defines region 2 of said target execution environment and the frame pointer of the topmost stack frame in said target environment, a supervisor Stack Pointer that is a linear address (in words) for the supervisor stack used when invoking a supervisor call in the user mode (instead of the stack pointer in the current frame) to locate the new frame; said domain object further Including Procedure Entries that specify the type and address of said target procedure, each of said procedure entries including a Procedure Entry Type field that indicates the type of procedure to be invoked in s cluding, but not limited to, a supervisor procedure and a subsystem procedure, and an Offset into said target execu tion environment. which offset specifies first instruction of said target procedure.
2. The combination in accordnce with CLAIM 1 wherein: said Environment Table Object contains two data structures, a subsystem table and a control stack; said subsystem table (108) locating all the region 2 stack objects and their corresponding topmost frame and is stack pointers associated with a process.
3. The combination in accordnce with CLAIM 1 wherein a Current Subsystem ID is saved in said second process object together with said current subsystem table offset for the current subsystem entry in the subsystem table associated with said first process.
4. The combination in accordnce with CLAIM 1 wherein the linear address of the topmost frame is saved in the subsystem entry upon the condition that a subsystem is exited on a call to another subsystem.
5. The combination in accordrice with CLAIM 1 wherein said region 0 is a Data Object that contains static data and private variables. said region 1 is an instruction object that contains instructions, and, said region 2 is a stack object that contains stack frames associated with a specific process.
6. A data processing system substantially as hereinbefore described with reference to the accompanying drawings.
Published 1991 at 71e Patent Office. State House, 66171 High Holborn, London WC1R41P. Further copies may be obtained from Sales Branch, Unit 6. Nine Mile Point Cwmfelirifach. Cross Keys. Newport. NPI 7HZ. Printed by Multiplex techniques ltd, St Mary Cray, Kent.
GB9019821A 1989-12-22 1990-09-11 Synchronous communication between execution environments in a data processing system employing an object-oriented memory protection mechanism Expired - Lifetime GB2239334B (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US45562689A 1989-12-22 1989-12-22

Publications (3)

Publication Number Publication Date
GB9019821D0 GB9019821D0 (en) 1990-10-24
GB2239334A true GB2239334A (en) 1991-06-26
GB2239334B GB2239334B (en) 1994-07-06

Family

ID=23809601

Family Applications (1)

Application Number Title Priority Date Filing Date
GB9019821A Expired - Lifetime GB2239334B (en) 1989-12-22 1990-09-11 Synchronous communication between execution environments in a data processing system employing an object-oriented memory protection mechanism

Country Status (3)

Country Link
JP (1) JP3554320B2 (en)
DE (1) DE4040992C2 (en)
GB (1) GB2239334B (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2836569A1 (en) * 2002-02-28 2003-08-29 Gemplus Card Int Memory space for chip card downloaded applications has a data structure and two separate memory parts that improve card security in the face of attacks against applet type applications
US7941411B2 (en) 2007-06-29 2011-05-10 Microsoft Corporation Memory transaction grouping
US8006227B2 (en) 2007-06-01 2011-08-23 Microsoft Corporation Efficiently locating transactional code blocks in a transactional memory system
US8032870B2 (en) 2007-06-25 2011-10-04 Microsoft Corporation Transacting accesses via unmanaged pointers
US8099719B2 (en) 2007-06-19 2012-01-17 Microsoft Corporation Transactional debugger for a transactional memory system and detecting conflicts
US8196123B2 (en) 2007-06-26 2012-06-05 Microsoft Corporation Object model for transactional memory
US8601456B2 (en) 2006-08-04 2013-12-03 Microsoft Corporation Software transactional protection of managed pointers

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4545012A (en) * 1981-05-22 1985-10-01 Data General Corporation Access control system for use in a digital computer system with object-based addressing and call and return operations
US4811208A (en) * 1986-05-16 1989-03-07 Intel Corporation Stack frame cache on a microprocessor chip

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2836569A1 (en) * 2002-02-28 2003-08-29 Gemplus Card Int Memory space for chip card downloaded applications has a data structure and two separate memory parts that improve card security in the face of attacks against applet type applications
US8601456B2 (en) 2006-08-04 2013-12-03 Microsoft Corporation Software transactional protection of managed pointers
US8006227B2 (en) 2007-06-01 2011-08-23 Microsoft Corporation Efficiently locating transactional code blocks in a transactional memory system
US8099719B2 (en) 2007-06-19 2012-01-17 Microsoft Corporation Transactional debugger for a transactional memory system and detecting conflicts
US8650551B2 (en) 2007-06-19 2014-02-11 Microsoft Corporation Transactional debugger for a transactional memory system and detecting conflicts
US8032870B2 (en) 2007-06-25 2011-10-04 Microsoft Corporation Transacting accesses via unmanaged pointers
US8196123B2 (en) 2007-06-26 2012-06-05 Microsoft Corporation Object model for transactional memory
US7941411B2 (en) 2007-06-29 2011-05-10 Microsoft Corporation Memory transaction grouping
US8484175B2 (en) 2007-06-29 2013-07-09 Microsoft Corporation Memory transaction grouping

Also Published As

Publication number Publication date
DE4040992A1 (en) 1991-06-27
GB9019821D0 (en) 1990-10-24
GB2239334B (en) 1994-07-06
DE4040992C2 (en) 2002-10-31
JP3554320B2 (en) 2004-08-18
JPH03240134A (en) 1991-10-25

Similar Documents

Publication Publication Date Title
US5157777A (en) Synchronous communication between execution environments in a data processing system employing an object-oriented memory protection mechanism
US7213125B2 (en) Method for patching virtually aliased pages by a virtual-machine monitor
US5075848A (en) Object lifetime control in an object-oriented memory protection mechanism
US5280614A (en) Apparatus and method for controlling access to data using domains
US7330942B2 (en) Method for efficient virtualization of physical memory in a virtual-machine monitor
US5075845A (en) Type management and control in an object oriented memory protection mechanism
US6895491B2 (en) Memory addressing for a virtual machine implementation on a computer processor supporting virtual hash-page-table searching
US5095526A (en) Microprocessor with improved interrupt response with interrupt data saving dependent upon processor status
US5390310A (en) Memory management unit having cross-domain control
US20060036830A1 (en) Method for monitoring access to virtual memory pages
GB2239335A (en) Disabling tag bit recognition and allowing privileged operations to occur in an object-oriented memory protection mechanism
US7996833B2 (en) Method and system for replacing instructions and instruction blocks in computer code
JPS60221851A (en) Data processor and memory access controller used therefor
JPS6248258B2 (en)
US4866599A (en) Call instruction, return instruction and trap procedure for ring crossing architecture
US5187791A (en) Microprocessor with improved interrupt response with data saving dependent upon processor status using status flag
US20050172098A1 (en) Immediate virtual memory
US5732404A (en) Flexible expansion of virtual memory addressing
TW201941063A (en) Controlling guard tag checking in memory accesses
CN112639750A (en) Apparatus and method for controlling memory access
CN115885266A (en) Label inspection device and method
WO2019008324A1 (en) An apparatus and method for controlling execution of instructions
US8091090B2 (en) Method for providing scratch registers for use by a virtual-machine monitor
GB2239334A (en) Communication between execution environments in a data processing system employing an object-oriented memory protection mechanism
KR100791815B1 (en) Privilege promotion based on check of previous privilege level

Legal Events

Date Code Title Description
PE20 Patent expired after termination of 20 years

Expiry date: 20100910