HIGH-PERFORMANCE RISC MICROPROCESSOR ARCHITECTURE

Abstract: The high-performance, RISC core based microprocessor architecture permits concurrent execution of instructions obtained from memory through an instruction prefetch unit having multiple prefetch paths allowing for the main program instruction stream, a target conditional branch instruction stream and a procedural instruction stream. The target conditional branch prefetch path allows both possible instruction streams for a conditional branch instruction to be prefetched. The procedural instruction prefetch path allows a supplementary instruction stream to be accessed without clearing the main or target prefetch buffers. Each instruction set includes a plurality of fixed length instructions. An instruction FIFO is provided for buffering instruction sets in a plurality of instruction set buffers including a first buffer and a second buffer. An instruction execution unit including a register file and a plurality of functional units is provided with an instruction control unit capable of examining the instruction sets within the first and second buffers and scheduling any of the instructions for execution by available functional units. Multiple data paths between the functional units and the register file allow multiple independent accesses to the register file by the functional units as necessary for the execution of the respective instructions.

Description: DESCRIPTION HIGH-PERFORMANCE RISC MICROPROCESSOR ARCHITECTURE Cross-Reference to Related Applications The present application is related to the following Applications, all assigned to tbe Assignee of the present Application: 1. EXTENSIBLE RISC MICROPROCESSOR ARCHITECTURE, invented by Le T. Nguyen et al, SMOS 7985 MCF/GBR, Application Serial Number 07/ 727.058. filed 08 July 1991: 2. RISC MICROPROCESSOR ARCHITECTURE WITH ISOLATED ARCHITECTURAL DEPENDENCIES, invented by Le T. Nguyen.-et al, SMOS 7987 MCF/GBR, Application Serial Number 07/726,744 filed 08 July 1991;. 3. RISC MICROPROCESSOR ARCHITECTURE IMPLEMENTING MULTIPLE TYPED REGISTER SETS, invented by Sanjiv Garg et al, SMOS 7988 MCF/GBR/RCC, Application Serial Number 07/726,773 filed 08 July 1991; 4. RISC MICROPROCESSOR ARCHITECTURE IMPLEMENTING FAST TRAP AND EXCEPTION STATE, invented by Le T. Nguyen et al, SMOS 7989 MCF/GBR/WSW, Application Serial Number 07/726,942 filed 08 July 1991; 5. SINGLE CHIP PAGE PRINTER CONTROLLER, invented by Derek J. Lentz et al, SMOS 7991 MCF/GBR, Application Serial Number 07 /726329 . filed 08 July 1991- and 6. MICROPROCESSOR ARCHITECTURE CAPABLE OF SUPPORTING MULTIPLE HETEROGENEOUS PROCESSORS, invented by Derek J..Lentz et al, SMOS 799_- _FΛ__B, " Application Serial Number 07 /726.893. filed 08 July 1991. Background of the Invention 1. Field of the Invention: The present invention is generally related to the design of RISC type microprocessor architectures and, in particular, to RISC microprocessor architectures that are capable of executing multiple instructions concurrently. 2. Deseription of the Related Art: Recently, the design of microprocessor architectures have matured from the use of Complex Instruction Set Computer (CISC), to simpler Reduced Instruction Set Computer (RISC) Architectures. The CISC architectures are notable for the provision of substantial hardware to implement and support an instruction execution pipeline. The typical conventional pipeline structure includes, in fixed order, instruction fetch, instruction decode, data load, instruction execute and data store stages. A performance advantage is obtained by the concurrent execution of different portions of a set of instructions through the respective stages of the pipeline. The longer the pipeline, the greater the number of execution stages available and the greater number of instructions that can be concurrently executed. Two general problems limit the effectiveness of CISC pipeline architectures. The first problem is that conditional branch instructions may not be adequately evaluated until a prior condition code setting instruction has substantially completed execution through the pipeline. Thus, the subsequent execution of the conditional branch instruction is delayed, or stalled, resulting in several pipeline stages remaining inactive for multiple processor cycles. Typically, the condition codes are written to a condition code register, also referred to as a processor status register (PSR) , only at completion of processing an instruction through the execution stage. Thus, the pipeline must be stalled with the conditional branch instruction in the decode stage for multiple processor cycles pending determination of the branch condition code. The stalling of the pipeline results in a substantial loss of through-put. Further, the average through-put of the computer will be substantially dependent on the mere frequency of conditional branch instructions occurring closely after the condition code setting instructions in the program instruction stream. A second problem arises from the fact that instructions closely occurring in the program instruction stream will tend to reference the same registers of the processor register file. Data registers are often used as the destination or source of data in the store and load stages of successive instructions. In general, an instruction that stores data to the register file must complete processing through at least the execution stage before the load stage processing of a subsequent instruction can be allowed to access the register file. Since the -4- execution of many instructions require multiple processor cycles in the single execution stage to produce store data, the entire pipeline is typically stalled for the duration of an execution stage operation. Consequently, the execution through-put of the computer is substantially dependent on the internal order of the instruction stream being executed. A third problem arises not so much from the execution of the instructions themselves, but the maintenance of the hardware supported instruction execution environment, or state-of-the- achine, of the microprocessor itself. Contemporary CISC microprocessor hardware sub-systems can detect the occurrence of trap conditions during the execution of instructions. Traps include hardware interrupts, software traps and exceptions. Each trap requires execution of a corresponding trap handling routines by the processor. On detection of the trap, the execution pipeline must be cleared to allow the immediate execution of the trap handling routine. Simultaneously, the state-of-the- machine must be established as of the precise point of occurrence of the trap; the precise point occurring at the conclusion of the first currently executing instruction for interrupts and traps and immediately prior to an instruction that fails due to a exception. Subsequently, the state-of-the-machine and, again depending on the nature of the trap the executing instruction itself must be restored at the completion of the handling routine. Consequently, with each trap or related event, a latency is introduced by the clearing of the pipeline at both the inception and conclusion of the handling routine and storage and return of the precise state-of-the-machine with corresponding reduction in the through-put of the processor. These problems have been variously addressed in an effort to improve the potential through-put of CISC architectures. Assumptions can be made about the proper execution of conditional branch instructions, thereby allowing pipeline execution to tentatively proceed in advance of the final determination of the branch condition code. Assumptions can also be made as to whether a register will be modified, thereby allowing subsequent instructions to also be tentatively executed. Finally, substantial additional hardware can be provided to minimize the Occurrence of exceptions that require execution of handling routines and thereby reduce the frequency of exceptions that interrupt the processing of the program instruction stream. These solutions,, while obviously introducing substantial " additional hardware complexities, also introduce distinctive problems of their own. The continued execution of instructions in advance of a final resolution of either a branch condition or register file store access require that the state-of- the-machine be restorable to any of multiple points in the program instruction stream including the location of the conditional branch, each modification of a register file, and for any occurrence of an exception; potentially to a point prior to the fully completed execution of the last several instructions. Consequently, even more supporting hardware is required and, further, must be particularly designed not to significantly increase the cycle time of any pipeline stage. RISC architectures have sought to avoid many of the foregoing problems by drastically simplifying the hardware implementation of the microprocessor architecture. In the extreme, each RISC instruction executes in only three pipelined program cycles including a load cycle, an execution cycle, and a store cycle. Through the use of load and store data bypassing, conventional RISC architectures can essentially execute a single instruction per cycle in the three stage pipeline. Whenever possible, hardware support in RISC architectures is minimized in favor of software routines for performing the required functions. Consequently, the RISC architecture holds out the hope of substantial flexibility and high speed through the use of a simple load/store instruction set executed by an optimally matched pipeline. And in practice, RISC architectures have been found to benefit from the balance between a short, high-performance pipeline and the need to execute substantially greater numbers of instructions to implement all required functions. The design of the RISC architecture generally avoids or minimizes the problems encountered by CISC architectures with regard to branches, register references and exceptions. The pipeline involved in a RISC architecture is short and optimized for speed. The shortness of the pipeline minimizes the consequences of a pipeline stall or clear as well as minimizing the problems in restoring the εtate-of-the-machine to an earlier execution point. However, significant through-put performance gains over the generally realized present levels cannot be readily achieved by the conventional RISC architecture. Consequently, alternate, so-called εuper-εcaler architectures, have been variously proposed. These architectures generally attempt to execute multiple instructions concurrently and thereby proportionately increase the through-put of the processor. Unfortunatel , such architectures are, again, subject to similar, if not the same conditional branch, register referencing, and exception handling problems as encountered by CISC architectures. Summary of the Invention Thus, a general purpose of the present invention is to provide a high-performance, RISC based, εuper-εcaler processor architecture capable of substantial performance gains over conventional CISC and RISC architectures a ' nd that is further suited for microprocessor implementation. This purpose is obtained in the present invention through the provision of a microprocessor architecture capable of the concurrent execution of instructions obtained from an instruction store. The microprocessor architecture includes an instruction prefetch unit for fetching instruction sets from the instruction store. Each instruction set includes a plurality of fixed length instructions. An instruction FIFO is provided for buffering instruction sets in a plurality of instruction set buffers including a first buffer and a second buffer. An instruction execution unit, including a register file and a plurality of functional units, is provided with an instruction control unit capable of examining the instruction sets within the first and second buffers and issuing any of these instructions for execution by available functional units. Multiple data paths between the functional units and the register file allow multiple independent accesses to the register file as necessary for the concurrent execution of the respective instructions. The register file includes an additional set of data registers used for the temporary storage of register data. These temporary data registers are utilized by the instruction execution control unit to receive data processed by the functional units in the out-of-order execution of instructions. The data stored in the temporary data registers is selectively held, then cleared or retired to the register file when, and if, the precise εtate-of-the-machine advances to the instruction's location in the instruction stream; where all prior in-order instructions have been completely executed and retired. Finally, the prefetching of instruction sets from the instruction store is facilitated by multiple prefetch paths allowing for prefetching of the main program instruction stream, a target conditional branch instruction stream and a procedural instruction stream. The target conditional branch prefetch path enables both possible instruction streams for a conditional branch instruction, main and target, to be simultaneously prefetched. The procedural instruction prefetch path allows a supplementary instruction stream, effective for allowing execution of an extended procedures implementing a singular instruction found in the main or target instruction streams; the procedural prefetch path enables these extended procedures to be fetched and executed without clearing at least the main prefetch buffers. Consequently, an advantage of the present invention is that it provides an architecture that realizes extremely high performance through-put utilizing a fundamentally RISC type core architecture. Another advantage of the present invention is that it provides for the execution of multiple instructions per cycle. A further advantage of the present invention is that it provides for the dynamic selection and utilization of functional units necessary to optimally execute multiple instructions concurrently. Still another advantage of the present invention is that it provides for a register file unit that integrally incorporates a mechanism for supporting a precise εtate-of-the-machine return capability. Yet another advantage of the present invention is that it incorporates multiple register files within the register file unit that are generalized, typed and capable of multiple register file functions including operation as multiple independent and parallel integer register files, operation of a register file as both a floating point and integer file and operation of a dedicated boolean register file. A still further advantage of the present invention is that load and store operations and the handling of exceptions and interrupts can be performed in a precise manner through the use of a precise εtate-of-the-machine return capability including efficient instruction cancellation mechanisms and a load/store order synchronizer. A yet still further advantage of the present invention is the provision for dedicated register file unit εupport of trap εtates so as to minimize latency and enhance processing through-put. Yet still another advantage of the present invention is the provision for main and target branch instruction prefetch queues whereby even incorrect target branch stream execution ahead minimally impacts the overall processing through-put obtainable by the present invention. Further, the procedural instruction prefetch queue allows an efficient manner of intervening in the execution of the main or target branch instruction streams to allow the effective implementation of new instructions through the execution of procedural routines and, significantly, the externally provided revision of procedural routines implementing built-in procedural instructions. Brief Description of the Drawings These and other advantages and features of the present invention will become better understood upon consideration of the following detailed description of the invention when considered in connection of the accompanying drawings, in which like reference numerals designate like parts throughout the figures thereof, and wherein: Figure 1 is a simplified block diagram of the preferred microprocessor architecture implementing the present invention; Figure 2 is a detailed block diagram of the instruction fetch unit constructed in accordance with the present invention; Figure 3 is a block diagram of the program counter logic unit constructed in accordance with the present invention; Figure 4 is a further detailed block diagram of the program counter data and control path logic- Figure 5 is a simplified block diagram of the instruction execution unit of the present invention; Figure 6a is a εimplified block diagram of the register file architecture utilized in a preferred embodiment of the present invention. Figure 6b is a graphic illustration of the storage register format of the temporary buffer register file and utilized in a preferred embodiment of the present invention; Figure 6c is a graphic illustration of the primary and secondary instruction sets as present in the last two stages of the instruction FIFO unit of the present invention; Figures 7a-c provide a graphic illustration of the reconfigurable states of the primary integer register set as provided in accordance with a preferred embodiment of the present invention; Figure 8 is a graphic illustration of a reconfigurable floating point and secondary integer register . set as provided in accordance with the preferred embodiment of the present invention; Figure 9 is a graphic illustration of a tertiary boolean register set as provided in a preferred embodiment of the present invention; Figure 10 is a detailed block diagram of the primary integer processing data path portion of the instruction execution unit constructed in accordance with the preferred embodiment of the present invention; Figure 11 is a detailed block diagram of the primary floating point data path portion of the instruction execution unit constructed in accordance with a preferred embodiment of the present invention; Figure 12 iε a detailed block diagram of the boolean operation data path portion of the instruction execution unit as constructed in accordance with the preferred embodiment of the present invention; Figure 13 is a detailed block diagram of a load/store unit constructed in accordance with the preferred embodiment of the present invention; Figure 14 is a timing diagram illustrating the preferred sequence of operation of a preferred embodiment of the present invention in executing multiple instructions in accordance with the present invention; Figure 15 is a simplified block diagram of the virtual memory control unit as constructed in accordance with the preferred embodiment of the present invention; Figure 16 is a graphic representation of the virtual memory control algorithm as utilized in a preferred embodiment of the present invention; and Figure 17 is a simplified block diagram of the cache control unit as utilized in a preferred embodiment of the present invention. Detailed Description of the Invention I. Microprocessor Architectural Overview . . . . 14 II. Instruction Fetch Unit 17 A) IFU Data Path 18 B) IFU Control Path 23 C) IFU/IEU Control Interface 32 D) PC Logic Unit Detail 35 1) PF and ExPC Control/Data Unit Detail 39 2) PC Control Algorithm Detail . . . . 46 E) Interrupt and Exception Handling . . . . 59 1) Overview 59 2) Asynchronous Interrupts: 61 3) Synchronous Exceptions 62 4) Handler Dispatch and Return . . . . 66 5) Nesting 70 6) List of Traps: 72 III. Instruction Execution Unit 73 A) IEU Data Path Detail 79 1) Register File Detail 79 2) Integer Data Path Detail 88 3) Floating Point Data Path Detail . . 92 4) Boolean Register Data Path Detail . 94 B) Load/Store Control Unit 99 C) IEU Control Path Detail 102 1) EDecode Unit Detail 103 2) Carry Checker Unit Detail 106 3) Data Dependency Checker Unit Detail 107 4) Register Rename Unit Detail . . . . 108 5) Instruction Issuer Unit Detail . . . 110 6) Done Control Unit Detail 113 7) Retirement Control Unit Detail . . . 113 8) Control Flow Control Unit Detail . . 114 9) Bypass Control Unit Detail 115 IV. Virtual Memory Control Unit 115 V. Cache Control Unit 118 VI. Summary/Conclusion 120 I. Microprocessor Architectural Overview: The architecture 100 of the present invention is generally shown in Figure 1. An Instruction Fetch Unit (IFU) 102 and an Instruction Execution Unit (IEU) 104 are the principal operative elements of the architecture 100. A Virtual Memory Unit (VMU) 108, Cache Control Unit (CCU) 106, and Memory Control Unit (MCU) 110 are provided to directly support the function of the IFU 102 and IEU 104. A Memory Array Unit (MAU) 112 is also provided as a generally essential element for the operation of the architecture 100, though the MAU 112 does not directly exist as an integral component of the architecture 100. That is, in the preferred embodiments of the present invention, the IFU 102, IEU 104, VMU 108, CCU 106, and MCU 110 are fabricated on a single silicon die utilizing a conventional 0.8 xiicron design rule low-power CMOS process and comprising some 1,200,000 transistors. The standard processor or system clock speed of the architecture 100 is 40 MHz. However, in accordance with a preferred embodiment of the present invention, the internal processor clock speed is 160 MHz. The IFU 102 is primarily responsible for the fetching of instructions, the buffering of instructions pending execution by the IEU 104, and, generally, the calculation of the next virtual addresε to be used for the fetching of next instructions. In the preferred embodiments of the present invention, instructions are each fixed at a length of 32 bits. Instruction sets, or "buckets" of four instructions, are fetched by the IFU 102 simultaneously from an instruction cache 132 within the CCU 106 via a 128 bit wide instruction bus 114. The transfer of instruction sets is coordinated between the IFU 102 and CCU 106 by control εignalε provided via a control bus 116. The virtual address of a instruction set to be fetched is provided by the IFU 102 via an IFU combined arbitration, control and address bus 116 onto a shared arbitration, control and address bus 120 further coupled between the IEU 104 and VMU 108. Arbitration for access to the VMU 108 arises from the fact that both the IFU 102 and IEU 104 utilize the VMU 108 as a common, shared resource. In the preferred embodiment of the architecture 100, the low order bits defining an address s within a physical page of the virtual address are transferred directly by the IFU 102 to the Cache Control Unit 106 via the control lines 116. The virtualizing, high order bits of the virtual address supplied by the IFU 102 are provided by the address portion of the buses 118, 120 t the VMU 108 for translation into a corresponding physical page address. For the IFU 102, this physical page address is transferred directly from the VMU 108 to the Cache Control Unit 106 via the address control lines 122 one-half internal processor cycle after the translation request is placed with the VMU 108. The instruction stream fetched by the IFU 102 is, in turn, provided via an instruction stream bus 124 to the IEU 104. Control εignalε are exchanged between the IFU 102 and the IEU 104 via controls lines 126. In addition, certain instruction fetch addresses, typically those requiring access to the register file present within the IEU 104, are provided back to the IFU via a target address return bus within the control lines 126. The IEU 104 stores and retrieves data with respect to a data cache 134 provided within the CCU 106 via an 80-bit wide bi-directional data bus 130. The entire physical address for IEU data accesses is provided via an address portion of the control bus 128 to the CCU 106. The control buε 128 alεo provides for the exchange of control signals between the IEU 104 and CCU 106 for managing data transfers. The IEU 104 utilizes the VMU 108 as a resource for converting virtual data address into physical data addresses suitable for submission to the CCU 106. The virtualizing portion of the data address is provided via the arbitration, control and address bus 120 to the VMU 108. Unlike operation with respect to the IFU 102, the VMU 108 returns the corresponding physical address via the bus 120 to the IEU 104. In the preferred embodiments of the architecture 100, the IEU 104 requires the physical address for use in ensuring that load/store operations occur in proper program stream order. The CCU 106 performs the generally conventional high-level function of determining whether physical address defined requests for data can be satisfied from the instruction and data caches 132, 134, as appropriate. Where the access request can be properly fulfilled by access to the instruction or data caches 132, 134, the CCU 106 coordinates and performs the data transfer via the data buses 114, 128. Where a data access request cannot be satisfied from the instruction or data caches 132, 134, the CCU 106 provides the corresponding physical address to the MCU 110 along with sufficient control information to identify whether a read or write access of the MAU 112 is desired, the source or destination cache 132, 134 of the CCU 106 for each request, and additional identifying information to allow the request operation to be correlated with the ultimate data request as issued by the IFU 102 or IE0 104. The MCU 110 preferably includes a port switch unit 142 that is coupled by a uni-directional data bus 136 with the instruction cache 132 of the CCU 106 and a bi¬ directional data bus 138 to the data cache 134. The port switch 142 is, in essence, a large multiplexer allowing a physical address obtained from the control bus 140 to be routed to any one of a number of ports P 0 - P N 146-_ n and the bi-directional transfer of data from the ports to the data buses 136, 138. Each memory access request processed by the MCU 110 is associated with one of the ports 146^ ' for purposes of arbitrating for access to the main system memory bus 162 as required for an access of the MAU 112. Once a data transfer connection has been established, the MCU provides control information via the control bus 140 to the CCU 106 to initiate the transfer of data between either the instruction or data cache 132, 134 and MAU 112 via the port switch 142 and the corresponding one of the ports 146^ . In accordance with the preferred embodiments of the architecture 100 the MCU 110 does not actually store or latch data in transit between the CCU 106 and MAU 112. This is done to minimize latency in the transfer and to obviate the need for tracking or managing data that may be uniquely present in the MCU 110. II. Instruction Fetch Unit: The primary elements of the Instruction Fetch Unit 102 are shown in Figure 2. The operation and interrelationship of these elements can beεt be understood by considering their participation in the IFU data and control paths. h ) IFU Pete Path; The IFU data path begins with the instruction bus 114 that receives instruction sets for temporary storage in a prefetch buffer 260. An instruction set from the prefetch buffer 260 iε passed through an IDecode unit 262 and then to an IFIFO unit 264. Instruction sets stored in the last two stages of the instruction FIFO 264 are continuously available, via the data buses 278, 280, to the IEU 104. The prefetch buffer unit 260 receives a single instruction set a't a time from the instruction bus 114. The full 128 bit wide instruction set is generally written in parallel to one of four 128 bit wide prefetch buffer locations in a Main Buffer (MBUF) 188 portion of the prefetch buffer 260. Up to four additional instruction sets may be similarly written into two 128 bit wide Target Buffer (TBUF) 190 prefetch buffer locations or to two 128 bit wide Procedural Buffer (EBUF) 192 prefetch buffer locations. In the preferred architecture 100, an instruction set in any one of the prefetch buffer locations within the MBUF 188, TBUF 190 or EBUF 192 may be transferred to the prefetch buffer output bus 196. In addition, a direct fall through instruction set bus 194 is provided to connect the instruction bus 114 directly with the prefetch buffer output bus 196, thereby bypassing the MBUF, TBUF and EBUF 188, 190, 192. In the preferred architecture 100, the MBUF 188 is utilized to buffer instruction sets in the nominal or main instruction stream. The TBUF 190 iε utilized to buffer instruction sets fetched from a tentative target branch instruction stream. Consequently, the prefetch buffer unit 260 allows both possible instruction streams following a conditional branch instruction to be prefetched. This facility obviates the latency for further accesses to at least the CCU 106, if not the subεtantially greater latency of a MAU 112, for obtaining the correct next instruction set for execution following a conditional branch instruction regardless of the particular instruction stream eventually εelected upon resolution of the conditional branch instruction. In the preferred architecture 100 invention, the provision of the MBUF 188 and TBUF 190 allow the instruction fetch unit 102 to prefetch both potential instruction streams and, as will be discussed below in relationship to the instruction execution unit 104, to further allow execution of the presumed correct instruction stream. Where, upon resolution of the conditional branch instruction, the correct instruction stream has been prefetched into the MBUF 188, any instruction εetε in the TBUF 190 may be simply invalidated. Alternately, where instruction sets of the correct instruction stream are present in the TBUF 190, the instruction prefetch buffer unit 260 provides for the direct, lateral transfer of those instruction sets from the TBUF 190 to respective buffer locations in the MBUF 188. The prior MBUF 188 stored instruction sets are effectively invalidated by being overwritten by the TBUF 190 transferred instruction sets. Where there iε no TBUF instruction set tranεferred to an MBUF location, that location is simply marked invalid. Similarly, the EBUF 192 iε provided as another, alternate prefetch path through the prefetch buffer 260. The EBUF 192 is preferably utilized in the prefetching of an alternate instruction stream that iε used to implement an operation specified by a single instruction, a "procedural" instruction, encountered in the MBUF 188 instruction stream. In this manner, complex or extended instructions can be implemented through software routines, or procedures, and processed through the prefetch buffer unit 260 without disturbing the instruction streams already prefetched into the MBUF 188. Although the present invention generally permits handling of procedural instructions that are first encountered in the TBUF 190, prefetching of the procedural instruction stream is held with all prior pending conditional branch instructions are resolved. This allows conditional branch instructions occurring in the procedural i struction stream to be consistently handled through the use of the TBUF 190. Thus, where a branch is taken in the procedural stream, the target instruction sets will have been prefetched into the TBUF 190 and can be simply laterally transferred to the EBUF 192. Finally, each of the MBUF 188, TBUF 190 and EBUF 192 are coupled to the prefetch buffer output bus 196 so as to provide any instruction set stored by the prefetch unit onto the output bus 196. In addition, a flow through bus 194 is provided to directly transfer an instruction set from the instruction bus 114 directly to the output bus 196. In the preferred architecture 100, the prefetch buffers within the MBUF 188, TBUF 190, EBUF 192 do not directly form a FIFO structure. Instead, the provision of an any buffer location to output bus 196 connectivity allows substantial freedom in the prefetch ordering of instruction sets retrieved from the instruction cache 132. That iε, the instruction fetch unit 102 generally determines and requests instruction sets in the appropriate instruction stream order of instructions. However, the order in which instruction sets are returned to the IFU 102 is allowed to occur out-of- order as appropriate to match the circumstances where some requested instruction sets are available and accessible from the CCU 106 alone and others require an access of the MAU 112. Although instruction sets may not be returned in order to the prefetch buffer unit 260, the sequence of instruction sets output on the output bus 196 must generally conform to the order of instruction set requests issued by the IFU 102; the in-order instruction stream sequence subject to, for example, tentative execution of a target branch stream. The IDecode unit 262 receives the instruction sets, generally one per cycle, IFIFO unit 264 space permitting, from the prefetch buffer output bus 196. Each set of four instructions that make up a single instruction set is decoded in parallel by the IDecode unit 262. While relevant control flow information is extracted via lines 318 for the benefit of the control path portion of the IFU 102, the contents of the instruction set iε not altered by the IDecode unit 262. Instruction sets from the IDecode Unit 162 are provided onto a 128 bit wide input bus 198 of the IFIFO unit 264. Internally, the IFIFO unit 264 consists of a sequence of master/slave registers 200, 204, 208, 212, 216, 220, 224. Each register is coupled to its successor to allow the contents of the master registers 200, 208, 216 to be transferred during a first half internal processor cycle of FIFO operation to the slave registers 204, 212, 220 and then to the next εuccesεive master register 208, 216, 224 during the succeeding half-cycle of operation. The input bus 198 iε connected to the input of each of the master registers 200, 208, 216, 224 to allow loading of an instruction set from the IDecode unit 262 directly in to a master register during the second half-cycle of FIFO operation. However, loading of a master register from the input bus 198 need not occur simultaneously with a FIFO shift of data within the IFIFO unit 264. Consequently, the IFIFO unit 264 can be continuously filled from the input bus 198 regardless of the current depth of instruction sets r rcd within the instruction FIFO unit 264 and, further, independent of the FIFO shifting of data through the IFIFO unit 264. Each of the master/slave registers 200, 204, 208, 212, 216, 220, 2 ' 24, in addition to providing for the full parallel storage of a 128 bit wide instruction set, also provides for the storage of several bits of control information in the respective control registers 202, 206, 210, 214, 218, 222, 226. The preferred set of control bits include exception miss and exception modify, (VMU), no memory (MCU), branch bias, stream, and offset (IFU). This control information originates from the control path portion of the IFU 102 simultaneous with the loading of an IFIFO master register with a new instruction set from the input bus 198. Thereafter, the control register information iε shifted in parallel concurrently with the instruction sets through the IFIFO unit 264. Finally, in the preferred architecture 100, the output of instruction sets from the IFIFO unit 264 is obtained simultaneously from the last two master registers 216, 224 on the I_Bucket_0 and I_Bucket_l instruction set output buses 278, 280. In addition, the corresponding control register information is provided on the IBASV0 and IBASV1 control field buses 282, 284. These output buses 278, 282, 280, 284 are all provided as the instruction stream bus 124 to the IEU 104. B. TFU Control Path: The control path for the IFU 102 directly supports the operation of the prefetch buffer unit 260, IDecode unit 262 and IFIFO unit 264. A prefetch control logic unit 266 primarily manages the operation of the prefetch buffer unit 260. The prefetch control logic unit 266 and IFU 102 in general, receives the system clock signal via the clock line 290 for synchronizing IFU operations with these of the IEU 104, CCU 106 and VMU 108. Control signals appropriate for the selection and writing of instruction sets into the MBUF 188, TBUF 190 and EBUF 192 are provided on the control lines 304. A number of control signals are provided on the control lines 316 to the prefetch control logic unit 266. Specifically, a fetch request control signal is provided to initiate a prefetch operation. Other control signals provided on the control line 316 identify the intended destination of the requested prefetch operation as being the MBUF 188, TBUF 190 or EBUF 192. In response to a prefetch request, the prefetch control logic unit 266 generates an ID value and determines whether the prefetch request can be posted to the CCU 106. Generation of the ID value is accomplished through the use of a circular four-bit counter. The use of a four-bit counter is significant in three regards. The first iε that, typically a maximum of nine instruction sets may be active at one time in the prefetch buffer unit 260; four instruction sets in the MBUF 188, two in the TBUF 190, two in the EBUF 192 and one provided directly to the IDecode unit 262 via the flow through bus 194. Secondly, instruction sets include four instructions of four bytes each. Consequently, the least significant four bits of any address selecting an instruction set for fetching are superfluous. Finally, the prefetch request ID value can be easily associated with a prefetch request by insertion as the least significant four bits of the prefetch request address; thereby reducing the total number of address lines required to interface with the CCU 106. To allow instruction sets to be returned by the CCU 106 out-of-order with respect to the sequence of prefetch requests issued by the IFU 102, the architecture 100 ' provides for the return of the ID request value with the return of instruction sets from the CCU 106. However, the out-of-order instruction set return capability may result in exhaustion of the sixteen unique IDs. A combination of conditional instructions executed out-of-order, resulting in additional prefetches and instruction sets requested but not yet returned can lead to potential re-use of an ID value. Therefore, the four-bit counter is preferably held, and no further instruction set prefetch requests issued, where the next ID value would be the same as that associated with an as yet outstanding fetch request or another instruction set then pending in the prefetch buffer 260. The prefetch control logic unit 266 directly manages a prefetch status array 268 which contains status storage locations logically corresponding to each instruction set prefetch buffer location within the MBUF 188, TBUF 190 and EBUF 192. The prefetch control logic unit 266, via selection and data lines 306, can scan, read and write data to the status register array 268. Within the array 268, a main buffer register 308 provides for storage of four, four-bit ID values (MB ID), four single-bit reserved flags (MB RES) and four εingle-bit valid flags (MB VAL) , each corresponding by logical bit-position to the respective instruction set storage locations within the MBUF 180. Similarly, a target buffer register 310 and extended buffer register 312 each provide for the storage of two four-bit ID values (TB ID, EB ID) , two single-bit reserved flags (TB RES, EB RES), and two single-bit valid flags (TB VAL, EB VAL). Finally, a flow through status register 314 provides for the storage of a single four-bit ID value (FT ID), a single reserved flag bit (FT RES), and a single valid flag' bit (FT VAL). The status register array 268 is first scanned and, as appropriate, updated by the prefetch control logic unit 266 each time ' a prefetch request is placed with the CCU 106 and subsequently scanned and updated each time an instruction set is returned. Specifically, upon receipt of the prefetch request signal via the control lines 316, the prefetch control logic unit 216 increments the current circular counter generated ID value, scans the status register array 268 to determine whether the ID value is available for use and whether a prefetch buffer location of the type specified by the prefetch request signal is available, examines the state of the CCU IBUSY control line 300 to determine whether the CCU 106 can accept a prefetch request and, if so, asserts a CCU IREAD control signal on the control line 298, and places the incremented ID value on the CCU ID out bus 294 to the CCU 106. A prefetch εtorage location is available for use where both of the corresponding reserved and valid status flags are false. The prefetch request ID is written into the ID εtorage location within the status register array 268 corresponding to the intended εtorage location within the MBUF 188, TBUF 190, or EBUF 192 concurrent with the placement of the requeεt with the CCU 106. In addition, the correεponding reserved status flag is set true. When the CCU 106 is able to return a previously requested instruction set to the IFU 102, the CCU IREADY signal is asserted on control line 302 and the corresponding instruction set ID is provided on the CCU ID control lines 296. The prefetch control logic unit 266 scans the ID values and reserved flags within the status register array 268 to identify the intended destination of the instruction set within the prefetch buffer unit 260. - Only a single match is possible. Once identified, the instruction set is written via the bus 114 into the appropriate location within the prefetch buffer unit 260 or, if identified as a flow hrough request, provided directly to the IDecode unit 262. In either case, the valid status flag in the corresponding status register array is set true. The PC logic unit 270, as will be described below in greater detail, tracks the virtual address of the MBUF 188, TBUF 190 and EBUF 192 instruction streams through the entirety of the IFU 102. In performing this function, the PC logic block 270 both controls and operates from the IDecode unit 262. Specifically, portions of the instructions decoded by the IDecode unit 262 potentially relevant to a change in the program instruction stream flow are provided on the bus 318 to a control flow detection unit 274 and directly to the PC logic block 270. The control flow detection unit 274 identifies each instruction in the decoded instruction set that constitutes a control flow instruction including conditional and unconditional branch instructions, call type instructions, software traps procedural instructions and various return instructions. The control flow detection unit 274 provides a control εignal, via lines 322, to the PC logic unit 270 to identify the location and specific nature of the .control flow instructions within the instruction set present in the IDecode unit 262. The PC logic unit 270, in turn, determines the target address of the control flow instruction, typically from data provided within the instruction and transferred to the PC logic unit via lines 318. Where, for example, a branch logic bias has been selected to execute ahead for conditional branch instructions, the PC logic unit 270 will begin to direct and separately track the prefetching of instruction sets from the conditional branch instruction target address. Thus, with the next assertion of a prefetch request on the control lines 316, the PC logic unit 270 will further assert a control signal, via lines 316, selecting the destination of the prefetch to be the TBUF 190, assuming that prior prefetch instruction sets were directed to the MBUF 188 or EBUF 192. Once the prefetch control logic unit 266 determines that a prefetch request can be supplied to the CCU 106, the prefetch control logic unit 266 provides an enabling signal, again via lines 316, to the PC logic unit 270 to enable the provision of a page offset portion of the target addresε (CCU PADDR [13:4]) via the address lines 324 directly to the. CCU 106. At the same time, the PC logic unit 270, where a new virtual to physical page translation is required further provides a VMU request signal via control line 328 and the virtualizing portion of the target address (VMU VADDR [31:14]) via the addresε lineε 326 to the VMU 108 for translation into a physical addresε. Where a page translation is not required, no operation by the VMU 108 is required. Rather, the previous translation result is maintained in an output latch coupled to the bus 122 for immediate use by the CCU 106. Operational errors in the VMU 108 in performing tbe virtual to physical translation requested by the PC logic unit 270 are reported via the VMU exception and VMU miss control lines 332, 334. The VMU miss control . lite 334 reports a .translation lookaside buffer (TLB) miss. The VMU exception control signal, on VMU exception line 332, is raised for all other exceptions. In both cases, the PC logic unit handles the error condition by storing the current execution point in the instruction stream and then prefetching, as if in response to an unconditional branch, a dedicated exception handling routine instruction stream for diagnosing and handling the error condition. The VMU exception and miss control signals identify the general nature of the exception encountered, thereby allowing the PC logic unit 270 to identify the prefetch address of a corresponding exception handling routine. The IFIFO control logic unit 272 is provided to directly support the IFIFO unit 264. Specifically, the PC logic unit 270 provides a control signal via the control lines 336 to signal the IFIFO control logic unit 272 that an instruction set is available on the input bus 198 from the IDecode unit 262. The IFIFO control unit 272 is responsible for selecting the deepest available master register 200, 208, 216, 224 for receipt of the instruction set. The output of each of tbe master control registers 202, 210, 218, 226 is provided to the IFIFO control unit 272 via the control bus 338. The control bits stored by each master control register includes a two-bit buffer address (IF_Bx_ADR), a single stream indicator bit (IF_Bx_STRM) , and a single valid bit (IF Bx VLD) . The two bit buffer addresε identifies the first valid instruction within the corresponding instruction set. That is, instruction sets returned by the CCU 106 may not be aligned έuc_T that the target instruction of a branch operation, for example, is located in the initial instruction location within the instruction set. Thus, the buffer address value is provided to uniquely identify the initial instruction within an instruction set that is to be considered for execution. The stream bit iε used essentially as a marker to identify the location of instruction sets containing conditional control flow instructions, and giving rise to potential control flow changes, in the stream of instructions through the IFIFO unit 264. The main instruction stream is processed through the MBUF 188 generally with a stream bit value of 0. On -the occurrence of a relative conditional branch instruction, for example, the corresponding instruction set is marked with a stream bit value of 1. The conditional branch instruction is detected by the IDecode unit 262. Up to four conditional control flow instructions may be present in the instruction set. The instruction set is then stored in the deepest available master register of the IFIFO unit 264. In order .to determine the target addreεε of the conditional branch inεtruction, the current IEU 104 execution point addreεε (DPC), the relative location of the conditional instruction containing instruction set as identified by the stream bit, and the conditional inεtruction location offset in the instruction set, as provided by the control flow detector 274, are combined with the relative branch offset value as obtained from a corresponding branch instruction field via control lines 318. The result is a branch target virtual addreεε that is stored by the PC logic unit 270. The initial instruction sets of the target instruction stream may then be prefetched into the TBUF 190 utilizing this address. Depending on the preselected branch bias selected for the PC logic unit 270, the IFIFO unit 264 will continue to be loaded from either the MBUF 188 or TBUF 190. If a second instruction set containing one or more conditional flow instructions is encountered, the instruction set is marked with a stream bit value of 0. Since a second target stream cannot be fetched, the target addresε is calculated and stored by the PC logic unit 270, but no prefetch iε performed. In addition, no further instruction sets can be processed through the IDecode unit 262, or at least none that are found to contain a conditional flow control instruction. The PC logic unit 270, in the preferred embodiments of the present invention, can manage up to eight conditional flow instructions occurring in up to two instruction sets. The target addresses for each of the two instruction sets marked by stream bit changes are stored in an array of four address registers with each target address positioned logically with respect to the location of the corresponding conditional flow instruction in ,the instruction set. Once the branch reεult of the firεt in-order conditional flow instruction is resolved, the PC logic unit 270 will direct the prefetch control unit 260, via control signalε on lines 316, to transfer the contents of the TBUF 190 to the MBUF 188, if the branch iε taken, and to mark invalid the contents of the TBUF 190. Any instruction sets in the IFIFO unit 264 from the incorrect instruction stream, target stream if the branch is not taken and main stream if the branch is -31- taken, are cleared from the IFIFO unit 264. If a second or subsequent conditional flow control inεtruction exists in the first stream bit marked inεtruction set, that instruction iε handled in a conεistent manner: tbe instruction setε from the target stream are prefetched, instruction setε from the MBUF 188 or TBUF 190 are processed through the IDecode unit 262 depending on the branch bias, and the IFIFO unit 264 is cleared of incorrect stream instruction sets when the conditional flow instruction finally resolves. If a secondary conditional flow instruction set remains in the IFIFO unit 264 once the IFIFO unit 264 is cleared of incorrect stream instruction sets, and the first conditional flow instruction set contains no further conditional flow instructions, the target addresses of the second stream bit marked instruction set are promoted to the first array of address registers. In any case, a next instruction set containing conditional flow instructions can then be evaluated through the IDecode unit 262. Thus, the toggle usage of the stream bit allows potential control flow changes to be marked and tracked through the IFIFO unit 264 for purposes of calculating branch target addresses and for marking the instruction set location above which .to clear where the branch bias is subsequently determined to have been incorrect for a particular conditional flow control instruction. Rather than actually clearing instruction εetε from the aεter regiεters, the IFIFO control logic unit 272 simply resetε the valid bit flag in the control registers of the corresponding master regiεters of the IFIFO unit 264. The clear operation is instigated by the PC logic unit 270 in a control signal provided on lines 336. The inputs of each of the master control regiεterε 202, 210, 218, 226 are directly accessible by the IFIFO control logic unit 272 via the status bus 230. In the preferred architecture 100, the bits within these master control regiεterε 202, 210, 218, 226 may be set by the IFIFO control unit 272 concurrent with or independent of a data εhift operation by the IFIFO unit _:64. This capability allows an instruction set to be written into any of the master registers 200, 208, 216, 224, and the corresponding status information to be written into the master control registers 202, 210, 218, 226 asynchronousl'y with respect to the operation of the IEU 104. Finally, an additional control line on the control and status bus 230 enables and directs the FIFO operation of the IFIFO unit 264. An IFIFO shift is performed by the IFIFO control logic unit 272 in response to the εhift request control signal provided by the PC logic unit 270 via the control lines 336. The IFIFO control unit 272, based on the availability of a master register 200, 208, 216, 224 to receive an instruction set provides a control signal, via lines 316, to the prefetch control unit 266 to request the transfer of a next appropriate instruction set from the prefetch buffers 260. On tranεfer of the instruction set, the corresponding valid bit in the array 268 is reset. C. TFU/IEU Control Interface: The control interface between the IFU 102 and IEU 104 is provided by the control bus 126. This control bus 126 iε coupled to the PC logic unit 270 and consists of a number of control, address and specialized data lines. Interrupt request and acknowledge control signals, as paεεed via the control lines 340, allow the IFU 102 to signal and synchronize interrupt operations with the IEU 104. An externally generated interrupt signal iε provided on a line 292 to the logic unit 270. In reεponεe, an interrupt requeεt control εignal, provided on lineε 340, causes the IEU 104 to cancel tentatively executed instructionε. Information regarding the nature of an interrupt iε exchanged via interrupt information lineε 341. When the IEU 104 iε ready to begin receiving instruction sets prefetched from the interrupt service routine address determined by the PC logic unit-'270, the IEU 104 asεertε an interrupt acknowledge control εignal on the lines 340. Execution of the interrupt service routine, as prefetched by the IFU 102, will then commence. An IFIFO read (IFIFO RD) control εignal is provided by the IEU -104 to signal that the instruction set present in the deepest master register 224 has been completely executed and that a next instruction set iε desired. Upon receipt of this control signal, the PC logic unit 270 directs the IFIFO control logic unit 272 to perform a IFIFO shift operation on the IFIFO unit 264. A PC increment request and size value (PC INC/SIZE) is provided on the control lineε 344 to direct the PC logic unit 270.. to update the current program counter value by a correεponding size number of inεtructions. This allows the PC logic unit 270 to maintain a point of execution program counter (DPC) that is precise to the location of the first in-order executing instruction in the current program instruction stream. A target address (TARGET ADDR) is returned on the addresε lines 346 to the PC logic unit 270. The target address iε the virtual target address of a branch instruction that depends on data stored within the regiεter file of the IEU 104. Operation of the IEU 104 is therefore required to calculate the target addresε. Control flow result (CF RESULT) control signals are provided on the control lines 348 to the PC logic unit 270 to identify whether any currently pending conditional branch instruction has been resolved and whether the result is either a branch taken or not taken. Based on these control signals, the PC logic unit 270 can determine which of the instruction sets in the prefetch buffer 260 and IFIFO unit 264 must h>e cancelled, if af ' all, as a consequence of the execution of the conditional flow instruction. A number of IEU instruction return type control signals (IEU Return) are provided on the control lines 350 to alert the IFU 102 to the execution of certain instructions by the IEU 104. These instructions include a return from procedural instruction, return from trap, and return from subroutine call. The return from trap instruction is used equally in hardware interrupt and software trap handling routines. The subroutine call return is also used in conjunction with jump-and-Iini type calls. In each case, the return control signals are provided to alert the IFU 102 to resume its instruction fetching operation with respect to the previously interrupted instruction stream. Origination of the signals from the IEU 104 allows the precise operation of the system 100 to be maintained; the resumption of an "interrupted" instruction streaa is performed at the point of execution of the return instruction. A current instruction execution PC address (Current IF_PC) is provided on an address bus 352 to the IEU 104. This address value, the DPC, identifies the precise instruction being executed by the IEU 104. That is. while the IEU 104 may tentatively execute ahead instructions past the current IF_PC address, this address must be maintained for purposes of precise control of the architecture 100 with respect to the occurrence of interrupts, exceptions, and any other events that would require knowing the precise state-of- the-machine. When the IEU 104 determines that the precise εtate-of-the-machine in the currently executing instruction stream can be advanced, the PC Inc/Size signal is provided to the IFU 102 and immediately reflected back in the current IF_PC address value. Finally, an address and bi-directional data bus 354 is provided for the transfer of special register data. This data may be programmed into or read from special registers within the IFU 102 by the IEU 104. Special register data is generally loaded or calculated by the IEU 104 for use by the IFU 102. PI PC Loσic Unit Detail: A detailed diagram of the PC Logic unit 270 including a PC control unit 362, interrupt control unit 363, prefetch PC control unit 364 and execution PC control unit 366, is shown in Figure 3. The PC control unit 362 provides timing control over the prefetch and execution PC .control units 364, 366 in response to control signals from the prefetch control logic unit 266, IFIFO control logic unit 272, and the IEU 104, via the interface bus 126. The Interrupt Control Unit 363 is responsible for managing the precise processing of interrupts and exceptions, including the determination of a prefetch trap addresε offset that selects an appropriate handling routine to process a respective type of trap. The prefetch PC control unit 364 is, in particular, responsible for managing program counters necessary to support the prefetch buffers 188, 190, 192, including storing return addresses for traps handling and procedural routine instruction flowε. In support of this operation, the prefetch PC control unit 364 iε responsible for generating the prefetch virtual address including the CCU PADDER address on the physical address Las lines 324 and the VMU VMADDR addresε on the addreεε lines 326. Consequently, the prefetch PC control unit 364 is responsible for maintaining the current prefetch PC virtual address value. The prefetcH operation is generally initiated by the IFIFO control logic unit 272 via a control signal provided on the control lines 316. In response, the PC control unit 362 generates a number of control signals provided on the control lines 372 to operate the prefetch PC control unit 364 to generate the PADDR and, as needed, the VMADDR addresses on the address lines 324, 326. An increment εignal, having a value of 0 to four, may be also provided on the control lines 374 depending on whether the PC control unit 362 is re- executing an instruction set fetch at the present prefetch address, aligning for the second in a series of prefetch requests, or selecting the next full sequential instruction set for prefetch. Finally, the current prefetch addresε PF_PC iε provided on the buε 370 to the execution PC control unit 366. New prefetch addreεses originate from a number of sources. A primary source of addresεes is the current IF__PC address provided from the execution PC control unit 366 via bus 352. Principally, the IF_PC addresε provides a return address for subsequent use by the prefetch PC control unit 364 when an initial call, trap or procedural instruction occurs. The IF_PC address iε stored in registers in the prefetch PC control unit 364 upon each occurrence of theεe instructions. In this manner, the PC control unit 362, on receipt of a IEU return εignal, via control lines 350, need merely select the correεponding return addreεε regiεter within the prefetch PC control unit 364 to source a new prefetch virtual addresε, thereby reεuming the original program inεtruction stream. Another source of prefetch addresses is the target address value provided on the relative target address bus 382 from the execution PC control unit 366 or on the absolute target 'address bus 346 provided from the IEU 104. Relative target addresεes are those that can be calculated by the execution PC control unit 366 directly. Absolute target addresses must be generated by the IEU 104, since such target addresses are dependant on data contained in the IEU register file. The target address is routed over the target address bus 384 to the prefetch PC control unit 364 for use as a prefetch virtual address. In calculating the relative target address, an operand portion of the corresponding branch instruction is also provided on the operand displacement portion of the bus 318 from the IDecode unit 262. Another source of prefetch virtual addresses is the execution PC control unit 366. A return address bus 352' iε provided to transfer the current IF_PC value (DPC) to the prefetch PC control unit 364. This addreεs is utilized as a return address where an interrupt, trap or other control flow instruction such aε a call has occurred within the instruction stream. The prefetch PC control unit 364 is then free to prefetch a new instruction stream. The PC control unit 362 receives an IEU return signal, via lineε 350, from the IEU 104 once the correεponding interrupt or trap handling routine or εubroutine has been executed. In turn, the PC control unit 362 selects, via one of the PFPC control εignalε on line 372 and based on an identification of the return instruction executed as provided via lines 350, a register containing the current return virtual address. This address is then used to continue the prefetch operation by the PC logic unit 270. Finally, another source of prefetch virtual addresses is from the special register address and data bus 354. An address value, or at least a base address value, calculated or loaded by the IEU 104 is transferred as data via the bus 354 to the prefetch PC control unit 364. The base addresses include the base addresses for the trap address table, a fast trap table, and a base procedural instruction dispatch table. The bus 354 also allows many of the registers in the prefetch and execution PC control units 364, 366 to be read to allow corresponding aspects of the state-of- the-machine to be manipulated through the IEU 104. The execution PC control unit 366, subject to the control of the PC control unit 362 is primarily responsible for calculating the current IF_PC addresε value. In this role, the execution PC control unit 366 responds to control signals provided by the PC control unit 362 on the ExPC control lineε 378 and increment/εize control εignals provided on the control lines 380 to adjust the IF_PC address. These control signals are generated primarily in response to the IFIFO read control εignal provided on line 342 and the PC increment/size value provided on the control lines 344 from the IEU 104. -39- 11 PF and ExPC Control/Data Unit Detail. Figure 4 provides a detailed block diagram of the prefetch and execution PC control units 364, 366. These unitε primarily conεist of registers, incrementors and the like, selectors and adder blocks. Control for managing the transfer of data between these biocks iε provided by the PC Control Unit 362 via the PFPC control lines 372, the ExPC control lines 378 and the Increment Control lines 374, 380. For purposes of clarity, those specific control lines are not shown in the block diagram of Figure 4. However, it should be understood that these control signals are provided to the blocks shown as described herein. Central to the prefetch PC control unit 364 is a prefetch selector (PF_PC SEL) 390 that operates as a central selector of the current prefetch virtual address. This current prefetch address is provided on the output bus 392 from the prefetch selector to an incrementor unit 394 to generate a next prefetch address. This next prefetch addresε is provided on the incrementor output bus 396 to a parallel array of registers MBUF PFnPC 398, TBUF PFnPC 400, and EBUF PFnPC 402. These regiεterε 398, 400, 402 effectively store the next instruction prefetch address. However, in accordance with the preferred embodiment of the present invention, separate prefetch addresεeε are held for the MBUF 188, TBUF 190, and EBUF 192. The prefetch addresses, as stored by the MBUF, TBUF and EBUF PFnPC regiεterε 398, 400, 402 are reεpectively provided by the address buseε 404, 408, 410 to the prefetch selector 390. Thuε, the PC control unit 362 can direct an immediate switch of the prefetch instruction stream merely by directing the selection, by the prefetch selector 390, of another one of the prefetch regiεters 398, 400, 402. Once that address value has been incremented by the incrementor 394, if a next instruction set in the stream is to be prefetched, the value iε returned to the appropriate one of the prefetch regiεters 398, 400, 402. Another parallel array of registers, for simplicity shown as the single special register block 412, is provided to store a number of special addresses. The register block 412 includes a trap return address register, a procedural inεtruction return address register, a procedural instruction dispatch table base address register, a trap routine dispatch table base address register, and a fast trap routine table base address register. Under the control of the PC control unit 362, these return address registers may receive the current IF_PC execution address via the bus 352'. The address values stored by the return and base address registers within the register block 412 may be both read and written independently by the IEU 104. The register are selected and values transferred via the special register address and data bus 354. A selector within the special register block 412, controlled by the PC control unit 362, allows the addresses stored by the registers of the register block 412 to be put on the special register output bus 416 to the prefetch selector 390. Return addresses are provided directly to the prefetch selector 390. Base address values are combined with the offset value provided on the interrupt offset bus 373 from the interrupt control unit 363. Once εourced to the prefetch selector 390 via the buε 373', a special address can be used as the initial address for a new prefetch instruction stream by thereafter continuing the incremental loop of the addresε through the incrementor 394 and one of the prefetch registers 398, 400, -402. Another source of addresses to the prefetch selector 390 is an array of registers within the target address register block 414. The target registers within the block 414 provide for storage of, in the preferred embodiment, eight potential branch target addresseε. Theεe eight εtorage locations logically correspond to the eight potentially executable instructions held in the lowest two master registers 216, 224 of the IFIFO unit 264. Since" ' any, and potentially all of the those instructions could be conditional branch instructions, the target register block 414 allows for their precalculated target addresses to be stored awaiting use for fetching of a target instruction stream through the TBUF 190. In particular, if a conditional branch bias iε set such that the PC Control Unit 362 immediately begins prefetching of a target instruction stream, the target address is immediately fed through the target register block 414 via the addresε buε 418 to the prefetch εelector 390. Once incremented by the incrementor 394, the addreεε iε εtored back to the TBUF PFnPC 400 for use in subsequent prefetch operations of the target instruction stream. If additional branch instructions occur within the target inεtruction stream, the target addresεes of such secondary branches are calculated and εtored in the target regiεter array 414 pending uεe upon reεolution of the firεt conditional branch instruction. A calculated target address as εtored by the target register block 414, is transferred from a target address calculation unit within the execution PC control unit 366 via the address lines 382 or from the IEU 104 via the absolute target address bus 346. The Addreεε value tranεferred through the prefetch PF_PC εelector 390 iε a full thirty-two bit .virtual address value. The page size, in the preferred embodiment of the present invention is fixed * at 16 KBytes, correεponding to the maximum page offεet addreεs value [13:0]. Therefore, a VMU page translation is not required unless there is a change in the current prefetch virtual page address [27:14]. A comparitor in the prefetch selector 390 detects this circumstance. A VMU translation request signal (VMXLAT) is provided via line 372' to the PC control unit 362 when there is a change in the virtual page address, either due incrementing across * a page boundary or a control flow branch to another page address. In turn, the PC control unit 362 directs the placement of the VH VADD addresε on lines 326, in addition to the CCU PADD on lines 324, both via a buffer unit 420, and the appropriate control signals on the VMU control lines 326, 328, 330 to obtain a VMU virtual to physical page translation. Where a psge translation is not required, the current physical page addreεs [31:14] is maintained by a latch at the output of the VMU unit 108 on the bus 122. The virtual address provided onto the bus 370 is incremented by the incrementor 394 in response to a εignal provided on the increment control line 374. The incrementor 394 incrementε by a value representing an instruction set (four instructions or sixteen bytes) in order to select a next instruction set. The low-order four bits of a prefetch address as provided to the CCD unit 106 are zero. Therefore the actual target address instruction in a first branch target instruction set may not be located in the first instruction location. However, the low-order four bits of the addresε are provided to the PC control unit 362 to allow the proper firεt branch instruction location to be known by the IFU 102. The detection and handling, by returning .-the low order bits [3:2] of a target addresε aε the ' two-bit buffer addreεε, to εelect the proper firεt inεtruction for execution in a non-aligned target instruction set, is performed only for the first prefetch of a new instruction stream, i.e., any first non-sequential instruction set address in an instruction stream. The non-aligned relationship between the address of the firεt instruction in an instruction set and the prefetch address used in prefetching the instruction set can and is thereafter ignored for the duration of the current sequential instruction εtrea . The remainder of the functional blocks shown in Figure 4 comprise the execution PC control unit 366. In accordance with the preferred embodiment of the present invention, the execution PC control unit 366 incorporates its own independently functioning program counter incrementor. Central to this function is an execution selector (DPC SEL) 430. The address output by the execution selector 430, on the addreεε bus 352', is the present execution address (DPC) of the architecture 100. This execution addreεs iε provided to an adder unit 434. The increment/size control εignalε provided on the lineε 380 specify an instruction increment value of from one to four that the adder unit 434 adds to the addresε obtained from the εelector 430. Aε the adder 432 additionally performε an output latch function, the incremented next execution address is provided on the address lineε 436 directly back to the execution εelector 430 for use in the next execution increment cycle. The initial execution addreεs and all εubεequent new stream addresses are obtained through a new stream register unit 438 via the addreεs lines 440. The new stream register unit 438 allows the new current prefetch address, as provided on the PFPC address bus 370 from the prefetch selector 390 to be passed on to the addresε bus 440 directly or εtored for subsequent use. That is, where the prefetch PC control unit 364 determines to begin prefetching at a new virtual address, the new stream address is temporarily stored by the new stream register unit 438. The PC control unit 362, by its participation in both the prefetch and execution increment cycles', " holds the new stream address in the new stream register 438 unit until the execution address has reached the program execution point corresponding to the control flow instruction that instigated the new instruction stream. The new stream address is then output from the new stream register unit 438 to the execution εelector 430 to initiate the independent generation of execution addresses in the new instruction stream. In accordance with the preferred embodiments of the present invention, the new stream register unit 438 provides for the buffering of two control flow instruction target addreεεeε. By the immediate availability of the new εtream addreεs, there iε essentially no-latency in the switching of the execution PC control unit 366 from the generation of a current sequence of execution addresεes to a new stream sequence of execution addresses. Finally, an IF_PC selector (IF__PC SEL) 442 is provided to ultimately issue the current IF_PC address on the address bus 352 to the IEU 104. The inputs to the IF_PC selector 442 are the output addresses obtained from either the execution εelector 430 or new εtream register unit 438. In most instances, the IF_PC εelector 442 iε directed by the PC control unit 362 to select the execution address output by the execution εelector 430. However, in order to further reduce latency in switching to a new virtual address used to initiate execution of a new instruction stream, the εelected address provided from the new stream register unit 438 can be bypassed via bus 440 directly to the IF_PC selector 442 for provision as the current IF__PC execution addresε. The execution PC control unit 366 iε capable of calculating all 'relative branch target addresses. The current execution point addresε and the new εtream register unit 438 provided address are received by a control flow εelector (CF_PO 446 " "via the address buses 352', 440. Consequently, the PC control unit 362 has substantial flexibility in selecting the exact initial address from which to calculate a target address. This initial, or base, address is provided via address bus 454 to a target addresε ALU 450. A second input value to the target ALU 450 is provided from a control flow displacement calculation unit 452 via buε 458. Relative branch inεtructionε, in accordance with the preferred architecture 100, incorporate a diεplacement value in the form of an immediate mode conεtant that specifies a relative new., target addresε. The control flow diεplacement calculation unit 452 receiveε the operand diεplacement value initially obtained via the IDecode unit operand output buε 318. Finally, an offεet regiεter value iε provided to the target addreεε ALU 450 via the lineε 456. The offεet regiεter 448 receiveε an offset value via the control lines 378' from the PC control unit 362. The magnitude of the offset value is determined by the PC control unit 362 based on the addresε offεet between the base address provided on the addresε lineε 454 and the addresε of the current branch inεtruction for which the relative target addresε iε being calculated. That is, the PC control unit 362, through its control of the IFIFO control logic unit 272 _. tracks the number of instructionε εeparating the instruction at the current execution point addreεε fo uested by CP_PC) and the instruction that is currently being processed by the IDecode unit 262 and, therefore, being processed by the PC logic unit 270 to determine the target address for that instruction. Once the . .relative target address has been calculated by the target address ALU 450, the target address is written into a corresponding one of the target registers 414 via the address bus 382. 2) PC Control Algorithm Detail: 1. Main Instruction Stream Processing: MBUF PFnPC 1.1 the address of the next main flow prefetch instruction is stored in the MBUF PFnPC. 1.2 in the absence of a control flow instruction, a 32 bit incrementor adjusts the address value in the MBUF PFnPC by sixteen bytes (xl6) with each prefetch cycle. 1.3 when an unconditional control flow instruction iε IDecoded, all prefetched data fetched εubsequent to the inεtruction set will be fluεhed and the MBUF PFnPC is loaded, through the target regiεter unit, PF_PC εelector and incrementor, with the new main instruction εtream addreεε. The new addreεs is also εtored in the new εtream registers. 1.3.1 the target address of a relative unconditional control flow is calculated by the IFU from regiεter -47- data maintained- by the IFU and from operand data following the control flow instruction. 1.3.2 the target address of an absolute unconditional control flow instruction is eventually calculated - by the IEU from a register reference, a baεe regiεter value, and an index register value. 1.3.2.1 instruction prefetch cycling stalls until the target addreεs is returned by the IEU for absolute address control flow instruction; instruction execution cycling continues. 1.4 the address of the next main flow prefetch instruction set, resulting from an unconditional control flow instruction, is bypassed through the target address register unit, PF__PC selector and incrementor and routed for eventual εtorage in the MBUF PFnPC; prefetching continueε at 1.2. 2. Procedural Instruction Stream Procesεing: EBUF PFnPC 2.1 a procedural instruction may be prefetched in the main or branch target instruction stream. If fetched in a target stream, stall prefetching of the procedural stream until the conditional control flow instruction resolves and the procedural instruction is transferred to the MBUF. This allows the TBUF to be used in handling of conditional control flows that occur in the procedural instruction stream. 2.1.1 a procedural instruction should not appear in a procedural instruction stream, i.e. , procedural instructions should not be nested: a return from procedural instruction will return execution to the main ' instruction flow. In order to allow nesting, an additional, dedicated return from nested procedural instruction would be required. While the architecture can readily support such an instruction, the need for a nested procedural instruction capability will not likely improve the performance of the architecture. 2.1.2 in a main instruction εtrean, a procedural instruction εtream that, in turn, includes firεt and second conditional control flow instruction containing instruction setε will stall prefetching with respect to the second conditional control flow instruction set until any conditional control flow instructions in the first such instruction set are reεolved and the second conditional control flow instruction set has been transferred to the MBUF. 2.2 procedural instructions provide a relative offεet, included as an immediate mode operand field of the instruction, to identify the procedural routine starting address: 2.2.1 the offset value provided by the procedural inεtruction is combined with a value contained* ' in a procedural base address (PBR) register maintained in the IFU. This PBR regiεter iε readable and writable via the εpecial addreεε and data buε in response to the execution of a special regiεter move instruction. 2.3 when a.-procedural instruction is encountered, the next main instruction stream IF_PC address is stored in the uPC return address register and the procedure-in-progresε bit in the proceεεor εtatus register (PSR) is set. 2.4 the starting address of the procedural stream is routed from the PBR regiεter (plus the procedural inεtruction operand offεet value) to the PF_PC εelector. 2.5 the εtarting address of the procedural stream is εimultaneouεly provided to the new εtream regiεter unit and to the incrementor for incrementing (xl6); the incremented addreεε is then stored in the EBUF PFnPC. 2.6 in the absence of a control flow instruction, a 32 bit incrementor adjusts addresε value (xl6) in the EBUF PFnPC with each procedural instruction prefetch cycle. 2.7 when an unconditional control flow instruction is IDecoded, all prefetched data fetched subsequent to the branch instruction will be flushed and the EBUF PFnPC is loaded with the new procedural instruction εtream addresε. 2.7.1 the target addresε of a relative unconditional control , flow instruction is calculated by the IFU from IFU maintained register data and from the operand data provided within an immediate mode operand field of the control flow instruction. 2.7.2 the target address of an absolute unconditional branch is calculated by the IEU from a register reference, a base regiεter value, and an index register value. 2.7.2.1 instruction prefetch cycling stalls until the target address is returned by the IEU for absolute address branches; execution cycling continues. 2.S the addreεs of the next procedural flow prefetch instruction set iε εtored in the EBUF PFnPC and prefetching continues at 1.2. 2.9 when a return from procedure inεtruction is IDecoded, prefetching continues from the addresε εtored in the uPC regiεter, which iε then, incremented (xlδ) and returned to the MBUF PFnPC regiεter for εubεequent prefetcheε . Branch Instruction Stream Procesεing: TBUF PFnPC 3.1 when a conditional control flow inεtruction, occurring in a first instruction set in the MBUF instruction stream, is IDecoded, the target address is determined by the IFU if the target address iε relative to the current addresε or by the IEU for absolute addresεeε. 3.2 for "branch taken bias":. 3.2.1 if the branch is to an absolute addreεs, stall instruction prefetch cycling until the target address is returned by the IEU; execution cycling continues. 3.2.2 load the TBUF PFnPC with the branch target addresε by tranεfer through the PF_PC εelector and incrementor. 3.2.3 target inεtruction εtream instructions are prefetched into the TBUF and then routed into the IFIFO for subsequent execution; if the IFIFO and TBUF becomes full, stall prefetching. 3.2.4 the 32 bit incrementor adjusts (xl6) the address value in the TBUF PFnPC with each prefetch cycle. 3.2.5 stall the prefetch operation on IDecode of a conditional control flow instruction, occurring in a εecond inεtruction εet in the target inεtruction stream until the all conditional branch inεtructions in the first (primary) set are resolved (but go ahead and calculate the relative target addresε and εtore in target regiεterε). 3.2.6 if conditional branch in the firεt instruction set resolveε to "taken": 3.2.6.1 fluεh instruction sets following the first conditional 5 flow instruction εet in the MBUF or EBUF, if the source of the branch was the EBUF instruction εtream as determined from the procedure- 10 in-progresε bit. 3.-2.6.2 transfer the TBUF PFnPC value to MBUF PFnPC or EBUF based on the state of the procedure-in- progress bit. 15 3.2.6.3 transfer the prefetched TBUF instructions to the MBUF or EBUF baεed on the state of procedure-in-progress bit. 3.2.6.4 if a second conditional branch 20 instruction set has not been IDecoded, continue MBUF or EBUF prefetching operations based on the state of the procedure-in- progress bit. 25 .3.2.6.5 if a second conditional branch instruction has been IDecoded, begin processing that instruction (go to step 3.3.1). 3.2.7 if the conditional control for 30 inεtruction(ε) in the firεt conditional inεtruction εet reεolveε to "not taken" : 3.2.7.1 flush the IFIFO and IEU of inεtruction sets and instructions from the target instruction εtream. 3.2.7.2 continue MBUF or EBDF prefetching operations. 3.3 for "branch not taken bias": 3.3..1 stall prefetch of instructionε into the MBUF; execution cycling continues. 3.3.1.1 if the conditional control flow instruction in the first conditional inεtruction set is relative, calculate the target addreεs and store in the target registers. 3.3.1.2 if the conditional control flow instructions in the first conditional instruction set is absolute, wait for the IEU to calculate the target address and return the address to the target registerε. 3.3.1.3 stall the prefetch operation on IDecode of a conditional control flow instruction in a second instruction set until the conditional control flow instructions) in the first conditional instruction set instruction is resolved. 3.3.2 once the target addresε of the first conditional branch is calculated, load into TBUF PFnPC and also begin prefetching instructions into the TBUF concurrent with execution of the main instruction stream. Target inεtruction εetε are not loaded into the IFIFO (the branch target instructions are thus on hand when 5 each conditional control flow instruction in the first instruction εet resolves) . 3.3.3 if a conditional control flow instruction in the firεt εet 10 resolves to "taken": 3.-3.3.1 fluεh the MBUF or EBUF, if the εource of the branch was the EBUF instruction stream, aε determined from the state of 15 the procedure-in-progress bit, and the IFIFO and IEU of instructions from the main stream following the first conditional branch inεtruction 20 set. 3.3.3.2 transfer the TBUF PFnPC value to MBUF PFnPC or EBUF, as determined from the state of the procedure-in-progress bit. 25 , 3.3.3.3 transfer the prefetched TBUF inεtructions to the MBUF or EBUF, as determined from the state of the procedure-in- progress bit. 30 3.3.3.4 continue MBUF or EBUF prefetching operations, as determined from the state of the procedure-in-progress bit. 3.3.4 if a conditional control flow instruction in the firεt set resolves to "not taken": 3.3.4.1 fluεh the TBUF of instruction sets from the target instruction stream. 3.3.4.2 if a second conditional branch instruction has not been IDecoded, continue MBUF or EBUF, as determined from the s t a t e o f t h e procedure-in-progress bit, prefetching operations. 3.3.4.3 if a second conditional branch instruction has been IDecoded, begin proceεεing that inεtruction (go to εtep 3.4.1). 4. Interrupts, Exceptions and Trap Instructions. 4.1 Traps generically include: 4.1.1 Hardware Interrupts. 4.1.1.1 asynchronouεly (external) occurring eventε, internal or external. 4.1.1.2 can occur at any time and perεiεt. 4.1.1.3 serviced in priority order between atomic (ordinary) instructionε and may εuspend procedural instructions. 4.1.1.4 the starting addresε of an interrupt handler is determined as the vector number offset into a predefined table of trap handler entry points. 4.1.2 Software Trap Instructionε. 4.1.2.1 εynchronouεly (internal) _ occurring inεtructionε. 4.1.2.2 a software instruction that executes as an exception. 4.1.2.3 the εtarting address of the trap handler is determined from 0 the trap number offεet combined with a baεe addreεε value εtored in the TBR or FTB register. 4.1.3 Exceptions. 4.1.3.1 Events occurring synchronously with an instruction. 4.1.3.2 handled at the time the instruction is executed. 4.1.3.3 due to consequences of the exception, the excepted instruction and all subεequent executed instructions are cancelled. 4.1.3.4 the starting addreεs of the exception handler is determined from the trap number offεet into a predefined table of trap handler entry point. 4.2 Trap instruction εtream operations occur in- line with the then currently executing instruction εtream. 4.3 Trapε may neεt, provided the trap handling routine εaveε the xPC addreεε prior to a next allowed trap — failure to do εo will corrupt the state of the machine if a trap occurε prior to completion of the current trap operation. 5. Trap Inεtruction Stream Proceεsing: xPC. 5.1 when a trap is encountered: 5.1.1 if an asynchronous interrupt, the execution of the currently executing instruction(s) is suεpended. 5.1.2 if a εynchronouε exception, the trap is processed upon execution of the excepted instruction. 5.2 when a trap is processed: 5.2.1 interrupts are disabled. 5.2.2 the current IF_PC addresε is stored in the xPC trap state return addresε register. 5.2.3 the IFIFO and the MBUF prefetch buffers at and subεequent to the IF_PC address are flushed. 5.2.4 executed instructions at and subsequent to the address IF_PC and the resultε of thoεe instructions are flushed from the IEU. 5.2.5 the MBUF PFnPC is loaded with the address of the trap handler routine. 5.2.5.1 source of a trap address either the TBR or FTB register, depending on the type of trap as determined by the trap number, which are provided in the εet of εpecial regiεterε. 5.2.6 instructions are prefetched and dropped into the IFIFO for execution in a normal manner. 5.2.7 the instructions of the trap routine are then executed. 5.2.7.1 the trap handling routine may provide for the xPC address to be saved to a predefined location and interrupts re-enabled; the xPC register is read/write via a special register move instruction and the special register addresε and data bus. 5.2.8 the trap state must be exited by the execution of a return from trap instruction. 5.2.8.1 if prior saved, the xPC addresε must be restored from its predefined location before executing the return from trap instruction. 5.3 when a return from trap iε executed: 5.3.1 interrupts are enabled. 5.3.2 the xPC address is returned to the current inεtruction εtream regiεter MBUF or EBUF PFnPC, as determined from the state of the procedure-in-progresε bit, and prefetching continues from that addreεs. 5.3.3 the xPC address iε restored to the IF_PC register through the new εtream regiεter. -59- E. Interrupt and Exception Handling: I ) Overview: Interrupts and exception.* will be proceεsed, aε long as they are enabled, regardleεε of whether the proceεsor is executing from the main inεtruction εtream or a procedural instruction stream. Interruptε and exceptions are εerviced in priority order, and perεiεt until cleared. The εtarting address of a trap handler is determined as the vector number offset into a predefined table of trap handler addresεeε aε described below. Interrupts and exceptions are of two basic types in the present embodiment, those which occur synchronously with particular instructionε in the inεtruction εtream, and those which occur asynchronously with particular inεtructionε in the inεtruction εtream. The terms interrupt, exception, trap and fault are used interchangeably herein. Asynchronous interrupts are generated by hardware, either on-chip or off-chip, which does not operate synchronously with the instruction εtream. For example, interrupts generated by an on- chip timer/counter are asynchronouε, aε are hardware interruptε and non-maεkable interrupts (NMI) provided from off-chip. When an asynchronouε interrupt occurs, the procesεor context iε frozen, all trapε are diεabled, certain procesεor εtatuε information is stored, and the processor vectors to an interrupt handler corresponding to the particular interrupt received. After the interrupt handler completes its proceεεing, prograjn execution continues with the instruction following the last completed instruction in the stream which was executing when the interrupt occurred. Synchronous exceptions are those that occur synchronously with instructions in the instruction εtream. These exceptionε occur in relation to particular inεtructionε, and are held until the relevant instruction iε to be executed. In the preferred embodiments, synchronouε exceptionε arise during prefetch, during instruction decode, or during instruction execution. Prefetch exceptions include, for example, TLB miss or other VMU exceptions. Decode exceptions arise, for example, if the instruction being decoded is an illegal instruction or does not match the current privilege level of the processor. Execution exceptions arise due to arithmetic errors, for example, such as divide by zero. Whenever these exceptions occur, the preferred embodiments maintain them in correspondence with the particular instruction which caused the exception, until the time at which that instruction is to be retired. At that time, all prior completed instructions are retired, any tentative results from the instruction which caused the exception are flushed, as are the tentative results of any following tentatively executed instructions. Control iε then transferred to an exception handler corresponding to the highest priority exception which occurred for that instruction. Software trap inεtructions are detected at the IDecode stage by CF__DET 274 (Fig. 2) and are handled similarly to both unconditional call instructions and other synchronous traps. That is, a target address is calculated and prefetch continues to the then-current prefetch queue (EBUF or MBUF). At the same time, the exception iε alεo noted in correεpondence with the instruction and is handled when the instruction is to be retired. All other types of synchronous exceptions are merely noted and accumulated in correspondence with the particular instruction which caused it and are handled at execution time. 2 ) Asynchronous Interrupts: Asynchronous interrupts are signaled to the PC logic unit 270 over interrupt lines 292. As shown in Figure 3, these lines are provided to the interrupt logic unit 363 ' in the PC logic unit 270, and comprise an NMI line, an IRQ line and a set of interrupt level lines (LVL) . The NMI line signals a non-maskable interrupt, and derives from an external source. It iε the highest priority interrupt except for hardware reset. The IRQ . line alεo deriveε from an external εource, and indicates when an external device iε requeεting a hardware interrupt. The preferred e bodimentε permit up to 32 user-defined externally εupplied hardware interruptε and the particular external device requeεting the interrupt provides the number of the interrupt (0-31) on the interrupt level lines (LVL). The memory error line is activated by the MCU 110 to εignal variouε kinds of memory errors. Other asynchronous interrupt lineε (not shown) are alεo provided to the interrupt logic unit 363, including lineε for requesting a timer/counter interrupt, a memory I/O error interrupt, a machine check interrupt and a performance monitor interrupt. Each of the asynchronous interrupts, as well as the synchronouε exceptionε deεcribed below, have a correεponάing predetermined trap number aεεociated with them, 32 of these trap numbers being associated with the 32 available hardware interrupt levels. A table of these trap numbers iε maintained in the interrupt logic unit 363. The higher the trap number, in general, the higher the priority of the trap. When one of the asynchronous interrupts is signaled to the interrupt logic unit 363, the interrupt control unit 363 εends out an interrupt request to the IEU 104 over INT REQ/ACK lines 340. Interrupt control unit 363 also εends a εuεpend prefetch εignal to PC control unit 362 over lines 343, causing the PC control unit 262 to t-tcp prefetching instructions. The IEU 104 either cancels all then-executing instructions, and flushing all tentative results, or it may allow some or all instructions to complete. In the preferred embodiments, any then-executing instructions are canceled, thereby permitting the fastest response to asynchronous interrupts. In any event, the DPC in the execution PC control unit 366 is updated .to correspond to the last instruction which has been completed and retired, before the IEU 104 acknowledges the interrupt. All other prefetched instructions in MBUF, EBUF, TBUF and IFIFO 264 are also cancelled. Only when the IEU 104 is ready to receive instructions from an interrupt handler does it εend an interrupt acknowledge εignal on INT REQ/ACK lines 340 back to the interrupt control unit 363. The interrupt control unit 363 then dispatches to the appropriate trap handler as described below. 3 * . Synchronous Exceptions: For synchronous exceptions, the interrupt control unit 363 maintains a εet of four internal exception bits (not shown) for each instruction εet, one bit corresponding to each inεtruction in the εet. The interrupt control unit 363 also maintains an indication of the particular trap numbers, if any detected for each instruction. If the VMU signalε a TLB miss or another VMU exception while a particular instruction εet iε being prefetched, thiε information iε transmitted to the PC logic unit 270, and in particular to the interrupt control unit 363, over the VMU control lines 332 and 334. When the interrupt control unit 363 receiveε such a signal, it εignalε the PC control unit 362 over line 343 to εuεpend further prefetcheε. At the same time, the interrupt control unit 363 sets the VM__Misε or VM_Excp bit, aε appropriate, associated the prefetch buffer to which the instruction set was destined. The interrupt control unit 363 then setε all four internal exception indicator bits corresponding to that instruction εet, since none of the instructionε in the εet are valid, and stores the trap number for the particular exception received in correspondence with each of the four instructions in the faulty instruction set. The εhifting and executing of inεtructions prior to the faulty instruction set then continues as usual until the faulty εet reaches the lowest level in the IFIFO 264. Similarly, if other synchronouε exceptionε are detected during the εhifting of an instruction through the prefetch buffers 260, the IDecode unit 262 or the IFIFO 264, this information is also transmitted to the interrupt control unit 363 which sets the internal exception indicator bit corresponding to the instruction generating the exception and stores the trap number in correεpondence with that exception. Aε with prefetch synchronouε exceptions, the shifting and executing of instructions prior to the faulty inεtruction then continues as usual until the faulty set reaches the lowest level in the IFIFO 264. In the preferred embodiments, the only type of exception which is detected during the shifting of an instruction through the prefetch buffers 260, the . -64- IDecode unit 262 or the IFIFO 264 is a software trap instruction. Software trap instructions are detected at the IDecode stage by CF__DET unit 274. While ' in some embodiments other forms of synchronous exceptions may be detected in the IDecode unit 262, it is preferred that the detection of any other synchronous exceptions wait until the instruction reaches the execution unit 104. This avoids the possibility that certain exceptions, such as arising from the handling of privileged instruction, might be signaled on the basis of a processor state which could change before the effective in-order-execution of the inεtruction. Exceptions which do not depend on the procesεor εtate, εuch as illegal instruction, could be detected in the IDecode stage, but hardware is minimized if the same logic detects all pre- execution synchronous exceptionε (apart from VMU exceptions). Nor iε there any time penalty imposed by waiting until instructions reach the execution unit 104, since the handling of such exceptions is rarely time critical. As mentioned, software trap instructions are detected at the IDecode stage by the CF_DET unit 274. The internal exception indicator bit corresponding to that instruction in the interrupt logic unit 363 is set and the software trap number, which can be any number from 0 to 127 and which is specified in an immediate mode operand field of the software trap instruction, is εtored in correεpondence with the trap instruction. Unlike prefetch synchronous exceptions, however, since software traps are treated as both a control flow instruction and as a synchronous exception, the interrupt control unit 363 does not signal PC control unit 362 to suspend prefetches when a software trap instruction iε detected. Rather, at the εame time the inεtruction iε shifting through the IFIFO 264, the IFU 102 prefetches the trap handler into the MBUF instruction εtream buffer. When an inεtruction εet reacheε the loweεt level of the IFIFO 264, the interrupt logic unit 363 tranεmits the exception indicator bits for that instruction εet as a 4-bit vector to the IEU 104 over the SYNCH_INT_INFO lines 341 to indicate which, if any, of the instructions in the inεtruction εet have already been determined to be the source of a synchronous exception. The IEU 104 does not respond.immediately, but rather permits all the instructions in the inεtruction set to be scheduled in the normal course. Further exceptions, such as integer arithmetic exceptions, may be generated during execution. Exceptions which depend on the current state of the machine, such as due to the execution of a privileged instruction, are also detected at this time, and in order to ensure that the εtate of the machine is current with respect to all previous instructions in the instruction stream, all instructions which have a possibility of affecting the PSR (such as special move and returns from trap instructions) are forced to execute in order. Only when an instruction that is the source of a εynchronouε exception of any εort iε about to be retired., iε the occurrence of the exception signaled to the interrupt logic unit 363. The IEU 104 retires all instructionε which have been tentatively executed and which occur in the instruction εtream prior to the first instruction which has a synchronous exception, and flusheε the tentative results from any tentatively executed instructionε which occur εubεequently in the instruction stream. The particular instruction that caused the exception iε also flushed since that instruction will typically be re- executed upon return from trap. The IF_PC in the execution PC control unit 366 iε then updated to correspond to the last instruction actually retired, and the before any exception is εignaled to the interrupt control unit 363. When the instruction that iε the source of an exception is retired, the IEU 104 returns to the interrupt logic unit 363, over the SYNCH_INT_INFO lines 341, both a new 4-bit vector indicating which, if any, inεtructionε in the retiring instruction set (register 224) had a synchronous exception, as well as information indicating the source of the firεt exception in the instruction set. The information in the 4-bit exception vector returned by IEU 104 is an accumulation of the 4-bit exception vectors provided to the IEU 104 by the interrupt logic unit 363, as well as exceptions generated in the IEU 104. The remainder of the information returned from the IEU 104 to interrupt control unit 363, together with any information already stored in the interrupt control unit 363 due to exceptions detected on prefetch or IDecode, is sufficient for the interrupt control unit 363 to determine the nature of the highest priority synchronouε exception and itε trap number. 41 Handler Dispatch and Return: After an interrupt acknowledge εignal iε received over lineε 340 from the IEU, or after a non-zero exception vector iε received over lines 341, the current DPC iε temporarily εtored aε a return addreεs in an xPC register, which is one of the special regiεters 412 (Figure 4). The current procesεor εtatus regiεter (PSR) is also εtored in a previous PSR (PPSR) register, and the current compare εtate regiεter (CSR) iε εaved in a prior compare state register (PCSR) in the special registers 412. The addresε of a trap handler iε calculated aε a trap base register addresε pluε an offεet. The PC logic unit 270 maintains two baεe registers for traps, both of which are part of the special registerε 412 (Figure 4), and both of which are initialized by special move instructions executed previously. For most traps, the base register used to calculate the addreεε of the handler iε a trap base register TBR. The interrupt control unit 363 determines the highest priority interrupt or exception currently pending and, through a look-up table, determines the trap number asεociated therewith. Thiε iε provided over a set of INTJDFFSET lines 373 to the prefetch PC control unit 364 as an offset to the selected base register. Advantageously, the vector addreεε is calculated by merely concatenating the offset bits aε low-order bits to the higher order bitε obtained from the TBR regiεter. This avoids any need for the delays of an adder. (As used herein, the 2 1 bit is referred to as the i'th order bit.) For example, if traps are numbered from 0 through 255, repreεented aε an 8 bit value, the handler address may be calculated by concatenating the 8 bit trap number to the end of a 22-bit TBR stored value. Two low-order zero bits may be appended to the trap number to ensure that the trap handler addreεε alwayε occurε on a word boundary. The concatenated handler addreεε thus constructed is provided as one of the inputs, 373; to the prefetch εelector PF_PC Sel 390 (Figure 4), and is εelected aε the next addreεε from which inεtructionε are to be prefetched. The vector handler addreεε for trapε uεing the TBR register are all only one word apart. Thus, the inεtruction at the trap handler address must be a preliminary branch instruction to a longer trap handling routine. Certain traps require very careful handling, however, to prevent degradation of εyεtem performance, TLB trapε, for example, muεt be executed very quickly. For this reason, the preferred embodiments include a fast trap mechanism deεigned to allow the calling of εmall trap handlerε without the coεt of this preliminary branch. In addition, fast trap handlers can be located independently in memory, in on-chip ROM, for example, to eliminate memory.- system penalties associated with RAM locations. In the preferred embodiments, the only traps which result in fast traps are the VH exceptions mentioned above. Fast traps are numbered separately from other traps, and have a range from 0 tc 7. However, they have the same priority as MHU exceptions. When the interrupt control unit 363 recognizes a fast trap aε the highest priority trap then pending, it causes a fast trap base register (FTB) to be selected from the special registerε 412 and provided on the lines 416 to be combined with the trap offset. The resulting vector addresε provided to the prefetch εelector PF_PC Sel 390, via lines 373', is then a concatenation of the high-order 22 bits from the FTB register, followed by three bits representing the fast trap number, followed by seven bits of 0's. Thus, each faεt trap addreεε is 128 bytes, or 32 words apart. When called, the procesεor brancheε to the εtarting word and may execute programs within the block or branch out of it. Execution of εmall programs, such as standard TLB handling routines which may be implemented in 32 instructions or less, is faster than ordinary traps because the preliminary branch to the actual exception handling routine iε obviated. It εhould be noted that although all inεtructionε have the same length of 4 bytes (i.e., occupy four addresε locationε) in the preferred embodimentε, it εhould be noted that the fast trap mechanism iέ alεo useful in microprocessors whose instructions are variable in length. In this case, it will be appreciated that the fast trap vector addresseε be εeparated by enough εpace to accommodate at leaεt two of the εhorteεt instructions available on the microprocesεor, and preferably about 32 average-sized instructions. Certainly, if the microprocesεor includeε a return from trap inεtruction, the vector addresseε εhould be εeparated by at leaεt enough space to permit that instruction to be preceded by at least one other inεtruction in the handler. Also on dispatch to a trap handler, the procesεor enters both a kernel mode and an interrupted εtate. Concurrently, a copy of the compare εtate regiεter (CSR) iε placed in the prior carry εtate regiεter (PCSR) and a copy of the PSR iε εtored in the prior PSR (PPSR) regiεter. The kernel and interrupted εtateε modeε are repreεented by bits in the procesεor status register (PSR) . Whenever the interrupted_state bit in the current PSR is set, the εhadow registers or trap registers RT[24] through RT[31], as described above and as shown in Figure 7b, become visible. The interrupt handler may εwitch out of kernel mode merely by writing a new mode into the PSR, but the only way to leave the interrupted εtate iε by executing a return from trap (RTT) inεtruction. When the IEU 104 executeε an RTT instruction, PCSR is restored to CSR register and PPSR register is reεtored to the PSR register, thereby automatically clearing the interrupt_εtate bit in the PSR regiεter. -70- The PF__PC SEL εelector 390 alεo εelectε εpecial register xPC in the εpecial regiεter εet 412 as the next / address from which to prefetch. xPC iε reεtored to either the MBUF PFnPC or the EBUF PFnPC aε appropriate, via incrementor 394 and bus 396. The decision aε to whether to restore xPC into the EBUF or MBUF PFnPC is made according to the "procedure_in_j?rogresε" bit of the PSR, once restored. It εhould be noted that the proceεεor does not use the same special register xPC to εtore the return addreεε for both -traps and procedural instructions. The return address for a trap is stored in the special register xPC, as mentioned, but the addresε to return to after a procedural instruction is εtored in a different εpecial register, uPC. Thus, the interrupted εtate remains available even while the procesεor iε executing an emulation εtream invoked by a procedural inεtruction. On the other hand, exception handling routineε εhould not include any procedural instructions since there is no special regiεter to store an address for return to the exception handler after the emulation εtream is complete. 5. Nesting: Although certain proceεεor status information is. . automatically backed up on diεpatch to a trap handler, in particular CSR, PSR, the return PC, and in a sense the "A" register εet ra[24] through ra[31], other context information iε not protected. For example, the contentε of a floating point εtatus register (FSR) iε not automatically backed up. If a trap handler intends to alter these registers, it must perform its own backup. Because of the limited backup which is performed automatically on a diεpatch to a trap handler, nesting -71- of traps iε not automatically permitted. A trap handler εhould back up any desired registers, clear any interrupt condition, read any information necessary for handling the trap from the εyεtem regiεters and process it as appropriate. Interrupts are automatically disabled upon dispatch to the trap handler. After processing, the handler can then restore the backed up registers, re-enable interrupts and execute the RTT instruction to return from the interrupt. If nested traps are to be allowed, the trap handler εhould be divided into firεt and εecond portions. In the first portion, while interrupts are disabled, the xPC εhould be copied, uεing a εpecial regiεter move instruction, and pushed onto the stack maintained by the trap handler. The addresε of the beginning of the εecond portion of the trap handler should then be moved uεing the εpecial regiεter move instruction into the xPC, and a return from trap instruction (RTT) executed. The RTT removes the interrupted state (via the restoration of PPSR into PSR) and transferε control to the addreεs in the xPC, which now contains the addresε of the εecond portion of the handler. The εecond portion may enable interruptε at this point and continue to process the exception in an interruptable mode. It should be noted that the shadow registerε RT[24] through RT[31] are visible only in the firεt portion of this handler, and not in the second portion. Thus, in the second portion, the handler εhould preεerve any of the "A" regiεter valueε where theεe regiεter valueε are likely to be altered by the handler. When the trap handling procedure iε finiεhed, it εhould reεtore all backed up regiεterε, pop the original xPC off the trap handler εtack and move it back into the xPC εpecial regiεter using a εpecial register move inεtruction, and -72- execute another RTT. Thiε returns control to the appropriate inεtruction in the main or emulation instruction εtream. 6. List of Traps: The following Table I sets forth the trap numbers, priorities and handling modes of traps which are recognized in the preferred embodiments: -73- III. Instruction Execution Unit: The combined control and data path portions of IEU 104 are shown in Figure 5. The primary data path begins with the instruction/operand data bus 124 from the IFU 102. As a data bus, immediate operands are provided to an operand alignment unit 470 and passed on to a register file (REG ARRAY) 472. Register data is provided from the regiεter file 472 through a bypaεε unit 474, via a register file output bus 476, to a parallel array of functional computing elements (FU^) 478 o- r .' via a distribution bus 480. Data generated by the functional units 478 0 _ n is provided back to the bypasε unit 474 or the register array 472, or both, via an output bus 482. A load/store unit 484 completes the data path portion of the IEU 104. The load/store unit 484 is responsible for managing the transfer of data between the IEU 104 and CCU 106. Specifically, load data obtained from the data cache 134 of the CCU 106 is transferred by the load/store unit 484 to an input of the register array 472 via a load data bus 486. Data to be stored to the data cache 134 of the CCU 106 iε received from the functional unit distribution bus 480. The control path portion of the IEU 104 is responεible for iεεuing, managing, and completing the proceεεing of information through the IED data path. In the preferred embodimentε of the present invention the IEU control path iε capable of managing the concurrent execution of multiple inεtructions and the IEU data path provides for multiple independent data transfers between esεentially all data path elementε of the IEU 104. The IEU control path operates in response to instructions received via the instruction/operand bus 124. Specifically, inεtruction sets are received by the -74- EDecode unit 490. In the preferred embodiments of the present invention, the EDecode 490 receiveε and decodes both instruction sets held by the IFIFO master registers 216, 224. The resultε of the decoding of all eight instructions is variously provided to a carry checker (CRY CHKR) unit 492, dependency checker (DEP CHKR) unit 494, register renaming unit (REG RENAME) 496, instruction issuer (ISSUER) unit 498 and retirement control unit (RETIRE CTL) 500. The carry checker unit 492 receives decoded information about the eight pending instructions from the EDecode unit 490 via control lines 502. The function of the carry checker 492 is to identify those ones of the pending instructionε that either affect the carry bit of the proceεsor status word or are dependent on the state of the carry bit. This control information is provided via control lines 504 to the instruction isεuer unit 498. Decoded information identifying the regiεters of the regiεter file 472 that are uεed by the eight pending instructions as provided directly to the regiεter renaming unit 496 via control lines 506. This information is also provided to the dependency checker unit 494. The function of the dependency checker unit 494 is to determine which of the pending instructionε reference regiεterε as the destination for data and which instructions, if any, are dependant on any of those destination registerε. Those instructions that have register dependencies are identified by control εignalε provided via the control lines 508 to the register rename unit 496. Finally, the EDecode unit 490 provides control information identifying the particular nature and function of each of the eight pending instructions to -75- the inεtruction issuer unit 498 via control lineε 510. The issuer unit 498 is responsible for determining the data path resourceε, particularly of the availability of particular functional units, for the execution of Ξ pending inεtructionε. In accordance with the preferred embodimentε of the architecture 100, instruction isεuer unit 498 allowε for the out-of-order execution of any of the eight pending inεtructionε subject to the availability of data path resources and carry and 0 regiεter dependency constraints. The register rename unit 496 provideε the instruction iεεuing unit 498 with a bit map, via control lines 512 of those instructions that are suitably unconstrained to allow execution. Instructions that have already been executed (done) and 5 those with regiεter or carry dependencieε are logically removed from the bit map. Depending on the availability of required functional units 78^, the instruction isεuer unit 498 may initiate the execution of multiple instructions during each εyεtem clock cycle. The status of the functional units 78^ are provided via a status bus 514 to the instruction isεuer unit 498. Control εignalε for initiating, and εubεequently managing the execution of inεtructionε are provided by the inεtruction iεεuer unit 498 on the control lines 516 to the register rename unit 496 and selectively to the functional units 78^. In reεponεe, the regiεter rename unit 496 provideε regiεter εelection signals on a register file access control bus 518. The specific registers enabled via the control signals provided on the buε 518 are determined by the εelection of the inεtruction being executed and by the determination by the regiεter rename unit 496 of the regiεterε referenced by that particular inεtruction. A bypaεs control unit (BYPASS. CTL) 520 generally controls the operation of the bypass data routing unit 474 via control signals on control lines 524. The bypass control unit 520 monitors the εtatus of each of the functional units 478,^ and, in conjunction with the register references provided from the register rename unit 496 via control lines 522, determines whether data is to be routed from the regiεter file 472 to the functional unitε 478^ or whether data being produced by the functional unitε 478^ can be immediately routed via the bypaεs unit 4-74 to the functional unit diεtribution bus 480 for uεe in the execution of a newly iεsued instruction selected by the instruction isεuer unit 498. In either case, the instruction issuer unit 498 directly controls the routing of data from the diεtribution bus 480 to the functional units 478,^, by selectively enabling εpecific regiεter data to each of the functional unitε 478^. The remaining units of the IEU control path include a retirement control unit 500, a control flow control (CF CT1) unit 528, and a done control (DONE CTL) unit 536. The retirement control unit 500 operates to void or confirm the execution of out-of-order executed instructions. Where an instruction has been executed out-of-order, .that instruction can be confirmed or retired once all prior instructions have also been retired. Based on an identification of which of the current εet of eight pending inεtructionε have been executed provided on the control lineε 532, the retirement control unit 500 provides control εignalε on control lines 534 coupled to the bus 518 to effectively confirm the result data εtored by the regiεter array 472 aε the reεult of the prior execution of an out-of-order executed instruction. The retirement control unit 500 provideε the PC increment/size control signals on control lines 344 to the IFU 102 aε it retires each inεtruction. Since multiple instructions may be executed out-of-order, and therefore ready for εimultaneouε retirement, the retirement control unit 500 determineε a εize value ]__•___. on the number of inεtructions simultaneously retired. Finally, where all inεtructionε of the IFIFO master register 224 have been executed and retired, the retirement control unit 500 provides the IFIFO read control signal on the control line 342 to the IFU 102 to initiate an IFIFO unit 264 εhift operation, thereby providing the EDecode unit 490 with an additional four instructionε as instructions pending execution. The control flow control unit 528 performs the somewhat more specific function of detecting the logical branch result of each conditional branch instruction. The control flow control unit 528 receives an 8 bit vector identification of the currently pending conditional branch instructions from the EDecode unit 490 via the control lines 510. An 8 bit vector inεtruction done control εignal iε similarly received via the control lines 538 from the done control unit 540. This done control εignal allows the control flow control unit 5 8 to identify when a conditional branch instruction iε done at leaεt to a point sufficient to determine a conditional control flow status. The control flow status result for the pending conditional branch inεtructionε are εtored by the control flow control unit 528 aε they are executed. The data neceεεary to determine the conditional control flow inεtruction outcome iε obtained from temporary εtatuε registers in the register array 472 via the control lineε 530. Aε each conditional control flow instruction iε executed, the control flow control unit provideε a new control flow reεult εignal on the control lineε 348 to the IFU 102. This control flow result εignal preferably includes two 8 bit vectors defining whether the status results,- by respective bit position, of the eight potentially pending control flow instruction are known and the corresponding statuε result stateε, alεo given by bit position correspondence. Lastly, the done control unit 540 iε provided to monitor the operational execution state of each of the functional units -478^. As any of the functional units 478-^, signal completion of an instruction execution operation, the done control unit 540 provides a corresponding done control signal on the control lines 542 to alert the register rename unit 496, instruction issuer unit 498, retirement control unit 500 and bypaεs control unit 520. The parallel array arrangement of the functional unitε 478,^ enhances the control consiεtency of the IEU 104. The particular nature of the individual functional unitε 478^ must be known by the instruction issuer unit 498 in order for instructions to be properly recognized and scheduled for execution. The functional units 478-. n are reεponεible for determining and implementing their εpecific control flow operation neceεsary to perform their requiεite function. Thus, other than the instruction isεuer 498, none of the IEU control unitε need to have independent knowledge of the control flow proceεεing of an instruction. Together, the instruction issuer unit 498 and the functional units 478^ provide the necessary control signal prompting of the functions to be performed by the remaining control flow managing units 496, 500, 520, 528, 540. Thuε, alteration in the particular control flow operation of a functional unit 478^ does not impact the control operation of the IED 104. Further, the functional augmentation, of an existing functional unit 78^ and even the addition of one or more new functional units 478,^, such aε an extended precision floating point multiplier and extended precision floating point ALU, a fast fourier computation * functional unit, and a trigonometric computational unit, require only minor modification of the inεtruction iεsuer unit 498. The required modifications must provide for recognition of the particular instruction, based on the corresponding instruction field isolated by the EDecode unit 490, a correlation of the instruction to the required functional unit 478-^,. Control over the εelection of regiεter date, routing of data, instruction completion and retirement remain consistent with tbe handling of all other instructionε executed with respect to all other ones of the functional unitε 478^. A, IEU Data Path Detail: The central element of the IEU data path iε the register file 472. Within the IEU data path, however, the present invention provides for a number of parallel data paths optimized generally for specific functions. The. two principal data paths are integer and floating point. Within each parallel data path, a portion of the regiεter file 472 iε provided to εupport the data manipulations occurring within that data path. 1) Register File Detail: The preferred generic architecture of a data path register file is shown in Figure 6a. The data path register file 550 includes a temporary buffer 552, a regiεter file array 564, an input εelector 559, and an output εelector 556. Data ultimately deεtine for the regiεter array 564 iε typically firεt received by the temporary buffer 552 through a combined data input bus 558'. That iε, all data directed to the data path register file 550 is multiplexed by the input εelector 559 from a number of input buεeε 558, preferably two, onto the input buε 558'. Regiεter select and enable control εignals provided on the control bus 518 select the register location for the received data within the temporary buffer 552. On retirement of an instruction that produced data stored in the temporary .buffer, control εignals again provided on the control bus 518 enable the transfer of the data from the temporary buffer 552 to a logically corresponding register within the register file array 564 via the data buε 560. However, prior to retirement of the instruction, data stored in the registerε of the temporary buffer 552 may be utilized in the execution of εubsequent instructions by routing the temporary buffer stored data to the output data εelector 556 via a bypass portion of the data bus 560. The selector 556, controlled by a control εignal provided via the control buε 518 εelects between data provided from the registerε of the temporary buffer 552 and of the register file array 564. The resulting data is provided on the register file output bus 564. Also, where an executing instruction will be retired on completion, i.e., the inεtruction has been executed in-order, the input εelector 559 can be directed to route the reεult data directly to the regiεter array 554 via bypass extension 558". In accordance with the preferred embodiments of the present invention, each data path register file 550 permits two εimultaneouε regiεter operationε to occur. Thuε, the input bus 558 provides for two full regiεter width data values to be written to the temporary buffer 552. Internally, the temporary buffer 552 provides a multiplexer array permitting the simultaneous routing of the input data to any two registers within the temporary buffer 552. Similarly, internal multiplexers allow any five registerε of the temporary buffer 552 to be εelected to output data onto the bus 560. The register file array 564 likewise includes input and output multiplexers allowing two registers to be selected to receive, on bus 560, or five to source, via bus 562, respective data simultaneously. Finally, the register file output selector 556 is preferably implemented to allow any five of the ten register data values received via the buses 560, 562 to be simultaneously output on the register file output buε 564. The register set within the temporary buffer iε generally shown in Figure 6b. The register εet 552' consistε of eight εingle word (32 bit) registers IORD, I1RD...I7RD. The regiεter set 552' may also be used as a set of four double word registerε IORD, IORD+1 (IORD4), I1RD, I1RD+1 (ISRD)... I3RD, I3RD+1 (I7RD) . In accordance with the preεent invention, rather than provide duplicate regiεters for each of the regiεterε within the regiεter file array 564, the regiεterε in the temporary buffer regiεter set 552 are referenced by the register rename unit 496 based on the relative location of the reεpective inεtructionε within the two IFIFO maεter regiεters 216, 224. Each instruction implemented by the architecture 100 may reference for output up to two registerε, or one double word register, for the destination of data produced by the execution of the instruction. Typically, an instruction will reference only a εingle output regiεter. Thus, for an instruction two (I 2 ) of the eight pending inεtructionε, poεitionally identified aε εhown in Figure 6C and that referenceε a εingle . output register, the data destination regiεter I2RD will be εelected to receive data produced by the execution of the inεtruction. Where the data produced by the inεtruction I 2 iε used by a subsequent instruction, for example, I 5 , the data εtored in the I2RD regiεter will be tranεferred out via the buε 560 and the reεultant data εtored back to the temporary buffer 552 into the register identified as I5RD. Notably, instruction I 5 is dependent on instruction I 2 . Inεtruction I 5 cannot be executed until the result data from I 2 is available. However, aε can be εeen, instruction I 5 can execute prior to the retirement of instruction I 2 by obtaining its required input data from the instruction I 2 data location of the temporary buffer 552'. Finally, as inεtruction I 2 is retired, the data from the register I2RD is written to the register location within the register file array 564 aε determined by the logical position of the inεtruction at the point of retirement. That is, the retirement control unit 560 determineε the addreεs of the destination registers in the register file array from the register reference field data provided from the EDecode unit 490 on the control lines ^ 510. Once instructions I M have been retired, the valueε in I4RD-I7RD are εhifted into I0RD- I3RD εimultaneouε with a εhift of the IFIFO unit 264. A complication ariεes where instruction I 2 provideε a double word reεult value. In accordance with a preferred embodiment of the preεent invention, a combination of locations I2RD and I6RD is used to store the data resulting from instruction I 2 until that inεtruction is retired or otherwise cancelled. In the preferred embodiment, execution of instructionε I < _ 7 are held where a double word output reference by any of the instructions I M is detected by the register rename unit 496. This allows the entire temporary buffer 552' to be used as a single rank of double word registers. Once instructions I^ j have been retired, the temporary buffer 552' can again be used as two ranks of single word regiεters. Further, the execution of any instruction 1^ 7 is held where a double word output register is required until the instruction has been shifted into a corresponding I M location. The logical organization of the register file array 564 is shown in Figure 7a-b. In accordance with the preferred embodiments of the present invention, the register file array 564 for the integer data path consists of 40 32-bit wide registers. Thiε set of registerε, constituting a register set "A", is organized as a base regiεter εet ra[0..23] 565, a top set of general purpose registerε ra[24..31] 566, and a εhadow regiεter εet of eight general purpose trap registers rt[24..31]. In normal operation, the general purpose registerε ra[0..31] 565, 566 constitutes the active "A" register εet of the regiεter file array for the integer data path. Aε εhown in Figure 7b the trap regiεters rt[24..31] 567 may be swapped into the active register set "A" to allow acceεε along with the active baεe εet of regiεterε ra[0..23] 565. Thiε configuration of the "A" register εet is εelected upon the acknowledgement of an interrupt or the execution of an exception trap handling routine. Thiε state of the register εet "A" iε maintained until expreεεly returned to the εtate εhown in Figure 7a by the execution of an enable interrupts instruction or execution of a return from trap instruction. In the preferred embodiment of the present invention aε implemented by the architecture 100, the floating point data path utilizes an extended precision register file array 572 as generally shown in Figure 8. The register file array 572 consists of 32 registers, rf[0..31], each having a width of 64 bits. The floating point register file 572 may alεo be logically referenced as a "B" set of integer registerε rb[0..31]. In the architecture 100, thiε "B" εet of regiεterε is equivalent to the low-order 32 bits of each of the floating point registers rf[0..31]. Representing a third data path, a boolean operator register set 574 is provided, as shown in Figure 9, to εtore the logical result of boolean combinatorial operations. This "C" regiεter set 574 consists of 32 single bit registers, rc[0..31]. The operation of the boolean register set 574 is unique in that the results of boolean operations can be directed to any instruction selected register of the boolean register set 574. This is in contrast to utilizing a single processor status word register that storeε single bit flags for conditions such as equal, not equal, greater than and other simple boolean εtatuε values. Both the floating point register set 572 and the boolean register εet 574 are complimented by temporary buffers architecturally identical to the integer temporary buffer 552 shown in Figure 6b. The essential difference iε that the width of the temporary buffer regiεterε iε defined to be identical to thoεe of the complimenting register file array 572, 574; in the preferred implementation, 64 bits and one bit, respectively. A number of additional special regiεters are at least logically present in the regiεter array 472. The registers that are physically present in the regiεter array 472, aε shown in Figure 7c, include a kernel stack pointer 568, procesεor εtate regiεter (PSR) 569, previous processor εtate regiεter (PPSR) 570, and an array of eight temporary proceεεor state registers (tPSR[0..7]) 571. The remaining special registers are distributed throughout various parts of the architecture 100. The special address and data bus 354 iε provided to εelect and tranεfer data between the εpecial regiεters and the "A" and "B" εetε of regiεters. A special register -move inεtruction iε provided to εelect a regiεter from either the "A" or . "B" register set, the direction of transfer and to εpecify the address identifier of a special regiεter. The kernel stack pointer register and temporary processor state registerε differ from the other εpecial regiεterε. The kernel εtack pointer may be accessed through execution of a standard register to register move instruction when in kernel state. The temporary procesεor εtate regiεterε are not directly acceεεible. Rather, thiε array of regiεterε is used to implement an inheritance mechaniεm for propagating the value of the processor state register for use by out-of-order executing instructions. The initial propagation value is that of the processor state register: the value provided by the last retired instruction. This initial value iε propagated forward through the temporary proceεεor εtate regiεterε εo that any out-of-order executing instruction has accesε to the value in the poεitionally correεponding temporary proceεεor εtate register. The specific nature of an instruction defineε the condition code bits, if any, that the instruction is dependent on and may change. Where an instruction is unconstrained by dependencies, register or condition code aε determined by the regiεter dependency checker unit 494 and carry dependency checker 492, the instruction can be executed out-of-order.- Any modification of the condition code bits of the processor εtate regiεter are directed to the logically correεponding temporary proceεεor εtate register. Specifically, only those bits that may change are applied to the value in the temporary processor state register and propagated to all higher order temporary procesεor εtate regiεterε. Conεequently, every out-of- order executed .inεtruction executes from a procesεor state register value modified appropriately by any intervening PSR modifying instructions. Retirement of an inεtruction only transferε the correεponding temporary processor state registers value to the PSR register 569. The remaining special registerε are described in Table II. TABLE II Special Registers Special Move Reg R/W Description: PC R Program Counters: in general, PCs maintain the next addresε of the currently executing program instruction εtream. IF PC R/W IFU Program Counter: the IF_PC maintainε the preciεe next execution addreεε. PFnPCε Prefetch Program Counters: the MBUF, TBUF and EBUF PFnPCs maintain the next prefetch instruction addresseε for the reεpective prefetch inεtruction εtreams. uPC R/W Micro-Program Counter: maintains the address of the inεtruction following a procedural instruction. This iε the addreεε of the firεt inεtruction to be executed upon return from a procedural routine. xPC R/W Interrupt/Exception Program Counter: holdε the return addreεs of an interrupt or and exception. The return addresε is the addresε of the IF_PC at the time of the trap. TBR W Trap Base Register: base address of a vector table used for trap handling routine dispatching. Each entry is one word long. The trap number, provided by Interrupt Logic Unit 363, is used as an index into the table pointed to by this address. FTB W Faεt Trap Base Register: base address of an immediate trap handling routine table. Each table entry is 32 words and is used to directly implement a trap handling routine. The trap number, provided by Interrupt Logic Unit 363, times 32 is used as an offεet into the table pointed to by thiε addreεε. PBR W Procedural Baεe Regiεter: base addreεε of a vector table uεed for procedural routine diεpatching. Each entry iε one word long, aligned on four word boundaries. The procedure number, provided aε a procedural inεtruction field, iε used aε an index into the table pointed to by thiε address. PSR R/W Procesεor State Regiεter: maintainε the proceεsor statuε word. Statuε data bitε include: carry, overflow, zero, negative, processor mode, current interrupt level, procedural routine being executed, divide by 0, overflow exception, hardware function enables, procedural enable, interrupt enable. PPSR R/W Previous Processor State Register: loaded from the PSR on εucceεεful completion of an inεtruction or when an interrupt or trap iε taken. CSR R/W Compare State (Boolean) Regiεter: the boolean regiεter εet acceεsible εs a single word. PCSR R/W Previous Compare State Register: loaded from the CSR on succeεεful completion of an instruction or when an interrupt or trap iε taken. 2 * 1 Integer Data Path Detail: "he integer data path of the IEU 104, constructed in accordance with the preferred embodiment of the present invention, is shown in Figure 10. For purposes cf clarity, the many control path connections to the integer data path 580 are not shown. Those connections are defined with respect to Figure 5. Input data for the data path 580 is obtained from the alignment units 582, 584 and the integer load/store unit 586. Integer immediate data values, originally provided as an instruction embedded data field are obtained from the operand unit 470 via a bus 588. The alignment unit 582 operates to isolate the integer data value and provide the resulting value onto the output bus 590 to * a multiplexer 592. A second input to the multiplexer 592 is the special register addresε and data buε 354. Immediate operands obtained from the instruction stream are also obtained from the operand unit 570 via the data bus 594. These values are again right juεtified by the alignment unit 584 before provision onto an output bus 596. The integer load/store unit 586 communicates bi- directionally via the external data bus 598 with the CCU 106. Inbound data to the IEU 104 is transferred by the integer load/store unit 586 onto the input data bus 600 to an input latch 602. Data output from the multiplexer 592 and latch 602 are provided on the multiplexer input buses 604, 606 of a multiplexer 608. Data from the functional unit output bus 482' is also received by the multiplexer 608. This multiplexer 608, in the preferred embodiments of the architecture 100, provideε for two simultaneous data paths to the output multiplexer buses 610. Further, the transfer of data through the multiplexer 608 can be completed within each half cycle of the system clock. Since most instructions implemented by the architecture 100 utilize a single destination regiεter, a maximum of four inεtructions can provide data to the temporary buffer 612 during each system clock cycle. Data from the temporary buffer 612 can be transferred to an integer register file array 614, via temporary regiεter output buεeε 616 or to a output multiplexer 620 via alternate temporary buffer regiεter buseε 618. Integer regiεter array output buεes 622 permit the transfer of integer register data to the multiplexer 620. The output buses connected to the temporary buffer 612 and integer regiεter file array 614 each permit five register valueε to be output εimultaneouεly. That iε, two inεtructions referencing a total of up to five source registerε can be issued simultaneouεly. The temporary buffer 612, register file array 614 and multiplexer 620 allow outbound regiεter data tranεfers to occur every half system clock cycle. Thuε, up to four integer and floating point instructions may be iεεued during each clock cycle. The multiplexer 620 operateε to εelect outbound register data values from the register file array 614 or directly from the temporary buffer 612. This allows out-of-order executed instructions with dependencies on prior out-of-order executed instructions to be executed by tbe IEU 104. This facilitates the twin goals of maximizing the execution through-put capability of the IEU integer data path by the out-of-order execution of pending instructions while precisely segregating out- of-order data reεultε from data reεults produced by instructions that have been executed and retired. Whenever an interrupt or other exception condition occurs that requires the precise state of the machine to be restored, the present invention allows the data values present in the temporary buffer 612 to be simply cleared. The register file array 614 is therefore left to contain precisely those data values produced only by the execution of instructionε completed and retired prior to the occurrence of the interrupt or other exception condition. The up to five register data values selected during each half system clock cycle operation of the multiplexer 620 are provided via the multiplexer output buses 624 to an integer bypaεε unit 626. Thiε bypaεε unit 626 iε, in eεεence, a parallel array of multiplexers that provide for the routing of data presented at any of itε inputε to any of its outputs. The b paεε unit 626 inputs include the εpecial regiεter addressed data value or immediate integer value via the output buε 604 from the multiplexer 592, the up to five regiεter data values provided on the buses 624, the load operand data from the integer load/store unit 586 via the double integer buε 600, the immediate operand value obtained from the alignment unit 584 via itε output bus 596, and, finally, a bypaεε data path from the functional unit output bus 482. Thiε bypaεs data path, and the data bus 482, provides for the simultaneous transfer of four register values per syεtem clock cycle. Data iε output by ' the bypaεε unit 626 onto an integer bypaεε buε 628 that iε connected to the floating point data path, to two operand data buses providing for the transfer out of up to five register data valueε εimultaneouεly, and a εtore data buε 632 that iε uεed to provide data to the integer load/εtore unit 586. The functional unit diεtribution bus 480 is implemented through the operation of a router unit 634. Again, the router unit 634 is implemented by a parallel array of multiplexers that permit five register values received at its inputs to be routed to the functional units provided in the integer data path. Specifically, the router unit 634 receiveε the five regiεter data values provided via the buses 630 from the bypass unit 626, the current IF_PC address value via the addreεε bus 352 and the control flow offset value determined by the PC control unit 362 and as provided on the lineε 378'. The router unit 634 may optionally receive, via the data buε 636 an operand data value εourced from a bypaεε unit provided within the floating point data path. The register data values received by the router unit 634 may be transferred onto the special register addresε and data buε 354 and to the functional unitε 640, 642, 644. Specifically, the router unit 634 is capable of providing up to three register operand values to each of the functional unitε 640, 642, 644 via router output buεeε 646, 648, 650. Conεiεtent with the general architecture of the architecture 100, up to two inεtructionε could be simultaneously iεεued to the functional unitε 640, 642, 644. The preferred embodiment of the present invention provides for three dedicated integer functional units, implementing respectively a programmable shift function and two arithmetic logic unit functions. An ALUO functional unit 644, ALU1 functional unit 642 and shifter functional unit 640 provide respective output regiεter data onto the functional unit bus 482'. The output data produced by the ALUO and shifter functional unit 6.44, 640 are also provided onto a shared integer functional unit bus 650 that iε coupled into the floating point data path. A similar floating point functional unit output value data bus 652 is provided from the floating point data path to the functional unit output bus 482'. The ALUO functional unit 644 is used also in the generation of virtual addreεs values in support of both the prefetch operations of the IFU 102 and data operations of the integer load/εtore unit 586. The virtual addresε value calculated by the ALUO functional unit 644 is provided onto an output bus 654 that connects to both the target address bus 346 of the IFU 102 and to the CCU 106 to provide the execution unit physical address (EX PADDR) . A latch 656 is provided to εtore the virtualizing portion of the addresε produced by the ALUO functional unit 644. Thiε virtualizing portion of the address is provided onto an output buε 658 to the VMU 108. 3 ) Floating Point Data Path Deta il : Referring now to Figure 1 1 , the floating point data path 660 is εhown . Initial data iε again received from a number of εources including the immediate integer operand bus 588 , immediate operand bus 594 and the εpecial regiεter address data buε 354. The final εource of external data iε a floating point load/εtore unit 662 that iε coupled to the CCU 106 via the external data buε 598. Tiie immediate integer operand iε received by an alignment unit 664 that functions to right justify the integer data field before submiεεion to a multiplexer 666 via an alignment output data buε 668. The multiplexer 666 alεo receiveε the εpecial register addresε data bus 354. Immediate operands are provided to a second alignment unit 670 for right justification before being provided on an output bus 672. Inbound data from the floating point load/εtore unit 662 is received by a latch 674 from a load data bus 676. Data from the multiplexer 666, latch 674 and a functional unit data return bus 482" is received on the inputs of a multiplexer 678. The multiplexer 678 provides for εelectable data pathε εufficient to allow two register data values to be written to a temporary buffer 680, via the multiplexer output buses 682, each half cycle of the syεtem clock. The temporary buffer 680 incorporateε a regiεter εet logically identical to the temporary buffer 552' aε εhown in Figure 6b. The temporary buffer 680 further provideε for up to five regiεter data values to be read fr-om the temporary buffer 680 to a floating point regiεter file array 684, via data buεeε 686, and to an output multiplexer 688 via output data buεeε 690. The multiplexer 688 alεo receiveε, via data buεeε 692, up to five regiεter data values from the floating point regiεter file array 684 εimultaneouεly. The multiplexer 688 functionε to εelect up to five regiεter data valueε for εimultaneouε tranεfer to a bypass unit 694 via data buεeε 696. The bypass unit 694 also receiveε the immediate operand value provided by the alignment unit 670 via the data buε 672, the output data bus 698 from the multiplexer 666, the load data buε 676 and a data bypaεε extension of the functional unit data return bus 482". The bypaεs unit 694 operateε to select up to five simultaneous register operand data values for output onto the bypass unit output buseε 700, a εtore data bus 702 connected to the floating point load/store unit 662, and the floating point bypass bus 636 that connects to the router unit 634 of the integer data path 580. A floating point router unit 704 provides for simultaneous selectable data paths between the bypass unit output buses 700 and the integer data path bypass bus 626 and functional unit input buses 706, 708, 710 coupled to the respective functional units 712, 714, 716. Each of the input buses 706, 708, 710, in accordance with the preferred embodiment of the architecture 100, permits the simultaneous transfer of up to three register operand data values to each of the functional unit 712, 714, 716. The output buseε of these functional units 712, 714, 716 are coupled to the functional unit data return bus 482" for returning data to the register file input multiplexer 678. The integer data path functional unit output bus 650 may also be provided to connect to the functional unit data return bus 482". The architecture 100 does provide for a connection of the functional unit output buses of a multiplier functional unit 712 and a floating point ALU 714 to be coupled via the floating point data path functional unit bus 652 to the functional unit data return bus 482' of the integer data path 580. 4) Boolean Register Data Path Detail: The boolean operations data path 720 is shown in Figure 12. This data path 720 is utilized in support of the execution of esεentially two typeε of inεtructionε. The firεt type iε an operand comparison instruction where two operands, selected from the integer register sets, floating point register sets or provided as immediate operands, are compared by subtraction in one of the ALU functional units of the integer and floating point data paths. Comparison is performed by a subtraction operation by any of the ALU functional units 642, 644, 714, 716 with the resulting sign and zero status bits being provided to a combined input εelector and comparison operator unit 722. This unit 722, in reεponεe to instruction identifying control signals received from the EDecode unit 490, selectε the output of an ALU functional unit 642, 644, 714, 716 and combines the εign and zero bitε to extract a boolean co pariεon reεult value. An output bus 723 allows the results of the comparison operation to be transferred simultaneouεly to an input multiplexer 726 and a bypaεε unit 742. Aε in the integer and floating point data paths, the bypaεε unit 742 is implemented as a parallel array of multiplexers providing multiple selectable data paths between the inputs of the bypasε unit 742 to multiple outputε. The other inputε of the bypass unit 742 include a boolean operation result return data bus 724 and two boolean operands on data buses 744. The bypass unit 742.permits boolean operands representing up to two simultaneouεly executing boolean inεtructionε to be transferred to a boolean operation functional unit 746, via operand buses 748. The bypasε unit 746 alεo permitε transfer of up to two single bit boolean operand bitε (CF0, CF1) to be εimultaneouεly provided on the control flow reεult control lineε 750, 752. The remainder of the boolean operation data path 720 includeε the input multiplexer 726 that receiveε as its inputs, the comparison and the boolean operation reεult valueε provided on the compariεon result bus 723 and a boolean reεult buε 724. The buε 724 permits up to two εimultaneouε boolean reεult bitε * •' to be transferred to the multiplexer 726. In addition, up to two comparison result bitε may be transferred via the bus 723 to the multiplexer 726. The multiplexer 726 permits any two single bits preεented at the multiplexer inputs to be transferred via the multiplexer output buses 730 to a boolean operation temporary buffer 728 during each half cycle of the syεtem clock. The temporary buffer-- 728 iε logically equivalent to the temporary buffer 752', aε εhown in Figure 6b, though differing in two significant reεpectε. The first respect is that each register entry in the temporary buffer 728 consists of a single bit. The second distinction is that only a single register is provided for each of the eight pending instruction slots, since the result of a boolean operation is, by definition, fully defined by a εingle result bit. The temporary buffer 728 provides up to four output operand valueε εimultaneouεly. This allows the simultaneous execution of two boolean inεtructions, each requiring accesε to two εource regiεterε. The four boolean regiεter valueε may be transferred during each half cycle of the εyεtem clock onto the operand buεeε 736 to a multiplexer 738 or to a boolean regiεter file array 732 via the boolean operand data buses 734. The boolean register file array 732, as logically depicted in Figure 9, is a εingle 32 bit wide data regiεter that permitε any εeparate combination of up to four εingle bit locationε to be modified with data from the temporary buffer 728 and read from the boolean regiεter file array 732 onto the output buseε 740 during each half cycle of the εyεtem clock. The multiplexer 738, provides for any two pairs of boolean operands received at its inputs via the buses 736, 740 to be transferred onto the operand output buses 744 to the bypasε unit 742. The boolean operation functional unit 746 is capable of performing a wide range of boolean operations on two source values. In the case of comparison instructionε, the εource values are a pair of operands obtained from any of the integer and floating point regiεter sets and any immediate operand provided to the IEU 104, and, for a boolean instruction, any two of boolean register operands. Tables III and IV identify the logical comparison operations provided by the preferred embodiment of the architecture 100. Table V identifieε the direct boolean operationε provided by the preferred implementation of the architecture 100. The inεtruction condition codeε and function codeε εpecified in the Tableε III-V represent a segment of the corresponding instructionε. The instruction alεo provides an identification of the εource pair of operand regiεterε and the deεtination boolean regiεter for εtorage of the corresponding boolean operation result. TABLE III Integer Comparison Instruction Condition* SvmbolCondition Code rsl greater than rε2 > 0000 rεl greater than >= 0001 or equal to rε2 rεl lesε than rε2 < 0010 rεl leεε than >= 0011 or equal to rs2 rsl unequal to rs2 != 0100 rεl equal to rs2 == 0101 reserved 0110 unconditional 1111 *rs = regiεter'source TAB E IV Fleeting Point prπparison Instruction Condition rsl greater than rε2 rsl greater than or equal to rε2 rsl less than rs2 rsl less than or equal to rs2 rsl unequal to rs2 rsl equal to rs2 unordered unordered or rsl greater than rs2 unordered, rεl greater than or equal to rs2 unordered or rεl less than rs2 unordered, rsl less than or equal to rs2 unordered or rsl equal to rs2 reserved TABLE V an *bs = boolean εource regiεter BT Load/Store Control Unit: An exemplary load/εtore unit 760 is shown in Figure 13. Although separately εhown in the data paths 580, 660, the load/store unitε 586 662 are preferably implemented aε a single shared load/store unit 760. The interface from a reεpective data path 580, 660 is via an address bus 762 and load and εtore data buεeε 764 (600, 676), 766 (632, 702). The address utilized by the load/store unit 760 iε a physical address as opposed to the virtual address utilized by the ''IFU 102 and the remainder of the IEU 104. While the IFU 102 operates on virtual addresseε, relying on coordination between the CCU 106 and VMU 108 to produce a physical address, the IEU 104 requires the load/store unit 760 to operate directly in a phyεical address mode. This requirement is necessary to insure data integrity in the preεence of out-of-order executed inεtructions that may involve overlapping physical address data load and εtore operationε and in the preεence of out-of-order data returnε from the CCU 106 to the load/εtore unit 760. In order to inεure data integrity, the load/εtore unit 760 bufferε data provided by εtore instructions until the εtore inεtruction iε retired by the IEU 104. Conεequentl , εtore data buffered by the load store unit 760 may be uniquely present only in the load/εtore unit 760. Load inεtructionε referencing the εame phyεical address as executed but not retired εtore inεtructionε are delayed until the εtore instruction is actually retired. At that point the store data may be transferred to the CCU 106 by the load/εtore unit 760 and then immediately loaded back by the execution of a CCU data load operation. Specifically, full physical addresεeε are provided from the VMU 108 onto the load/εtore addreεε bus 762. Load addresεeε are, in general, εtored in load address regiεterε 768^. Store addresεes are latched into εtore address registers 770 3 ^. A load/store control unit 774 operates in response to control εignals received from the inεtruction issuer unit 498 in order to coordinate latching of load and εtore addreεεes into the regiεters 768-.-, 770-. Q . The load/store control unit 774 provides control εignals on control lines 778 for latching load addresses and on-'control lines 780 for latching store addresses. Store data is latched simultaneous with the latching of store addresses in logically corresponding slots of the store data register set 782 3 _ 0 . A 4x4x32 bit wide address comparator unit 772 is simultaneously provided with each of the addresεeε in the load and εtore addreεε registers 168^, 770 M . The execution of a full matrix address comparison during each half cycle of the syεtem clock iε controlled by the load/store control unit 774 via control lineε 776. The existence and logical location of a load addreεε that matches a εtore addreεs is provided via control εignalε returned to the load store control unit 774 via control lines 776. Where a load address is provided from the VMU 108 and there are no pending stores, the load address is bypasεed directly from the buε 762 to an addreεs selector 786 concurrent with the initiation of a CCU load operation. However, where store data is pending, the load addresε will be latched in an available load address latch 768 M . Upon receipt of a control signal from the retirement control unit 500, indicating that the correεponding εtore data inεtruction iε retiring, the load/εtore control unit 774 initiates a CCU data tranεfer operation by arbitrating, via control lines 784 for access to the CCU 106. When the CCU 106.signals ready, the load/store control unit 774 directε the εelector 786 to provide a CCU physical addresε onto the CCU PADDR addreεε buε 788. This addreεε iε obtained from the correεponding store register 770^ via the addresε bus 790. Data from the correεponding εtore data regiεter 782 3 _ 0 is provided onto the CCU data bus 792. Upon issuance of load instruction by the instruction issuer 498, the load store control unit 774 enables one of the load address latches 768 3 ^, to latch the requested load addreεε. The εpecific latch 68^ εelected logically correspondε to the position of the load instruction in the relevant inεtruction εet. The inεtruction isεuer 498 provides the load/store control unit 774 with a five bit vector identifying the load inεtruction within either of the two possible pending inεtruction setε. Where the comparator 772 does not identify a matching store address, the load addresε iε routed via an addreεε bus 794 to the selector 786 for output onto the CCU PADDR addresε bus 788. Provision of the addresε is performed in concert with CCU request and ready control signalε being exchanged between the load/εtore control unit 774 and CCU 106. An execution ID value (ExID) iε also prepared and isεued by the load/εtore control unit 774 to the CCU 106 in order to identify the load requeεt when the CCU 106 εubεequently returnε the requested data including ExID value. This ID value conεiεtε of a four bit vector utilizing unique bitε to identify the reεpective load addreεε latch 768^. 3 from which the current load requeεt iε generated. A fifth bit iε utilized to identify the inεtruction εet that containε the load inεtruction. The ID value iε thuε the same aε the bit vector provided with the load requeεt from the inεtruction issuer unit 498. On subsequent εignal from the CCU 106 to the load/store control unit 774 of the availability of prior requested load data, the load/εtore control unit 774 enables an alignment unit to receive the data and provide it on the load data bus 764. An alignment unit 798 operates to right justify the load data. Simultaneously with the return of data from the CCU 106, the load/εtore control unit 774 receives the ExID value from the CCU 106. The load/store control unit 774, in turn, provides a control signal to the instruction issuer unit 498 identifying that load data iε being provided on the load data bus 764 and, further, returns a bit vector identifying the load instruction for which the load data is being returned. C1 IEU Control Path Detail: Referring again to Figure 5, the operation of the IEU control path will now be described in detail with respect to the timing diagram provided in Figure 14. The timing of the execution of instructionε repreεented in Figure 14 iε exemplary of the operation of the present invention, and not exhaustive of execution timing permutations. The timing diagram of Figure 14 showε a sequence of processor system clock cycles, P M . Each procesεor cycle begins with an internal T Cycle, T 0 . There are two T cycles per procesεor cycle in a preferred embodiment of the present invention as provided for by the architecture 100. In processor cycle zero, the IFU 102 and the VMU 108 operate to generate a phyεical addreεε. The physical addresε iε provided to the CCU 106 and an instruction cache access operation, is initiated. Where the requested instruction εet is preεent .in the instruction cache 132, an instruction set is returned to the IFU 102 at about the mid-point of processor cycle one. The IFU 102 then manages the transfer of the instruction εet through the prefetch unit 260 and IFIFO 254, whereupon the instruction set is first presented to the IEU 104 for execution. 1) EDecode Unit Detail: The EDecode unit 490 receives the full inεtruction-'εet in parallel for decoding prior to the conclusion of processor cycle one. The EDecode unit 490, in the preferred architecture 100, is implemented as a pure combinatorial logic block that provides for the direct parallel decoding of all valid instructionε that are received via the bus 124. Each type of instruction recognized by the architecture 100, including the specification of the instruction, register requirements and resource needs are identified in Table VI. TABLE VI Instruction/Specifications Ir.strvct.-Qn Control and Operand Infornation * * Move Register Logical/Arithmetic Function Code: to Register specifies Add, Subtract, Multiply, Shift, etc. Destination Register Set PSR only Source Register 1 Source Register 2 or Immediate constant value Regiεter Set A/B εelect Move Immediate Destination Register to Register Immediate Integer or Floating Point constant value Regiεter Set A/B εelect Load/Store Operation Function Code: εpecifieε Regiεter Load or Store, uεe immediate value, baεe and immediate value, or baεe and offεet Source/Deεtination Regiεter Baεe Regiεter Index Register or Immediate constant value Regiεter Set A/B select Immediate Call Signed Immediate Diεplacement Control Flow Operation Function Code: specifies branch type and triggering condition Base Register Index Register, Immediate constant displacement value, or Trap Number Register Set A/B select Special Register Operation Function Code: specifies Move move to/from special/integer regiεter Special Register Address Identifier Source/Destination Regiεter Regiεter Set A/B εelect Convert Integer Operation Function Code: εpecifieε Move type of floating point to integer converεion Source/Destination Register Register Set A/B select Boolean Functions Boolean Function Code: εpecifieε And, Or, etc. Deεtination boolean regiεter Source Register 1 Source Register 2 Register Set A/B select Extended Procedure Procedure specifier: specifieε addreεε offεet from procedural base value Operation: value passed to procedure routine Atomic Procedure Procedure specifier: εpecifieε addreεε value * - instruction includes these fields in addition to a field that decodes to identify the instruction. ". The EDecode unit 490 decodes each instruction of an inεtruction set in parallel. The resulting identification of instructionε, inεtruction functionε, regiεter references and function requirements are made available on the outputs of the EDecode unit 490. This information is regenerated and latched by the EDecode unit 490 during each half processor cycle until all instructions in the instruction set are retired. Thus, information regarding all eight pending instructions is constantly maintained at the output of the EDecode unit 490. This information is presented in the form of eight element bit vectors where the bitε or εub-fieldε of each vector logically correspond to the phyεical location of the corresponding instruction within the two pending inεtruction setε. Thuε, eight vectors are provided via the control lines 502 to the carry checker 492, where each vector specifies whether the corresponding instruction affects or is dependant on the carry bit of the .proceεεor εtatus word. Eight vectors are provided via the control lineε 510 to identify the εpecific nature of each inεtruction and the function unit requirementε. Eight vectorε are provided via the control lineε 506 specifying the register references used by each of the eight pending instructionε. Theεe vectors are provided prior to the end of processor cycle one. 21 Carry Checker Unit Detail: The carry checker unit 492 operateε in parallel with the dependency check unit 494 during the data dependency phaεe of operation εhown in Figure 14. The carry check unit 492 is implemented in the preferred architecture 100 as pure combinatorial logic. Thus, during each iteration of operation by the carry checker unit 492, all eight instructionε are considered with respect to whether they modify the carry flag of the proceεsor state regiεter. This is necesεary in order to allow the out-of-order execution of instructions that depend on the state of the carry bit as set by prior instructions. Control εignals provided on the control lines 504 allow the carry check unit 492 to identify the specific instructionε that are dependant on the execution of prior instructions with respect to the carry flag. In addition, the carry checker unit 492 maintains a temporary copy of the carry bit for each of the eight pending instructionε. For those inεtructions that do not modify the carry bit, the carry checker unit 492 propagates the carry bit to the next instruction forward in the order of the program instruction stream. Thus, an out-of-order executed instruction that modifies the carry bit can ,be executed and, further, a subεequent inεtruction that iε dependant on such an out-of-order executed inεtruction may also be allowed to execute, though εubεequent to the inεtruction that modifies the carry bit. Further, maintenance of the carry bit by the carry checker unit 492 facilitates out-of-order execution in that any exception occurring prior to the retirement of those instructions merely requires the carry checker unit 492 to clear the internal temporary carry bit register. Consequently, the processor status regiεter iε unaffected by the execution of out-of-order executed instructions. The temporary bit carry register maintained by the carry checker unit 492 is updated upon completion of each out-of-order executed instruction. Upon retirement of out-of-order executed instructionε, the carry bit correεponding to the laεt retired inεtruction in the program inεtruction .εtream iε tranεferred to the carry bit location of the proceεsor statuε regiεter. 3") Data Dependency Checker Unit Detail: The data dependency checker unit 494 receiveε the eight regiεter reference identification vectorε from the EDecode unit 490 via the control lines 506. Each register reference is indicated by a five bit value, suitable for identifying any one of 32 registerε at a time, and a two bit value that identifies the regiεter bank aε located within the "A*, "B" or boolean regiεter εetε. The floating point regiεter εet iε equivalently identified aε the "B" regiεter εet. Each instruction may have up to three register reference fields: two source register fields and one deεtination. Although some instructions, most notably the move register to register instructions, may specify a destination register, an instruction bit field recognized by the EDecode unit 490 may signify that no actual output data is to be produced. Rather, execution of the instruction is only for the purpose of determining an alteration of the value of the processor εtatuε regiεter. The data dependency checker 494, implemented again aε pure combinatorial logic in the preferred architecture 100, operateε to εimultaneouεly determine dependencieε between εource regiεter referenceε of -106- instructions εubεequent in the program inεtruction εtream and deεtination regiεter referenceε of relatively prior instructionε. A bit array iε produced by ' the data dependency checker 494 that identifies not only which instructions are dependant on others, but alεo the registers upon which each dependency ariseε. The carry and regiεter data dependencies are identified εhortly after the beginning of the εecond processor cycle. 4-") Register Rename Unit Detail: The register rename unit 496 receives the identification of the register references of all eight pending instructionε via the control lines 506, and register dependencies via the control lines 508. A matrix of eight elements is also received via the control lines 542 that identify those inεtructionε within the current εet of pending instructionε that have been executed (done) . From this information, the register rename unit 496 provides an eight element array of control εignalε to the instruction isεuer unit 498 via the control lineε 512. The control information εo provided reflectε the determination made by the regiεter rename unit 496 aε to which of the currently pending instructionε, that have not already been executed, are now available to be executed given the current εet of identified data dependencies. The register rename unit 496 receives a selection control signal via the lines 516 that identifies up to six instructions that are to be simultaneously issued for execution: two integer, two floating point and two boolean. The register rename unit 496 performs the additional function of selecting, via control εignals provided on the buε 518 to the register file array 472, the εource registerε for acceεs in the execution of the identified inεtructions. Destination registers for out- of-order executed instructions are selected as being in the temporary buffers 612, 680, 728 of the correεponding data path. In-order executed instructionε are retired on completion with result data being εtored through to the register files 614, ' 684, 732. The selection of source registerε dependε on whether the regiεter haε been prior selected as a deεtination and the correεponding prior inεtruction haε not yet been retired. In εuch an instance, the source register is selected from the corresponding temporary buffer 612, 680, 728. Where the prior instruction has been retired, then the register of the corresponding register file 614, 684, 732 is selected. Consequently, the register rename unit 496 operateε to effectively εubεtitute temporary buffer register referenceε for regiεter file regiεter referenceε in the caεe of out-of-order executed inεtructionε. Aε implemented in the architecture 100, the temporary bufferε 612, 680, 728 are not duplicate regiεter εtructureε of their correεponding regiεter file arrayε. Rather, a εingle deεtination regiεter slot is provided for each of eight pending instructionε. Conεequently, ,the substitution of a temporary buffer deεtination register reference iε determined by the location of the correεponding inεtruction within the pending regiεter sets. A subsequent εource register reference is identified by the data dependency checker 494 with respect to the instruction from which the εource dependency occurs. Therefore, a destination slot in the temporary buffer register is readily determinable by the register rename unit 496. 5) Instruction Issuer Unit Detail; The inεtruction iεsuer unit 498 determines the set of instructions that can be issued, based on the output of the register rename unit 496 and the function requirements of the instructions as identified by the EDecode unit 490. The instruction issuer unit 498 makes this determination based on the status of each of the functional units 478^ as reported via control lineε 514. Thus, the instruction isεuer unit 498 begins operation upon receipt of the available εet of inεtructi'onε to isεue from the regiεter rename unit 496. Given that a regiεter file access is required for the execution of each inεtruction, the instruction iεεuer unit 498 anticipates the availability of functional unit 478-. n that may be currently executing an inεtruction. In order to minimize the delay in identifying the instructions to be issued to the register rename unit 496, the inεtruction iεsuer unit 498 iε implemented in dedicated combinatorial logic. Upon identification of the instructions to issue, the register rename unit 496 initiates a regiεter file access that continues to the end of the third processor cycle, P 2 . At the beginning of procesεor cycle P 3 , the inεtruction issuer unit 498 initiates operation by one or more of the. functional units 478,^, εuch as εhown aε ■ Execute 0", to receive and proceεε εource data provided from the regiεter file array 472. Typically, most instructions processed by the architecture 100 are executed through a functional unit in a εingle proceεεor cycle. However, some instructions require multiple processor cycles to complete, such as shown aε "Execute 1", a εimultaneouεly iεsued instruction. The Execute zero and Execute 1 instructions may, for example, be executed by an ALU and floating point multiplier functional unitε reεpectively. The ALU functional unit, as shown is Figure 14, produces output data within one procesεor cycle and, by ' εimple proviεion of output latching, available for uεe in executing another inεtruction during the fifth proceεsor cycle, P 4 . The floating point multiply functional unit iε preferably an internally pipelined functional unit. Therefore, another additional floating point multiply instruction can be isεued in the next processor cycle. However, the result of the first instruction will not be available for a'' data dependant number of procesεor cycleε; the inεtruction εhown in Figure 14 requireε three proceεεor cycleε to complete proceεεing through the functional unit. During each proceεεor cycle, the function of the inεtruction issuer unit 498 iε repeated. Conεequently, the εtatus of the current set of pending inεtructionε aε well as the availability state of the full set of functional units 478 0 _ n are reevaluated during each procesεor cycle. Under optimum conditionε, the preferred architecture 100 iε therefore capable of executing up to εix inεtructionε per proceεεor cycle. However, a typical inεtruction mix will reεult in an overall average execution of 1.5 to 2.0 inεtructionε per proceεεor cycle. A final conεideration in the function of the inεtruction iεεuer 498 iε itε participation in the handling of trapε conditionε and the execution of εpecific inεtructions. The occurrence of a trap condition requires that the IEU 104 be cleared of all instructions that have not yet been retired. Such a circumstance may arise in response to an externally received interrupt that is relayed to the IEU 104 via the interrupt request/acknowledge control line 340, from any of the functional units 478 0 _ n in responεe to an arithmetic fault, or, for example, the EDecode unit 490 upon the decoding of an illegal instruction. On the occurrence of the trap condition, the instruction isεuer unit 498 iε reεponsible for halting or voiding all un- retired instructionε currently pending in the IEU 104. All inεtructionε that cannot be retired simultaneously will be voided. This result is essential to maintain the preciseness of the occurrence of the interrupt with respect to the conventional in-order execution of a program inεtructi'on εtream. Once the IEU 104 is ready to begin execution of the trap handling program routine, the instruction issuer 498 acknowledges the interrupt via a return control εignal along the control lines 340. Also, in order to avoid the possibility that an exception condition relative to one instruction may be recognized based on a proceεεor εtate bit which would have changed before that inεtruction would have executed in a classical pure in-order routine, the instruction issuer 498 is responsible for ensuring that all instructions which can alter the PSR (such as special move and return from trap) are executed strictly in- order. Certain instructions that alter program control flow are not., identified by the IDecode unit 262. Instructionε of this type include subroutine returns, returns from procedural instructions, and returns from traps. The instruction issuer unit 498 provides identifying control εignals via the IEU return control lines 350 to the IFU 102. A corresponding one of the εpecial regiεters 412 iε εelected to provide the IF_PC execution addreεs that existed at the point in time of the call instruction, occurrence of the trap or encountering of a procedural instruction. 61 Done Control Unit Detail: The done control unit 540 monitors the functional units 78,^ for the completion status of their current operations. In the preferred architecture 100, the done control unit 540 anticipates the completion of operations by each functional unit sufficient to provide a completion vector, reflecting the εtatuε of the execution of each inεtruction in the currently pending εet of instructionε, to the register rename unit 496, bypaεε control unit 520 and retirement control unit 500-'approximately one half processor cycle prior to the execution completion of an instruction by a functional unit 478^. This allows the instruction issuer unit 498, via the register rename unit 496, to conεider the inεtruction completing functional units aε available resources for the next instruction issuing cycle. The bypasε control unit 520 iε allowed to prepare to bypaεs data output by the functional unit through the bypass unit 474. Finally, the retirement control unit 500 nay operate to retire the corresponding instruction simultaneous with the transfer of data from the functional unit 478^ to the register file array 472. 7) Retirement Control Unit Detail: In addition to the instruction done vector provided from the done control unit 540, the retirement control unit 500 monitors the oldest instruction εet output from the EDecode output 490. As each instruction in instruction stream order is marked done by the done control unit 540, the retirement control unit 500 directs, via control εignalε provided on control lineε 534, the tranεfer of data from the temporary buffer slot to the corresponding instruction specified register file register location within the regiεter file array 472. The PC Inc/Size control εignalε are provided on the control lineε 344 for each one or more instruction εimultaneouεly retired. Up to four inεtructionε may be retired per proceεsor cycle. Whenever an entire instruction εet haε been retired, an IFIFO read control εignal iε provided on the control line 342 to advance the IFIFO 264. 8) Control Flow Control Unit Detail: The control flow control unit 528 operates to continuouεly provide the IFU 102 with information specifying whether any control flow instructionε within the current set of pending inεtructions have been resolved and, further, whether the branch result is taken or not taken. The control flow control unit 528 obtains, via control lines 510, an identification of the control flow branch instructionε"by the EDecode 490. The current set of register dependencies is provided via control lines 536 from the data dependency checker unit 494 to the control flow control unit 528 to allow the control flow control unit 528 to determine whether the outcome of a branch instruction is constrained by dependencies or is now known. The register references provided via bus 518 from the register rename unit 496 are monitored by the control flow control 528 to identify the boolean register that ..will define the branch decision. Thus, the branch decision may be determined even prior to the out-of-order execution of the control flow instruction. Simultaneous with the execution of a control flow instruction, the bypasε unit 472 is directed by the bypasε control unit 520 to provide the control flow reεultε onto control lineε 530, conεisting of the control flow zero and control flow one 1 control lines 750, 752, to the control flow control unit 528. Finally, the control flow control unit 528 continuously provideε two vectorε of eight bitε each to the IFU 102 via control lineε 348. These vectors define whether a branch instruction at the corresponding logical location correεponding to the bitε within the vectorε have been resolved and whether the branch result is taken or not taken. In the preferred architecture 100, the control flow control unit 528 is implemented as pure combinatorial logic operating continuously in response to the input control signalε to the control unit 528. 9fr Bypass Control Unit Detail: The inεtruction iεεuer unit 498 operates closely in conjunction with the bypass control unit 520 to control the routing of data between the register file array 472 and the functional unitε 478 01 . The bypass control unit 520 operates in conjunction with the register file accesε, output and εtore phaεeε of operation εhown in Figure 14. During a regiεter file acceεs, the bypaεε control unit 520 may recognize, via control lineε 522, an access of a destination register within the register file array 472 that is in the procesε of being written during the output phaεe of execution of an inεtruction. In this case, the bypasε control unit 520 directε the selection of data provided on the functional unit output buε 482 to be bypaεεed back to the functional unit diεtribution buε 480. Control over the bypaεε unit 520 iε provided by the inεtruction iεεuer unit 498 via control lineε 542. TV. Virtual Memory Control Unit: An interface definition for the VMU 108 is provided in Figure 15. The VMU 108 consists principally of a VMU control logic unit 800 and a content addresεable memory (CAM) 802. The general function of the VMU 108 iε εhown graphically in Figure 16. There, a representation of a virtual address iε εhown partitioned into a space identifier (sID[31:28] ) , a virtual page number (VADDR[27: 14] ) , page offset (PADDR[13:4]) , and a request ID (rID[3:0]). The algorithm for generating a physical addresε iε to uεe the space ID to εelect one of 16 registers within a space table 842. The contents of the selected εpace regiεter in combination with a virtual page number is used as an addreεs for accesεing a table look aεide buffer (TLB) 844. The 34 bit addreεs operates as a content address tag used to identify a corresponding buffer regiεter within the buffer 844. On the occurrence of a tag match, an 18 bit wide register value is provided as the high order 18 bits of a physical address 846. The page offset and requeεt ID are provided as the low order 14 bits of the physical addresε 846. Where there is a tag miss in the table look aside buffer 844, a VMU miεε is signalled. This requires the execution of a VMU fast trap handling routine that implements conventional hash algorithm 848 that accesses a complete page table data structure maintained in the MAU 112. This page table 850 contains entries for all memory pages c.urrently in use by the architecture 100. The hash algorithm 848 identifies those entries in the page table 850 necessary to satisfy the current virtual page translation operation. Those page table entries are loaded from the MAU 112 to the trap registerε of regiεter εet "A" and then tranεferred by εpecial regiεter move instructions to the table look aside buffer 844. Upon return from the exception handling routine, the inεtruction giving rise to the VMU miεε exception iε re-executed by the IEU 104. The virtual to phyεical address translation operation εhould then complete without exception. The VMU control logic 800 provides a dual interface to both the IFU 102 and IEU 104. A ready signal is provided on control lines 822 to the IEU 104 to signify that the VMU 108 is available for an address translation. In the preferred embodiement, the VMU 108 is always ready to accept IFU 120 translation requeεtε. Both the IFU and IEU 102, 104 may poεe requeεts via control line 328, 804. In the preferred architecture 100, the IFU 10Z has priority access to the VMU 108. Consequently, only a single busy control line 820 iε provided to the IEU 104. Both the IFU and IEU 102, 104 provide the space ID and virtual page number fields to the VMU control logic 800 via control lines 326, 808, respectively. In addition, the IEU 104 provides a read/write control signal via control signal 806 to define whether the addresε iε to be uεed for a load or εtore operation as necesεary to modify memory acceεs protection attributes of the virtual memory referenced. The space ID and virtual page fields of the virtual addreεε are paεsed to the CAM unit 802 to perform the actual translation operation. The page offεet and ExID fields are eventually proyided by the IEU 104 directly to the CCU 106. The physical page and request ID fields are provided on the addreεε lineε 836 to the CAM unit 802. The occurrence of a table look aεide buffer match iε εignalled via the hit line and control output lines 830 to the VMU control logic unit 800. The resulting physical address, 18 bits in length, is provided on the addresε output lineε 824. The VMU control logic unit 800 generates the virtual memory miεs and virtual memory exception control εignalε on lineε 334, 332 in reεponεe to the hit and control output control εignalε on lineε 830. A* virtual memory tranεlation miεε is defined aε failure to match a page table identifier in the table look aside buffer 844. All other translation errors are reported as virtual memory exceptions. Finally, the data tables within the CAM unit 802 may be modified through the execution of special register to register move inεtructions by the IEU 104. Read/write, register select, reset, load and clear control signals .are provided by the IEU 104 via control lines 610, 812, 814, 816, 818. Data to be written to the CAM unit registerε iε received by the VMU control logic unit 800 via the addresε buε 808 coupled to the εpecial address data bus 354 from the IEU 104. This data is transferred via bus 836 to the CAM unit 802 simultaneouε with control εignalε 628 that control the initialization, regiεter εelection, and read or write control εignal. Conεequently, the data regiεterε within the CAM unit 802 may be readily written as required during the dynamic operation of the architecture 100 including read out for storage as required for the handling of context εwitcheε defined by a higher level operating εyεtem. V. Cache Control Unit: The control on data interface for the CCU 106 iε shown in Figure 17. Again, separate interfaces are provided for the IFU 102 and IEU 104. Further, logically separate interfaces are provided by the CCU 106 to the MCU 110 with respect to instruction and data transfers. The IFU interface consiεts of the physical page addresε provided on addreεs lineε 324, the VMU converted page addresε aε provided on the address lines 824, and requeεt IDs as tranεferred separately on control lineε 294, 296. A unidirectional data transfer buε 114 is provided to transfer an entire inεtruction εet in parallel to the IFU 102. Finally, the read/buεy and ready control εignalε are provided to the CCU 106 via control lineε 298, 300, 302. Similarly, a complete phyεical addreεε iε provided by the IEU 102 via the physical addresε bus 788. The request ExIDs are separately provided from and to the load/εtore unit of the IEU 104 via control lineε 796. An 80 bit wide bidirectional data buε is provided by the CCU 106 to the IEU 104. However, in the present preferred implementation of the architecture 100, only the lower 64 bits are utilized by the IEU 104. The availability and support within the CCU 106 of a full 80 bit data transfer bus is provided to support εubεequent implementationε of the architecture 100 that εupport, through modificationε of the floating point data path 660, floating point operation in accordance with IEEE εtandard 754. The IEU control interface, established via request, busy, ready, read/write and with control εignalε 784 is subεtantially the same as the corresponding control signals utilized by the IFU 102. The exception being the provision of a read/write control signal to differentiate between load and εtore operationε. The width control εignalε εpecify the number of byteε being transferred during each CCU 106 access by the IEU 104; in contrast every access of the instruction cache 132 is a fixed 128 bit wide data fetch operation. The CCU 106 implements a substantially conventional cache controller function with respect to the separate instruction and data caches 132, 134. In the preferred architecture 100, the inεtruction cache 132 iε a high εpeed memory providing for the εtorage " of 256 ,128 bit wide inεtruction εets. The data cache 134 provideε for the εtorage of 1024 32 bit wide wordε of data. Inεtruction and data requests that cannot be immediately satisfied from the contents of the inεtruction and data caches 132, 134 are paεεed on to the MCU 110. For instruction cache misses, the 28 bit wide physical address is provided to the MCU 110 via the address bus 860. The request ID and additional control signals for coordinating the-'operation of the CCU 106 and MCU 110 are provided on control lines 862. Once the MCU 110 haε coordinated the necessary read access of the MAU 112, two consecutive 64 bit wide data transfers are performed directly from the HAU 112 through to the instruction cache 132. Two transfers are required given that the data bus 136 is, in the preferred architecture 100, a 64 bit wide bus. As the requested data is returned through the MCU 110 the requeεt ID maintained during the pendency of the requeεt operation iε also returned to the CCU 106 via the control lines 862. Data transfer operations between the data cache 134 and MCU 110 are substantially the same aε instruction cache operations. Since data load and store operations may reference a εingle byte, a full 32 bit wide physical addreεs iε provided to the MCU 110 via the addreεs bus 864. Interface control εignals and the request ExID are transferred via control lineε 866. Bidirectional 64 bit wide data transfers are provided via the data cache bus 138. VI . Summary /Conc lu s ion : Thus , a high-performance RISC based microprocessor architecture has been disclosed . The architecture efficiently _ implements out-of-order execution of instructions, separate main and., target inεtruction εtream prefetch instruction transfer paths, and a procedural instruction recognition and dedicated prefetch path. The optimized instruction execution unit provides multiple optimized data procesεing paths supporting integer, floating point and boolean operations and incorporates respective temporary regiεter fileε facilitating out-of-order execution and instruction cancellation while maintaining a readily established precϊέe εtate-of-the-machine εtatuε. It iε therefore to be understood that while the foregoing disclosure describes the preferred embodiment of the present invention, other variations and modifications may be readily made by those of average skill within the scope of the present invention.

