RISC MICROPROCESSOR ARCHITECTURE WITH ISOLATED ARCHITECTURAL DEPENDENCIES

Abstract: A microprocessor design technique whereby the major functional modules of a microprocessor architecture are divided into front end and back end portions. The back end portion, which interfaces between the front end portion and memory, is common to two or more microprocessor designs, and the front end portion, which includes all instruction interpretation and execution facilities, is different for the different microprocessors.

Description: DESCRIPTION RISC MICROPROCESSOR ARCHITECTURE WITH ISOLATED ARCHITECTURAL DEPENDENCIES CROSS-REFERENCE TO RELATED APPLICATIONS This Application is related to the following applications, all of which are assigned to the assignee of the present application, and all of which are incorporated herein by reference: 1. HIGH-PERFORMANCE RISC MICROPROCESSOR ARCHITECTURE, invented by Le T. Nguyen et al, SMOS 7984 MCF/GBR, Application Serial Number 07/7 ■ _.T..006. filed 08 July 1991; 2. EXTENSIBLE RISC MICROPROCESSOR ARCHITECTURE, invented by Le T. Nguyen et al, SMOS 7985 MCF/GBR, Application Serial Number 07_ 2__________≥_L. filed08 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. 736 , 942 , filed 08 Jul y 1991: 5 . SINGLE CHIP PAGE PRINTER CONTROLLER , invented by Derek J. Lentz et al, SMOS 7991 MCF/GBR/HKW, Application Serial Number 07 / 726 , 929 , f iled 08 July 1991. 6. MICROPROCESSOR ARCHITECTURE CAPABLE OF SUPPORTING HETEROGENEOUS PROCESSORS , invented by Derek J, Lentz et al, SMOS 7992 M_F/WMB, Application Serial Number 07 / 726. 893 . filed 08 July 1991. BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to microprocessor architectures, and more particularly, to a modular microprocessor architecture capable of easy modification to satisfy differing microprocessor requirements. 2. Description of Related Art When a manufacturer designs a microprocessor, the -process tvnicallv beσinε with a new instruction set and architectural definition, setting forth the major functional blocks and their interconnections. Each of the functional blocks is then designed at a logic or circuit level and optimized for the particular microprocessor architecture defined. The entire process typically begins anew each time a new microprocessor iε to be designed. This process can be very time consuming and error-prone, ^ which undesirably lengthens the amount of time necessary to bring the product to market. In the field of integrated circuit design in general, designers have attempted to reduce the time to market for the design of new products by creating and using libraries of macrocells and standard cells. These are pre-defined and pre-designed circuit portions which a designer can call up on a computer-aided design (CAD) system and insert as desired in a larger integrated system. Macrocells and standard cellε are often made available for SSI functional blocks, such as individual logic gates, as well as some MSI and LSI blocks such as RAMs and PLAs. These small functional blocks are useful for designing new microprocessors and other circuitε, but they ά not significantly reduce the overall time required to complete the product and bring it to market. In a few instances, it iε believed that a full microprocessor, or at leaεt a bit-εlice portion of a microprocessor, has been defined as a standard cell. These, however, are limited in application to a single microprocessor architecture and minor variations thereof. Certainly the instruction set and the reεources available cannot be easily changed. Various VLSI design methodologies are described in Weste, et al. , Principles CMOS VLST Design, __ Systems Perspective, pp. 236-255 (1988), incorporated by reference herein. SUMMARY OF THE INVENTION According to the invention, the microprocessor is designed in a modular fashion which permits major functional portions of the microproceεεor to be reuεed with little or no modification in the deεign of a εecond microprocessor architecture. In particular, the architecture is divided into front end and back end portions, the front end including an instruction procesεor unit (IPU) and the back end including I/O and memory interface modules. The front end portion might include an instruction fetch unit (IFU) and an instruction execution unit (IEU) , and possibly a virtual memory unit (VMU) for translating addresses from a virtual to a physical form. The back end portion, in turn,. ' may include a cache control unit (CCU) and a memory control unit (MCU) coupled between the CCU and memory. The back end portion responds to instruction fetch requests from the front end, and returns the fetched inεtruction information back to the front end. The IPU then procesεeε the inεtruction information returned from the back end according to its own instruction set and using its own internal techniques. The IPU does not need to know how the back end is fetching the inεtructionε, and the back end does not need to know ≠ how the IPU is interpreting the instructions or generating addresseε for the CCU. The back end may also respond to read and write data requests from the IPU. Again, the IPU need not know how the back end is reading or writing the data pursuant to the requests, or even whether they are being cached. Similarly, the back end does not need to know the purpose or use of the read and write requestε made by the IPU. It can be seen that using this modular design technique, a back end portion designed for one particular microprocessor architecture can be uεed substantially without change to implement a second icroproceεεor architecture which need not be at all εimilar to the first. In particular, two different IPUs can be designed to implement entirely different instruction sets, even with differing fixed or variable length instructions and different addresεing schemes. Time to market iε εignificantly reduced because it is not necessary to.design the back end portion more than once. Similarly, two different back end portions might be designed for use with a single front end portion to provide a range of two or more performance options for customers. 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 εimplified 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 iε a further detailed block diagram of the program counter data and control path logic; Figure 5 iε a εimplified block diagram of the inεtruction 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 iε ^ a graphic illuεtration of the primary and secondary inεtruction setε as present in the last two stageε of the instruction FIFO unit of the preεent invention; Figureε 7a-c provide a graphic illustration of the reconfigurable εtateε of the primary integer regiεter set aε provided in accordance with a preferred embodiment of the present invention; Figure 8 iε a graphic illustration of a reconfigurable floating point and secondary integer register set aε provided in accordance with the preferred embodiment of the present invention; Figure 9 iε a graphic illuεtration of a tertiary boolean register set as provided in a preferred embodiment of the present invention; Figure 30 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 iε 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 is 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 εequence of operation of a preferred embodiment of the preεent invention in executing multiple instructions in accordance with the preεent invention; Figure 15 iε a simplified block diagram of the virtual memory control unit as constructed in accordance with the preferred embodiment of the preεent invention; Figure 16 is a graphic representation of the virtually memory control algorithm as utilized in a preferred embodiment of the present invention; Figure 17 is a εimplified block diagram of the cache control unit aε utilized in a preferred embodiment of the present invention. Figure 18 shows a division of the microprocessor architecture of Figure 1 into front end and back end portions; and Figure 19 is a block diagram of a second microprocessor architecture using the same back end portion aε the architecture of Figure 18. DETAILED DESCRIPTION OF THE INVENTION I. Microproceεεor Architectural Overview . . . . 11 II. Instruction Fetch Unit 14 A) IFϋ Data Path 15 B) IFD Control Path 20 C) IFD/IEU Control Interface 29 D) PC Logic Unit Detail 32 1) PF and ExPC Control/Data Unit Detail . 36 2) PC Control Algorithm Detail 43 E) Interrupt and Exception Handling 55 1) Overview 55 2) Asynchronous Interrupts: 57 3) Synchronous Exceptions 59 4) Handler Dispatch and Return 63 5) Nesting 67 6) List of Traps: 68 III. Instruction Execution Unit 69 A) IEU Data Path Detail 75 1) Register File Detail 75 2) Integer Data Path Detail 84 3) Floating Point Data Path Detail . . . 88 4) Boolean Register Data Path Detail . . 90 B) Load/Store Control Unit 95 C) IEU Control Path Detail 98 1) EDecode Unit Detail 99 2) Carry Checker Unit Detail 102 3) Data Dependency Checker Unit Detail . 103 4) Register Rename Unit Detail 104 5) Instruction Issuer Unit Detail . . . . 106 6) Done Control Unit Detail 109 7) Retirement Control Unit Detail . . . . 109 8) Control Flow Control Unit Detail . . . 110 9) Bypass Control Unit Detail Ill IV. Virtual Memory Control Unit 112 V. Cache Control Unit 115 VI. Modularity of Design 117 I. Microprocessor Architectural Overview: The architecture 100 of the preεent invention is generally εhown 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 εupport the function of the IFU 102 and IEU 104. A Memory Array Unit (MAU) 112 iε alεo provided aε 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 iε, 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 micron deεign rule low-power CMOS proceεε and compriεing some 1,200,000 transistors. The standard processor or εyεtem clock εpeed of the architecture 100 iε 40 MHz. However, in accordance with a preferred embodiment of the preεent invention, the internal processor clock speed is 160 MHz. The IFU 102 is primarily responsible for the fetching of instructionε, the buffering of inεtructionε pending execution by the IEU 104, and, generally, the calculation of the next virtual addreεε to be uεed for the fetching of next inεtructionε. In the preferred embodiments of the present invention, instructions are each fixed at a length of 32 bits. Inεtruction εetε, or "bucketε" of four instructions, are fetched by the IFU 102 simultaneously from * an inεtruction cache 132 within the CCU 106 via a 128 bit wide inεtruction bus 114. The transfer of inεtruction εetε iε coordinated between the IFU 102 and CCU 106 by control εignals provided via a control bus 116. The virtual addreεε of a inεtruction εet to be fetched is provided by the IFU 102 via an IFU combined arbitration, control and addreεε buε 118 onto a εhared arbitration, control and addreεs buε 120 further coupled between the IEU 104 and VMU 108. Arbitration for acceεs to the VMU 108 ariεeε 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 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 bitε of the virtual addreεε εupplied by the IFU 102 are provided by the address portion of the buses 118, 120 to the VMU 108 for tranεlation into a correεponding phyεical page address. For the IFU 102, this physical page addresε 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 tranεlation request iε placed with the VMU 108. The inεtruction stream fetched by the IFU 102 is, in turn, provided via an instruction stream buε 124 to the IEU 104. Control εignals are exchanged between the IFU 102 and the IEU 104 via controls lines 126. In addition, certain instruction fetch addresεeε, typically those requiring access to the register file present within the IEU 104, are provided back to the IFU via a target addresε 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 buε 130. The entire phyεical addreεε for IEU data acceεεeε iε provided via an addreεε portion of the control buε 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 εuitable for εubmisεion to the CCU 106. The virtualizing portion of the data addreεε iε 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 phyεical addreεs via the buε 120 to the IEU 104. In the preferred embodiments of the architecture 100, the IEU 104 requires the physical addreεs for use in enεuring that load/store operations occur in proper program εtream order. The CCU 106 performε the generally conventional high-level function of determining whether phyεical addreεs defined requeεtε for data can be εatiεfied 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 buseε 114, 128. Where a data acceεε 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 εource 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 requeεt aε isεued by the IFU 102 or IEU 104. The MCU 110 preferably includeε a port switch unit 142 that iε coupled by a uni-directional data buε 136 with the inεtruction 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 addresε obtained from the control bus 140 to be routed to any one of a number of ports P 0 - P N 146-^ and the bi-directional tranεfer of data from the portε 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 εyεtem memory bus 162 as required for an access of the MAU 112. Once a data transfer connection has been establiεhed, 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 0 _ n . 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 iε done to minimize latency in the tranεfer and to obviate the need for tracking or managing data that may be uniquely preεent in the MCU 110. II. Instruction Fetch Unit: The primary elementε of the Inεtruction Fetch Unit 102 are shown in Figure 2. The operation and interrelationεhip of theεe elements can best be understood by considering their participation in the IFU data and control paths. A) FD Data 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 εetε εtored in the laεt 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 at a time from the instruction bus 114. The full 128 bit wide instruction set iε 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 inεtruction εetε 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 buε 196. In addition, a direct fall through inεtruction set buε 194 iε provided to connect the inεtruction bus 114 directly with the prefetch buffer output buε 196, thereby bypaεεing the MBUF, TBUF and EBUF 158, 190, 192. In the preferred architecture 100, the MBUF 188 iε utilized to buffer inεtruction εets in the nominal or main inεtruction stream. The TBUF 190 iε utilized to buffer instruction εetε fetched from a tentative target branch instruction εtream. Conεequently, the prefetch buffer unit 260 allowε both poεεible inεtruction εtreamε 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 εet for execution following a conditional branch instruction regardlesε of the particular instruction stream eventually selected upon resolution of the conditional branch instruction. In the preferred architecture 100 invention, the proviεion of the MBUF 188 and TBUF 190 allow the inεtruction 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 εtream has been prefetched into the MBUF 188, any instruction setε in the TBUF 190 may be εi ply invalidated. Alternately, where instruction εets of the correct inεtruction εtream 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 H3UF 188 stored instruction sets are effectively invalidated by being overwritten by the TBUF 190 transferred instruction εetε. Where there is no TBUF instruction set transferred to an MBUF location, that location is simply marked invalid. Similarly, the EBDF 192 iε provided aε another, alternate prefetch path through the prefetch buffer 260. The EBUF 192 iε preferably utilized in the prefetching of an alternate inεtruction εtream that iε uεed to implement an operation εpecified by a εingle instruction, a "procedural" instruction, encountered in the MBUF 188 instruction εtream. In thiε manner, complex or extended instructions can be implemented through software routineε, or procedureε, and processed through the prefetch buffer unit 260 without disturbing the inεtruction εtreamε 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 iε held with all prior pending conditional branch inεtructionε are reεolved. This allowε conditional branch inεtructions occurring in the procedural instruction stream to be consiεtently handled through the uεe of the TBUF 190. Thuε, where a branch is taken in the procedural εtream, the target instruction setε will have been prefetched into the TBUF 190 and can be εimply laterally tranεferred to the EFUF 192. Finally, each of the MBUF 188, TBUF 190 and EBUF 192 are coupled to the prefetch buffer output buε 196 εo aε to provide any instruction set stored by the prefetch unit onto the output buε 196. In addition, a flow through bus 194 iε provided to directly tranεfer an inεtruction εet from the instruction buε 114 directly to the output bus 196. In the preferred architecture 100, the prefetch bufferε 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 buε 196 connectivity allows substantial freedom in the prefetch ordering of instruction εets retrieved from the instruction cache 132. That iε, the inεtruction fetch unit 102 generally determines and requests instruction εetε in the appropriate instruction εtream order of inεtructionε. However, the order in which inεtruction εetε are returned to the IFU 102 iε allowed to occur out-of- -IB- order aε appropriate to match the circumstanceε where some requested inεtruction εetε are available and acceεεible from the CCU 106 alone and otherε 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 setε output on the output bus 196 must generally conform to the order of instruction set requeεtε isεued 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 buε 196. Each εet of four inεtructionε that make up a εingle 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 εet is 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 conεistε of a sequence of master/εlave regiεterε 200, 204, 208, 212, 216, 220, 224. Each regiεter is coupled to itε εucceεεor to allow the contentε of the master registerε 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 successive master regiεter 208, 216, 224 during the succeeding half-cycle of operation. The input bus 198 iε connected to the input of each of the maεter regiεterε 200, 208, 216, 224 to allow loading of an instruction set from the IDecode unit 262 directly in to a maεter regiεter during the εecond half-cycle of FIFO operation. However, loading of a maεter regiεter 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 inεtruction setε εtored within the inεtruction FIFO unit 264 and, further, independent of the FIFO shifting of data through the IFIFO unit 264. Each of the master/εlave registers 200, 204, 208, 212, 216, 220, __24, in addition to providing for the full parallel storage of a 128 bit wide instruction set, alεo 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 misε and exception modify, (VMU), no memory (MCU), branch bias, εtream, and offεet (IFU) . Thiε control information originateε from the control path portion of the IFU 102 εimultaneouε with the loading of an IFIFO master regiεter with a new inεtruction set from the input buε 198. Thereafter, the control regiεter information iε εhifted in parallel concurrently with the inεtruction εets through the IFIFO unit 264. Finally, in the preferred architecture 100, the output of instruction sets from the IFIFO unit 264 is obtained εimultaneouεly from the laεt two maεter registers 216, 224 on the I_Bucket__0 and I_Bucket_l instruction set output buseε 278, 280. In addition, the correεponding control register information is provided on the, IBASV0 and IBASV1 control field buseε 282, 284. These- output buseε 278, 282, 280, 284 are all provided aε the inεtruction εtream buε 124 to the IEU 104. B) IFU 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 syεte clock εignal 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 εets into the MBUF 188, TBUF 190 and EBUF 192 are provided on the control lines 304. A number of control εignals 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 requeεted 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 requeεt can be posted to the CCU 106. Generation of the ID value is accomplished through the uεe of a circular four-bit counter. The use of a four-bit counter is significant in three regards. The first is that, typically a maximum of nine instruction εets may be active at one time in the prefetch buffer unit 260; four instruction εetε 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 buε 194. Secondly, instruction setε include four inεtructionε of four bytes each. Conεequently, the leaεt significant four bits of any addreεε selecting an inεtruction set for fetching are εuperfluouε. Finally, the prefetch request ID value can be easily aεsociated with a prefetch request by insertion aε the leaεt significant four bits of the prefetch request address; thereby reducing the total number of addresε lines required to interface with the CCU 106. To allow instruction εetε to be returned by the CCU 106 out-of-order with reεpect to the εequence of prefetch requeεts issued by the IFU 102, the architecture 100 provideε for the return of the ID requeεt value with the return of instruction εets 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 setε requeεted but not yet returned can lead to potential re-uεe of an ID value. Therefore, the four-bit counter iε preferably held, and no further instruction set prefetch requestε issued, where the next ID value would be the εa e aε that associated with an as yet outstanding fetch requeεt or another instruction εet then pending in the prefetch buffer 260. The prefetch control logic unit 266 directly manages a prefetch statuε array 268 which containε εtatuε εtorage locationε logically correεponding to each instruction εet prefetch buffer location within the MBUF 168, 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 εtatuε regiεter array 268. Within the array 268, a main buffer regiεter 308 provides for εtorage of four, four-bit ID values (MB ID), four single-bit reεerved flags (MB RES) and four single-bit valid flags (MB VAL) , each corresponding by logical bit-position to the respective inεtruction εet εtorage locationε within the MBUF 180. Similarly, a target buffer register 310 and extended buffer register 312 each provide for the εtorage of two four-bit ID values (TB ID, EB ID) , two εingle-bit reserved flagε (TB RES, EB RES), and two εingle-bit valid flagε (TB VAL, EB VAL). Finally, a flow through εtatuε 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, aε appropriate, updated by the prefetch control logic unit 266 each time a prefetch requeεt is placed with the CCU 106 and εubsequently εcanned and updated each time an inεtruction εet is returned. Specifically, upon receipt of the prefetch request εignal via the control lines 316, the prefetch control logic unit 216 increments the current circular counter generated ID value, scans the εtatus regiεter 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 requeεt εignal iε 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 buε 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 iε written into the ID εtorage location within the εtatuε regiεter 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 εtatuε flag iε εet true. When the CCU 106 is able to return a p eviouεly requested instruction set to the IFU 102, the CCU IREADY εignal iε aεεerted on control line 302 and the correεponding inεtruction εet ID iε provided on the CCU ID control lines 296. The prefetch control logic unit 266 εcanε the ID valueε and reεerved flags within the εtatus register array 268 to identify the intended deεtination of the inεtruction εet within the prefetch buffer unit 260. Only a single match iε poεεible. Once identified, the instruction set is written via the buε 114 into the appropriate location within the prefetch buffer .unit 260 or, if identified as a flow through request, provided directly to the IDecode unit 262. In either case, the valid status flag in the corresponding εtatuε regiεter array iε εet true. The PC logic unit 270, as will be described below in greater detail, tracks the virtual addresε 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 instructionε decoded by the IDecode unit 262 potentially relevant to a change in the program inεtruction εtream flow are provided on the buε 318 to a control flow detection unit 274 and directly to the PC logic block 270. The control flow detection unit 274 identifies each inεtruction in the decoded inεtruction εet that conεtitutes a control flow instruction including conditional and unconditional branch instructions, call type instructions, software traps procedural inεtructionε and variouε 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 εpecific nature of the control flow inεtructions within the inεtruction εet preεent 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 εetε from the conditional branch inεtruction target addreεε. Thuε, with the next assertion of a prefetch request on the control lines 316, the PC logic unit 270 will further asεert a control signal, via lines 316, εelecting the destination of the prefetch to be the TBUF 190, asεuming that prior prefetch inεtruction εetε 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 εignal, again via lines 316, to the PC logic unit 270 to enable the provision of a page offset portion of the target address (CCU PADDR [13:4]) via the addresε lineε 324 directly to the CCU 106. At the same time, the PC logic unit 270, where a new virtual to phyεical page tranεlation iε required further provideε a VMU requeεt εignal via control line 328 and the virtualizing portion of the target addreεε (VMU VADDR [31:14]) via the addreεε lines 326 to the VMU 108 for translation into a physical addreεs. Where a page translation iε not required, no operation by the VMU 108 iε required. Rather, the previous tranεlation result iε maintained in an output latch coupled to the buε 122 for immediate use by the CCU 106. Operational errors in the VMU 108 in performing the virtual to phyεical translation requested by the PC logic unit 270 are reported via the VMU exception and VMU misε control lineε 332, 334. The VMU miεε control line 334 reportε a translation lookaside buffer (TLB) miεε. The VMU exception control εignal, on VMU exception line 332, iε 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 εtream and then prefetching, aε if in reεponεe to an unconditional branch, a dedicated exception handling routine inεtruction εtream for diagnoεing and handling the error condition. The VMU exception and miεε control εignalε identify the general nature of the exception encountered, thereby allowing the PC logic unit 270 to identify the prefetch addresε of a correεponding exception handling routine. The IFIFO control logic unit 272 iε provided to directly support the IFIFO unit 264. Specifically, the PC logic unit 270 provideε a control εignal via the control lineε 336 to εignal 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 ' responεible for selecting the deepeεt available maεter regiεter 200, 208, 216, 224 for receipt of the inεtruction set. The output of each of the maεter control regiεterε 202, 210, 218, 226 iε provided to the IFIFO control unit 272 via the control buε 338. The control bits stored by each maεter control regiεter includes a two-bit buffer addreεε (IF_Bx_ADR) , a εingle εtream indicator bit (IF_Bx_STRM) , and a εingle valid bit (IF Bx VLD) . The two bit buffer addreεε identifies the firεt valid inεtruction within the corresponding instruction εet. That iε, instruction setε returned by the CCU 106 may not be aligned εuch that the target inεtruction of a branch operation, for example, iε located in the initial inεtruction location within the inεtruction εet. Thuε, the buffer addreεε value is provided to uniquely identify the initial instruction within an instruction set that iε to be considered for execution. The stream bit is used eεεentially aε a marker to identify the location of inεtruction εetε containing conditional control flow inεtructionε, and giving riεe to potential control flow changeε, in the εtream of instructions through the IFIFO unit 264. The main instruction stream is proceεεed through the MBUF 188 generally with a εtream bit value of 0. On the occurrence of a relative conditional branch inεtruction, for example, the corresponding instruction εet iε marked with a stream bit value of 1. The conditional branch inεtruction iε detected by the IDecode unit 262. Up to four conditional control flow inεtructions may be present in the instruction εet. The inεtruction εet is then stored in the deepeεt available maεter regiεter of the IFIFO unit 264. In order to determine the target addreεε of the conditional branch inεtruction, the current IEU 104 execution point address (DPC) , the relative location of the conditional inεtruction containing instruction set aε identified by the εtream bit, and the conditional instruction location offset in the inεtruction εet, aε provided by the control flow detector 274, are combined with the relative branch offεet value aε obtained from a correεponding branch inεtruction field via control lineε 318. The. reεult iε a branch target virtual address that is stored by the PC logic unit 270. The initial instruction εetε of the target instruction εtream 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 iε encountered, the inεtruction εet iε marked with a εtream bit value of 0. Since a εecond ^target εtream cannot be fetched, the target addreεε iε calculated and εtored by the PC logic unit 270, but no prefetch iε performed. In addition, no further inεtruct . ion εetε can be proceεεed through the IDecode unit 262, or at leaεt none that are found to contain a conditional flow control inεtruction. The PC logic unit 270, in the preferred embodimentε of the preεent invention, can manage upto eight conditional flow instructions occurring in upto two instruction εets. The target addresεeε for each of the two inεtruction εetε marked by εtream bit changes are εtored in an array of four addresε regiεterε with each target addreεε poεitioned logically with respect to the location of the corresponding conditional flow inεtruction in the inεtruction set. Once the branch result of the firεt in-order conditional flow inεtruction iε resolved, the PC logic unit 270 will direct the prefetch control unit 260, via control signals on lines 316, to transfer the contents of the TBUF 190 to the MBUF 188, if the branch is taken, and to mark invalid the contents of the TBUF 190. Any instruction εetε in the IFIFO unit 264 from the incorrect inεtruction εtream, target εtream if the branch iε not taken and main εtream if the branch iε taken, are cleared from the IFIFO unit 264. If a second or εubεeguent conditional flow control inεtruction exiεtε in the first εtream bit marked inεtruction set, that inεtruction iε handled in a consistent manner: the instruction sets from the target εtream are prefetched, inεtruction εetε from the MBUF 188 or TBUF 190 are proceεsed through the IDecode unit 262 depending on the branch bias, and the IFIFO unit 264 iε cleared of incorrect εtream inεtruction εetε when the conditional flow instruction finally reεolves. If a εecondary conditional flow instruction εet remains in the IFIFO unit 264 once the IFIFO unit 264 iε cleared of incorrect stream instruction setε, and the firεt conditional flow inεtruction εet containε no further conditional flow inεtructionε, the target addreεεes of the εecond εtream bit marked inεtruction εet are promoted to the firεt array of address registers. In any case, a next instruction εet containing conditional flow instructions can then be evaluated through the IDecode unit 262. Thus, the toggle usage of the stream bit allowε potential control flow changes to be marked and tracked through the IFIFO unit 264 for purposeε of calculating branch target a άreεses and for marking the inεtruction εet location above which to clear where the branch bias iε subεequently determined to have been incorrect for a particular conditional flow control inεtruction. Rather than actually clearing inεtruction εetε from the master regiεters, the IFIFO control logic unit 272 εi ply reεetε the valid bit flag in the control registers of the correεponding maεter regiεters of the IFIFO unit 264. The clear operation iε inεtigated by the PC logic unit 270 in a control εignal provided on lineε 336. The inputs of each of the maεter control regiεterε 202, 210, 218, 226 are directly accesεible by the IFIFO control logic unit 272 via the εtatuε buε 230. In the preferred architecture 100, the bits within theεe master control registers 202, 210, 218, 226 may be εet by the IFIFO control unit 272 concurrent with or independent of a data εhift operation by the IFIFO unit 264. Thiε capability allowε an inεtruction εet to be written into any of the maεter regiεters 200, 208, 216, 224, and the correεponding εtatuε information to be written into the,maεter control regiεterε 202, 210, 218, 226 asynchronously with respect to the operation of the IEU 104. Finally, an additional control line on the control and εtatuε buε 230 enableε and directε the FIFO operation of the IFIFO unit 264. An IFIFO shift is performed by the IFIFO control logic unit 272 in reεponεe to the εhift requeεt control εignal provided by the PC logic unit 270 via the control lineε 336. The IFIFO control unit 272, baεed on the availability of a maεter 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 tranεfer of a next appropriate inεtruction set from the prefetch bufferε 260. On tranεfer of the inεtruction εet, the correεponding valid bit in the array 268 iε reεet. Cl IFU/IEU Control Interface: The control interface between the IFU 102 and IEU 104 iε provided by the control bus 126. This control bus 126 is coupled to the PC logic unit 270 and conεiεtε of a number of control, addresε and specialized data lineε. Interrupt requeεt and acknowledge control εignalε, as paεεed via the control lineε 340, allow the IFU 102 to εignal and synchronize interrupt operations with the IEU 104. An externally generated interrupt εignal iε provided on a line 292 to the logic unit 270. In reεponεe, an interrupt requeεt control signal, provided on lines 340, causes the IEU 104 to cancel tentatively executed inεtructionε. Infornation regarding the nature of an interrupt is exchanged via interrupt information lineε 341. When the IEU 104 iε ready to begin receiving instruction sets prefetched from the interrupt service routine addresε determined by the PC logic unit 270, the IEU 104 asserts an interrupt acknowledge control signal on the lines 340. Execution of the interrupt service routine, aε prefetched by the IFU 102, will then commence. An IFIFO read (IFIFO RD) control εignal is provided by the IEU 104 to εignal that the inεtruction εet present in the deepeεt maεter regiεter 224 has been completely executed and that a next instruction εet iε desired. Upon receipt of this control εignal, the PC logic unit 270 directs the IFIFO control logic unit 272 to perform a IFIFO εhift operation on the IFIFO unit 264. A PC increment requeεt and εize value (PC INC/SIZE) iε provided on the control lineε 344 to direct the PC logic unit 270 to update the current program counter value by a correεponding εize number of inεtructions. This allows the PC logic unit 270 to maintain a point of execution program counter (DPC) that iε precise to the location of the first in-order executing instruction in the current program instruction stream. A target addresε (TARGET ADDR) iε returned on the addreεε lineε 346 to the PC logic unit 270. The target addreεε is the virtual target addreεs of a branch instruction that dependε on data εtored within the regiεter file of the IEU 104. Operation of the IEU 104 iε therefore required to calculate the target addreεε. Control flow result (CF RESULT) control εignals are provided on the control lineε 348 to the PC logic unit 270 to identify whether any currently pending conditional branch inεtruction has been resolved and whether the result is either a branch taken or not taken. Based on these control εignalε, the PC logic unit 270 can determine which of the inεtruction εetε in the prefetch buffer 260 ' and IFIFO unit 264 muεt be cancelled, if at all, aε 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 instructionε include a return from procedural inεtruction, return from trap, and return from εubroutine call. The return from trap inεtruction iε uεed equally in hardware interrupt and εoftware trap handling routineε. The εubroutine call return iε alεo uεed in conjunction with jump-and-link type callε. In each case, the return control εignalε are provided to alert the IFU 102 to reεume itε inεtruction fetching operation with reεpect to the previouεly interrupted inεtruction εtream. Origination of the εignalε from the IEU 104 allowε the preciεe operation of the εyεtem 100 to be maintained; the reεumption of an "interrupted" inεtruction εtream iε performed at the point of execution of the return instruction. A current inεtruction execution PC addreεs (Current IFPC)-iε provided on an addreεs buε 352 to the IEU 104. This addreεε value, the DPC, identifieε the preciεe instruction being executed by the IEU 104. That iε, while the IEU 104 may tentatively execute ahead instructionε past the current IFPC address, this addresε must be maintained for purposes of precise control of the architecture 100 with reεpect to the occurrence of interruptε, exceptions, and any other events that would require knowing the precise state-of-the-machine. When the IEU 304 determineε that the preciεe εtate-of-the- achine in the currently executing inεtruction εtream can be advanced, the PC Inc/Size signal is provided to the IFU 102 and immediately reflected back in the current IFPC addreεε value. Finally, an addreεs 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 regiεters within the IFU 102 by the IEU 104. Special regiεter data is generally loaded or calculated by the IEU 104 for use by the IFU 102. D) PC Logic 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, iε εhown in Figure 3. The PC control unit 362 provideε timing control over the prefetch and execution PC control unitε 364, 366 in reεponεe to control εignalε 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 addreεs offεet that εelectε an appropriate handling routine to process a respective type of trap. The prefetch PC control unit 364 is, in particular, responεible for managing program counterε neceεεary to εupport the prefetch buffers 188, 190, 192, including storing return addresses for traps handling and procedural routine instruction flows . In εupport of thiε operation, the prefetch PC control unit 364 is responsible for generating the prefetch virtual address including the CCU PADDER address on the physical address buε lines 324 and the VMU VMADDR addresε on the address lines 326. Consequently, the prefetch PC control unit 364 is responsible for maintaining the-current prefetch PC virtual addresε value. The prefetch operation iε generally initiated by the IFIFO control logic unit 272 via a control signal provided on the control lineε 316. In reεponεe, the PC control unit 362 generateε a number of control signalε provided on the control lineε 372 to operate the prefetch PC control unit 364 to generate the PADDR and, as needed, the VMADDR addresεeε on the address lines 324, 326. An increment signal, 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 addresε, .aligning for the εecond in a εeries of prefetch requeεtε, or εelecting the next full sequential instruction εet for prefetch. Finally, the current prefetch addreεε PF_PC is provided on the bus 370 to the execution PC control unit 366. New prefetch addresεeε originate from a number of sources. A primary source of addresεeε is the current IF_PC address provided from the execution PC control unit 366 via bus 352. Principally, the IF_PC addreεs provides a return address for subsequent uεe by the prefetch PC control unit 364 when an initial call, trap or procedural inεtruction occurε. The IF_PC addreεs iε εtored in regiεters in the prefetch PC control unit 364 upon each occurrence of these inεtructionε. In thiε manner, the PC control unit 362, on receipt of a IEU return εignal, via control lines 350, need merely select the corresponding return addresε regiεter within the prefetch PC control unit 364 to source a new prefetch virtual address, thereby reεuming the original program instruction εtream. Another εource of prefetch addreεεeε iε the target addreεε value provided on the relative target addreεε bus 382 from the execution PC control unit 366 or on the abεolute target 'addreεε buε 346 provided from the IEU 104. Relative target addresεeε are those that can be calculated by the execution PC control unit 366 directly. Absolute target addresseε muεt be generated by the IEU 104, εince εuch target addreεεeε are dependant on data contained in the IEU regiεter file. The target addreεε iε routed over the target addreεε bus 384 to the prefetch PC control unit 364 for uεe aε a prefetch virtual addreεε. In calculating the relative target addreεs, an operand portion of the corresponding branch instruction is also provided on the operand displacement portion of the buε 318 from the IDecode unit 262. Another εource of prefetch virtual addreεεeε iε the execution PC control unit 366. A return addreεs buε 352' iε provided to tranεfer the current IF_PC value (DPC) to the prefetch PC control unit 364. Thiε addresε iε utilized as a return addreεε where an interrupt, trap or other control flow inεtruction such aε a call has occurred within the inεtruction εtream. The prefetch PC control unit 364 iε then free to prefetch a new inεtruction εtream. The PC control unit 362 receiveε an IEU return εignal, via lineε 350, from the IEU 104 once the corresponding interrupt or trap handling routine or εubroutine haε been executed. In turn, the PC control unit 362 εelectε, via one of the PFPC control εignals on line 372 and based on an identification of the return instruction executed aε provided via lines 350, a register containing the current return virtual address. Thiε address is then uεed to continue the prefetch operation by the PC logic unit 270. Finally, another source of prefetch virtual addreεseε iε from the εpecial register•address and data bus 354. An addresε value, or at leaεt a base addresε value, calculated or loaded by the IEU 104 is transferred aε data via the buε 354 to the prefetch PC control unit 364. The baεe addreεεeε include the base addreεseε for the trap addreεε table, a faεt trap table, and a baεe procedural inεtruction diεpatch table. The buε 354 alεo allows many of the regiεterε in the prefetch and execution PC control unitε 364, 366 to be read to allow correεponding aεpectε of the εtate-of- the- achine to be manipulated through the IEU 104. The execution PC control unit 366, εubject to the control of the PC control unit 362 iε primarily reεponεible for calculating the current IF_PC addreεs value. In this role, the execution PC control unit 366 reεpondε to control εignals provided by the PC control unit 362 on the ExPc control lineε 378 and increment/εize control signalε provided on the control lineε 380 to ad uεt the IF_PC addreεε. These control εignals are generated primarily in reεponεe 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. 1) PF and ExPC Control /Data Unit Detail: Figure 4 provideε a detailed block diagram of the prefetch and execution PC control unitε 364, 366. Theεe unitε primarily conεiεt of regiεterε, incrementorε and the like, εelectorε and adder blockε. Control for managing the tranεfer of data between theεe blocks is provided by the PC Control Unit 362 via the PFPC control lines 372, the ExPC Control lines 378 and the Increment Control lineε 374, 380. - For purposes of clarity, those specific control lines are not shown in the block diagra'm of Figure 4. However, it should be understood that theεe control εignalε are provided to the blocks εhown aε deεcribed herein. Central to the prefetch PC control unit 364 iε a prefetch selector (PF_PC SEL) 390 that operateε as a central εelector of the current prefetch virtual addresε. This current prefetch address is provided on the output bus 392 from the prefetch εelector to an incrementor unit 394 to generate a next prefetch addreεε. This next prefetch address is provided on the incrementor output bus 396 to a parallel array of regiεters MBUF PFnPC 398, TBUF PFnPC 400, and EBUF PFnPC 402. These registerε 398, 400, 402 effectively εtore the next instruction prefetch addresε. However, in accordance with the preferred embodiment of the preεent invention, εeparate prefetch addreεεeε are held for the MBUF 188, TBUF 190, and EBUF 192. The prefetch addresses, aε stored by the MBUF, TBUF and EBUF PFnPC regiεterε 398, 400, 402 are reεpectively provided by the addreεε buεeε 404, 408, 410 to the prefetch εelector 390. . Thus, the PC control unit 362 can direct an immediate switch of the prefetch instruction εtream merely by directing the εelection, by the prefetch εelector 390, of another one of the prefetch regiεterε 398, 400, 402. Once that address value haε been incremented by the incrementor 394, if a next inεtruction set in the εtream iε to be prefetched, the value is returned to the appropriate one of the prefetch regiεterε 398, 400, 402. Another parallel array of regiεterε, for simplicity shown as the single special regiεter block 412, iε provided to εtore a number of εpecial addreεεeε. The regiεter block 412 includes a trap return addreεε regiεter, a procedural instruction return addreεε regiεter, a procedural inεtruction diεpatch table - >aεe addreεε regiεter, a trap routine diεpatch table base addreεs register, and a fast trap routine table baεe addreεε regiεter. Under the control of the PC control unit 362, theεe return address registerε may receive the current IFPC execution addreεε via the buε 352'. The addreεε valueε εtored by the return and baεe addreεs registerε within the regiεter block 412 may be both read and written independently by the IEU 104. The regiεter are εelected and valueε tranεferred via the εpecial regiεter addreεε and data bus 354. A εelector within the εpecial regiεter block 412, controlled by the PC control unit 362, allowε the addreεεeε εtored by the regiεterε of the regiεter block 412 to be put on the special regiεter output buε 416 to the prefetch εelector 390. Return addreεεeε are provided directly to the prefetch εelector 390. Baεe address valueε are combined with the offεet value provided on the interrupt offεet bus 373 from the interrupt control unit 363. Once εourced to the prefetch εelector 390 via the buε 373', a εpecial addreεs can be uεed aε the initial addreεs for a new prefetch inεtruction εtream by thereafter continuing the incremental loop of the addresε through the incrementor 394 and one of the prefetch regiεterε 398, 400, 402. Another εource of addreεεeε to the prefetch εelector 390 iε an array of registerε within the target addreεε register block 414. The target regiεterε within the block 414 provide for εtorage of, in the preferred embodiment, eight potential branch target addreεεeε. These eight εtorage locations logically correspond to the eight potentially executable inεtructionε held in the loweεt two maεter regiεters 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 inεtruction stream through the TBUF 190. In particular, if a conditional branch bias iε εet εuch that the PC Control Unit 362 immediately beginε prefetching of a target inεtruction εtream, the target address is immediately fed through the target register block 414 via the addreεε buε 418 to the prefetch selector 390. Once incremented by the incrementor 394, the addreεε iε εtored back to the TBUF PFnPC 400 for uεe in εubεequent prefetch operations of the target inεtruction εtream. If additional branch inεtructionε occur within the target instruction stream, the target addreεεeε of εuch secondary brancheε are calculated and εtored in the target register array 414 pending use upon reεolution of the firεt conditional branch inεtruction. A calculated target addresε as εtored by the target regiεter block 414, is transferred from a target addreεε calculation unit within the execution PC control unit 366 via the addreεε lineε 382 or from the IEU 104 via the abεolute target addresε buε 346. The Addreεs value tranεferred through the prefetch PP_PC εelector 390 iε a full thirty-two bit virtual addreεε value. The page εize, in the preferred embodiment of the present invention is fixed at 16 Byteε, corresponding to the maximum page offset address value [13:0]. Therefore, a VMU page translation iε not required unless there is a change in the current prefetch virtual page address [27:14]. A co paritor in the prefetch selector 390 detects this- circumstance. A VHU translation request εignal (VMXLAT) iε provided via line 372' to the PC control unit 362 when there iε a change in the virtual page addreεε, either due incrementing accross a page boundary or a control flow branch to another page address. In turn, the PC control unit 362 directs the placement of the VM VADDR addreεs on lineε 326, in addition to the CCU PADDR on lines 324, both via a buffer unit 420, and the appropriate control εignalε on the VMU control lines 326, 328, 330 to obtain a VMU virtual to phyεical page tranεlation. Where a page tranεlation iε not required, the current phyεical page addresε [31:14] iε maintained by a latch at the output of the VMU unit 108 on the bus 122. The virtual addreεε provided onto the buε 370 is incremented by the incrementor 394 in reεponεe to a εignal provided on the increment control line 374. The incrementor 394 increments by a value representing an instruction set (four instructionε or εixteen byteε) in order to εelect a next instruction εet. The low-order four bitε of a prefetch addreεε aε provided to the CCU unit 106 are zero. Therefore the actual target address instruction in a firεt branch target inεtruction εet may not be located in the firεt inεtruction location. However, the low-order four bitε of the addreεε are provided to the PC control unit 362 to allow the proper firεt branch inεtruction 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 addresε, to εelect the proper firεt inεtruction for execution in a non-aligned target inεtruction εet, is performed only for the first prefetch of a new inεtruction εtream, i.e., any firεt non-εequential inεtruction set addresε in an inεtruction εtream. The non-aligned relationεhip between the- addreεε of the firεt inεtruction in an inεtruction εet and the prefetch address used in-prefetching the instruction εet can and is thereafter ignored for the duration of the current εequential inεtruction εtream. The remainder of the functional blockε . εhown in Figure 4 compriεe the execution PC control unit 366. In accordance with the preferred embodiment of the preεent invention, the execution PC control unit 366 incorporateε itε own independently functioning program counter incrementor. Central to this function iε an execution selector (DPC SEL) 430. The addresε output by the execution εelector 430, on the addreεε buε 352', iε the present execution addreεε (DPC) of the architecture 100. Thiε execution addreεε iε provided to an adder unit 434. The increment/size control εignalε provided on the lineε 380 εpecify an instruction increment value of from one to four that the adder unit 434 addε to the addresε obtained from the εelector 430. Aε the adder 432 additionally performs an output latch function, the incremented next execution addreεε iε provided on the addreεs lines 436 directly back to the execution selector 430 for uεe in the next execution increment cycle. The initial execution addreεε and all εubsequent new stream addreεseε are obtained through a new εtream register unit 438 via the address lines 440. The new εtream regiεter unit 438 allowε the new current prefetch addreεε, aε provided on the PFPC addreεε buε 370 from the prefetch εelector 390 to be paεsed on to the addreεs buε 440 directly or stored for subsequent uεe. That iε, where the prefetch PC control unit 364 determineε to begin prefetching at a new virtual addresε, the new stream addreεs iε temporarily εtored by the new εtream regiεter unit 438. The PC control unit 362, by itε participation in both the prefetch and execution increment cycleέ, holdε the new stream addreεε in the new εtream regiεter 438 unit until the execution addreεs haε reached the program execution point correεponding to the control flow inεtruction that inεtigated the new inεtruction εtream. The new εtream addreεε is then output from the new stream regiεter unit 438 to the execution εelector 430 to initiate the independent generation of execution addreεεeε in the new inεtruction εtream. In accordance with the preferred embodimentε of the present invention, the new stream regiεter unit 438 provides for the buffering of two control flow inεtruction target addresses. By the immediate availability of the new stream addresε, there is esεentially no latency in the switching of the execution PC control unit 366 from the generation of a current εequence of execution addresseε to a new stream sequence of execution addresεeε. Finally, an IFPC εelector (IF_PC SEL) 442 is provided to ultimately iεsue the current IFPC addreεs on the addreεs bus 352 to the IEU 104. The inputs to the IFPC εelector 442 are the output addresses obtained from either the execution selector 430 or new stream regiεter unit 438. In moεt inεtanceε, the IFPC εelector 442 iε directed by the PC control unit 362 to εelect the execution addreεε output by the execution εelector 430. However, in order to further reduce latency in switching to a new virtual addreεs uεed to initiate execution of a new instruction εtream, the selected addresε provided from the new εtream regiεter unit 438 can be bypassed via buε 440 directly to the IFPC selector 442 for provision aε the current IFPC execution addreεε. The execution PC control unit 366 iε capable of calculating all relative branch target addresses. The current execution point addresε and the new stream register unit 438 provided addreεε are received by a control flow εelector (CF_PC) 446 via the addreεε buεeε 352', 440. Consequently, the PC control unit 362 haε εubεtantial flexibility in εelecting the exact initial addreεε from which to calculate a target addreεs. This initial, or base, address is provided via address bus 454 to a target address ALU 450. A second input value to the target ALU 450 is provided from a control flow displacement calculation unit 452 via bus 458. Relative branch instructions, in accordance with the preferred architecture 100, incorporate a displacement value in the form of an immediate mode constant that specifieε a relative new target addreεε. The control flow diεplacement calculation unit 452 receiveε the operand displacement value initially obtained via the IDecode unit operand output bus 318. Finally, an offset 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 lineε 378' from the PC control unit 362. The magnitude of the offεet value iε determined by the PC control unit 362 based on the addreεε offεet between the baεe addreεε provided on the addreεs lineε 454 and the addreεε of the current branch inεtruction for which the relative target address is being calculated. That iε, the PC control unit 362, through its control of the IFIFO control logic unit 272 tracks the number of instructions separating the instruction at the current execution point addresε (requeεted by CP_PC) and the instruction that iε currently being proceεεed by the IDecode unit 262 and, therefore, being proceεεed by the PC logic unit 270 to determine the target addreεε for that -inεtruction. Once the relative target addreεs has been calculated by t_he target addresε ALU 450, the target address is written into a corresponding one of the target regiεterε 414 via the addreεε buε 382. 2 ) PC Control Algorithm Detail: 1. Main Inεtruction Stream Proceεεing: MBUF PFnPC 1.1 the address of the next main flow prefetch instruction iε εtored in the MBUF PFnPC. 1.2 in the abεence of a control flow inεtruction, a 32 bit incrementor adjuεtε the addreεε value in the MBUF PFnPC by εixteen byteε (xl6) with each prefetch cycle. 1.3 when an unconditional control flow inεtruction iε IDecoded, all prefetched data fetched subεequent to the inεtruction εet will be fluεhed and the MBUF PFnPC iε loaded, through the target register unit, PF_PC εelector and incrementor, with the new main inεtruction εtream addreεε. The new address iε alεo stored in the new stream regiεterε. 1.3.1 the target addreεε of a relative unconditional control flow iε calculated by the IFU from regiεter data maintained by the IFU and from operand data following the control flow inεtruction. 1.3.2 the target addreεs of an absolute unconditional control flow inεtruction iε eventually calculated by the IEU from a regiεter reference, a baεe register value, and an index register value. 1.3.2.1 instruction prefetch cycling stallε until the target addreεε iε returned by the IEU for absolute addreεs control flow instruction; instruction execution cycling continues. 1.4 the addresε of the next main flow prefetch inεtruction εet, resulting from an unconditional control flow instruction, is bypaεεed through the target addreεε regiεter unit, PF_PC εelector and incrementor and routed for eventual εtorage in the MBUF PFnPC; prefetching continueε at 1.2. 2. Procedural Inεtruction Stream Proceεεing: EBUF PFnPC 2.1 a procedural inεtruction may be prefetched in the main or branch target inεtruction εtream. If fetched in a target εtream, εtall prefetching of the procedural εtream until the conditional control flow instruction resolves and the procedural instruction iε tranεferred to the MBUF. Thiε allowε the TBUF to be uεed in handling of conditional control flowε that occur in the procedural inεtruction εtream. 2.1.1 a procedural inεtruction εhould not appear in a procedural inεtruction stream, i.e., procedural inεtructions εhould not be nested: a return from procedural inεtruction will return execution to the main inεtruction flow. In order to allow neεting, an additional, - dedicated return from neεted procedural inεtruction would be required. While the architecture can readily εupport εuch an inεtruction, the need for a neεted procedural instruction capability will not likely improve the performance of the architecture. 2.1.2 in a main inεtruction stream, a procedural instruction stream that, in turn, includes firεt and εecond conditional control flow inεtruction containing inεtruction εetε will εtall prefetching with reεpect to the εecond conditional control flow inεtruction εet until any conditional control flow inεtructionε in the firεt εuch inεtruction εet are reεolved and the εecond conditional control flow instruction set has been transferred to the MBUF. 2.2 procedural instructionε provide a relative offεet, included aε an immediate mode operand field of the instruction, to identify the procedural routine starting addreεε: 2.2.1 the offset value provided by the procedural inεtruction iε combined with a value contained in a procedural baεe addreεs (PBR) regiεter 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 register move inεtruction. 2.3 when a procedural inεtruction iε encountered, the next main inεtruction εtream IF_PC addreεε iε εtored in the uPC return addreεε register and the procedure-in-progreεε bit in the processor statuε regiεter (PSR) is εet. 2.4 the εtarting address of the procedural stream is routed from the PBR regiεter (pluε the procedural instruction operand offset value) to the PF_?C selector. 2.5 the εtarting addreεε of the procedural εtream iε εimultaneouεly provided to the new εtream register unit and to the incrementor for incrementing (xl6); the incremented addresε is then εtored in the EBUF PFnPC. 2.6 in the abεence of a control flow instruction, a 32 bit incrementor adjusts addresε value (xl6 in the EBUF PFnPC with each procedural inεtruction prefetch cycle. 2.7 when an unconditional control flow inεtruction iε IDecoded, all prefetched data fetched subsequent to the branch instruction will be fluεhed and the EBUF PFnPC iε loaded with the new procedural inεtruction εtream addreεε. 2.7.1 the target addreεε of a relative unconditional control flow inεtruction iε calculated by the IFU from IFU maintained regiεter 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 baεe regiεter value, and an index regiεter value. 2.7.2.1 instruction prefetch cycling stalls until the target addreεε iε returned by the IEU for abεolute addresε brancheε; execution cycling continueε. 2.8 the addreεε of the next procedural flow prefetch inεtruction εet iε εtored in the EBUF PFnPC and prefetching continueε at 1.2. 2.9 when a return from procedure instruction is IDecoded, prefetching continues from the addreεε εtored in the uPC regiεter, which iε then incremented (xl6) and returned to the MBUF PFnPC regiεter for εubεequent prefetcheε. Branch Inεtruction Stream Proceεεing: TBUF PFnPC 3.1 when a conditional control flow inεtruction, occuring in a firεt inεtruction set in the MBUF instruction εtream, iε IDecoded, the target addreεε iε determined by the IFU if the target addreεs is relative to the current addresε or by the IEU for absolute addreεεeε. 3.2 for "branch taken biaε": 3.2.1 if the branch iε to an abεolute addreεε, εtall inεtruction prefetch cycling until the target addresε iε returned by the IEU; execution cycling continueε. 3.2.2 load the TBUF PFnPC with the branch target address by thransfer 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, εtall prefetching. 3.2.4 the 32 bit incrementor adjuεtε (xl6) the addreεε value in the TBUF PFnPC with each prefetch cycle. 3.2.5 εtall the prefetch operation on IDecode of a conditional control flow instruction, occuring in a second instruction set in the target inεtruction εtream until the all conditional branch inεtructionε in the firεt (primary) εet are reεolved (but go ahead and calculate the relative target addreεε and εtore in target reiεters) . 3.2.6 if conditional branch in the firεt inεtruction εet resolves to "taken": 3.2.6.1 flush instruction sets following the first conditional flow instruction set in the MBUF or EBUF, if the εource of the branch was the EBUF inεtruction εtream aε determined from the procedure-in- progreεε bit. 3.2.6.2 transfer the TBUF PFnPC value to MBUF PFnPC or EBUF baεed on the εtate of the procedure-in-progreεε bit. 3.2.6.3 tranεfer the prefetched TBUF inεtructionε to the MBUF or EBUF baεed on the εtate of procedure- in-progreεε bit. 3.2.6.4 if a εecond conditional branch instruction set has not been IDecoded, continue MBUF or EBUF prefetching operations based on the εtate of the procedure-in-progreεε bit. 3.2.6.5 if a εecond conditional branch inεtruction has been IDecoded, begin processing that inεtruction (go to εtep 3.3.1). 3.2.7 if the conditional control for inεtruction(ε) in the firεt conditional inεtruction εet resolves to "not taken": 3.2.7.1 flush the IFIFO and IEU of instruction εetε and inεtructionε from the target inεtruction εtream. 3.2.7.2 continue MBUF or EBUF prefetching operationε. 3.3 for "branch not taken biaε": 3.3.1 εtall prefetch of inεtructionε into the MBUF; execution cycling continueε. 3.3.1.1 if the conditional control flow inεtruction in the firεt conditional inεtruction set is relative, calculate the target addreεε and store in the target regiεterε. 3.3.1.2 if the conditional control flow inεtructions in ' the first conditional instruction set iε abεolute, wait for the IEU to calculate the target addreεε and return the addreεs to the target registerε. 3.3.1.3 stall the prefetch operation on IDecode of a conditional control flow inεtruction in a εecond inεtruction εet until the conditional control flow inεtruction(ε) in the firεt conditional inεtruction εet inεtruction iε reεolve . 3.3.2 once the target address of the first conditional branch iε calculated, load into TBUF PFnPC and also begin prefetching instructions into the TBUF concurrent with execution of the main instruction εtream. Target inεtruction εetε are not loaded into the IFIFO (the branch target inεtructions are thus on hand when each conditional control flow inεtruction in the firεt inεtruction set resolveε) . 3.3.3 if a conditional control flow instruction in the firεt εet reεolveε to "taken": 3.3.3.1 fluεh the MBUF or EBUF, if the εource of the branch was the EBUF instruction stream, as determined from the εtate of the procedure- in-progreεε bit, and the IFIFO and IEU of inεtructionε from the main εtream following the firεt conditional branch inεtruction set. 3.3.3.2 transfer the TBUF PFnPC value to MBUF PFnPC or EBUF, aε determined from the εtate of the procedure- in-progreεε bit. 3.3.3.3 tranεfer the prefetched TBUF inεtructionε to the MBUF or EBUF, aε determined from the εtate of the procedure-in-progreεε bit. 3.3.3.4 continue MBUF or EBUF prefetching operationε, aε determined from the state of the procedure-in-progreεε bit. 3.3.4 if a conditional control flow inεtruction in the firεt εet reεolveε to "not taken": 3.3.4.1 fluεh the TBUF of inεtruction εetε from the target instruction εtream. 3.3.4.2 if a εecond conditional branch inεtruction haε not been IDecoded, continue MBUF or EBUF, aε determined from the εtate of the procedure-in-progreεε bit, prefetching operationε. 3.3.4.3 if a εecond conditional branch inεtruction haε been IDecoded, begin proceεεing that inεtruction (go to step 3.4.1). 4. Interrupts, Exceptions and Trap Inεtructionε. 4.1 Traps generically include: 4.1.1 Hardware Interrupts. 4.1.1.1 asynchronously (external) occurring events, internal or external. 4.1.1.2 can occur at any time and persiεt. 4.1.1.3 εerviced in priority order between atomic (ordinary) inεtructionε and may εuεpend procedural inεtructionε. 4.1.1.4 the εtarting addreεε of an interrupt handler is determined aε the vector number offεet into a predefined table of trap handler entry pointε. 4.1.2 Software Trap Instructions. 4.1.2.1 synchronously (internal) occurring inεtructionε. 4.1.2.2 a εoftware inεtruction that executeε aε an exception. 4.1.2.3 the εtarting addreεε of the trap handler iε determined from the trap number offεet combined with a baεe addreεε value stored in the TBR or FTB register. 4.1.3 Exceptions. 4.1.3.1 Events occurring εynchronouεly with an instruction. 4.1.3.2 handled at the time the instruction is executed. 4.1.3.3 due to consequenceε of the exception, the excepted inεtruction and all subsequent executed instructions are cancelled. 4.1.3.4 the εtarting addreεε of the exception handler iε determined from the trap number offεet into a predefined table of trap handler entry point. 4.2 Trap instruction stream operations occur in¬ line with the then currently executing instruction εtream. 4.3 Traps may nest, provided the trap handling routine εaveε the xPC addreεs prior to a next allowed trap -- failure to do so will corrupt the state of the machine if a trap occurs prior to completion of the current trap operation. 5. Trap Inεtruction Stream Proceεsing: xPC. 5.1 when a trap iε encountered: 5.1.3 if an asynchronous interrupt, the execution of the currently executing inεtruction(ε) iε εuεpended. 5.1.2 if a εynchronouε exception, the trap iε proceεεed upon execution of the excepted instruction. 5.2 when a trap iε proceεεed: 5.2.1 interrupts are diεabled. 5.2.2 the current IF_PC addreεε iε εtored in the xPC trap εtate return addreεε regiεter. 5.2.3 the IFIFO and the MBUF prefetch bufferε at and subsequent to the IF_PC address are flushed. 5.2.4 executed instructions at and subsequent to the addresε IF_PC and the reεultε of thoεe inεtructionε are fluεhed from the IEU. 5.2.5 the MBUF PFnPC iε loaded with the addreεε of the trap handler routine. 5.2.5.1 εource of a trap addreεε either the TBR or FTB regiεter, depending on the type of trap aε determined by the trap number, which are provided in the εet of εpecial regiεterε. 5.2.6 inεtructions are prefetched and dropped into the IFIFO for execution in a normal manner. 5.2.7 the instructionε of the trap routine are then executed. 5.2.7.1 the trap handling routine may provide for the xPC addreεε to be saved to a predefined location and interrupts re-enabled; the xPC regiεter iε read/write via a εpecial regiεter move inεtruciton and the εpecial regiεter addreεε and data buε. 5.2.8 the trap εtate must be exited by the execution of a return from trap inεtruction. 5.2.8.1 if prior saved, the xPC addreεε muεt be reεtored from its predefined location before executing the return from trap inεtruction. 5.3 when a return from trap is executed: 5.3.1 interrupts are enabled. 5.3.2 the xPC addresε iε returned to the current inεtruction -εtream regiεter MBUF or EBUF PFnPC, aε determined from the εtate of the procedure-in-progreεε bit, and prefetching continueε from that addreεε. 5.3.3 the xPC addreεε iε reεtored to the IF_PC register through the new stream regiεter. Ε ) Interrupt and Exception Handling: 1 ) Overview: Interruptε and exceptionε will be proceεεed, aε long aε they are enabled, regardleεε of whether the processor iε executing from the main inεtruction εtream or a procedural inεtruction εtream. Interruptε and exceptionε are εerviced in priority order, and persist until cleared. The starting addresε of a trap handler iε determined aε the vector number offεet into a predefined table of trap handler addreεseε as described below. Interrupts and exceptionε are of two baεic typeε in the preεent embodiment, thoεe which occur εynchronously with particular instructionε in the inεtruction εtream, and thoεe which occur aεynchronouεly with particular inεtructionε in the inεtruction εtream. The terms interrupt, exception, trap and fault are used interchangeably herein. Asynchronous interruptε are generated by hardware, either on-chip or off-chip, which doeε not operate εynchronouεly with the inεtruction εtream. For example, interruptε generated by an on- chip timer/counter are aεynchronouε, aε are hardware interrupts and non-maskable interrupts (NMI) provided from off-chip. When an aεynchronouε interrupt occurε, the processor context is frozen, all trapε are diεabled, certain proceεεor statuε information iε εtored, and the proceεεor vectorε to an interrupt handler correεponding to the particular interrupt received. After the interrupt handle ' r completes itε proceεεing, program execution continues with the inεtruction following the laεt completed inεtruction in the εtream which waε executing when the interrupt occurred. Synchronous exceptions are those that occur εynchronouεly with inεtructionε in the inεtruction εtream. Theεe exceptionε occur in relation to particular inεtructionε, and are held until the relevant inεtruction iε to be executed. In the preferred e bodimentε, εynchronous exceptions arise during prefetch, during inεtruction decode, or during inεtruction execution. Prefetch exceptions include, for example, TLB miss or other VMU exceptionε. Decode exceptions ariεe, for example, if the inεtruction being decoded iε an illegal inεtruction or doeε not match the current privilege level of the proceεεor. Execution exceptionε ariεe due to arithmetic errors, for example, εuch as divide by zero. Whenever theεe exceptions occur, the preferred embodimentε maintain them in correεpondence with the particular inεtruction which caused, the exception, until the time at which that inεtruction iε to be retired. At that time, all prior completed inεtructionε are retired, any tentative results from the inεtruction which cauεed the exception are fluεhed, aε are the tentative reεultε of any following tentatively executed inεtructionε. Control iε then transferred to an exception handler corresponding to the higheεt priority exception which occurred for that inεtruction. Software trap inεtructionε are detected at the IDecode stage by CF_DET 274 (Fig. 2) and are handled similarly to both unconditional call inεtructionε and other εynchronouε traps. That is, a target addreεε is calculated and prefetch continues to the then-current prefetch queue (-EBUF or MBUF). At the same time, the exception is also noted in correspondence with the instruction and is handled when the instruction is to be retired. All other types of synchronouε exceptionε are merely noted and accumulated in correεpondence with the particular inεtruction which cauεed it and are handled at execution time. 2) Aεvnchronouε Interruptε: Asynchronouε interruptε are εignaled to the PC logic unit 270 over interrupt lineε 292. As shown in Figure 3, these lineε are provided to the interrupt logic unit 363 in the PC logic unit 270, and compriεe an NMI line, an IRQ line and a set of interrupt level lineε (LVL) . The NMI line signals a nonmaskable interrupt, and derives from an external εource. It is the highest priority interrupt except for hardware reset. The IRQ line also derives from an external εource, and indicateε when an external device iε requesting a hardware interrupt. The preferred embodiments 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 lineε (LVL). The memory error line iε activated by the MCU 110 to εignal various kinds of memory errors. Other aεynchronouε interrupt lineε (not εhown) 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 interruptε, aε well aε the synchronous exceptions deεcribed below, have a correεponding 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 is 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 aεynchronouε interruptε iε εignaled to the interrupt logic unit 363, the interrupt control unit 363 εendε out an interrupt regueεt to the IEU 104 over INT REQ/ACK lineε 340. Interrupt control unit 363 alεo εendε a εuεpend prefetch εignal to PC control unit 362 over lineε 343, cauεing the PC control unit 262 to stop prefetching inεtructionε. The IEU 104 either cancels all then-executing inεtructionε, and fluεhing all tentative reεultε, or it may allow some or all inεtructionε to complete. In the preferred embodimentε, any then-executing inεtructionε are canceled, thereby permitting the faεteεt reεponεe to aεynchronouε interrupts. In any event, the DPC in the execution PC control unit 366 iε updated to correεpond to the laεt inεtruction which haε been completed and retired, before the IEU 104 acknowledges the interrupt. All other prefetched instructions in MBUF, EBUF, TBUF and IFIFO 264 are alεo cancelled. Only when the IEU 104 iε ready to receive inεtructionε from an interrupt handler doeε it εend an interrupt acknowledge εignal on INT REQ/ACK lineε 340 back to the interrupt control unit 363. The interrupt control unit 363 then dispatcheε to the appropriate trap handler as described below. 3) Synchronouε Exceptionε: For εynchronouε exceptionε, the interrupt control unit 363 maintainε a εet of four internal exception bitε (not shown) for each instruction εet, one bit correεponding to each inεtruction in the εet. The interrupt control unit 363 alεo maintainε an indication of "the particular trap numberε, if any detected for each inεtruction. If the VMU εignalε a TLB miεs or another VMU exception while a particular instruction εet is being prefetched, thiε information iε tranεmitted to the PC logic unit 270, and in particular to the interrupt control unit 363, over the VMU control lineε 332 and 334. When the interrupt control unit 363 receiveε εuch a εignal, it εignalε the PC control unit 362 over line 343 to εuεpend further prefetcheε. At the same time, the interrupt control unit 363 setε the VM_Miεε or VM_Excp bit, aε appropriate, aεsociated the prefetch buffer to which the instruction set was destined. The interrupt control unit 363 then sets all four internal exception indicator bits corresponding to that inεtruction εet, since none of the inεtructionε in the εet are valid, and εtoreε the trap number for the particular exception received in correεpondence with each of the four inεtructionε in the faulty inεtruction εet. The εhifting and executing of inεtructionε prior to the faulty inεtruction εet then continueε aε uεual until- the faulty εet reaches the lowest level in the IFIFO 264. Similarly, if other synchronous exceptions are detected during the shifting of an inεtruction through the prefetch bufferε 260, the IDecode unit 262 or the IFIFO 264, thiε information is also transmitted to the interrupt control unit 363 which sets the internal exception indicator bit corresponding to the inεtruction generating the exception and εtoreε the trap number in correεpondence with that exception. As with prefetch εynchronouε exceptions, the shifting and executing of instructionε prior to the faulty inεtruction then continueε as usual until the faulty εet reaches the loweεt level in the IFIFO 264. In the preferred embodimentε, the only type of exception which iε detected during the εhifting of an instruction through the prefetch bufferε 260, the IDecode unit 262 or the IFIFO 264 iε a εoftware trap instruction. Software trap inεtructionε 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 εynchronouε exceptions wait until the instruction reaches the execution unit 104. Thiε avoidε the possibility that certain exceptions, εuch aε arriεing from the handling of privileged instruction, might be signaled on the basis of a procesεor εtate which could change before the effective in-order-execution of the inεtruction. Exceptionε which do not depend on the proceεεor εtate, εuch aε illegal instruction, could be detected in the IDecode stage, but hardware is minimized if the same logic detectε all pre- execution εynchronouε exceptionε (apart from VMU exceptions). Nor iε there any time penalty imposed by waiting until instructionε reach the execution unit 104, εince the handling of such exceptionε is rarely time critical. Aε mentioned, software trap inεtructions are detected at the IDecode stage by the CF_DET unit 274. The internal exception indicator bit correεponding to that instruction in the interrupt logic unit 363 iε set and the software trap number, which can be any number from 0 to 127 and which iε εpecified in an immediate mode operand field of the εoftware trap- instruction, iε εtored in correspondence with the trap inεtruction. Unlike prefetch synchronouε exceptionε, however, εince εoftware trapε are treated aε both a control flow inεtruction and aε a εynchronouε exception, the interrupt control unit 363 does not signal PC control unit 362 to suspend prefetches when a software trap instruction is detected. Rather, at the same time the instruction iε εhifting through the IFIFO 264, the IFU 102 prefetcheε 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εmitε the exception indicator bitε for that inεtruction εet aε a 4-bit vector to the IEU 104 over the SYNCH_INT_INFO lineε 341 to indicate which, if any, of the instructions in the inεtruction set have already been determined to be the εource of a εynchronouε exception. The IEU 104 doeε not respond immediately, but rather permits all the inεtructionε in the inεtruction εet to be εcheduled in the normal courεe. Further exceptionε, εuch aε integer arithmetic exceptionε, may be generated during execution. Exceptionε which depend on the current εtate of the machine, εuch aε due to the execution of a privileged inεtruction, are alεo detected at thiε time, and in order to ensure that the εtate of the machine iε current with reεpect to all previous inεtructionε in the inεtruction εtream, all instructionε which have a poεεibility of affecting the PSR (εuch aε εpecial move and returns from trap inεtructionε) are forced to execute in order. Only when an inεtruction that iε the εource of a synchronous exception of any sort is about to be retired, is the occurance 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 inεtruction εtream prior to the first instruction which haε a εynchronous exception, and flushes the tentative resultε from any tentatively executed inεtructionε which occur εubsequently in the instruction stream. The particular instruction that caused the exception is also flushed since that instruction will typically be re- executed upon return from trap. The IF_PC in the execution PC control unit 366 is then updated to correspond to the last instruction actually retired, and the before any exception iε εignaled to the interrupt control unit 363. When the inεtruction that iε the εource 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, instructionε in the retiring inεtruction εet (regiεter 224) had a εynchronouε exception, as well as information indicating the source of the first exception in the instruction εet. The information in the 4-bit exception vector returned by IEU 104 iε an accumulation of the 4-bit exception vectorε provided to the IEU 104 by the interrupt logic unit 363, aε well as exceptionε 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 εtored in the interrupt control unit 363 due to exceptionε detected on prefetch or IDecode, iε sufficient for the interrupt control unit 363 to determine the nature of the higheεt priority εynchronous exception and its trap number. 4. Handler Dispatch and Return: After an interrupt acknowledge signal iε received over lines 340 from the IEU; or after a non- zero exception vector iε received over lineε 341, the current DPC iε temporarily εtored aε a return addreεε in an xPC regiεter, which iε one of the εpecial regiεters 412 (Figure 4). The current proceεεor εtatuε regiεter (PSR) is also stored 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 regiεterε 412. The addreεε of a trap handler iε calculated aε a trap baεe regiεter addreεε pluε an offεet. The PC logic unit 270 maintains two baεe regiεterε for trapε, both of which are part of the special regiεters 412 (Figure 4), and both of which are initialized by εpecial move instructions executed previously. For most traps, the baεe regiεter uεed to calculate the addreεε of the handler iε a trap base register TBR. The interrupt control unit 363 determineε the highest priority interrupt or exception currently pending and, through a look-up table, determines the trap number aεsociated therewith. This is provided over a εet of INT_OFFSET lineε 373 to the prefetch PC control unit 364 as an offset to the εelected baεe regiεter. Advantageously, the vector address iε calculated by merely concatenating the offεet bitε aε low-order bitε to the higher order bitε obtained from the TBR regiεter. Thiε avoids any need for the delayε of an adder. (Aε uεed herein, the 2 1 bit iε referred to aε the i'th order bit. ) For example, if trapε are numbered from 0 through 255, repreεented aε an 8 bit value, the handler addresε may be calculated by concatenating the 8 bit trap number to the end of a 22-bit TBR stored value. Two low-order zero bitε may be appended to the trap number to ensure that the trap handler address always occurs on a word boundary. The concatenated handler addreεε thuε constructed is provided aε one of the inputε, 373; to the prefetch selector PF_PC Sel 390 (Figure 4), and iε εelected aε the next addreεs from which instructions are to be prefetched. The vector handler addreεε for trapε uεing the TBR register are all only one word apart. Thuε, the inεtruction at the trap handler addreεs must be a preliminary branch inεtruction to a longer trap handling routine. Certain traps require very careful handling, however, to prevent degradation of syεtem performance. TLB trapε, for example, muεt be executed very quickly. For thiε reason, the preferred embodiments include a fast trap mechanism designed to allow the calling of εmall trap handlerε without the coεt of thiε preliminary branch. In addition, faεt trap handlerε can be located independently in memory, in on-chip ROM, for example, to eliminate memory εyεte penaltieε asεociated with RAM locationε. In the preferred embodiments, the only traps which result in faεt trapε are the VMU exceptions mentioned above. Fast traps are numbered separately from other traps,,and have a range from 0 to 7. However, they have the εame priority aε MMU exceptionε . When the interrupt control unit 363 recognizeε a faεt trap as the highest priority trap then pending, it causes a fast trap baεe regiεter (FTB) to be εelected from the εpecial regiεterε 412 and provided on the lineε 416 to be combined with the trap offset. The resulting vector addresε provided to the prefetch εelector PF_PC Sel 390, via lineε 373', iε then a concatenation of the high-order 22 bits from the FTB register, followed by three bitε representing the faεt trap number, followed by seven bitε of 0'ε. Thus, each faεt trap addreεs is 128 bytes, or 32 words apart. When called, the procesεor -brancheε to the εtarting word and may execute programε within the block or branch out ofit. Execution of εmall programε, εuch as εt≥ndard TLB handling routineε which may be implemented in 32 inεtructionε or leεε, iε faεter than ordinary trapε becauεe 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 byteε (i.e., occupy four addreεs locations) in the preferred embodiments, it should be noted that the fast trap mechanism is alεo useful in microproceεεorε whose inεtructionε are variable in length. In thiε caεe, it will be appreciated that the faεt trap vector addreεεeε be εeparated by enough εpace to accommodate at leaεt two of the εhortest instructionε available on the microprocessor, and preferably about 32 average-εized inεtructionε. Certainly, if the microprocessor includeε a return froia trap inεtruction, the vector addreεεeε εhould be εeparated by at leaεt enough εpace to permit that inεtruction to be preceded by at leaεt one other inεtruction in the handler. Also on dispatch to a trap handler, the proceεεor enterε both a kernel mode and an interrupted εtate. Conncurrently, 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 is stored in the prior PSR (PPSR) register. The kernel and interrupted states modes are repreεented by bitε in the proceεεor εtatuε regiεter (PSR) . Whenever the interrupted_εtate bit in the current PSR iε εet, the shadow regiεterε or trap regiεters RT[24] through RT[31], aε deεcribed above and aε εhown in Figure 7b, become viεible. 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) instruction. When the IEU 104 executes an RTT instruction, PCSR is restored to CSR register and PPSR register is restored to the PSR register, thereby automatically clearing the interrupt_state bit in the PSR register. The PF_PC SEL selector 390 alεo εelectε εpecial regiεter xPC in the εpecial register εet 412 aε the next addreεε from which to prefetch. xPC iε reεtored to either the MBUF PFnPC or the EBUF PFnPC aε appropriate, via incrementor 394 and buε 396. The deciεion aε to whether to reεtore xPC into the EBUF or MBUF PFnPC iε made according to the "procedure_in_j?rogress" bit of the PSR, once reεtored. It should be noted that the procesεor does not use the εame εpecial register xPC to εtore the return addreεε for both trapε and procedural inεtructionε. The return addreεε for a trap iε εtored in the εpecial regiεter xPC, as mentioned, but the addreεε to return to after a procedural instruction iε εtored in a different εpecial regiεter, uPC. Thuε, the interrupted εtate remains available even while the proceεεor iε executing an emulation εtream invoked by a procedural inεtruction. On the other hand, exception handling routineε εhould not include any procedural inεtructionε εince there is no εpecial regiεter to εtore an addreεε for return to the exception handler after the emulation εtream iε complete. _) Nesting ; Although certain processor εtatuε information iε automatically backed up on dispatch to a trap handler, in particular CSR, PSR, the return PC, and in a εenεe the "A" regiεter set ra[24] through ra[31], other context information is not protected. For example, the contents of a floating point εtatuε regiεter (FSR) iε not automatically backed up. If a trap handler intends to alter these regiεters, it muεt perform itε own backup. Becauεe of the limited backup which is performed automatically on a dispatch to a trap handler, nesting of traps is not automatically permitted. A trap handler εhould back up any deεired regiεterε, clear any interrupt condition, read any information necessary for handling the trap from the system 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 regiεterε, re-enable interruptε and execute the RTT inεtruction to return from the interrupt. If neεted trapε are to be allowed, the trap handler εhould be divided into firεt and εecond portionε. In the firεt portion, while interruptε are diεabled, the xPC εhould be copied, uεing a εpecial regiεter move inεtruction, and pushed onto the stack maintained by the trap handler. The addreεε of the beginning of the εecond portion of the trap handler should then be moved uεing the εpecial regiεter move inεtruction into the xPC, and a return from trap instruction (RTT) executed. The RTT removes the interrupted εtate (via the reεtoration of PPSR into PSR) and tranεferε control to the addreεε in the xPC, which now containε the addreεε of the second portion of the handler. The εecond portion may enable interruptε at thiε point and continue to proceεε the exception in an interruptable mode. It εhould be noted that the shadow registerε RT[24] through RT[31] are viεible only, in the firεt portion of this handler, and not in the εecond portion. Thus, in the second portion, the handler should preserve any of the "A" register values where these register values are likely to be altered by the handler. When the trap handling procedure is finished, it εhould reε ore all backed up registers, pop the original xPC off the trap handler εtack and move it back into the xPC εpecial register using a special register move instruction, and execute another RTT. This returns control to the appropriate instruction in the main or emulation instruction εtream. 6T List of Traps: The following Table I setε forth the trap numbers, prioritieε and handling modeε of trapε which are recognized in the preferred embodimentε: -69- The combined control and data path portions of IEU 104 are εhown in Figure 5. .The primary data path beginε with the instruction/operand data bus 124 from the IFU 102. Aε a data buε, immediate operands are provided to an operand alignment unit 470 and pasεed on to a regiεter file (REG ARRAY) 472. Regiεter data iε provided from the regiεter file 472 through a bypaεε unit 474, via a regiεter file output buε 476, to a parallel array of functional computing elements (Fϋ,^) 478 o- n ' via a diεtribution bus 480. Data generated by the functional unitε 478 0 _ n iε provided back to the bypaεε unit 474 or the regiεter array 472, or both, via an output buε 482. A load/εtore unit 484 completeε the data path portion of the IEU 104. The load/εtore unit 484 iε reεponεible 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 iε tranεferred by the load/εtore 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 diεtribution buε 480. The control path portion of the IEU 104 iε reεponεible for iεεuing, managing, and completing the proceεεing of information through the IEU data path. In the preferred embodimentε of the preεent invention the IEU control path iε capable of managing the concurrent execution of multiple instructions and the IEU data path provides for multiple independent data tranεferε between eεεentially all data path elementε of the IEU 104. The IEU control path operateε in reεponεe to inεtructionε received via the inεtruction/operand buε 124. Specifically, inεtruction εetε are received by the EDecode unit 490. In the preferred embodimentε of the present invention, the EDcode 490 receives and decodes both inεtruction setε held by the IFIFO master regiεterε 216, 224. The reεultε of the decoding of all eight inεtructionε iε variouεly provided to a carry checker (CRY CH R) unit 492, dependency checker (DEP CHKR) unit 494, regiεter renaming unit (REG RENAME) 496, inεtruction iεεuer (ISSUER) unit 498 and retirement control unit (RETIRE CTL) 500. The carry checker unit 492 receiveε decoded information about the eight pending instructionε from the EDecode unit 490 via control lineε 502. The function of the carry checker 492 iε to identify those oneε of the pending instructions that either affect the carry bit of the proceεεor εtatus word or are dependent on the εtate of the carry bit. Thiε control information is provided via control lineε 504 to the inεtruction issuer unit 498. Decoded information identifying the regiεterε of the regiεter file 472 that are uεed by the eight pending instructions as provided directly to the register 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 iε to determine which of the pending instructionε reference regiεters aε the deεtination for data and which instructions, if any, are dependant on any of those destination registers. Thoεe instructions that have register dependencies are identified by control signalε provided via the control lineε 508 to the regiεter rename unit 496. Finally, the EDecode unit 490 provideε control information identifying the particular nature and function of each of the eight pending inεtructions to the instruction iεεuer unit 498 via control lineε 510. The iεεuer unit 498 iε reεponεible for determining the data path resourceε, particularly of the availability of particular functional units, for the execution of pending inεtructions. In accordance with the preferred embodimentε of the architecture 100, inεtruction issuer unit 498 allows for the out-of-order execution of any of the eight pending inεtructions subject to the availability of data path resources and carry and register dependency conεtraintε. The register rename unit 496 provideε the inεtruction iεεuing unit 498 with a bit map, via control lineε 512 of thoεe inεtructionε that are εuitably unconstrained to allow execution. Instructions that have already been executed (done) and thoεe with regiεter or carry dependancieε are logically removed from the bit map. Depending on the availability of required functional units 478 0 _ n , the instruction isεuer unit 498 may initiate the execution of multiple inεtructionε during each system clock cycle. The εtatuε of the functional units 478 0 _ n are provided via a εtatuε bus 514 to the instruction issuer unit 498. Control signals for initiating, and εubsequently managing the execution of instructions are provided by the inεtruction issuer unit 498 on the control lines 516 to the register rename unit 496 and selectively to the functional units 478^. In reεponεe, the regiεter rename unit 496 provi eε regiεter εelection signals on a register file accesε control buε 518. The εpecific regiεterε enabled via the control εignalε 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 registers referenced by that particular inεtruction. A bypasε control unit (BYPASS CTL) 520 generally controls the operation of the bypaεε data routing unit 474 via control εignalε on control lineε 524. The bypass control unit 520 monitorε the status of each of the functional units 478- ^ . and, in conjunction with the register references provided from the register rename unit 496 via control lineε 522, determines whether data is to be routed from the register file 472 to the functional unitε 478-^ or whether data being produced by the functional units 478.^, can be immediately routed via the bypaεε unit 474 to the functional unit diεtribution buε 480 for uεe in the execution of a newly issued inεtruction εelected by the inεtruction isεuer unit 498. In either caεe, the inεtruction iεεuer unit 498 directly controlε the routing of data from the distribution bus 480 to the functional units 478 0 _ n by selectively enabling . pecific regiεter data to each of the functional units The remaining unitε 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 operateε to void or confirm the execution of out-of-order executed inεtructionε. Where an instruction has been executed out-of-order, that instruction can be confirmed or retired once all prior inεtructionε have alεo been retired. Baεed 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 provideε control εignalε on control lineε 534 coupled to the buε 518 to effectively confirm the reεult data εtored by the regiεter array 472 aε the reεult of the prior execution of an out-of-order executed inεtruction. The retirement control unit 500 provideε the PC increment/εize control εignalε on control lineε 344 to the IFD 102 as it retireε each inεtruction. Since multiple instructionε may be executed out-of-order, and therefore ready for εimultaneouε retirement, the retirement control unit 500 determineε a εize value baεed on the number of inεtructionε εimultaneouεly retired. Finally, where all instructionε of the IFIFO maεter regiεter 224 have been executed and retired, the retirement control unit 500 provideε 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 inεtructionε aε inεtructionε pending execution. The control flow control unit 528 performε 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 signal is similarly received via the control lines 538 from the done control unit 540. This done control εignal allows the control flow control unit 528 to identify when a conditional branch inεtruction is done at least to a point εufficient to determine a conditional control flow εtatuε. The control flow εtatuε result for the pending conditional branch instructions are stored by the control flow control unit 528 as they are executed. The data neceεεary to determine the conditional control flow instruction outcome iε obtained from temporary εtatuε regiεterε in the regieter array 472 via the control lineε 530. Aε each conditional control flow inεtruction iε executed, the control flow control unit provideε a new control flow reεult εignal on the control lineε 348 to the IFU 102. Thiε control flow result εignal preferably includeε two 8 bit vectorε defining whether the εtatus results, by respective bit position, of the eight potentially pending control flow instruction are known and the correεponding εtatuε reεult states, alεo given by bit position correεpondence. Lastly, the done control unit 540 is provided to monitor the operational execution εtate of each of the functional unitε lb^. Aε any of the functional unitε 78,^, signal completion of an instruction execution operation, the done control unit 540 provides a correεponding done control signal on the control lineε 542 to alert the register rename unit 496, inεtruction issuer unit 498, retirement control unit 500 and bypasε control unit 520. IEU Data Path Detail: The central element of the IEU data path iε the regiεter . file 472. Within the IEU data path, however, the preεent invention provideε for a number of parallel data pathε optimized generally for εpecific functionε. The two principal data pathε are integer and floating point. Within each parallel data path, a portion of the regiεter file 472 is provided to εupport the data manipulationε occurring within that data path, i) Register File Peteil; The preferred generic architecture of a data path regiεter file is shown in Figure 6a. The data path regiεter 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εtined for the regiεter array 564 iε typically firεt received by the temporary buffer 552 through a combined data input buε 558' ' . That is, 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 εelect and enable control εignalε provided on the control buε 518 εelect -the regiεter location for the received data within the temporary buffer 552. On retirement of an instruction that produced data εtored in the temporary buffer, control εignalε again provided on the control buε 518 enable the tranεfer of the data from the temporary buffer 552 to a logically correεponding regiεter within the regiεter file array 564 via the data bus 560. However, prior to retirement of the inεtruction, data stored in the registers of the temporary buffer 552 may be utilized in the execution of subsequent inεtructions by routing the temporary buffer εtored data to the output data εelector 556 via a bypass portion of the data bus 560. The selector 556, controlled by a control signal provided via the control bus 518 εelectε between data provided from the regiεterε of the temporary buffer 552 and of the regiεter file array 564. The reεulting 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 haε 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 bypaεε extenεion 558". In accordance with the preferred embodimentε of the present invention, each data path regiεter file 550 per itε two εimultaneous regiεter operations to occur. Thus, the input bus 558 provideε for two full regiεter width data valueε to be written to the temporary buffer 552. Internally, the temporary buffer 552 provideε a multiplexer array permitting the εimultaneouε routing of the input data to any two " regiεterε within the temporary buffer 552. Similarly, internal multiplexerε allow any five registerε of the temporary buffer 552 to be εelected to output data onto the buε 560. The regiεter file array 564 likewiεe includeε input and output multiplexerε allowing two regiεterε to be εelected to receive, on buε 560, or five to εource, via buε 562, reεpective data εimultaneouεly. Finally, the regiεter file output selector 556 iε preferably implemented to allow any five of the ten regiεter data values received via the buεeε 560, 562 to be εimultaneouεly output on the regiεter file output buε 564. The regiεter εet within -the temporary buffer iε generally εhown in Figure 6b. The regiεter εet 552' conεiεtε of eight single word (32 bit) registerε IORD, I1RD...I7RD. The regiεter εet 552' may alεo be used as a set of four double word registers IORD, IORD+1 (IORD4), I1RD, I1RD+1 (ISRDJ... I3RD, I3RD+1 (I7RD). In accordance with the present invention, rather than provide duplicate registers for each of the registerε within the register file array 564, the registerε in the temporary buffer register set 552 are referenced by the register rename unit 496 based on the relative location of the respective instructions within the two IFIFO maεter regiεterε 216, 224. Each instruction implemented by the architecture 100 may reference for output up to two registerε, or one double word regiεter, for the destination of data produced by the execution of the instruction. Typically, an instruction will reference only a single output register. Thuε, for an inεtruction two (I 2 ) of the eight pending inεtructions, positionally identified as shown in Figure 6C and that references a εingle output regiεter, 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ε uεed by a subεeguent instruction, for example, I 5 , the data stored in the I2RD register will be tranεferred out via the buε 560 and the reεultant data εtored back to the temporary buffer 552 into the regiεter identified as I5RD. Notably, inεtruction I 5 iε dependent on instruction I 2 . Inεtruction I s cannot be executed until the reεult data from I 2 iε available. However, aε can be εeen, inεtruction I s can execute prior to the retirement of inεtruction I 2 by obtaining itε required input data from the inεtruction I 2 data location of the temporary buffer 552'. Finally, as inεtruction I 2 iε retired, the data from the regiεter I2RD is written to the register location within the regiεter file array 564 aε determined by the logical poεition of the inεtruction at the point of retirement. That is, the retirement control unit 560 determines the address of the deεtination regiεterε in the regiεter file array from the regiεter reference field data provided from the EDecode unit 490 on the control • lineε 510. Once instructionε 1-^ have been retired, the values in I4RD-I7RD are εhifted into I0RD- I3RD simultaneous with a shift of the IFIFO unit 264. A complication ariseε where instruction I 2 provides a double word result value. In accordance with a preferred embodiment of the present invention, a combination of locations I2RD and I6RD is used to store the data resulting from instruction I 2 until that instruction 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 inεtructionε I M iε detected by the regiεter rename unit 496. Thiε allows the entire temporary buffer 552' to be used aε a single rank of double word regiεterε. Once instructionε 1,^, have been retired, the temporary buffer 552' can again be used aε two ranks of εingle word regiεterε. Further, the execution of any inεtruction I 7 iε held where a double word output regiεter iε required until the instruction haε been εhifted into a corresponding 1^ location. The logical organization of the regiεter file array 564 iε εhown in Figure 7a-b. In accordance with the preferred embodimentε of the preεent invention, the regiεter file array 564 for the integer data path conεiεtε of 40 32-bit wide regiεterε. Thiε set of registerε, conεtituting a regiεter εet "A", iε organized as a baεe register εet ra[0..23] 565, a top set of general purpose regiεterε ra[24..31] 566, and a εhadow regiεter εet of eight general purpoεe trap regiεters rt[24..31]. In normal operation, the general purpose registerε ra[0. 31] 565, 566 conεtituteε the active "A" regiεter εet of the regiεter file array for the integer data path. Aε shown in Figure 7b the trap registerε rt[24..31] 567 may be swapped into the active register set "A" to allow access along with the active baεe set of registers ra[0..23] 565. This configuration of the "A" regiεter set iε εelected upon the acknowledgement of an interrupt or the execution of an exception trap handling routine. Thiε εtate of the regiεter set "A" is maintained until expresεly returned to the εtate εhown in Figure 7a by the execution of an enable interruptε instruction or execution of a return from trap inεtruction. In the preferred embodiment of the preεent invention aε implemented by the architecture 100, the floating point data path utilizes an extended precision regiεter file array 572 aε generally εhown in Figure 8. The regiεter file array 572 conεiεtε of 32 regiεterε, rf[0..31], each having a width of 64 bitε. The floating point regiεter file 572 may also be logically referenced aε a "B" εet of integer registers rb(0..31]. In the architecture 100, this "B" εet of regiεterε iε equivalent to the low-order 32 bitε of each of the floating point regiεterε rf[0..31]. Repreεenting a third data path, a boolean operator regiεter εet 574 iε provided, as εhown in Figure 9, to εtore the logical reεult of boolean combinatorial operations. This "C" register εet 574 conεiεtε of 32 single bit registers, rc[0..31]. The operation of the boolean regiεter set 574 is unique in that the results of boolean operations can be directed to any instruction selected register of the boolean regiεter εet 574. Thiε iε in contrast to utilizing a εingle processor εtatuε word regiεter that εtores single bit flagε for conditions such ^ as equal, not equal, greater than and other simple boolean status values. Both the floating point register set 572 and the boolean register εet 574 are complimented by temporar buffers architecturally identical to the integer temporary buffer 552 shown in Figure 6b. The essential difference is that the width of the temporary buffer registers is defined to be identical to those of the complimenting regiεter file array 572, 574; in the preferred implementation, 64 bitε and one bit, reεpectively. A number of additional εpecial regiεterε are at leaεt logically preεent in the regiεter array 472. The regiεters that are phyεically preεent in the regiεter array 472, as εhown in Figure 7c, include a kernel εtack pointer 568, proceεεor εtate regiεter (PSR) 569, previouε procesεor state regiεter (PPSR) 570, and an array of eight temporary procesεor εtate regiεterε (tPSR[0..7j) 571. The remaining εpecial regiεterε are diεtributed throughout variouε partε of the architecture 100. The εpecial addreεε and data buε 354 iε provided to εelect and tranεfer data between the εpecial regiεterε and the "A" and "B" εets of regiεterε. A εpecial regiεter move inεtruction iε provided to εelect a regiεter from either the "A" or "B" regiεter εet, the direction of tranεfer and to specify the addreεε identifier of a special register. The kernel stack pointer regiεter and temporary proceεsor εtate regiεters differ from the other εpecial regiεters. The kernel εtack pointer may be acceεεed through execution of a εtandard register to register move instruction when in kernel εtate. The temporary proceεεor εtate regiεterε are not directly acceεεible. Rather, thiε array of regiεters iε uεed to implement an inheritance mechanism for propagating the value of the proceεsor state register for use by out-of-order executing inεtructionε. The initial propagation value iε that of the proceεεor εtate regiεter: the value provided by the laεt retired inεtruction. Thiε initial value iε propagated forward through the temporary proceεεor εtate regiεterε εo that any out-of-order executing inεtruction haε accesε to the value in the poεitionally correεponding temporary proceεεor εtate regiεter. The εpecific nature of an instruction defineε the condition code bitε, if any, that the inεtruction iε dependent on and may change. Where an inεtruction iε unconεtrained by dependencies, register or condition code as determined by the regiεter dependency checker unit 494 and carry dependency checker 492, the inεtruction can be executed out-of-order. Any modification of the condition code bitε of the proceεεor εtate register are directed to the logically corresponding temporary procesεor εtate regiεter. Specifically, only thoεe bitε that may change are applied to the value in the temporary proceεεor εtate regiεter and propagated to all higher order temporary proceεεor εtate regiεterε. Conεequently, every out-of- order executed inεtruction executeε from a proceεεor εtate register value modified appropriately by any intervening PSR modifying inεtructions. Retirement of an instruction only transfers the correεponding temporary proceεsor εtate regiεterε value to the PSR register 569. The remaining εpecial regiεterε are deεcribed in Table II. TABLE IT Special Reσisterε Special Move Reσ R/W Description: PC R Program Counters: in general, PCs maintain the next address of the currently executing program instruction εtream. IF_PC R/W IFU Program Counter: the IF_PC maintainε the preciεe next execution addreεs . PFnPCs R Prefetch Progran Counters: the MBUF, TBUF and EBUF PFnPCs maintain the next prefetch inεtruction addresses for the respective prefetch inεtruction εtreamε. uPC R/W Micro-Program Counter: maintains the addreεε of the instruction following a procedural instruction. This is the addresε of the firεt inεtruction to be executed upon return from a procedural routine. xPC R/W Interrupt/Exception Program Counter: holds the return addresε of an interrupt or and exception. The return addreεε is the addreεs of the IFPC at the time of the trap. TBR W Trap Baεe Regiεter: baεe addreεε of a vector table uεed for trap handling routine diεpatching. Each entry is one word long. The trap number, provided by Interrupt Logic Unit 363, iε uεed aε an index into the table pointed to by thiε addreεε. FTB W Faεt Trap Baεe Regiεter: baεe addreεε of an immediate trap handling routine table. Each table entry is 32 words and iε uεed to directly implement a trap handling routine. The trap number, provided by Interrupt Logic Unit 363, timeε 32 iε uεed as an offset into the table pointed to by this addreεε. PBR W Procedural Baεe Register: baεe 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 Proceεεor State Regiεter: maintainε the proceεεor εtatuε word. Status data bitε include: carry, overflow, zero, negative, proceεεor mode, current interrupt level, procedural routine being executed, divide by 0, overflow exception, hardware function enableε, procedural enable, interrupt enable. PPSR R/W Previouε Proceεεor State Regiεter: 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 as a εingle word. PCSR R/W Previous Compare State Regiεter: loaded from the CSR on successful completion of an inεtruction or when an interrupt or trap iε taken. 2 ) Integer Data Path Detail: The integer data path of the IEU 104, conεtructed in accordance with the preferred embodiment of the present invention, iε εhown in Figure 10. For purpoεes of clarity, the many control path connectionε to the integer data path 580 are not εhown. Thoεe connectionε are defined with reεpect to Figure 5. Input data for the data path 580 iε obtained from the alignment units 582, 584 and the integer load/εtore 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 buε 5S0 to a multiplexer 592. A second input to the multiplexer 592 iε the εpecial regiεter addreεε and data bus 354. Immediate operands obtained from the inεtruction stream are alεo obtained from the operand unit 570 via the data buε 594. Theεe values are again right justified by the alignment unit 584 before proviεion onto an output bus 596. The integer load/εtore unit 586 communicateε bi- directionally via the external data buε 598 with the CCU 106. Inbound data to the IEU 104 iε tranεferred by the integer load/εtore unit 586 onto the input data buε 600 to an input latch 602. Data output from the multiplexer 592 and latch 602 are provided on the multiplexer input buseε 604, 606 of a multiplexer 608. Data from the functional unit output buε 482' is alεo received by the multiplexer 608. Thiε multiplexer 608, in the preferred embodimentε of the architecture 100, provideε for two εimultaneous data paths to the output multiplexer buεeε 610. Further, the tranεfer of data through the ultiplexer 608 can be completed within each half cycle of the system clock. Since most inεtructionε implemented by the architecture 100 utilize a εingle deεtination register, a maximum of four inεtructionε can provide data to the temporary buffer 612 during each εyεtem clock cycle. Data from the temporary buffer 612 can be tranεferred to an integer regiεter file array 614, via temporary regiεter output buεeε 616 or to a output multiplexer 620 via alternate temporary buffer regiεter buses 618. Integer register array output buseε 622 permit the tranεfer of integer regiεter data to the multiplexer 620. The Output buεeε connected to the temporary buffer 512 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 εource regiεterε can be iεεued εimultaneouεly. The temporary buffer 612, regiεter file array 614 and multiplexer 620 allow outbound regiεter data tranεfers to occur every half εyεtem clock cycle. Thus, up to four integer and floating point instructions may be isεued during each clock cycle. The multiplexer 620 operates to εelect outbound regiεter data valueε from the regiεter file array 614 or directly from the temporary buffer 612. Thiε allowε out-of-order executed instructionε with dependencieε on prior out-of-order executed instructions to be executed by the IEU 104. Thiε facilitateε the twin goals of maximizing the execution through-put capability of the IEU integer data path by the out-of-order execution of pending inεtructionε while preciεely εegregating out- of-order data results from data reεultε produced by inεtructionε that have been executed and retired. Whenever an interrupt or other exception condition occurε that reguireε the preciεe εtate of the machine to be reεtored, the preεent invention allowε the data valueε preεent in the temporary buffer 612 to be εi ply cleared. The regiεter file array 614 iε therefore left to contain preciεely thoεe data valueε produced only by the execution of inεtructionε completed and retired prior to the occurrence of the interrupt or other exception condition. The up to five regiεter data valueε εelected during each half εyεtem clock cycle operation of the multiplexer 620 are provided via the multiplexer output buses 624 to an integer bypass unit 626. Thiε bypaεε unit 626 iε, in essence, a parallel array of multiplexerε that provide for the routing of data preεented at any of itε inputs to any of itε outputε. The bypaεε unit 626 inputε include the special register addreεεed 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 buseε 624, the load operand data from the integer load/εtore unit 586 via the double integer bus 600, the immediate operand value obtained from the alignment unit 584 via its output buε 596, and, finally, a bypaεε data path from the functional unit output bus 482. Thiε bypaεε data path, and the data buε 482, provides for the simultaneouε transfer of four register values per syεtem clock cycle. Data iε output by the bypass unit 626 onto an integer bypaεs buε 628 that iε connected to the floating point data path, to two operand data buεeε providing for the tranεfer out of up to five regiεter data valueε simultaneously, and a store data buε 632 that is uεed to provide data to the integer load/εtore unit 586. The functional unit diεtribution buε 480 iε implemented through the operation of a router unit 634. Again, the router unit 634 iε implemented by a parallel array of multiplexerε that permit five regiεter valueε received at itε inputε to be routed to the functional unitε provided in the integer data path. Specifically, the router unit 634 receiveε the five register data values provided via the buεeε 630 from the bypass unit 626, the current IF_PC addresε value via the addreεε buε 352 and the control flow offεet value determined by the PC control unit 362 and aε 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 regiεter data values received by the router unit 634 may be transferred onto the special register address and data bus 354 and to the functional unitε 640, 642, 644. Specifically, the router unit 634 iε capable of providing up to three regiεter operand valueε 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 instructionε could be εimultaneouεly iεεued to the functional units 640, 642, 644. , The preferred embodiment of the preεent invention provideε for three dedicated integer functional unitε, implementing respectively a programmable εhift function and two arithmetic logic unit functions. An ALUO functional unit 644, ALU1 functional unit 642 and shifter functional unit 640 provide respective output register data onto the functional unit buε 482'. The output data produced by the ALUO and shifter functional unit 644, 640 are alεo provided onto a shared integer functional unit bus 650 that is coupled into the floating point data path. A εimilar floating point functional unit output value data buε 652 iε provided fro the floating point data path to the functional unit output buε 482' . The ALUO functional unit 644 iε uεed alεo in the generation of virtual addreεε valueε in εupport of both the prefetch operationε of the IFU 102 and data operationε of the integer load/εtore unit 586. The virtual addreεε value calculated by the ALUO functional unit 644 iε provided onto an output buε 654 that connects to both the target addreεε buε 346 of the IFU 102 and to the CCU 106 to provide the execution unit physical addreεε , ,(EX PADDR) . A latch 656 iε provided to εtore the virtualizing portion of the addreεε produced by the ALUO functional unit 644. Thiε virtualizing portion of the addreεε iε provided onto an output bus 658 to the VMU 108. 3) Floating Point Data Path Detail: Referring now to Figure 11, the floating point data path 660 iε εhown. Initial data iε again received from a number of εources including the immediate integer operand buε 588, immediate operand buε 594 and the εpecial regiεter addreεε data buε 354. The final εource of external data is a floating point load/εtore unit 662 that iε coupled to the CCU 106 via the external data buε 598. The immediate integer operand iε received by an alignment unit 664 that functionε to right juεtify the integer data field before εubmiεεion to a multiplexer 666 via an alignment output data buε 668. The multiplexer 666 alεo receiveε the εpecial regiεter address data buε 354. Immediate operandε are provided to a second alignment unit 670 for right juεtification before being provided on an output buε 672. Inbound data from the floating point load/εtore unit 662 iε received by a latch 674 from a load data buε 676. Data fro the multiplexer 666, latch 674 and a functional unit data return buε 482" iε received on the inputε of a multiplexer 678. The multiplexer 678 provideε for selectable data pathε sufficient to allow two regiεter data valueε to be written to a temporary buffer 680, via the multiplexer output buseε 682, each half cycle of the εyεtem clock. The temporary buffer 680 incorporates a register ε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 valueε to be read from 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 buses 690. The multiplexer 688 also receiveε, via data buεeε 692, up to five regiεter data values from the floating point regiεter file array 684 εimultaneously. The multiplexer 688 functionε to εelect up to five regiεter data valueε for εimultaneouε transfer to a bypasε unit 694 via data buεeε 696. The bypaεε unit 694 also receiveε the immediate operand value provided by the alignment unit 670 via the data bus 672, the output data bus 698 from the multiplexer 666, the load data bus 676 and a data bypaεε extenεion of the functional unit data return buε 482". The bypaεε unit 694 operateε to εelect up to five εimultaneouε regiεter operand data values for output onto the bypaεε unit output buseε 700, a εtore data buε 702 connected to the floating point load/εtore unit 662, and the floating point bypaεε buε 636 that connectε to the router unit 634 of the integer data path 580. A floating point router unit 704 provideε for εimultaneouε selectable data pathε between the bypaεε unit output buεeε 700 and the integer data path bypaεε buε 628 and functional unit input buεeε 706, 708, 710 coupled to the reεpective functional unitε 712, 714, 716. Each of the input buεeε 706, 708, 710, in accordance with the preferred embodiment of the architecture 100, permitε the εimultaneouε transfer of up to three regiεter operand data valueε to each of the functional unit 712, 714, 716. The output buεeε 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 εhown in Figure 12. This data path 720 is utilized in support of the execution of essentially two types of instructions. The firεt type iε an operand co pariεon instruction where two operandε, εelected from the integer regiεter εetε, floating point regiεter 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 εubtraction operation by any of the ALU functional unitε 642, 644, 714, 716 with the resulting sign and zero status bitε being provided to a combined input εelector and compariεon operator unit 722. Thiε unit 722, in response to instruction identifying control εi nals received from the EDecode unit 490, εelectε the output of an ALU functional unit 642, 644, 714, 716 and combines the εign and zero bitε to extract a boolean compariεon reεult value. An output buε 723 allowε the reεultε of the comparison operation to be tranεferred εimultaneouεly to an input multiplexer 726 and a bypaεε unit 742. Aε in the integer and floating point data paths, the bypaεs unit 742 is implemented aε a parallel array of multiplexers providing multiple selectable data paths between the inputs of the bypass unit 742 to multiple outputs. The other inputs of the bypaεε unit 742 include a boolean operation reεult return data bus 724 and two boolean operands on data buses 744. The bypaεε unit 742 permitε boolean operandε representing up to two εimultaneouεly executing boolean inεtructionε to be tranεferred to a boolean operation functional unit 746, via operand buεeε 748. The bypaεε unit 746 alεo permitε tranεfer of up to two εingle bit boolean operand bitε (CFO, CF1) to be εimultaneouεly provided on the control flow result control lines 750, 752. The remainder of the boolean operation data path 720 includes the input multiplexer 726 that receives as itε inputε, the compariεon and the boolean operation reεult valueε provided on the compariεon reεult buε 723 and a boolean reεult bus 724. The bus 724 permitε up to two εimultaneouε boolean reεult bitε to be tranεferred to the multiplexer 726. In addition, up to two compariεon result bits may be transferred via the bus 723 to the multiplexer 726. The multiplexer 726 permits any two εingle bits preεented at the multiplexer inputε to be tranεferred via the multiplexer output buεeε 730 to a boolean operation temporary buffer 728 during each half cycle of the εyεtem clock. The temporary buffer 728 iε logically equivalent to the temporary buffer 752', aε shown in Figure 6b, though differing in two εignificant reεpectε. The firεt respect iε that each regiεter entry in the temporary buffer 728 conεiεtε of a εingle bit. The εecond diεtinction iε that only a εingle regiεter iε provided for each of the eight pending inεtruction εlotε, εince the reεult of a boolean operation iε, by definition, fully defined by a εingle reεult bit. The temporary buffer 728 provideε up to four output operand values εimultaneouεly. This allowε the εimultaneouε execution of two boolean inεtructions, each requiring access to two source regiεterε. The four boolean regiεter values 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 buεeε 734. The boolean regiεter file array 732, as logically depicted in Figure 9, is a εingle 32 bit wide data regiεter that permits any separate 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 system clock. The multiplexer 738, provides for any two pairs of boolean operands received at its inputs via the buseε 736, 740 " to be tranεferred onto the operand output buεes 744 to the bypass unit 742. The boolean operation functional unit 746 iε capable of performing a wide range of boolean operations on two εource valueε. In the case of compariεon inεtructionε, the εource values are a pair of operands obtained from any of the integer and floating point regiεter εetε and any immediate operand provided to the IEU 104, and, for a boolean inεtruction, any two of boolean register operands. Tables III and IV identify the logical compariεon operationε 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ε specified in the Tableε III-V repreεent a segment of the correεponding inεtructionε. The inεtruction also provides an identification of the εource pair of operand regiεterε and the deεtination boolean regiεter for εtorage of the correεponding boolean operation reεult. *rs = regiεter εource TABLE IV Floating Point Compariεon Condition rεl greater than rε2 rεl greater than or equal to' rs2 rεl leεs than rε2 rεl leεs than or equal to rε2 rεl unequal to rε2 rsl equal to rε2 unordered unordered or rεl greater than rε2 unordered, rsl greater than or equal to rs2 unordered or rsl^leεε than rε2 unordered, rsl leεε than or equal to rs2 unordered or rsl equal to rε2 reserved TABLE V Boolean Operation k bε = boolean εource regiεter B ) Load/Store Control Unit: An exemplary load/εtore unit 760 iε εhown in Figure 13. Although separately shown in the data pathε 580, 660, the load/store units 586 662 are preferrably implemented aε a single εhared load/store unit 760. The interface from a respective data path 550, 660 iε via an addresε buε 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 phyεical addreεε aε opposed to the virtual addresε utilized by the, IFU 102 and the remainder of the IEU 104. While the IFU 102 operateε on virtual addreεεeε, relying on coordination between the CCU 106 and VMU 108 to produce a phyεical addreεε, the IEU 104 requireε the load/εtore unit 760 to operate directly in a phyεical addreεs mode. Thiε requirement iε necessary to insure data integrity in the presence of out-of-order executed instructions that may involve overlapping physical address data load and store operations and in the presence of out-of-order data returnε from the CCU 106 to the load/εtore unit 760. In order to insure data integrity, the load/store unit 760 bufferε data provided by εtore inεtructionε until the εtore inεtruction iε retired by the IEU 104. Conεequently, εtore data buffered by the load εtore unit 760 may be uniquely preεent only in the load/εtore unit 760. Load instructionε referencing the εame phyεical addreεε aε executed but not retired store inεtructionε are delayed until the εtore inεtruction iε actually retired. At that point the εtore data may be tranεferred 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 phyεical addreεseε are provided from the VMU 108 onto the load/εtore addreεε buε 762. Load addreεεeε are, in general, εtored in load addreεε regiεterε 768^. Store addreεεes are latched into εtore addreεε regiεters 770 M . A load/store control unit 774 operates in reεponεe to control εignals received from the instruction iεεuer unit 498 in order to coordinate latching of load and εtore addresseε into the regiεterε 768^, 770-^ j . The load/store control unit 774 provides control εignals on control lineε 778 for latching load addreεses and on control lineε 780 for latching εtore addreεses. Store data is latched simultaneous with the latching of εtore addreεses in logically corresponding slots of the εtore data regiεter set 782 3 _ 0 . A 4x4x32 bit wide addresε comparator unit 772 is simultaneously provided with each of the addresseε in the load and εtore addreεε regiεterε 68-^, 770.^,. The execution of a full matrix addreεε compariεon during each half cycle of the εyεtem clock iε controlled by the load/store control unit 774 via control lineε 776. The existence and logical location of a load addreεs that atcheε a store addresε is provided via control signals returned to the load store control unit 774 via control lineε 776. Where a load addreεε iε provided from the VMU 108 and there are no pending stores, the load addresε is bypasεed directly from the buε 762 to an addreεε selector 786 concurrent with the initiation of a CCU load operation. However, where εtore data iε pending, the load addreεε will be latched in an available load addreεε latch 768-^. Upon receipt of a control εignal from the retirement control unit 500, indicating that the correεponding εtore data inεtruction iε retiring, the load/εtore control unit 774 initiateε a CCU data tranεfer operation by arbitrating, via control lineε 784 for acceεε to the CCO 106. When the CCU 106 signals ready, the load/εtore control unit 774 directε the εelector 786 to provide a CCU phyεical addreεs onto the CCU PADDR address bus 788. This address is obtained from the corresponding εtore regiεter 770 3 ^ via the addreεε buε 790. Data from the correεponding εtore data regiεter 782^, is provided onto the CCU data buε 792. Upon issuance of load inεtruction by the inεtruction iεεuer 498, the load εtore control unit 774 enables one of the load addreεε latcheε 768-,.-, to latch the requeεted load addreεε. The εpecific latch 768^ εelected logically correεpondε to the poεition of the load inεtruction in the relevant inεtruction εet. The inεtruction iεεuer 498 provideε the load/εtore control unit 774 with a five bit vector identifying the load inεtruction within either of the two poεεible pending inεtruction εets. Where the comparator 772 doeε not identify a matching store addreεε, the load addreεε iε routed via an addreεs buε 794 to the εelector 786 for output onto the CCU PADDR addreεε buε 788. Proviεion of the addreεε iε performed in concert with CCU requeεt and ready control εignalε being exchanged between the load/store control unit 774 and CCU 106. An execution ID value (ExID) is alεo prepared and issued by the load/εtore control unit 774 to the CCU 106 in order to identify the load requeεt when the CCU 106 subεequently returns the requeεted data including ExID value. Thiε ID value conεiεtε of a four bit vector utilizing unique bits to identify the respective load addreεε latch 768, j. 3 from which the current load requeεt iε generated. A fifth bit is utilized to identify the instruction εet that containε the load instruction. The ID value is thuε the εame as the bit vector provided with the load requeεt from the inεtruction iεεuer unit 498. On εubεequent εignal from the CCU 106 to the load/store control unit 774 of the availability of prior requeεted load data, the load/εtore control unit 774 enableε an alignment unit to receive the data and provide it on the load data buε 764. An alignment unit 798 operateε to right juεtify the load data. Simultaneouεly with the return of data from the CCU 106, the load/store control unit 774 receives the ExID value from the CCU 106. The load/store control unit 774, in turn, provideε a control εignal to the inεtruction iεεuer unit 498 identifying that load data iε being provided on the load data buε 764 and, further, returnε a bit vector identifying the load inεtruction for which the load data iε being returned. C) 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 preεent invention, and not exhauεtive of execution timing permutations. The timing diagram of Figure 14 shows a sequence of procesεor system clock cycles, P M . Each procesεor cycle beginε with an internal T Cycle, T 0 . There are two T cycleε per proceεεor cycle in a preferred embodiment of the preεent invention as provided for by the architecture 100. In procesεor cycle zero, the IFU 102 and the VMU 108 operate to generate a phyεical addreεε. The phyεical addreεε iε provided to the CCU 106 and an inεtruction cache access operation is initiated. Where the requeεted inεtruction εet iε preεent in the instruction cache 132, an instruction εet iε returned to the IFU 102 at about the mid-point of proceεεor cycle 5. one. The IFU 102 then manages the transfer of the instruction set through the prefetch unit 260 and IFIFO 264, whereupon the inεtruction set iε firεt preεented to the IEU 104 for execution. 1) EDecode Unit Detail: 0 The EDecode unit 490 receiveε the full inεtruction εet in parallel for decoding prior to the concluεion of proceεsor cycle one. The EDecode unit 490, in the preferred architecture 100, iε implemented as a pure combinatorial logic block that provides for 5 the direct parallel decoding of all Valid instructions that are received via the bus 124. Each type of instruction recognized by the architecture 100, including the εpecification of the instruction, regiεter requirementε and resource needs are identified in 0 Table VI. TABLE VI Instruction/Specifications Instruction Control and Operand Information* Move Regiεter Logical/Arithmetic Function Code: to Regiεter specifies Add, Subtract, Multiply, Shift, etc. Destination Register Set PSR only Source Regiεter 1 Source Regiεter 2 or Immediate conεtant value Register Set A/B εelect Move Immediate Destination Regiεter to Reciεter Immediate Integer or Floating Point conεtant value Regiεter Set A/B εelect Load/Store Operation Function Code: εpecifieε Register 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 Regiεter or Immediate conεtant value Regiεter Set A/B εelect Immediate Call Signed Immediate Diεplacement Control Flow Operation Function Code: εpecifies branch type and triggering condition Base Regiεter Index Regiεter, Immediate conεtant diεplacement value, or Trap Number Regiεter Set A/B select Special Register Operation Function Code: εpecifieε Move move to/from εpecial/integer regiεter Special Regiεter Addreεε 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/Deεtination Regiεter 5 Regiεter Set A/B εelect Boolean Functions Boolean Function Code: specifieε And, Or, etc. Deεtination boolean regiεter IC Source Regiεter 1 Source Regiεter 2 Regiεter Set A/B εelect Extended Procedure Procedure εpecifier: εpecifieε 15 addreεε offset from procedural base value ' Operation: value paεεed to procedure routine 20 Atomic Procedure Procedure εpecifier: εpecifieε addresε value * - instruction includeε theεe fieldε in addition to a field that decodes to identify the instruction. 25 The EDecode unit 490 decodes each instruction of an inεtruction εet in parallel. The reεulting identification of instructions, inεtruction functionε, regiεter references and function requirementε are made 30 available on the outputs of the EDecode unit 490. This information iε regenerated and latched by the EDecode unit 490 during each half processor cycle until all inεtructions in the instruction εet are retired. Thuε, information regarding all eight pending inεtructionε iε 35 conεtantly maintained at the output of the EDecode unit 490. Thiε information iε preεented in the form of eight element bit vectorε where the bitε or εub-fieldε of each vector logically correεpond to the phyεical location of the correεponding inεtruction within the two pending 0 inεtruction εetε. Thus, eight vectorε are provided via the control lines 502 to the carry checker 492, where each vector εpecifieε whether the correεponding inεtruction affects or is dependant on the carry bit of the processor εtatuε word. Eight vectorε are provided via the control lineε 510 to identify the ..specific nature of each inεtruction and the function unit requirements. Eight vectorε are provided via the control lineε 506 εpecifying the regiεter referenceε used by each of the eight pending inεtructionε. Theεe vectorε are provided prior to the end of proceεsor cycle one. 2 ) Carrv Checker Unit Detail: /The carry checker unit 492 operates in parallel with the dependency check unit 494 during the data dependency phase of operation εhown in Figure 14. The carry check unit 492 iε implemented in the preferred architecture 100 aε pure combinatorial logic. Thuε, during each iteration of operation by the carry checker unit 492, all eight inεtructionε are considered with respect to whether they modify the carry flag of the procesεor εtate regiεter. Thiε iε necessary in order to allow the out-of-order execution of instructions that depend on the state of the carry bit as εet by prior inεtructionε. Control εignalε provided on the control lineε 504 allow the carry check unit 492 to identify the εpecific inεtructionε that are dependant on the execution of prior inεtructionε with reεpect 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 inεtructionε. For thoεe inεtructions that do not modify the carry bit, the carry checker unit 492 propagates the carry bit to the next inεtruction forward in the order of the program inεtruction stream. Thus, an out-of-order executed inεtruction that modifieε the carry bit can be executed and, further, a εubεequent inεtruction that iε dependant on εuch an out-of-order executed instruction may alεo be allowed to execute, though subsequent to the inεtruction that modifieε the carry bit. Further, maintenance of the carry bit by the carry checker unit 492 facilitateε out-of-order execution in that any exception occurring prior to the retirement of those instructionε merely requireε the carry checker unit 492 to clear the internal temporary carry bit regiεter. Conεequentl , the proceεεor εtatuε regiεter iε unaffected by the execution of out-of-order executed inεtructions. The temporary bit carry regiεter maintained by the carry checker unit 492 iε updated upon completion of each out-of-order executed inεtruction. Upon retirement of out-of-order executed inεtructionε, 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εεor εtatuε regiεter. 31 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 lineε 506. Each regiεter reference iε indicated by a five bit value, εuitable for identifying any one of 32 regiεterε at a time, and a two bit value that identifieε the regiεter bank as located within the "A" , "B" or boolean regiεter εetε. The floating point regiεter εet iε eguivalently identified as the "B" register εet. Each inεtruction may have up to three register reference fieldε: two εource regiεter fields and one destination. Although some instructionε, most notably the move regiεter to regiεter instructionε, may specify a destination register, an instruction bit field recognized by the EDecode unit 490 may signify that no actual output data iε to be produced. Rather, execution of the inεtruction iε only for the purpoεe of determining an alteration of the value of the proceεεor ε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 register referenceε of instructions εubεequent in the program inεtruction εtream and deεtination regiεter references of relatively prior inεtructionε . A bit array iε produced by the data dependency checker 494 that identifieε not only which instructions are dependant on others, but also the registerε upon which each dependency arises. The carry and register data dependencies are identified εhortly after the beginning of the εecond proceεεor cycle. 41 Register Rename Unit Detail: The regiεter rename unit 496 receiveε the identification of the regiεter referenceε of all eight pending inεtructions via the control lineε 506, and regiεter dependencieε via the control lineε 508. A matrix of eight elementε iε alεo received via the control lineε 542 that identify thoεe inεtructionε within the current εet of pending instructionε that have been executed (done) . From this information, the regiεter rename unit 496 provides an eight element array of control εignals to the instruction issuer unit 498 via the control lines 512. The control information so provided reflects the determination made by the regiεter rename unit 496 aε to which of the currently pending instructions, that have not already been executed, are now available to be executed given the current εet of identified data dependencieε. The regiεter rename unit 496 receiveε a εelection control εignal via the lineε 516 that identifieε up to six inεtructionε that are to be simultaneously issued for execution: two integer, two floating point and two boolean. The regiεter rename unit 496 performs the additional function of selecting, via control signals provided on the bus 518 to the regiεter file array 472, the source regiεterε for acceεε in the execution of the identified inεtructions. Deεtination regiεterε for out- of-order executed inεtructions are εelected as being in the temporary bufferε 612, 680, 728 of the corresponding data path. In-order executed inεtructionε are retired on completion with reεult data being εtored through to the register fileε 614, 684, 732. The εelection of εource regiεterε dependε on whether the regiεter has been prior selected aε a deεtination and the correεponding prior inεtruction haε not yet been retired. In εuch an inεtance, the εource regiεter iε εelected from the correεponding temporary buffer 612, 680, 728. Where the prior inεtructioh haε been retired, then the regiεter of the correεponding regiεter file 614, 684, 732 iε εelected. Conεequently, the regiεter rename unit 496 operateε to effectively εubεtitute temporary buffer regiεter references for regiεter file regiεter referenceε in the caεe of out-of-order executed inεtructions. Aε implemented in the architecture 100, the temporary bufferε 612, 680, 728 are not duplicate regiεter structures of their corresponding regiεter file _..rayε. Rather, a εingle deεtination regiεter εlot iε provided for each of eight pending inεtructionε. Conεequently, the εubεtitution of a temporary buffer deεtination regiεter reference iε determined by the location of the correεponding inεtruction within the pending regiεter εetε . A εubεequent εource regiεter reference iε 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 regiεter iε readily determinable by the regiεter rename unit 496. 51 Instruction Isεuer Unit Detail: The inεtruction iεsuer unit 498 determineε the set of inεtructions that can be issued, based on the output of the register rename unit 496 and the function requirements of the inεtructionε as identified by the EDecode unit 490. The instruction isεuer unit 498 makeε thiε determination baεed on the εtatuε of each of the functional unitε 478,^ aε reported via control lineε 514. Thus, the instruction isεuer unit 498 begins operation upon receipt of the available set of instructions to iεεue from the regiεter rename unit 496. Given that a regiεter file acceεε iε required for the execution of each inεtruction, the inεtruction isεuer unit 498 anticipateε the availability of functional unit 478,^ that may be currently executing an instruction. In order to minimize the delay in identifying the inεtructions to be iεεued to the regiεter rename unit 496, the instruction isεuer unit 498 iε implemented in dedicated combinatorial logic. Upon identification of the inεtructionε to iεεue, the regiεter rename unit 496 initiateε a regiεter file acceεε that continues to the end of the third proceεεor cycle, P 2 . At the beginning of proceεsor cycle P 3 , the inεtruction iεεuer unit 498 initiates operation by one or more of the functional unitε 478^, εuch aε εhown aε "Execute 0", to receive and process εource data provided from the regiεter file array 472. Typically, moεt inεtructionε proceεεed by the architecture 100 are executed through a functional unit in a εingle proceεεor cycle. However, εome inεtructionε require multiple proceεεor cycleε to complete, εuch aε εhown aε "Execute 1", a εimultaneouεly iεεued inεtruction. The Execute zero and Execute 1 instructionε may, for example, be executed by an ALU and floating point multiplier functional units respectively. The ALU functional unit, aε εhown iε Figure 14, produceε output data within one proceεε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, Ε . The floating point multiply functional unit is preferably an internally pipelined functional unit. Therefore, another additional floating point multiply instruction can be issued in the next proceεsor cycle. However, the reεult of the firεt inεtruction will not be available for a data dependant number of processor cycles; the instruction ε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 instruction iεεuer unit 498 iε repeated. Conεequently, the εtatuε of the current εet of pending instructions aε well aε the availability εtate of the full εet of functional units 478^ are reevaluated during each proceεεor cycle. Under optimum conditionε, the preferred architecture 100 iε therefore capable of executing up to six inεtructionε per processor 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εtructionε. The occurrence of a trap condition requireε that the IEU 104 be cleared of all inεtructionε that have not yet been retired. Such a circumεtance may ariεe in reεponse 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 unitε 478-^ in reεponεe to an arithmetic fault, or, for example, the EDecode unit 490 upon the decoding of an illegal inεtruction. On the occurrence of the trap condition, the inεtruction iεεuer unit 498 iε reεponεible for halting or voiding all un- retired inεtructions currently pending in the IEU 104. All instructionε that cannot be retired εimultaneouεly will be voided. This result is esεential to maintain the precisenesε of the occurrence of the interrupt with respect to the conventional in-order execution of a program inεtruction εtream. Once the IEU 104 iε ready to begin execution of the trap handling program routine, the instruction iεεuer 498 acknowledgeε the interrupt via a return control εignal along the control lineε 340. Also, in order to avoid the posεibility that an exception condition relative to one inεtruction may be recognized baεed on a proceεεor εtate bit which would have changed before that inεtruction would have executed in a claεεical pure in-order routine, the inεtruction iεsuer 498 iε reεponsible for ensuring that all instructions which can alter the PSR (such as εpecial move and return from trap) are executed εtrictly in- order. Certain inεtructionε that alter program control flow are not identified by the IDecode unit 262. Inεtructionε of thiε type include εubroutine returnε, returnε from procedural inεtructionε, and returnε from trapε. The inεtruction iεεuer unit 498 provideε identifying control εignalε via the IEU return control lines 350 to the IFU 102. A correεponding one of the εpecial regiεterε 412 iε εelected to provide the IF_PC execution addreεε that existed at the point in time of the call inεtruction, occurrence of the trap or encountering of a procedural inεtruction. 61 Done Control Unit Detail: The done control unit 540 monitorε the functional unitε 478,^, for the completion εtatuε of their current operationε. In the preferred architecture 100, the done control unit 540 anticipateε the completion of operationε by each functional unit εufficient to provide a completion vector, reflecting the εtatuε of the execution of each instruction in the currently pending εet of instructions, to the regiεter rename unit 496, bypaεε control unit 520 and retirement control unit 500 approximately one half proceεεor cycle prior to the execution completion of an inεtruction by a functional unit 478.^,. Thiε allowε the inεtruction iεεuer unit 498, via the register rename unit 496, to conεider the inεtruction completing functional unitε as available resourceε for the next instruction issuing cycle. The bypaεε control unit 520 iε allowed to prepare to bypaεε data output by the functional unit through the bypaεε unit 474. Finally, the retirement control unit 500 may operate to retire the corresponding inεtruction simultaneous with the tranεfer of data from the functional unit 478 0 _ n to the regiεter file array 472. 71 Retirement Control Unit Detail: In addition to the inεtruction done vector provided from the done control unit 540, the retirement control unit 500 monitorε the oldeεt inεtruction set output from the EDecode output 490. Aε each inεtruction in inεtruction εtream order is marked done by the done control unit 540, the retirement control unit 500 directs, via control εignalε provided on control lines 534, the tranεfer of data from the temporary buffer εlot to the correεponding inεtruction εpecified register file register location within the register file array 47-2. The PC Inc/Size control εignalε are provided on the control lines 344 for each one or more instruction simultaneously retired. Up to four instructions may be retired per processor cycle. Whenever an entire instruction set has been retired, an IFIFO read control signal is provided on the control line 342 to advance the IFIFO 264. 81 Control Flow Control Unit Detail: The control flow control unit 528 operates to continuously provide the IFU 102 with information εpecifying whether any control flow inεtructions within the current set of pending instructions have been resolved and, further, whether the branch result is taken or not taken. The control flow control unit 528 obtains, via control lineε 510, an identification of the control flow branch inεtructionε 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 iε constrained by dependencies or iε now known. The regiεter referenceε provided via bus 518 from the regiεter rename unit 496 are monitored by the control flow control 528 to identify the boolean regiεter that will define the branch decision. Thuε, the branch deciεion may be determined even prior to the out-of-order execution of the control flow inεtruction. Simultaneouε with the execution of a control flow inεtruction, the bypaεε unit 472 iε directed by the bypaεε control unit 520 to provide the control flow reεultε onto control lineε 530, consisting of the control flow zero and control flow one 1 control lineε 750, 752, to the control flow control unit 528. Finally, the control flow control unit 528 continuouεly provideε two vectorε of eight bits each to the IFU 102 via control lineε 348. Theεe vectorε define whether a branch instruction at the corresponding logical location corresponding to, the bitε within the vectors have been resolved and whether the branch reεult iε taken or not taken. In the preferred architecture 100, the control flow control unit 528 is implemented aε pure combinatorial logic operating continuouεly in reεponεe to the input control εignalε to the control unit 528. 91 Bypass Control Unit Detail: The inεtruction iεεuer unit 498 operateε cloεely in conjunction with the bypaεε control unit 520 to control the routing of data between the regiεter file array 472 and the functional unitε 478^. The bypaεε control unit 520 operateε in conjunction with the regiεter file acceεε, output and εtore phaεes of operation εhown in Figure 14. During a regiεter file acceεε, the bypass control unit 520 may recognize, via control lines 522, an access of a destination register within the regiεter file array 472 that iε in the proceεε of being written during the output phaεe of execution of an inεtruction. In thiε caεe, the bypaεε control unit 520 directε the εelection 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 instruction iεεuer unit 498 via control lines 542. IV. 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 repreεentation -of a virtual addreεs iε εhown partitioned into a εpace identifier (sID[31:28] ) , a virtual page number (VADDR[27: 14] ) , page offεet (PADDR[13:4] ) , and a requeεt ID (rID[3:0]). The algorithm for generating a phyεical addreεs is to use the space ID to select one of 16 registerε within a εpace table 842. The contentε of the εelected εpace register in combination with a virtual page number iε uεed aε an addreεε for acceεεing a table look aεide buffer (TLB) 844. The 34 bit addreεs operates as a content addresε tag uεed to identify a correεponding buffer regiεter within the buffer 844. On the occurrence of a tag match, an 18 bit wide regiεter value iε provided aε the high order 18 bitε of a phyεical addreεε 846. The page offεet and requeεt ID are provided aε the low order 14 bits of the physical addreεε 846. Where there is a tag miεε in the table look aεide buffer 844, a VMU iεs iε signalled. Thiε requireε the execution of a VMU faεt trap handling routine that implementε conventional haεh algorithm 848 that acceεεeε a complete page table data εtructure maintained in the MAU 112. Thiε page table 850 contains entries for all memory pageε currently in uεe by the architecture 100. The haεh algorithm 848 identifieε thoεe entrieε in the page table 850 neceεεary to εatiεfy the current virtual page tranεlation operation. Thoεe page table entrieε are loaded from the MAU 112 to the trap regiεterε of register set "A" and then tranεferred by -special register move inεtructions to the table look aside buffer 844. Upon return from the exception handling, routine, the instruction giving rise to the VMU miss exception iε re-executed by the IEU 104. The virtual to physical addreεε translation operation should 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 εignify that the VMU 108 iε available for an addreεε translation. In the preferred embodiement, the VMU 108 iε alεwayε ready to accept IFU 120 tranεlation requeεtε. Both the IFU and IEU 102, 104 may pose requests via control line 328, 804. In the preferred architecture 100, the IFU 102 has priority access to the VMU 108. Consequently, only a single busy control line 820 is provided to the IEU 104. Both the IFU and IEU 102, 104 provide the εpace ID and virtual page number fieldε to the VMU control logic 800 via control lineε 326, 808, respectively. In addition, the IEU 104 provideε a read/write control εignal via control εignal 806 to define whether the addreεε iε to be uεed for a load or εtore operation as neceεεary to modify memory access protection attributes of the virtual memory referenced. The space ID and virtual page fieldε of the virtual addreεε are paεεed to the CAM unit 802 to perform the actual tranεlation operation. The page offεet and ExID fieldε are eventually provided by the IEU 104 directly to the CCU 106. The phyεical page and request ID fields are provided on the addreεε lines 836 to the CAM unit 802. The occurrence of a table look aεide buffer match iε signalled via the hit line and control output lineε 830 to the VMU control logic unit 800. The resulting phyεical addreεε, 18 bitε in length, iε provided on the addreεε output lineε 824. The VMU control logic unit 800 generateε the virtual memory miεε and virtual memory exception control εignals on lines 334, 332 in response to the hit and control output control εignalε on lineε 830. A virtual memory translation miεs is defined as failure to match a page table identifier in the table look aεide buffer 844. All other tranεlation errors are reported aε virtual memory exceptions. Finally, the data tableε within the CAM unit 802 may be modified through the execution of εpecial regiεter to regiεter move instructionε by the IEU 104. Read/write, regiεter εelect, reεet, load and clear control signalε are provided by the IEU 104 via control lineε 810, 812, 814, 816, 818. Data to be written to the CAM unit regiεterε iε received by the VMU control logic unit 800 via the addreεε buε 808 coupled to the εpecial addreεε data buε 354 from the IEU 104. Thiε data iε tranεferred via buε 836 to the CAM unit 802 εimultaneouε with control εignalε 828 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 aε required during the dynamic operation of the architecture 100 including read out for εtorage aε required for the handling of context εwitcheε defined by a higher level operating εyεtem. ___. Cache Control Unit: The control on data interface for the CCU 106 iε εhown in Figure 17. Again, εeparate interfaceε are provided for the IFU 102 and IEU 104. Further, logically εeparate interfaceε are provided by the CCU 106 to the MCU 110 with respect to instruction and data trεnεfers. The IFU interface consistε of the phyεical page addreεε provided on addreεε lineε 324, the VMU converted page addreεε aε provided on the addreεε lineε 824, and request IDs as transferred separately on control lineε 294, 296. A unidirectional data transfer bus 114 is provided to tranεfer an entire inεtruction set 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 phyεical addreεε buε 788. The requeεt ExIDε are εeparately provided from and to the load/εtore unit of the IEU 104 via control lines 796. An 80 bit wide bidirectional data bus is provided by the CCU 106 to the IEU 104. However, in the preεent preferred implementation of the architecture 100, only the lower 64 bitε are utilized by the IEU 104. The availability and support within the CCU 106 of a full 80 bit data trans ' fer buε iε provided to support subε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, eεtabliεhed via requeεt, buεy, ready, read/write and with control εignalε 784 is εubεtantially the εame aε the correεponding control εignalε utilized by the IFU 102. The exception being the proviεion of a read/write control εignal to differentiate between load and εtore operationε. The width control signals specify the number of byteε being tranεferred during each CCU 106 acceεε by the IEU 104; in contraεt every acceεs of the instruction cache 132 is a fixed 128 bit wide data fetch operation. The CCU 106 implements a subεtantially conventional cache controller function with reεpect to the εeparate inεtruction and data cacheε 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 provides for the storage of 1024 32 bit wide words of data. Inεtruction and data requeεts that cannot be immediately εatiεfied from the contentε of the inεtruction and data cacheε 132, 134 are paεsed on to the MCU 110. For inεtruction cache misses, the 28 bit wide phyεical addreεs iε provided to the MCU 110 via the addreεε buε 860. The request ID and additional control signalε for coordinating the operation of the CCU 106 and MCU 110 are provided on control lineε 862. Once the MCU 110 has coordinated the necessary read acceεε of the MAU 112, two consecutive 64 bit wide data transferε are performed directly from the MAU 112 through to the inεtruction cache 132. Two tranεferε are required given that the data buε 136 iέ, in the preferred architecture 100, a 64 bit wide buε. Aε the requeεted data iε returned through the MCU 110 the requeεt ID maintained during the pendency of the requeεt operation iε alεo returned to the CCU 106 via the control lineε 862. Data tranεfer operationε between the data cache 134 and MCU 110 are εubεtantially the εame aε inεtruction cache operationε. Since data load and εtore operationε may reference a εingle byte, a full 32 bit wide phyεical addreεε iε provided to the MCU 110 via the addreεε buε 864. Interface control εignalε and the requeεt ExID are tranεferred via control lineε 866. Bidirectional 64 bit wide data tranεferε are provided via the data cache buε 138. VI. Modularity of Desiσn Aε mentioned above, the microproceεsor architecture 100 iε deεigned in a modular fashion for eaεy re-deεign to a different microproceεsor architectural εpecification. Figure 18 εhowε the architecture of Figure 1 divided into a front end portion 1010 and a back end portion 1012. The VMU 10c and the IPU 1008, conεiεting of the IFU 102 and the IEU 104, make up the front end portion 1010, and the CCU 106 and MCU 110 are in the back end portion 1012. Figure 19 εhows how the modular architecture of Figure 18 can be eaεily modified to implement a different microproceεεor architecture. In thiε architecture 100', a new front end 1010' iε deεigned for uεe with the εame back end 1012 aε in the architecture 100. The front end 1010' includeε a new IPU 1008' and a new VMU 108', and handles a completely different inεtruction εet from that implemented by the architecture 100. For example, whereaε the architecture 100 iε conεidered a RISC deεign, the architecture 100' emulateε a CISC microproceεεor deεign. For example, the architecture 100' may emulate the Intel 80486 architecture and inεtruction εet. The inεtruction εets for the architectures 100 and 100' are completely different, and in fact whereaε instructionε in the architecture 100 are fixed at four byteε each, inεtructionε in the architecture 100' are of variable length. In addition, whereaε IPU 1008 doeε not have εegmentation facilitieε, the IPU 1008' doeε. There may be many other differenceε between the front end portion 1010 and the front end portion 1010', but the back end portionε 1012 remain the εame. The port by which each of the front ends 1010 and 1010' communicate with the back end 1012 haε a clear, well-defined protocol previouεly deεcribed. It can be seen that the modular design technique permits two or more icroproceεεorε having εubstantially different architectures and inεtruction εetε to be deεigned in much less time than would be necesεary if each microproceεsor was designed anew. It is to be understood that while the foregoing discloεure 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 first modular microprocessor architecture, for uεe with memory, comprising on a single chip: a memory interface portion including -a firεt port and first means for fetching information from εaid memory in responεe to instruction fetch requests received over said first port and returning εaid fetched information over εaid firεt port; and a firεt instruction proceεεor portion coupled to εaid firεt port, including firεt meanε for providing instruction fetch requests over said first port and first means for processing information returned over said first port aε. inεtructionε of a firεt inεtruction εet, εaid firεt port having well-defined control and data εignalε and a well-defined protocol εuch that a εecond microproceεεor can . be deεigned uεing εubεtantially said εame memory interface portion and a second instruction processor portion which includeε εecond means for processing information returned over εaid first port as instructions of a second inεtruction εet. 2. Apparatuε according to claim 1, wherein εaid memory interface portion iε capable of returning fetched information over said firεt port in an order different from the order in which it receives instruction fetch requestε, wherein said first meanε for providing inεtruction fetch requeεtε compriεeε firεt meanε for providing firεt instruction fetch addresses and corresponding firεt requeεt IDs, and wherein εaid first means for fetching and returning returnε fetched information in correεpondence with the firεt requeεt IDs to which the fetched information is responεive. 3. Apparatuε according to claim 1, wherein εaid memory interface portion further includeε a εecond port, εecond meanε for fetching information from εaid memory in reεponεe to data fetch requeεtε received over εaid εecond port and returning εaid fetched information over εaid εecond port, and for writing information from εaid εecond port to εaid memory in response to data write requestε received over εaid εecond port, and wherein εaid firεt inεtruction proceεεor portion iε further coupled to said second port and further includes second means for providing data read and write requestε over εaid second port in responεe to εaid instructions returned over said first port, said εecond port also having well-defined control and data signalε and a well-defined protocol. 4. Apparatuε according to claim 2, wherein εaid memory interface portion iε capable of returning fetched information over εaid εecond port in an order different from the order in which it receiveε data fetch requeεtε, wherein εaid εecond means for providing data read and write requeεtε compriεeε εecond meanε for providing εecond data fetch addreεεeε and correεponding εecond requeεt IDε, and wherein εaid εecond meanε for fetching and returning returnε fetched information in correεpondence with the εecond request IDε to which the fetched information iε reεponεive. 5. Apparatuε according to claim 1, wherein εaid memory interface portion iε capable of returning fetched information over εaid firεt port in an order different from the order in which it receiveε inεtruction fetch requeεtε, wherein εaid firεt meanε for providing inεtruction fetch requests compriεeε firεt meanε for providing firεt inεtruction fetch addreεeeε and correεponding firεt requeεt IDε, and wherein εaid firεt meanε for fetching and returning returnε fetched information in correspondence with the first request IDε to which the fetched information iε reεponεive. 6. Apparatus according to claim 1, wherein said memory interface portion compriεeε a cache control unit coupled to said first port and a memory and I/O control unit coupled between said cache control unit and εaid memory. 7.. Apparatuε according to claim 1, further compriεing a virtual memory unit having a third port coupled to εaid firεt inεtruction processor portion and means for performing virtual-to-phyεical memory addresε tranεlationε in reεponεe to translation requestε received over εaid third port, εaid firεt instruction proceεεor portion further including third meanε for providing virtual-to-phyεical addresε tranεlation requeεtε over εaid third port and firεt meanε for generating εaid virtual addreεεeε in reεponεe to εaid instruction^, εaid third port having well-def ned control and data εignalε and a well-defined protocol such that a third microproceεεor can be deεigned uεing εubεtantially the εame virtual memory unit as said firεt microproceεεor and uεing a third inεtruction proceεεor portion which includeε third means for generating εaid virtual addreεεes in reεponεe to εaid instructionε, εaid third means for generating being different from εaid firεt means for generating. 8. Apparatuε according to claim 7, wherein εaid virtual memory unit further includeε third meanε for returning εaid tranεlated phyεical addreεεeε over εaid third port. 9. Apparatuε according to claim 7, wherein εaid virtual memory unit further compriεeε a fourth port coupled to said memory interface portion, and fourth means for providing εaid tranεlated phyεical addreεεes over εaid fourth port, εaid fourth port having well- defined control and data εignalε and a well-defined protocol. 10. The combination of firεt and εecond microproceεεorε, each formed on a reεpective εingle chip, and each for uεe with memory, εaid firεt microproceεεor compriεing: a memory interface portion including a firεt port, firεt means for fetching firεt information from said memory in response to instruction fetch requestε received over said first port and returning said fetched first information over said firεt port; and a firεt inεtruction proceεεor portion coupled to εaid firεt port and including firεt means for providing inεtruction fetch requeεtε over εaid firεt port and firεt meanε for proceεεing information returned over εaid firεt port aε inεtructionε of a firεt inεtruction εe ' t, and wherein εaid second microprocesεor compriεeε: a memory interface portion including a εecond port, εecond meanε for fetching εecond information from εaid memory in reεponεe to inεtruction fetch requeεtε received over εaid εecond port and returning εaid fetched εecond information over εaid second port; and a second instruction proceεεor portion coupled to said εecond port and including second meanε for providing inεtruction fetch requeεts over said second port and εecond means for processing information returned over εaid εecond port aε inεtructionε of a εecond inεtruction εet, wherein said • firεt instruction proceεεor portion iε substantially different from εaid second inεtruction procesεor portion and εaid first memory interface portion iε εubεtantially the εame aε said second memory interface portion.

Inventors: GARG SANJIV, HAGIWARA YASUAKI, LAU TE-LI, LENTZ DEREK J, MIYAYAMA YOSHIYUKI, NGUYEN LE TRONG, TRANG QUANG H, WANG JOHANNES, GARG, SANJIV, HAGIWARA, YASUAKI, LAU, TE-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: G06F15
IPC codes: G06F9, G06F12, G06F15