Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
  • G06F13/14—Handling requests for interconnection or transfer
  • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
  • G06F13/1605—Handling requests for interconnection or transfer for access to memory bus based on arbitration

Definitions

• the present invention relates generally to a data processors and, more particularly, to a data processor having a module access control mechanism.
• the executing program has the ability to access any address within the address space generally available to the processor.
• access limitations are imposed upon a user program, but not upon the supervisor program.
• the access limitations are in the form of address range or space limits imposed by hardware.
• Another common limitation is the imposition of write protection upon certain designated address ranges which are otherwise accessible to the user program.
• the supervisor program includes a number of service routines for performing input/output operations and other necessary system functions.
• routines are considered to be privileged, and all accesses thereto by user programs typically results in traps to an appropriate privilege violation handler within the supervisor program.
• the handler is responsible for deciding if the request should be honored. If the decision is affirmative, the handler enables the requested service to be performed before control is transferred back to the user program. While this software implemented access control mechanism is quite versatile, the overhead associated with such a mechanism is far from insignificant.
• a program may be configured as a set of data/code modules which can be "called” as appropriate by other modules. At the end of the called module, control is returned to the calling module.
• these processors provide no mechanism for controlling access to such modules.
• the module call instruction is comparable to a conventional branch-to-subroutine instruction wherein the data processor would simply stack away onto a user stack certain return information before branching to the appropriate starting address of the module.
• this starting address is part of a "module descriptor" which is constructed by the compiler/assembler and linker in the process of creating an executable load module. Other information relating to the module may also be provided in the module descriptor.
• each "page" of the available address space within the system memory has associated with it an access level, creating in effect a set of concentric "rings" of protection.
• rings may vary, the most sensitive data/code modules are typically stored within the innermost ring and the user modules are within the outermost ring, the balance of the supervisor program and associated compilers/assemblers being appropriately distributed among the several available rings.
• the calling module In order to obtain access to data/code modules stored within the innermost ring, the calling module must have been granted the highest access level, while even those modules having the lowest access level can access modules stored in the outermost ring.
• the call module instruction allows a user program controlled access to data/code modules which the system wishes to protect against unauthorized use.
• the supervisor program has the responsibility of assigning access levels to each of the user programs which are installed in the system. For example, some ⁇ sers, because of their duties, may be assigned a higher access privilege than other users of the same program. Similarly, different programs, because of their nature, may require higher access levels than other programs. On the other hand, all of the programs will typically require access to those modules of the supervisor program which perform common input/output and related service functions.
• the call module mechanism facilitates just such a dynamic change in access level.
• the supervisor program typically Initializes the module descriptors (sometimes referred to as segment descriptors) to contain information relating to the address of the respective modules and to the access level thereof. Depending upon the requirements of the system, these descriptors may be stored either within or without the ring containing the respective modules. The addresses of these descriptors are thereafter inserted into the appropriate call module instructions in the calling module and the linked program installed into an appropriate storage medium within the system resources.
• the supervisor program can be sure that all module calls made by that program have previously been approved. However, the program must still be prevented from extending the higher level access privilege beyond the authorized module.
• This dynamic access control function is typically handled by an access controller implemented within the data processor itself or in a memory management unit which is tightly coupled to the data processor.
• the access controller monitors each access to the system storage to determine that the access level of the currently executing module is greater than or equal to the access level of the accessed page. If so, the access is allowed; if not, the access is faulted to force the termination of the calling module.
• the data processor Whenever a call module instruction is executed, the data processor notifies the access controller that the access level must be changed to a higher level, if necessary, to enable the called module to execute. The access controller would thereafter allow accesses to pages having the higher access level.
• the data processor orders the access control to change the access level back to the original level of the calling module.
• each access level has a set of "gates” associated therewith, each of which can be “open” or “closed” at the discretion of the supervisor program.
• the supervisor program will open a gate to that module by storing the descriptor for that module within a particular gate table at that access level; without such an entry, the gate will be effectively closed.
• a calling module can request access to a module by specifying the number of the gate within the calling module's access level which controls access to the desired module, together with the index into the respective gate table at which the module descriptor is stored.
• the processor If the access controller verifies that such an entry actually exists, the processor is allowed to establish the appropriate access level and pathway to the called module using the information contained in the module descriptor identified in the call module instruction; otherwise the access is faulted to force the termination of the calling module. Upon exiting from the called module, the processor reestablishes the original access level of the calling module before returning control thereto. In addition to dedicating significant storage space for the gate tables, this technique requires a significant amount of rather complex circuitry to implement the table lookup function.
• Still another object is to provide an efficient mechanism for a data processor to cooperate with an independent access controller in the control of access to a module stored in system storage.
• One other object of the present invention is to provide an improved gate mechanism for an access controller to directly control access to the system storage by modules executing in a data processor.
• the data processor is constructed to receive an instruction which requests accesss to the module, the Instruction specifying an address within the storage device containing an access request. Using the address specified in the instruction, the data processor retrieves the access request and provides the access request to the access controller. The data processor then Initiates the requested access to the module. However, the access will be faulted If the access controller decides to deny the access request.
• the data processor requests the decision of the access controller to the access request before attempting the requested access. If the decision of the access controller is affirmative, the data processor allows access to the module. However, if the decision of the access controller is negative, the data processor denies access to the module.
• the data processor need not be aware of the access criteria being Imposed by the access controller.
• the form and content of the access request may be changed to suit specific requirements without changing the data processor and the manner in which the access control mechanism is implemented therein.
• Figure 1 is a block diagram of a data processing system suitable for practicing the present invention.
• FIG. 2 is a block diagram of the data processor of
• a data processing system 10 wherein logical addresses (LADDR) Issued by a data processor (DP) 12 are mapped by a memory management unit (MKU) 14 to a corresponding physical address (PADDR) for output on a physical bus (PBUS) 16.
• LADDR logical addresses
• MKU memory management unit
• PADDR physical address
• PBUS physical bus
• the various logical access control signals (LCNTL) provided by DP 12 to control the access are converted to appropriately timed physical access control signals (PCNTL) by a modifier unit 18 under the control of MHU 14.
• PCNTL physical access control signals
• DP 12 is adapted in accordance with the present invention to cooperate with an access controller Implemented, for example, in MHU 14, to control access to data and code stored as modules in the memory 20.
• memory 20 In response to a particular range of physical addresses (PADDR), memory 20 will cooperate with an error detection and correction circuit (EDAC) 22 to exchange data (DATA) with DP 12 in synchronization with the physical access control signals (PCNTL) on PBUS 16.
• EDAC 22 Upon detecting an error in the data, EDAC 22 will either signal a bus error (BERR) or request DP 12 to retry (RETRT) the exchange, depending upon the type of error.
• mass storage Interface 24 In response to a different physical address, mass storage Interface 24 will cooperate with MP 12 to transfer data to or from mass storage 26. If an error occurs during the transfer, interface 24 may signal a bus error (BERR) or, if appropriate, request a retry (RETRT).
• BERR bus error
• RETRT request a retry
• a watchdog timer 28 may be provided to signal a bus error (BERR) if no physical device has responded to a physical address (PADDR) within a suitable time period relative to the physical access control signals (PCNTL).
• OR gates 30 and 32 will respectively activate the BERR and HALT inputs of DP 12.
• DP 12 will abort the current bus cycle and, upon the termination of the RETRT signal, retry the cycle.
• operation of DP 12 may be externally controlled by judicious use of a HALT signal.
• DP 12 In response to the activation of only the HALT input thereof via OR gate 32, DP 12 will halt at the end of the current bus cycle, and will resume operation only upon the termination of the HALT signal.
• DP 12 In response to the activation of only the BERR input thereof during a processor-controlled bus cycle, DP 12 will abort the current bus cycle, internally save the contents of the status register, enter the supervisor state, turn off the trace state if on, and generate a bus error vector number. DP 12 will then stack into a supervisor stack area in memory 20 a block of information which reflects the current internal context of the processor, and then use the vector number to branch to an error handling portion of the supervisor program.
• DP 12 will stack certain information of a general nature, including: the saved status register, the current contents of the program counter, the contents of the instruction register which is usually the first word of the currently executing instruction, the logical address which was being accessed by the aborted bus cycle, and the characteristics of the aborted bus cycle, i.e. read/write, Instruction/data and function code.
• DP 12 is constructed to stack much more information about the Internal machine state. If the exception handler is successful in resolving the error, the last instruction thereof will return control of DP 12 to the aborted program. During the execution of this instruction, the additional stacked information is retrieved and loaded into the appropriate portions of DP 12 to restore the state which existed at the time the bus error occurred.
• DP 12 The preferred operation of DP 12 will be described with reference to Figure 2 which illustrates the internal organization of a microprogrammable embodiment of DP 12. Since the illustrated form of DP 12 is very similar to the Motorola MC68000 microprocessor described in detail in the several U.S. Patents cited hereafter, the common operation aspects will be described rather broadly. Once a general understanding of the internal architecture of DP 12 is established, the discussion will focus on the access control aspect of the present invention.
• the DP 12 is a pipelined, microprogrammed data processor.
• each instruction is typically fetched during the execution of the preceding instruction, and the interpretation of the fetched instruction usually begins before the end of the preceding instruction.
• each instruction is typically fetched during the execution of the preceding instruction, and the interpretation of the fetched instruction usually begins before the end of the preceding instruction.
• each instruction is executed as a sequence of microinstructions which perform small pieces of the operation defined by the instruction. If desired, user instructions may be thought of as macroinstructions to avoid confusion with the microinstructions.
• each microinstruction comprises a microword which controls microinstruction sequencing and function code generation, and a corresponding nanoword which controls the actual routing of information between functional units and the actuation of special function units within DP 12.
• a prefetch microinstruction will be executed.
• the microword portion thereof will, upon being loaded from micro ROM 34 into micro ROM output latch 36, enable function code buffers 38 to output a function code (FC) portion of the logical address (LADDR) indicating an instruction cycle.
• FC function code
• LADDR logical address
• the corresponding nanoword requests bus controller 44 to perform an instruction fetch bus cycle, and instructs execution unit 46 to provide the logical address of the first word of the next instruction to address buffers 48.
• bus controller 44 Upon obtaining control of the PBUS 16, bus controller 44 will enable address buffers 48 to output the address portion of the logical address (LADDR).
• bus controller 44 will provide appropriate data strobes (some of the LCNTL signals) to activate memory 20.
• bus controller 44 enables instruction register capture (IRC) 50 to input the first word of the next instruction from PBUS 16.
• IRC instruction register capture
• another microinstruction will be executed to transfer the first word of the next instruction from IRC 50 into instruction register (IR) 52, and to load the next word from memory 20 into IRC 50.
• the word in IRC 50 may be Immediate data, the address of an operand, or the first word of a subsequent instruction.
• address 1 decoder 54 begins decoding certain control fields in the instruction to determine the micro address of the first microinstruction in the initial microsequence of the particular instruction in IR 52.
• illegal instruction decoder 56 will begin examining the format of the instruction in IR 52. If the format is determined to be Incorrect, illegal instruction decoder 56 will provide the micro address of the first microinstruction of an illegal instruction microsequence. In response to the format error, exception logic 58 will force multiplexor 60 to substitute the micro address provided by illegal instruction decoder 56 for the micro address provide by address 1 decoder 54.
• the microword portion thereof may enable multiplexor 60 to provide to an appropriate micro address to micro address latch 62, while the nanoword portion thereof enables instruction register decoder (IRD) 64 to load the first word of the next Instruction from IR 52.
• instruction register decoder ILD
• micro ROM 34 Upon the selected micro address being loaded into micro address latch 62, micro ROM 34 will output a respective microword to micro ROM output latch 36 and nano ROM 40 will output a corresponding nanovord to nano ROM output latch 42.
• micro ROM output latch 36 specifies the micro address of the next microinstruction to be executed, while another portion determines which of the alternative micro addresses will be selected by multiplexor 60 for input to micro address latch 62.
• more than one microsequence must be executed to accomplish the specified operation. These tasks, such as Indirect address resolution, are generally specified using additional control fields within the instruction.
• the micro addresses of the first microinstructions for these additional microseq ⁇ ences are developed by address 2/3 decoder 66 using control information in IR 52.
• the first microsequence will typically perform some preparatory task and then enable multiplexor 60 to select the micro address of the microsequence which will perform the actual operation as developed by the address 3 portion of address 2/3 decoder 66.
• the first microsequence will perform the first preparatory task and then will enable multiplexor 60 to select the micro address of the next preparatory microsequence as developed by the address 2 portion of address 2/3 decoder 66.
• the second microsequence Upon performing this additional preparatory task, the second microsequence then enables multiplexor 60 to select the micro address of the microsequence which will perform the actual operation as developed by the address 3 portion of address 2/3 decoder 66.
• the nanowords which are loaded into nano ROM output latch 42 indirectly control the routing of operands Into and, if necessary, between the several registers in the execution unit 46 by exercising control over register control (high) 68 and register control (low and data) 70.
• the nanoword enables field translation unit 72 to extract particular bit fields from the instruction in IRD 64 for input to the execution unit 46.
• the nanowords also indirectly control effective address calculations and actual operand calculations within the execution unit 46 by exercising control over AU control 74 and ALU control 76.
• the nanowords enable ALU control 76 to store into status register (SR) 78 the condition codes which result from each operand calculation by execution unit 46.
• SR status register
• ALU control 76 ALU and Condition Code Control Unit for Data Processor 76 issued 19 January 1982 to Gunter, et al, and which is hereby incorporated by reference.
• Other details relating to the construction and operation of DP 12 may be found in US Application Serial Number 447,600 entitled “Data Processor Version Validation” filed 7 December 1982 and allowed on 21 June 1984.
• DP 12 is a microprogrammed machine
• additional instructions is primarily a matter of providing appropriate microsequences for the new Instructions, provided, of course, that all of the resources and control paths are available to support the functionality of the new instructions.
• CALLM module call
• RTM module return
• the access controller function is totally at the discretion of the system designer.
• the access controller which could be conveniently integrated into the MMU 14, for example, will be assumed to exist as a "black box" which DP 12 perceives as a set of several registers accessible at respective predetermined addresses within the existing address space.
• the CALLM instruction consists of an effective address which specifies the address within the memory 20 at which a descriptor for the called module may be found, and an argument count which indicates the number of arguments, if any, the calling module is passing to the called module.
• the module descriptor will have been initialized at link time by the supervisor program to contain the entry address of the called module and the address of the data area associated with that module.
• the module descriptor may also contain the address of a stack upon which the module expects to find the arguments.
• the module descriptor will contain an access request of a specific format appropriate for the particular level of access control desired by the designer of the system.
• the access request consists of an access type code which Indicates whether the access level must be changed, and, if so, what new access level the called module requires.
• DP 12 Upon receiving the CALLM instruction for execution, DP 12 will first evaluate the effective address and then retrieve from that address the access request, the module address and the module data area address. DP 12 then tests the access request to determine the type of access which is to be made, that is, whether an access level change is required or the current access level Is adequate for the called module. In addition, the preferred form of the access request also indicates whether the called module expects to find the arguments on the calling module's stack or on the called module's stack.
• DP 12 will build a module stack frame at the top of the current stack. If the called module expects to find the arguments on the calling module's stack, DP 12 will stack the calling module's stack pointer on the module stack frame so that the called module will know where to find the arguments. If the called module expects to find the arguments on its own stack, DP 12 does not stack the calling module's stack pointer, but simply advances the module stack frame pointer to compensate for the shortcut. DP 12 then writes the current value of the calling module's program counter on the module stack frame, followed by the address of the module descriptor.
• the first word of the called module specifies a particular one of the several registers within DP 12 which that module expects to contain the address of the data area of that module.
• DP 12 will retrieve this register specifier, and then store the current contents of the specified register on the module stack frame.
• DP 12 completes the module stack frame by storing the argument count specified by the CALLM instruction and the access request retrieved from the module descriptor.
• DP 12 then begins execution of the module at the first instruction following the register specifier.
• DP 12 will first determine if the calling module is passing arguments to the called module and, if so, DP 12 will verify that all of the arguments are within the legitimate address space of the calling module. If an access violation is detected, DP 12 will force the termination of the calling module by vectoring to an exception handler. If no access violation is detected, DP 12 will read what it believes to be the access level of the calling module from a "current access level register" known to the DP 12 only as a first predetermined address within the address space. DP
• module address register known to the DP 12 only as a second predetermined address in the available address space
• DP 12 will force the termination of the calling module by vectoring to the exception handler. On the other hand, if the decision is perceived by DP 12 to be affirmative, DP 12 will insert the "old" access level into the access request being maintained within a temporary register within DP 12 in place of the "new" access level originally contained therein.
• DP 12 proceeds to complete the module stack frame just as in the case described above when there was no access level change. On the other hand, if the called module expects to find the arguments on its own stack,
• DP 12 will retrieve the called module's stack pointer from the module descriptor, and transfer all of the arguments from the calling module's stack to the called module' stack. DP 12 then builds the module stack frame as described above but on the called module's stack rather than on the calling module's stack. In either case, after the module stack frame is complete, DP 12 then begins execution of the module at the first instruction following the register specifier. Upon receiving the RTM instruction tor execution at the end of the called module, DP 12 will retrieve the access request, the argument count, the program counter for the calling module and the value which was in the register used by the called module as the pointer to its data area.
• DP 12 adjusts the current stack pointer to discard the module stack frame and any associated arguments, restores the original value of the register used by the called module, and then restores the program counter to resume execution of the calling module. If, however, the access type indicates that an access level change was made, DP 12. retrieves the "old" stack pointer from the called module's stack, before writing the "old" access level to a "decrease access level register" known to DP 12 only as a fifth predetermined address within the address space. DP 12 then reads the "access status register" again to see what the decision of the access controller is to the access level decrease request.
• DP 12 will force the termination of the calling module by vectoring to the exception handler. If the decision is affirmative, DP 12 will adjust the "old" stack pointer to discard the module stack frame and the associated arguments to derive the proper current stack pointer. DP 12 will then proceede as described above to restore the original value of the register used by the called module, and then the program counter to resume execution of the calling module.
• DP 12 in the course of processing the CALLM and RTM instructions, waits for the decision of the access controller before proceeding with the execution of the called module. However, if desired, DP 12 could simply proceed with the requested access after passing the access request to the access controller. If the access controller decides to deny access, the access controller can simply fault the access cycle, thereby forcing DP 12 into the exception handler anyway.
• the present invention in a general sense, relates to a mechanism for a data processor such as DP 12 to advise an independent access controller that an access request is going to be made unless the access controller prevents it. How the access controller decides whether or not to allow the access is totally outside the scope of the data processor.
• A1A - use the A1 PLA sample interrupts, do not sample trace A1B - use the A1 PLA do not sample interrupts or trace A2 - use the A2 PLA
• the latch in which this value is held has the following encoding
• RX is a general register pointer. It is used to point at either special purpose registers or user registers. RX generally is used to translate a register pointer field within an instruction into the control required to select the the appropriate register.
• ry ry/dbin This is a conditional substitution ry/dob for the normal ry selection (which includes the residual substitutions like dt) with dbin or dob. The substitution is made based on residual control defined in opmap (about 2 ird lines) which selects the dbin/dob and inhibits all action to ry (or the residually defined ry). Depending upon the direction to/from the rails dbin or dob is selected. If the transfer is to the rails then dbin is substituted while if the transfer is from the rails dob is substituted.
• condition codes are updated during late T3 based upon the data in alut and/or rega. These registers can be written to during T3. In the case of rega, there are times when the value to be tested is the result of an insertion from regb.
• CC - CONDITION CODE UPDATE CONTROL
• ror value in rega is rotated right by value in shift count register into regb.
• sxtd value in rega defined by start and end registers is sign extended to fill the undefined bits and that value is rotated right by the value in the shift count register.
• the result is in regb.
• xxtd value in rega defined by start and end registers is PSWX extended to fill the undefined bits and that value is rotated right by the value in the shift count register.
• the result is in regb.
• zxtd value in rega defined by start and end registers is zero extended to fill the undefined bits and that value is rotated right by the value in the shift count register.
• the result is in regb.
• This value however should be shifted by 3 bits such that osr [4:3] are loaded onto regb [1:0] with zero zero extension of the remaining bits.
• 3- LDCR load the control register from regb.
• the register is selected by the value in ar[1:0], this can be gated onto the rx bus.
• 17- LDSH2 load the contents of the shifter control registers from regb. These include wr,osr,count. 19- LDSWB load the internal bus register from regb. This is composed of bus controller state information which must be accessed by the user in fault situations. 21- LDSWI load the first word, of sswi (internal status word) from regb. This is composed of tpend, fpend1, fpend2, ar latch 23- LDSH1 load the contents of the shifter control registers from regb. These include st,en,sc. 25- LDOPC load micro pc into A4 from regb and check validity of rev #. 26- LDPER load per with the value on the a-bus.
• MOVEM requires the least significant bit of the lower word (16-bits only) that is a one to be encoded and latched into the AR latch and onto the BC BUS (inverted) so that it can be used to point at a register. If no bits are one then the end signal should be active which is routed to the branch pla. After doing the encoding, the least significant bit should be cleared.
• the output is then gated onto the BC bus where it is sign extended to an 8-bit value. It does not hurt anything in the
• 34- STCR store the control register in regb. The register is selected by the value in ar[1:0], this can be gated onto the rx bus.
• 38- 0PEKD store the psw in regb then set the supervisor bit and clear the trace bit in the psw. Tpend and Fpend are cleared. The whole psw is stored in regb.
• 39- 1PSWS store the psw in regb then set the supervisor bit and clear both trace bits in the psw.
• the whole psw is stored in regb.
• 40- STINST store IRD decoded information onto the BC bus and into regb. This data can be latched from the BC bus into other latches (i.e. wr & osr) by other control.
• 41- STIRD store the ird in regb.
• 43- STINL store the new interrupt level in pswi and regb.
• the three bits are loaded into the corresponding pswi bits.
• Clear IPEND the following T1.
• 44- S1V# store the format & vector number associated with the exception in regb.
• 47- STCRC store the contents of the CRC register in regb. Latch A4 with microaddress.
• 48 STSH2 store the contents of the shifter control registers into regb. These include wr,osr,count.
• Store high portion of shift control 50- STSWB store the internal bus register in regb. This is composed of bus controller state information which must be accessed by the user in fault situations.
• 52- STSWI store sswi (internal status word) in regb, The sswi is composed of tpend, ar latch, fpendl, fpend2
• 54- STSHl store the contents of the shifter control registers into regb. These include st,en,sc.
• 56- STOPC store the micro pc in regb.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Software Systems (AREA)
• Executing Machine-Instructions (AREA)
• Medicines That Contain Protein Lipid Enzymes And Other Medicines (AREA)
• Medicines Containing Antibodies Or Antigens For Use As Internal Diagnostic Agents (AREA)
• Storage Device Security (AREA)

Applications Claiming Priority (2)

Publications (2)

Family

ID=24510094

Family Applications (1)

Country Status (5)

Citations (2)

Family Cites Families (5)

• 1985
  • 1985-04-16 CA CA000479216A patent/CA1235821A/fr not_active Expired
  • 1985-04-24 EP EP19850902340 patent/EP0187763A4/fr not_active Withdrawn
  • 1985-04-24 WO PCT/US1985/000735 patent/WO1986000437A1/fr not_active Application Discontinuation
  • 1985-04-24 JP JP60502137A patent/JPS61502568A/ja active Pending
• 1986
  • 1986-02-27 KR KR1019860700123A patent/KR860700168A/ko not_active Application Discontinuation

Patent Citations (2)

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events