Claims: Claims 1. A microprocessor for executing instructions obtained from an instruction εtore, εaid microproceεεor comprising: a) means for fetching instruction setε from an instruction εtore, each inεtruction set including an instruction; b) means, coupled to said fetching means, for buffering instruction sets, said buffering means including a first buffer and a second buffer; and c) means, coupled to εaid firεt and second buffers, for executing instructions, said executing means including register file means for storing data in a plurality of registers, a plurality of functional unit means for processing data wherein each said functional unit means processes data in a predetermined manner, bus means for providing plural data routing paths between said register file means and said plurality of functional unit means, and means for controlling the execution of instructionε. 2. The microproceεsor of Claim 1 wherein said controlling means is coupled to said first and second buffers for examining the inεtructions within the instruction εetε buffered therein, εaid controlling means including means for selecting an instruction to be executed, means for selecting instruction determined ones of εaid plurality of regiεters for the transfer of data and instruction determined ones of said plurality of functional unit means for the processing of data. 3. The microprocessor of Claim 2 wherein εaid controlling means directs the operation of said bus means to tranεfer data between said instruction determined ones of εaid plurality of regiεters and said instruction determined ones of said plurality of functional unit means. 4. The microprocesεor of Claim 1, 2, or 3 wherein εaid controlling means provides for the concurrent execution of instructionε, εaid controlling means controlling the initiation of the execution of inεtructionε baεec on the availability of εaid functional unit means for the processing of data. 5. A microprocessor comprising: a) means for obtaining a predetermined sequence of instructionε to be executed, wherein an instruction of said predetermined sequence of inεtructionε includes a register reference; b) means for storing respective data in a plurality of registerε including a predetermined register and a temporary register; and c) means, coupled to said obtaining means, for sequentially executing said predetermined sequence of instructions, said executing means including seans for directing the εtorage of data by an a-sequentially executed instruction to said temporary register where the register referenced by said a-sequentially executed instruction is said predetermined register. 6. A microprocesεor compriεing: a) means for storing data in a plurality of registerε identifiable by register referenceε, εaid plurality of registerε including a predetermined register and a temporary regiεter; b) means for obtaining a predetermined sequence of instructionε to be executed, wherein an inεtruction of εaid predetermined sequence of inεtructionε includes a regiεter reference; and c) executing means, coupled to εaid obtaining meanε, for a-εequentially executing εaid predetermined εequence of instructions, εaid executing means including means, coupled to εaid storing means, for selecting said temporary register where the sequential execution of said instruction provides said register reference to select said predetermined register for the εtorage of data. 7. The microprocesεor of Claim 6 wherein said executing means further includes aeans for determining whether all inεtructionε in said predetermined sequence of instructions prior to said instruction have been executed and meanε, responεive to εaid determining meanε and coupled to said storing means, for tranεferring the data εtored by εaid temporary register to said predetermined register.

Inventors: GARG SANJIV, HAGIWARA YASUAKI, LAU TEI-LI, LENTZ DEREK J, MIYAYAMA YOSHIYUKI, NGUYEN LE TRONG, TRANG QUANG H, WANG JOHANNES, GARG, SANJIV, HAGIWARA, YASUAKI, LAU, TEI-LI, LENTZ, DEREK, J., MIYAYAMA, YOSHIYUKI, NGUYEN, LE TRONG, TRANG, QUANG, H., WANG, JOHANNES
Applicants: SEIKO EPSON CORP, SEIKO EPSON CORPORATION
Application year: 1992
Main classification: G06F9
IPC codes: G06F9